MSDN Blogs
  • WarNov Developer Evangelist

    Windows 8 te hace la vida más fácil

    • 48 Comments

    Veamos en esta cortísima demo de 5 minutos, las características más importantes de Windows 8, que a nosotros como desarrolladores nos han de importar, para poderlas aprovechar a la hora de generar nuestras apps.

    image
  • WarNov Developer Evangelist

    Por qué Windows Phone no transmite Archivos por Bluetooth?

    • 2 Comments

    La tecnología de Bluetooth está basada en algo conocido como perfiles. Cada perfil sirve para desempeñar una función de Bluetooth. Por ejemplo hay un perfil llamado A2DP que permite emitir Audio a través del bluetooth y además controlar la reproducción del mismo: Siguiente Canción, Anterior, Pausar, stop, Volumen. Este perfil viene en Windows Phone y por eso es posible por ejemplo conectarlo al radio de mi auto y controlar toda la reproducción de la música que tengo allí a través de Bluetoothpor medio de la pantalla de mi estéreo.

    El perfil de transferencia de archivos no está presente en Windows Phone y esto principalmente obedece a que de esta manera se protege al usuario de que le transfieran programas dañinos a través de este medio, porque este perfil no permite limitar el tipo de archivos transmitidos. Es por eso que la única forma de transferir archivos permitidos es a través de Zune (fotos, videos, música) y descargados de internet: (documentos de office, PDFs, además de los ya mencionados).

  • WarNov Developer Evangelist

    Caller Information: Quién me llamó?

    • 1 Comments

    Una de las inclusiones que más me ha gustado en el Framework 4.5, es la adición de mecanismos que nos permiten identificar información acerca de quién llamó un método de nuestro código, en tiempo de ejecución.

    Así pues, la información que se puede obtener comprende el path del archivo que contiene el código que hizo el llamado, la línea dentro de ese archivo y el nombre del miembro que hizo el llamado. Obviamente toda esta información nos hace mucho sentido cuando hablamos de hacer tracing, depuración y diagnóstico de nuestras aplicaciones.

    La forma de obtener esta información es muy sencilla, a través de nuevos atributos que son aplicados como parámetros opcionales con un valor por defecto, dentro del método que queremos inspeccionar. Estos atributos todos se encuentran dentro del namespace System.Runtime.CompilerServices

    En la siguiente aplicación de consola de ejemplo, observamos cómo podemos usar estos nuevos atributos para obtener información acerca de quién llamó un método:

    using System;
    using System.Runtime.CompilerServices;
    
    
    namespace ConsoleApplication2
    {
        class Program
        {
            static void Main(string[] args)
            {
                WriteMessage("Mensaje de Trazado");
            }
    
            private static void WriteMessage(string message,
                [CallerMemberName] string caller="",
                [CallerLineNumber] int lineNumber=0,
                [CallerFilePath] string path = "")
            {
                Console.WriteLine
                    ("Mensaje:{0}\nLlamado:{1}\nArchivo:{2}\nLínea {3}",
                    message,
                    caller,
                    path,
                    lineNumber);
                Console.ReadLine();
            }
        }
    }

    El resultado de la ejecución es como sigue:

    image

    Como se observa, este mecanismo nos ha permitido tener información muy específica de quién llamó determinado método, sin necesidad de alterar la forma en que se llamó el método, pues los parámetros que tienen la información de caller son opcionales, de manera que es transparente para la línea de código que llama al método.

    Aunque la información del caller demuestra ser muy útil para la depuración, existe un uso colateral muy interesante sobretodo para el mundo de las apps, donde el binding es muy usado. Esto lo veremos en mi siguiente post.

  • WarNov Developer Evangelist

    Copiando Archivos al Isolated Storage de Windows Phone

    • 0 Comments

    Copiar archivos al Isolated Storage de Windows Phone no es tan sencillo como crear nuevo contenido allí.

    Copiar en este contexto, significa tomar algún archivo que esté almacenado en nuestro proyecto como contenido por ejemplo y luego pasarlo al Isolated Storage. Las situaciones en que esto hace sentido, son por ejemplo cuando queremos tener imágenes para los tiles, o para mostrar como contenido estático formateado en Web a través del WebBrowser Control de WP.

    Como ejemplo aquí trato de escribir un mapa de bits obtenido de los contenidos del proyecto

    var bitImage = new BitmapImage();
    bitImage.CreateOptions = BitmapCreateOptions.None;
    bitImage.UriSource = new Uri("Images/car.png", UriKind.Relative); 
    using (var store = IsolatedStorageFile.GetUserStoreForApplication())
    {
                   
        using (var st = new IsolatedStorageFileStream(
            WOW.passingCar.ImgUrl, FileMode.Create, FileAccess.Write, store))
        {
    
            WriteableBitmap wbmp = new WriteableBitmap(bitImage);
            wbmp.SaveJpeg(st, 173, 173, 0, 100);
        }
    }
    

    Pero por seguridad y como su nombre lo indica, el Isolated Storage ha de tener su propio puntero de datos. De manera que si intentamos hacer que el reader que leyó el archivo escriba sobre el Isolated Storage, entonces se nos producirá la siguiente excepción: (NullReferenceException was unhandled. Invalid Pointer)

    image

    Tenemos entonces que proceder a un accionar un poco más elaborado:

    byte[] data;
    StreamResourceInfo sr = Application.GetResourceStream(new Uri("Images/car.png",
    UriKind.Relative)); using (BinaryReader br = new BinaryReader(sr.Stream)) { data = br.ReadBytes((int)sr.Stream.Length); } using (BinaryWriter bw = new BinaryWriter(store.CreateFile
    (WOW.passingCar.ImgUrl))) { bw.Write(data); bw.Close(); }
                        
    Como se nota, es necesario recurrir a unos procedimientos un poco más básicos en los que recurrimos a los BinaryReader y BinaryWriter. Parece un poco complejo, pero es necesario, dada la naturaleza del Isolated Storage.
  • WarNov Developer Evangelist

    APPS: Depurando un error de navegación desde un Tile

    • 0 Comments

    Tanto Windows Phone como Windows 8 tienen la capacidad de poder adicionar un tile primario y uno secundario al inicio del teléfono o la tablet. Cuando se hace tap sobre alguno de estos tiles, se genera una navegación hacia alguna página o vista dentro de la app.

    Pero en ocasiones al tratar de lanzar la app desde un tile, la app abre y de inmediato se cierra. Esto es obviamente causado por un error en la forma en que programamos la navegación o en el estado que se encuentra la app.

    En condiciones normales pondríamos un breakpoint y chequearíamos que sucede; pero dado que estamos lanzando la app desde el inicio, esto quiere decir el el debugger ya no está anclado al proceso de ejecución de la app, así que no podemos hacer depuración.

    Cómo proceder entonces para detectar el error?
    Una alternativa muy que traigo de mis batallas en la Web, sencillamente consiste en manipular el evento de error no manejado en la clase principal de la ejecución... en Web, esta era la Global.asax.cs y en las apps es App.xaml.cs. Por ejemplo en Windows Phone tenemos dentro de esta clase el manejador del evento:

        private void Application_UnhandledException(object sender, 
            ApplicationUnhandledExceptionEventArgs e)
        {
            if (System.Diagnostics.Debugger.IsAttached)
            {
                // An unhandled exception has occurred; break into the debugger
                System.Diagnostics.Debugger.Break();
            }
            var storage = IsolatedStorageFile.GetUserStoreForApplication();
            using (var writer = new StreamWriter(new IsolatedStorageFileStream(
                "LastError1.txt", FileMode.CreateNew, storage)))
            {
                writer.Write(DateTime.Now.ToLongTimeString() + "\n\n");
                writer.Write(WOW.HistoryTracker.ToString());
                writer.Write(e.ExceptionObject.Message);
            }
        }
    

    Como se observa, lo que hice fue adicionalmente a las líneas de debugging, adicionar una pequeña rutina que copia el contenido de la última excepción a un archivo en el Isolated Storage, que queda como si de caja negra de avión se tratará, con las evidencias de lo que pasó antes de que el avión (la app) se estrellara. De esta manera podríamos por ejemplo poner pistas dentro del código que se escribieran en el archivo para saber en donde está el error. Por ejemplo, podemos tener un StringBuilder global que vaya acumulando la historia de hasta donde se llegó y luego descargue todo su contenido en el archivo. De hecho, podemos usar directivas de preprocesador, para estructurar más el asunto:

    #if DEBUG
    
                if (WOW.HistoryTracker == null)
                {
                    WOW.HistoryTracker = new System.Text.StringBuilder();
                    WOW.HistoryTracker.AppendLine("I was Null");
                }
                WOW.HistoryTracker.AppendLine("Directive is working.");
    #endif
    

    Luego sencillamente descargamos el contenido del isolated storage a una carpeta en el sistema de archivos convencional, y revisamos:

    image

    de esta manera ya podemos saber qué nos hace falta arreglar para que la app se lance bien por ejemplo desde un tile secundario.

  • WarNov Developer Evangelist

    Capturando imágenes con la webcam en WinRT

    • 0 Comments

    Antiguamente, capturar imágenes de la webcam con .net era todo un pain. Había que acceder al api de Windows 32 a través de [DLLImport], establecerlos puntos de entrada a función, simuladores de apuntadores y escribir montones de código.

    Hoy en día, la computación no es solo de PC. También es de dispositivos móviles. Y los dispositivos móviles vienen llenos de dispositivos. Y nosotros developers, necesitamos acceder a esos dispositivos de una manera muy sencilla. Con WinRT hemos pensado en ello y usando tecnología de avanzada como async (en este post explico de qué se trata async) hemos logrado que sea una tarea muy sencilla y en este video, les muestro cómo es de fácil acceder a la webcam para capturar una fotografía y las configuraciones que debemos hacer a nuestra app para que funcione correctamente.

    Observemos la ventaja de la inclusión de async contra Windows Phone, donde tendríamos que usar EventHandlers que nos complican un poco el asunto:

     

    image
  • WarNov Developer Evangelist

    Modificando los Settings de una aplicación Windows desde el código

    • 0 Comments

    En ocasiones es necesario ajustar la configuración de una app. por ejemplo, configurar cuál va a ser el directorio de trabajo, o qué colores quiere el usuario para la interfaz, etc.

    Las aplicaciones .net tienen un archivo llamado app.config (o web.config en el caso de las aplicaciones web), que puede contener estas configuraciones.

    Por lo general esas configuraciones se hacen a mano en el caso de las aplicaciones web. Pero en ocasiones es necesario que estas configuraciones se modifiquen desde el mismo código.

    System.Configuration contiene todas las herramientas para lograrlo, pero es una API que tiene muchísimas funcionalidades para manejar la configuración de las aplicaciones. Por eso puede resultar fácil perderse tratando solo de hacer unas sencillas manipulaciones en el archivo de settings.

    Aquí muestro de una forma sencilla cómo buscar un valor de llave de configuración de una aplicación Windows. Si no existe, cómo agregarlo y luego cómo modificarlo.

        //Objeto de configuración
        var config=ConfigurationManager
    .OpenExeConfiguration(ConfigurationUserLevel.None); //Búsqueda de un setting en particular var pathSettings = config.AppSettings.Settings["MusicPath"]; //Si está en nulo, es porque no se encuentra.
    //Entonces lo agregamos
    if (pathSettings == null) config.AppSettings.Settings
    .Add("MusicPath",ci.MusicPath); //Si no, ya está agregado, entonces lo modificamos else pathSettings.Value = newValue; //Grabamos la configuración en disco de nuevo. config.Save();

     

    Es necesario operar de esta manera, dado que intentar por ejemplo config.AppSettings.Settings["MusicPath"]=newValue; no es legal de acuerdo a la accesibilidad que se le ha dado a este indexador.

  • WarNov Developer Evangelist

    Git para .NET

    • 0 Comments

    Git es un administrador de código fuente muy famoso en el mundo del Open Source, que ha venido desplazando al hijo de Apache, Subversion. Git  ha tenido una altísima difusión, dadas sus principales características de poder funcionar totalmente offline y de ser supremamente ágil y veloz en los branches gracias a su acercamiento a través de Snapshots de versiones en vez de deltas. Es completamente descentralizado. Solo se requiere conexión para hacer merge de los cambios en un servidor externo (en el lenguaje Git esto se conoce como push), o para obtener una última versión externa (pull).

    Creado en 2005 por Linus Torvalds para satisfacer la necesidad del control de versiones que tenía el propio Linux, tan popular se ha vuelto este administrador escrito mayormente en C y de código abierto, que en el mundo .net también ha comenzado a incursionar y de manera similar, herramientas y servicios .net ya han comenzado a darle soporte. Por ejemplo los WebSites de Windows Azure ahora soportan que desde Git se pueda hacer push directamente, de manera que sitios por ejemplo escritos en PHP se pueden publicar a la nube de inmediato, sin salirse de Git. De hecho, los SDKs que tiene Windows Azure para Linux y MAC, son de código abierto y están hospedados en el servidor de Git,  GitHub. De la misma manera, cualquier solución .net y en general cualquier archivo puede ponerse en Git para hacer su control de versiones.

    Existe una versión de Git para Windows que por defecto soporta manejo a través de la consola tradicional de Windows o de un bash que instala específicamente para que todo sea más a la usanza Unix. Sobre esta versión también se han desarrollado varios clientes Windows como tal.

    Explorando varios de esos clientes, el oficial de Git visual para Windows es muy lindo y nos recuerda el metro style de Zune y que por si fuera poco se instala con Click Once (o algo supremamente parecido).

    image

    Con estas herramientas podemos controlar nuestros repositorios de Git que para nosotros usuarios de Windows, no son más que folders con los proyectos que manejamos.

    Sin embargo, si ustedes son como yo que cuando estamos desarrollando en .net, no nos queremos salir de allí, existen numerosos plugins que nos permiten conectar VS directamente a Git. Pero si son aún más obstinados (como yo también) y no les gusta tener un montón de botones por todo lado y quieren usar Git en modo consola desde VS (realmente pienso que una de las grandes ventajas de Git y de SVN es la gran versatilidad que adquieren cuando se están trabajando desde consola) , en ese caso hay un conjunto de operaciones que nos permitirá integrar Git a PowerShell y obviamente, esto nos habilita de inmediato tenerlo en la consola de NuGet que es un sistema administrador de paquetes .net Open Source basado en consola, que además brinda otras muchas ventajas dado que como deberían saber está altamente integrado a PowerShell.

    De manera que aprovechando un encapsulamiento de Git que hizo dahlbyk para PowerShell llamado posh-git, podemos desde dentro de Visual Studio operar con NuGet sin necesidad de tener que salirnos a la consola o a otro cliente.

    Así que ya tenemos instalado Git en nuestra máquina Windows (sí, aún Windows 8). Lo que sigue entonces es hacer un clone de posh-git. Esto se puede hacer desde la consola de Windows, desde el Bash o desde la aplicación visual. Con ese clone, se estarán descargando una copia de la versión actual de ese proyecto con todas sus fuentes, a la carpeta en la que se encuentren ubicados en el momento de ejecutar el comando.

    image

    En este ejemplo observamos como habiendo creado una carpeta para proyectos en Git en la ruta c:\git (o donde ustedes quieran) nos ubicamos allí con el bash y creamos una nueva carpeta para descargar la copia y ubicándonos dentro de ella ejecutamos el clone del proyecto en la dirección https://github.com/dahlbyk/posh-git.git y luego observando el contenido vemos que existe el script install.ps1 que es el que nos proveerá la integración completa con PowerShell para mostrar el estado de los branches, y tab completition para mayor agilidad.

    Para poder ejecutar este script es necesario configurar PowerShell para que pueda ejecutar scripts.

    image

    Por ejemplo al consultar aquí en mi PowerShell veo que puedo ejecutar scripts remotos firmados. Pero podría ser que estuvieran restringidos. En este caso, hemos de darle permisos de RemoteSigned o Unrestricted. Para hacerlo, se debe abrir PowerShell con permisos de administrador y ejecutar:

    Set-ExecutionPolicy RemoteSigned –Confirm

    Luego ejecutamos install.ps1 y listo!

    De esta manera, ya podemos ir a nuestra consola de NuGet en Visual Studio (2010 o 2012) y proceder a trabajar con Git sin salirnos de allí:

    image

    Este pantallazo es sacado de VS2012RC con la Consola de Administración de Paquetes abiertas y trabajando con Git. Obsérvese cómo me ubico en el nuevo proyecto que quiero incluir en el controlador de versiones. Allí uso todo el poder de PowerShell para escribir el archivo de exclusiones de Git (no todos los archivos van al control de versiones. Por ejemplo los ejecutables y obj). Esta función podría parametrizarse para poder ejecutarla con las rutas correctas para cada proyecto. Luego de haber escrito el archivo de exclusiones y de haberlo revisado, agrego mi proyecto a Git con un sencillo git init que operará sobre la carpeta actual. Ya con el repositorio listo, le agrego la carpeta con todos los fuentes WNexter  y después de esto para chequear reviso con git status y vemos como lista todos los archivos puestos en stage (listos para ser confirmados).

Page 1 of 1 (8 items)