MSDN Blogs
  • WarNov Developer Evangelist

    Windows 8 RTM Dev Machine

    • 2 Comments

    Tal vez ustedes ya hayan leído un post parecido a este aquí en mi blog, en el que enseñaba a dejar lista una máquina con Windows 8 RP para desarrollar todo lo que tradicionalmente se desarrolla con Visual Studio mas Windows Phone, Windows Azure y WinRT Apps.

    Pues bien, consideren este post como una actualización del mismo, para aquellos que ya tienen la última versión de Windows 8 (RTM) y la última de Visual Studio 2012, dado que el hecho de que tengamos las versiones finales, no significa que los tools que añadimos a Visual Studio para desarrollar para Azure o para Phone estén listos. La idea, es que estos últimos estén listos no más tarde que el día de GA (Disponibilidad General) de Windows 8 que es el 26 de octubre.

    Efectivamente, si instalamos Windows 8 RTM y luego VS2012, ya tendremos listo el ambiente para Desarrollo WinForms, Web WinRT y otros. Pero ni Phone ni Azure estarán listos. Es preferible preparar la máquina primero para Azure antes de Phone.

    La forma para poder continuar desarrollando para Azure y Phone es la siguiente:

    Azure

    1. Instalar Win8 RTM
    2. Instalar VS2012 RTM
    3. Abriendo un nuevo proyecto de tipo Cloud en VS2012 como ya es costumbre cuando no tenemos Azure, nos aparecerá un link para ir a descargar lo necesario a través del WebPI (Web Platform Instaler). Pero aquí puede pasar que nos ocurre un error que nos dice que se deben desinstalar todas las versiones previas al RTM de VS2012. Cuando cerramos este mensaje de error nos aparece la ventana que vemos a continuación:

    azureen8

    Esto no es el acabose sin embargo…. solo basta con seguir los “Direct Download Link”. Uno por uno y en orden. Al final, ya podremos desarrollar en Azure. Recuerden que por ahora solo está disponible el framework 4.0 para Azure. Así que Deben seleccionarlo en la lista cuando vayan a crear un Nuevo proyecto.

     

    Phone

    Tengan en cuenta que el SDK 7.1 solo está disponible con Visual Studio 2010.

    Así que pueden instalar todo el VS2010 o la versión express para Phone. Yo recomiendo lo segundo, pues se instala automáticamente con el SDK y no ocupa tanto espacio solo para Phone, pues el resto de funcionalidades andan correctamente en VS2012.     

     

    1. Instalar Win8 RTM
    2. Instalar VS2012 RTM
    3. Instalar la última versión de Games for Windows – LIVE. Esto es requerido para poder desarrollar juegos con XNA para WP7, dado que Windows 8 requiere archivos más nuevos que los que vienen con el SDK 7.1
    4. Instalar Windows Phone SDK 7.1 (Incluye gratuitamente Visual Studio Express for Windows Phone 7)
      1. En este paso, puede que el sistema pida instalar antes el Service Pack 1 de VS2010. Luego de esto ya se podrá instalar el SDK 7.1 Sí: Se puede instalar el service pack de VS2010 sin tener el VS2010 instalado.
    5. Instalar el patch 7.1.1
    6. Instalar Zune
    7. Desarrollar en WP7!!!
  • WarNov Developer Evangelist

    This is for Developers…

    • 2 Comments

    Esto es para los developers...
    los geeks,
    los nerds,
    los hackers...

    Aquellos que ven las cosas,
    de manera diferente.

    Ellos no tienen reglas que los aten.
    Y no tienen respeto por los estados establecidos.

    Trabajan en las noches,
    inician compañías,
    se sientan solos...
    con sus audífonos... porque están ocupados
    porque están ocupados...
    cambiando
    el mundo...

    Ellos inventan

    Codifican,
    exploran,
    inspiran


    Empujan la internet hacia adelante

    Depronto esllos estén,
    locos...
    de lo contrario como podrían estar al frente de una pantalla vacía
    y ver una obra de arte....
    o al frente de miles de líneas de código,
    y ver el futuro

    Mientras unos los ven como geeks,
    en realidad son genios...


    Porque aquellos que pueden crear magia...
    con código,
    son quellos que algún día,
    dominarán el mundo.

    Wistia
  • WarNov Developer Evangelist

    WindowsRT + Telerik

    • 2 Comments

    En mi experiencia de evangelización muy pero muy temprana en Windows 8, he visto que una de las principales falencias de la plataforma WindowsRT, es la inexistencia de controles para presentar información estadística tales como pie, scatt, lines, así como controles avanzados con autocomplete y en general todos esos a los que ya estamos acostumbrados en Web, Silverlight y Phone, gracias a los trabajos de terceros como Infragistics y Telerik entre muchos otros.

    Es una gran falencia, pues muchas apps quieren presentar a los usuarios información tipo Dash Board y requieren de este conjunto de controles para funcionar más adecuadamente liberando de trabajo muy pesado al desarrollador.

    Afortunadamente, Telerik anunció y efectívamente liberó en Beta los controles para Metro Style Apps. Estos están disponibles tanto para XAML como para HTML5+JS (Aunque a hoy algunos tienen ambas versiones, otros solo están disponibles para uno u otro enfoque, encontrándose más en este momento para HTML5).

    El instalador de estos controles se puede bajar a modo de evaluación desde aquí. Y una vez instalados en sus máquinas con Windows 8 y Visual Studio 2012 RC, se pueden hacer desarrollos como el que les muestro a continuación en el siguiente video, usando XAML.

    Como lo mencioné en el video, en el Framework 4.5 hay una interesante nueva característica llamada Caller Information que nos ha servido para construir este ejemplo. Si desea saber más de ella, visite este post donde la explico mejor, y luego este otro donde la implemento.

    Espero en un siguiente post mostrar un ejercicio similar, pero con HTML5.

  • WarNov Developer Evangelist

    INotifyPropertyChanged sin quemar nombre de propiedad

    • 0 Comments

    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.

    En las apps es muy frecuente enlazar datos a vistas a través de paradigmas como MVVM. Y este enlace de datos requiere de clases que soporten notificación de cambios en las propiedades, de manera que la interfaz siempre permanezca sincronizada con los valores a los que está ligada y que se encuentra mostrando.

    Es así como si tenemos una clase del Modelo, destinada a ligarse a una vista bien sea a través de un controlador o de una clase VistaModelo, lo más común es que queramos que implemente  INotifyPropertyChanged con el fin de que se incluya el evento de tipo PropertyChangedEventHandler que se dispara cada vez que una propiedad cambia.

    Esto se logra de la siguiente manera:

    class Person:INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;
    
        string _name;
        public string Name
        {
            get { return _name; }
            set 
            {
                _name = value;
                NotifyPropertyChanged("Name");
            }
        }
    
        int _age;
        public int Age
        {
            get { return _age; }
            set 
            { 
                _age = value;
                NotifyPropertyChanged("Age");
            }
        }
    
        private void NotifyPropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, 
    new PropertyChangedEventArgs(propertyName)); } } }

    Como observamos, siempre nos toca poner como parámetro de NotifyPropertyChanged el nombre de la propiedad en un string. Esto puede generar algunos problemas sobretodo a la hora del refactoring tras cambiar el nombre de alguna propiedad, pues dado que estos parámetros son strings, el refactoring no cambiará automáticamente estos valores y además no podríamos detectar el error en tiempo de compilación, sino que obtendríamos una excepción difícil de descifrar en tiempo de ejecución si cambiamos por ejemplo Name por SecondName.

    Para evitar hacer estas referencias quemadas como strings, podemos aprovechar el hecho de que el Framework 4.5 incluye información del caller. Así pues, lo único que hacemos es citar el nombre del miembro que hizo el llamado que provocó el cambio en la propiedad. En este caso, ese nombre, es precisamente el nombre de la propiedad que se está modificando, así que independientemente de que cambie, siempre se referenciará la propiedad adecuada:

    class Person:INotifyPropertyChanged
        {
            public event PropertyChangedEventHandler PropertyChanged;
    
            string _name;
            public string Name
            {
                get { return _name; }
                set 
                {
                    _name = value;
                    NotifyPropertyChanged();
                }
            }
    
            int _age;
            public int Age
            {
                get { return _age; }
                set 
                { 
                    _age = value;
                    NotifyPropertyChanged();
                }
            }
    
            private void NotifyPropertyChanged(
    [
    CallerMemberName] string propertyName="") { if (PropertyChanged != null) { PropertyChanged(this,
    new PropertyChangedEventArgs(propertyName)); } } }

    Como se observa, ya no es necesario quemar el nombre de la propiedad, dado que CallerMemberName representará ese nombre en el parámetro propertyName que al ser opcional, no requiere ser llamado por nosotros, sino que es llenado por el servicio de compilación. Esta es una práctica que espero tendrá una amplia difusión en las apps de Windows 8 y de Windows Phone 8.

  • 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

    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

    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

    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

    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

    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

    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).

  • 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

    SQL Azure Internals

    • 0 Comments
    SQL Azure, la propuesta de base de datos relacional como servicio que ofrece Microsoft desde Windows Azure tiene varias diferencias con las implementaciones convencionales de SQL Server, a pesar de que para los usuarios finales el uso es prácticamente el mismo.

    Veremos en este video post, realmente cómo está compuesto SQL Azure. En dónde realmente se almacenan nuestras bases de datos. Cuál es el respaldo que ofrece SQL Azure a nuestra información. Cómo se logra un 99.9% de disponibilidad en bases de datos en la nube. Por qué Microsoft no nos cobra los logs, por qué el máximo tamaño de una DB por el momento es de 150GB, cuáles son las configuraciones de hardware de un servidor SQL Azure y muchas otras dudas que seguro hemos tenido alrededor de este tema.

  • WarNov Developer Evangelist

    SQL Azure BACPAC - DB BACKUP en la nube

    • 1 Comments
    UPDATE: Estas instrucciones son para el antiguo portal de administración de Windows Azure en Silverlight. Para las últimas instrucciones sobre el Nuevo portal de Administración Windows Azure, visite este post
     

    El formato de archivo BACPAC, se refiere a un nuevo tipo de archivo que contiene tanto el esquema, como los datos de una base de datos.

    En el portal de Windows Azure, en la sección de Import and Export, existe una opción para generar un archivo BACPAC o para consumirlo, a través de Export e Import respectivamente:


    image


    Para crear un copia instantánea de la DB, escogemos dicha DB y le decimos exportar. Esta operación requiere una cuenta de almacenamiento de Windows Azure para guardar esa copia BACPAC en el blob storage. En este caso, la ruta del blob ha de ser suministrada por ejemplo http://micuenta.blob.core.windows.net/bacpacs/backupjunio En este caso, la cuenta de almacenamiento se llama micuenta, el container se llama bacpacs y el archivo o blob como tal se llama backupkjunio.

    Luego de especificar la cuenta, comienza a generarse la copia. Este es un proceso asíncrono, cuyo estado se puede consultar entrando a la opción de Status:

    image

    Si la DB no es tan grande, esta operación se siente casi que inmediata.image

    Una vez creada la copia, podemos importar. En este caso, ubicándonos sobre el servidor al que queremos agregarle la DB a importar; damos el nuevo nombre para la DB, el tamaño (mayor o igual al anterior), citamos la url en la que quedó el BACPAC, lo seleccionamos y comenzamos la recreación de la DB. Este proceso también es asícrono y su estado se puede confirmar de la manera ya descrita.

    image

    Lo mejor: Estas operaciones son susceptibles a ser automatizadas gracias al API de REST para acceder a los servicios de BACPAC; de esta forma, podemos programar los backups de nuestras DBs, y estos quedarán almacenados en el blob storage de Azure, que vale un centavo de dólar la giga al mes.

  • WarNov Developer Evangelist

    Moviendo Servidores de SQL Azure entre suscripciones

    • 0 Comments

    Liberando una de mis apps de Windows Azure a producción, me encontré con la necesidad de mover todos los datos que tenía en un servidor de SQL Azure de una de mis suscripciones de prueba, a una de producción.

    Venía poco animado, porque me implicaría generar los scripts de recreación de las dbs que allí tenía y luego además, mover los datos.

    Cuál sería mi grata sorpresa, cuando encontré que desde el panel de administración de bases de datos del portal de Windows Azure, se puede mover todo un server desde una suscripción a otra solo oprimiendo un botón!!

    image


    Como se puede apreciar en la imagen, solo es necesario hacer click en "Move Server"y luego escoger la suscripción a la que deseamos hacer el movimiento.

    Esto nos mueve de inmediato el servidor a la nueva cuenta, sin que quede offline ni un segundo y sin cambiarle el nombre! Esto es genial, porque si habían clientes conectados, estos no percibirán el cambio. Además, esos clientes no deberán ser actualizados, pues la cadena de conexión sigue idéntica.

    El único cambio, es que ahora el servidor es responsabilidad de la nueva suscripción y por ende, los costos generados ya no aplican a la anterior, sino a ésta.

  • WarNov Developer Evangelist

    Debugging de Windows Phone Apps con Fiddler

    • 0 Comments

    Para quienes no lo conocen, Fiddler es un impresionante aplicativo gratuito creado por un colega de Microsoft: Eric Lawrence. Es usado básicamente para capturar tráfico HTTP y si lo deseas, modificarlo. Sin embargo, posee decenas de utilidades más relacionadas con el tráfico HTTP; esto es útil para hacer depuración de aplicaciones que se conectan a servicios web, o aplicaciones web como tal.

    He encontrado supremamente útil por ejemplo, usar Fiddler para hacer depuración de un par de Apps que estaba construyendo y que consumían servicios de Windows Azure, pues Fiddler se puede configurar también para que escuche las transmisiones HTTP originadas por el emulador de Windows Phone. De esta manera, puedo ver claramente cuáles son los requests que está haciendo mi app, y qué es lo que se está retornando desde la Web. Por ejemplo aquí pude ver que el servicio de Windows Azure al que estaba accediendo la app ya no existía:

    image


    Para configurar Fiddler para el emulador de Windows Phone, has de tener la última versión y luego configurarle de esta manera:


    1. Tools->Fiddler Options
    2. Connections tab -> Allow remote computers to connect -> OK
    3. Escribir este comando en la caja de QuickExec (Cuadro de texto en la esquina inferior izquierda de Fiddler):
    prefs set fiddler.network.proxy.registrationhostname NOMBREDETUMAQUINA
    4. Cerrar y reiniciar Fiddler
    5. Reinicia el emulador y ya podrás hacer análisis de las comunicaciones HTTP que se originan desde el mismo Smile

  • WarNov Developer Evangelist

    Durabilidad de nombres de servicio en Windows Azure

    • 0 Comments

    Cuando creamos servicios en Windows Azure que usan WebRoles o WorkerRoles, hemos de especificar un nombre para estos servicios.

    Este nombre debe cumplir con las reglas para nombres de dominio, pues esta será la forma en que accedamos a ellos.

    A estos nombres de servicios podemos asignarle el dominio que queramos del cual seamos propietarios después de haberlo comprado por ejemplo en GoDaddy. Esto se logra a través de un sencillo cambio en la configuración del registro del dominio en la herramienta del proveedor del mismo.

    A veces sucede que tenemos un servicio establecido con un nombre dado y luego creamos otro servicio y queremos que este otro servicio reemplace al primero con nombre y todo. Obviamente esto nos lleva a pensar que tenemos que eliminar el servicio original y desplegar el nuevo y asignarle el nombre que ya habíamos definido.

    Cuando arrancó Windows Azure, cuando eliminábamos un servicio, el nombre quedaba "ocupado" hasta por varios días. De esta manera el reemplazo no se podía hacer de inmediato.

    Hoy en día si borras un servicio, el nombre del mismo queda INMEDIATAMENTE disponible para que puedas poner un servicio en su reemplazo si así lo deseas. De esta manera, se ofrece una gran ventaja al desarrollador que puede reemplazar sus servicios sin demora, manteniendo los nombres que están esperando los clientes que se han construido basados en dicho servicio.

  • WarNov Developer Evangelist

    The All New Windows Phone 8!

    • 6 Comments

    image

    Windows Phone 7 ya ha abierto un gran camino para lo que hoy conocemos como Windows Phone 8. Ya tenemos 100.000 apps (y contando) en el Marketplace y desde Microsoft agradecemos a todos los desarrolladores en el mundo que han colaborado para lograrlo (en Colombia hemos puesto nuestro granito de arena con cerca de 400 apps hasta ahora. Por otro lado, observando los ratings de Smart Phones en Amazon, de los 9 primeros puestos, mejor calificados por los consumidores en el mundo, 7 obedecen a Windows Phone 7 y hago énfasis en que los tres primeros puestos son ocupados por teléfonos con nuestro sistema operativo.

    Este, ha sido el mes en el que yo como Developer Evangelist, he recibido más información de novedades, que en todo el tiempo que llevo disfrutando en Microsoft. Primero, las novedades sin precedentes de Windows Azure que ahora también es IaaS. Luego la formidable Surface y ahora,  Windows Phone 8 (WP8).

    Nuevo Kernel Unificado

    El cambio que determina la mayor parte de novedades en nuestra plataforma, es la unificación del kernel de WP8, dentro de la familia NT. Esa unificación permite por ejemplo que drivers creados para PCs, slates y tablets, sean compatibles también con el teléfono.

    Multicore

    También como novedad trae el soporte a IPV6 y otra gran consecuencia nos trae que podemos soportar teóricamente hasta 64 núcleos de procesamiento. De hecho, los primeros aparatos WP8, vendrán con dual core, para ofrecer una experiencia de usuario más rápida y fluida que la que se tiene hoy en día. .

    Más resolución

    Esto nos lleva automáticamente a otra gran novedad. La inclusión de otras dos resoluciones adicionales a la tradicional 800x480. Tendremos aparatos con resoluciones HD y WHD, para ofrecer imágenes de una realidad sin precedentes. Lo mejor de todo, es que los desarrolladores no tendrán que lidiar con estos cambios, pues sus apps se renderizarán correctamente en estas resoluciones sin cambios adicionales.

    Soporte Nativo

    La unificación de kernel (que es el mismo usado por ejemplo en WindowsRT) obviamente nos trae también la oportunidad de desarrollar natívamente para WP8. I mean, usando C y C++. Unan esto por ejemplo a Direct3D y entonces podrán esperar en el corto plazo, juegos como Halo y Assassins Creed para WP8. En realidad tendremos un poder de renderización y animación propio de cualquier consola de juegos de alto nivel.

    Multitasking – VoIP

    image

    Estas mejoras nos permiten tener más poder con los procesos de multitarea. Especialmente con tecnologías como VoIP y Video Chat (Skype). Por ejemplo, ahora podremos observar como cuando tenemos una llamada de este tipo activa, podemos seguir ejecutando otras tareas en nuestro aparato sin ninguna interrupción. Y por ejemplo si estamos usando manos libres, el flujo de sonido de la llamada VoIP será redireccionado a esos dispositivos.

    Games - Direct3D

    El soporte nativo además, abre las puertas a que entornos como Unity3D (game engine en el que programamos usando C# o Boo y producimos juegos para múltiples plataformas como Windows, MAC, Android, IPad, IPhone, etc) puedan evolucionar para poder ofrecer la experiencia unificada de creación de juegos también para WP8 y que por ejemplo apps nativas creadas para IOS sean fácilmente portadas también a nuestra plataforma. Obviamente la portabilidad de código entre WinRT y WP8 será total y sólo tendremos que fijarnos en cambios relativos al form factor de los dispositivos.

    Y ya que mencioné a C y C++ como una alternativa para desarrollar sobre WP8, les cuento que tenemos otras dos alternativas: el ya muy conocido XAML + (C# o VB) y HTML5 a través del WebControl o de entornos como PhoneGap.

    IE10 + HTML 5

    Hablando de HTML5, en Windows Phone 8, ya vendrá la última versión de nuestro browser: Internet Explorer 10. Con exactamente el mismo motor de renderización de la versión de PC y la capacidad de ejecutar el HTML5 de manera nativa obteniendo unos resultados inigualables en cuanto a velocidad y fluidez en la renderización, sin dejar de lado los estándares ni la seguridad: En esta versión, el Explorter de WP8 nos informará cuándo estamos accediendo a sitios sospechosos, igual a como ocurre en el desktop.

    De hecho apps creadas para la web en HTML5, se pueden correr perfectamente en el browser del WP8, dado que ya viene optimizado para el touch en browsers. Y por si fuera poco, solo haciendo ligeras modificaciones (aquellas que tienen que ver con las características del tamaño de la pantalla), podríamos tener estas apps corriendo de manera nativa como una app propia del teléfono.

    Storage

    En cuanto a hardware, se ha agregado soporte a memorias MicroSD extraíbles, para agregar más almacenamiento y versatilidad en el teléfono.

    NFC

    NFC entre otras cosas ahora nos ha permitido generar toda una nueva experiencia llamada "Wallet Experience" consistente en  convertir al WP8 en la billetera que usamos todos los días. Tarjetas débito, crédito, cupones, membresías, etc., van a estar disponibles dentro del teléfono para que las podamos usar para pagar compras, recibir ofertas, ganar puntos, entrar a sitios, consultar saldos, etc. Obviamente el Wallet de #WP8 se puede asegurar con un pin, de la misma manera que aseguramos nuestras tarjetas.

    El servicio de Wallet, dependerá de que los operadores lo implementen. Orange en Francia ya está listo para el Wallet Hub y ofrecerá sus servicios en ese país, en bien aparezca WP8.

    image

    El NFC también permite por ejemplo, que acerquemos nuestros teléfonos a carteles o avisos que tengan chips NFC y de allí capturar información de la misma manera en que usamos los tag o QR codes. De manera similar sucede con información que queramos transferir desde una tablet al teléfono por ejemplo! Esto abre la posibilidad a nuevos escenarios como apps o juegos que se activan en la tablet al acercarle el teléfono que está ejecutando esa misma app o juego, para iniciar una partida multi-jugador en multi-dispositivos.

    AMBIENTE CORPORATIVO

    Un punto muy importante también dentro de estos anuncios, es que el ambiente corporativo ahora toma más relevancia. Por ejemplo, ahora vamos a tener la posibilidad de encriptar toda la información del dispositivo a través de la tecnología de BitLocker y también hacer secure Boot.   

    Existirá también un Hub corporativo, a través del cual se podrán instalar las apps corporativas sin que tengan que aparecer en el marketplace.

    INCLUSIONES DE SOFTWARE

    Mapas Nativos! Con tecnología Nokia / Navteq y la gran app Nokia Drive que nos da guías para movilizarnos bien sea a pie o en vehículos. Todos los teléfonos WP8 la incluirán, aún en modo offline. Es decir, los mapas vienen preinstalados, de manera que no necesitamos conexión de datos para poder utilizarlos!!!

    El speech se ha mejorado significativamente, ahora con el trabajo en conjunto con Audible que ha creado una plataforma (disponible también para WP7) para que las apps no solo puedan ser lanzadas con comandos de voz, sino que una vez abiertas, también sean operadas con la voz. Si eres desarrollador, ten en cuenta esta característica para adicionarla a tus apps, en caso de que aplique.

    La pantalla de inicio también fue trabajada para ser aún mejor; ahora es más personalizable y con tiles a los que se le pueden cambiar los tamaños, de manera que podemos tener muchas más apps ancladas al inicio, sin tener que desplazarnos verticalmente. Al final, lo que se ofrece es una manera única, no igualada por ningún otro teléfono en el mercado, para personalizar y hacer nuestro el teléfono. Con el color que queremos, el tipo de apps que queremos y la organización que queremos.

    Observemos un video de cómo funciona:

    La cámara tendrá nuevas funcionalidades como un Timer, un creador de Panoramas, y Smart Groove Shots que  permite tomar fotos de un grupo y luego detectar las mejores caras que hizo cada quien y finalmente armar la foto óptima.

    CUESTIONAMIENTOS

    Para finalizar, algunas de las dudas que nos quedan serían:
    Se podrá actualizar Windows Phone 7.5  a WP8? La respuesta corta es no. Sin embargo tendremos una última actualización para esta serie, que entre otras mejoras incluirá todo lo que tiene que ver con la nueva Start Screen que ya mencionamos. Esta, será la versión 7.8. Debemos tener en cuenta que WP8 incluye un kernel totalmente diferente al de WP7 que además da soporte a varios core y a otras resoluciones, por lo que es imposible lograr que un WP7 adquiera estas características meramente a través de una actualización de software.

    Esto nos lleva a otra pregunta: Las apps de WP7 correrán en WP8? Por supuesto! Pero eso sí, como es de lógica costumbre, una app compilada para WP8 no podrá correr en WP7.

    Cuándo puedo comenzar a desarrollar par WP8? Antes de terminar este verano estará disponible el nuevo SDK para escribir apps orientadas a WP8.

    Un solo mes; 3 espectaculares lanzamientos y todavía queda mucho por venir. Estén pendientes del este blog en donde encontrarán lo último de nuestras tecnologías.

  • WarNov Developer Evangelist

    Windows Phone Summit 2012

    • 0 Comments

    Aquí el cubrimiento en vivo, de este evento que develará las novedades que esperamos en nuestro Sistema Operativo para teléfonos!!

     

  • WarNov Developer Evangelist

    Windows 8 Surface Tablet/PC

    • 13 Comments

    UPDATE: Ya tenemos disponible el video del Keynote del lanzamiento de la Surface ayer en los Ángeles. Aquí esta:

     

    Ahora, un video de la tablet, porque vale mucho más que miles de palabras!!!

    Ahora imágenes! Muchas imágenes!

    Microsoft Surface

    La Surface, no viene con un docking. Viene con un forro que incluye teclado y pad multitouch (Touch Cover)! Además tiene un soporte en la parte trasera, que permite ajustar el ángulo de visualización.

    Microsoft Surface

     

    Microsoft Surface

    Microsoft Surface

    Microsoft Surface

    Microsoft Surface

    Forros con colores para todas las personalidades

    Un diseño sin precedentes!!!

    También se puede incluir un Type Cover que trae un teclado más físico que el del Touch Cover.

    El mejor tamaño que puede haber para una tablet de este estilo!

    No les  inspira rediseñar su espacio en torno a este aparato?

     

     

    El VaporMg Case es una total innovación que brinda elegancia, comodidad y ligereza gracias al magnesio con el que está construido.

    Todo el poder para una conectividad real!

     

    Que más hay que decir, que toda esta maravilla fue develada hoy a las 6.45pm hora Colombiana en Los Angeles, en un sitio que no fue develado sino hasta el día de hoy, a un grupo de selectos periodistas y bloggers quienes fueron avisados del evento solo hasta el viernes pasado.

    La Microsoft Surface Tablet, vendrá en dos versiones. Aquella para Windows RT,  y aquella para Windows 8 Pro. Se diferencian básicamente en la cantidad de espacio en disco (SSD): 64Gb máx y 128Gb max, la pro vendrá con un Stylus especial, el tipo de pantalla y sobretodo el procesador. la primera vendrá con ARM y la segunda con el Ivy Bridge de GBIntel, l que presumiblemente nos permitirá seguir teniendo el desktop tradicional.

    Otras especificaciones:

    Surface for Windows RT

    • OS: Windows RT

    • Light: 676 g

    • Thin: 9.3 mm

    • Clear: 10.6” ClearType HD Display

    • Energized: 31.5 W-h

    • Connected: microSD, USB 2.0, Micro HD Video, 2x2 MIMO antennae

    • Productive: Office ‘15’ Apps, Touch Cover, Type Cover

    • Practical: VaporMg Case & Stand

    • Configurable: 32 GB, 64 GB

    Surface for Windows 8 Pro

    • OS: Windows 8 Pro

    • Light: 903 g

    • Thin: 13.5 mm

    • Clear: 10.6” ClearType Full HD Display

    • Energized: 42 W-h

    • Connected: microSDXC, USB 3.0, Mini DisplayPort Video, 2x2 MIMO antennae

    • Productive: Touch Cover, Type Cover, Pen with Palm Block

    • Practical: VaporMg Case & Stand

    • Configurable: 64 GB, 128 GB

     

           

    Se espera la llegada de la Surface Windows RT en el RTM de Windows 8 y la Windows 8 Pro, aparecerá tres meses después.

    Mañana mismo podremos ver el video del lanzamiento aquí.

    Para terminar, solo me resta citar unas palabras:

    “I love this company.

    I love that we have brilliant engineers with brilliant ideas. I love that we aren’t afraid to make big bold bets. I love that we are persistent – after all it’s our passion and tenacity that bring our dreams to life. And right now, I love how so much of our hard work, passion and tenacity are coming together in the products we are bringing to market…

    … I’m incredibly proud of the work this company is doing and incredibly optimistic for what’s ahead. “

    Steve Ballmer,  al equipo de Microsoft.

  • WarNov Developer Evangelist

    WP7: Agentes en Background

    • 0 Comments

    Como su nombre lo indica, nos van a permitir ejecutar trabajos en Segundo plano, aún cuando la aplicación no esté activa.

    OJO: No están disponibles para los aparatos que solo tienen 256Mb de memoria.

    Tipos de Tareas:

    Periódicas

    Corren en un pequeño intervalo y recurrentemente. Por ejemplo para informar la locación del dispositivo y ejecutar sincronizaciones de poco tamaño.

    Intensivas

    (En Recursos) Largos períodos de ejecución cuando el teléfono cumple ciertas características de uso (actividad de cpu, fuente de poder, tipo de red. Útil para sincronizar grandes cantidades de datos al teléfono cuando no está siendo usado.

    Una app solo puede tener un agente de estos, que puede ejecutar ambos tipos de tareas.

    Restricciones:

    Existen unas apis que no se pueden usar dentro de las tareas que ejecutan los agentes: Cámara, vibración, radio, sensores, notificaciones, XNA, y otras que encuentran aquí.

    La geolocalización está disponible de manera restringida, ya que no reporta la ubicación real, sino que hace un cache cada 15 minutos, sin embargo, acciones como las que usan los HttpWebRequests desde los agentes sí se pueden hacer sin problema.

    Los agentes no pueden usar más de 6MB, excepto cuando manejan audio, en cuyo caso tienen hasta 15Mb. Cuando se exceden estos límites, la tarea se apaga de inmediato. Cuando cualquier tarea es apagada dos veces debido a un alto empleo de la memoria, dicha tarea es removida del agendamiento de tareas del teléfono. Es útil recordar que estos límites no aplican en modo debug, por lo que es necesario emplear el API ApplicationMemoryUsageLimit para verificar cuánto está empleando la tarea en tiempo de depuración.

    Los agendamientos de las tareas no se pueden hacer por un tiempo mayor a dos semanas. Para poder reagendar, la app tienen que ejecutarse en primer plano.

    Cuando se tienen agentes periódicos, lo normal es que corran mínimo cada 30 minutos. Este tiempo puede desfasarse hasta en 10 minutos, debido a otras tareas que están en segundo plano. La ejecución no debe ser mayor a 25 segundos.

    WP7 tiene un modo de operación llamado Battery Saver: Este modo que solo se puede habilitar por el usuario, podría impedir que los agentes periódicos se ejecuten.

    WP7 tiene una restricción acerca de la cantidad de agentes que pueden estar corriendo en un dispositivo dado y esta puede ser tan pequeña como 6. Antes de este límite, WP7 puede lanzar mensajes al usuario que indiquen que la cantidad de agentes está subiendo mucho y puede que la batería se agote más rápido. Si el límite ya se ha cumplido, cuando la app trata de agregar una nueva tarea, habrá una excepción de tipo InvalidOperationException que debería ser manejada para que la app no se estrelle por este motivo.

    Hay documentación de buenas prácticas que pueden encontrar aquí. En el caso de los agentes intensivos, estos pueden durar ejecutándose hasta 10 minutos. No pueden correr a menos que el dispositivo tenga más de 90% de batería, la pantalla esté bloqueada, no exista una llamada activa, esté conectado a una fuente de poder externa y a datos en una red distinta a la red celular. Si una tarea intensiva comienza a ejecutarse y por algún motivo alguna de las condiciones anteriores deja de cumplirse, de inmediato la tarea es terminada.

    Es bueno tener en cuenta que estas tareas intensivas pueden llegar a no ejecutarse nunca, debido a la gran cantidad de condiciones impuestas. Por ejemplo si el usuario no tiene WiFi en ningún lado, la tarea nunca se ejecutará.

    En mi sitio de preguntas y respuestas he respondido algunas preguntas acerca de los agentes en background:

    1. Hay alguna forma de manejar con código en wp7 que un agente sea suspendido porque hay bajos recursos de memoria o de batería?

    2. En wp7, se pueden concatenar varios agentes periódicos para lograr tener reportes cada 2 minutos en vez de cada 30?

    3. Es posible evitar a través de código que un usuario de WP7 apague los agentes de ejecución en background?


    Bien; ya que vimos las generalidades, si quieres incluir Background Agents en tu app, sigue este link, donde nos enseñan cómo implementarlos.

  • WarNov Developer Evangelist

    La “Asincronía” y su evolución en pro de la UX

    • 2 Comments

    Hace ya varios años, los primeros servicios Web que usábamos eran síncronos. Hacíamos un llamado a la web y nos quedábamos esperando muy pacientemente a que el servidor nos respondiera y la respuesta bajara.

    Para nosotros era suficiente con obtener la respuesta!

    Nos nos importaba cuánto se demorara... el hecho que después de un tiempo llegara esa información que necesitábamos ya era suficiente para sentir la magia de la web!!! El resto era irrelevante! Aún el hecho de que la interfaz de usuario se congelara no nos importaba. Finalmente, teníamos nuestro mensaje... valía la pena esperar.

    Pero humanos somos y cada vez queremos más. Cada vez queremos mejores opciones y mejores comportamientos. Más comodidad!!!
    Nos comenzó a parecer un fastidio que la interfaz se congelara y que ni siquiera pudiéramos mover la ventana de la aplicación... De ahí en adelante comenzó la evolución que hoy en .net se conoce como: async.

    En este video daremos un recorrido por las soluciones que se le han dado a este problema a través del tiempo. Desde los simples llamados síncronos a WebServices por ejemplo, pasando por el manejo de threads distintos para la comunicación junto con el uso de Invoke para evitar desactivar el CheckForIllegalCrossThreadCalls de los forms, siguiendo con el versátil BackgroundWorker y luego explorando los clientes web asíncronos obtenidos con WebClient en Silverlight y Windows Phone 7 y HttpClient en Windows 8, que al implementar el Framework 4.5 nos ofrece el maravilloso async que nos abstrae de todas esas operaciones que algún día fueron un dolor de cabeza para nosotros:

    Puntos Clave:

    1. async ha sido creado solo para manejar operaciones que al tardar, podrían bloquear la interfaz de usuario. En ningún momento ha de ser usado para ejecutar tareas en paralelo o procesos en Background.
    2. En WP7 aún no hay soporte para async. Así que hay que usar un WebClient y ejecutar sus métodos asíncronos asociando un manejador al evento de completitud del request. Esto es similar a las llamadas asíncronas a proxies de servicios WSDL o WCF tradicionales.
    3. La forma de manejar async difiere levemente desde WindowsRT (metro style) al resto del framework. Cuando no estamos en WindowsRT se usa el método que referencia a TaskAsync. Por ejemplo en vez de DownloadStringAsync, en un WebClient, llamamos el método DownloadStringTaskAsync
    1. WarNov Developer Evangelist

      Windows Azure SDK Junio 2012 Habilita a Visual Studio 2012RC !

      • 0 Comments

      imageCon la liberación del SDK de Windows Azure versión Junio 2012 (1.7) y las tools de la misma versión, el proceso nuevamente es automatizado y ahora además tiene completo soporte para Visual Studio 2012 RC!!! De esta manera lo único que tenemos que hacer es ir a este link, descargarlo e instalarlo.

      Problemas con la descarga: El sitio en español aún no se actualiza con los últimos bits. Así que si al seguir el link tu navegador identifica tu localización, no te llevará al sitio en inglés sino al de español y te presentará la versión del sdk anterior que no es compatible con el RC de Visual Studio 2012. En ese caso, asegúrate de ir al final de la página y cambiar el idioma a inglés, para que te aparezca el último SDK que dice: “Last updated June 2012”

      image 

      • Como se aprecia, todo el SDK más las tools ahora solo ocupan 34.26MB. Esto es debido a que Visual Studio 2012 RC ya viene con muchos de los elementos requeridos para el desarrollo en Azure, tales como un IIS Express y la base de datos compacta para desarrolladores llamada SQL LocalDB (Correcto, ya no necesitamos ni siquiera SQL Express!!! –más espacio y memoria para nuestros juegos!)

      Tengan en cuenta que este SDK soporta hasta la versión 4.0 del Framework .Net. Así que si en VS2012RC seleccionan como Target Framework el 4.5, no les aparecerá disponible el Windows Azure Cloud Service

      image

      La forma adecuada sería:

      image

      Este SDK funciona correctamente en Windows 7, Windows Server 2008R2, Windows Server 2012 RP y por supuesto en Windows 8 RP! Descárguenlo ahora mismo y disfruten del mayor cambio y evolución que ha tenido nuestra plataforma de Cloud Computing desde su creación hace dos años!

      image

       

       

    2. WarNov Developer Evangelist

      Apps de Windows Phone no disponibles en tu región cuando las vas a bajar?

      • 2 Comments

       

      El Marketplace de Windows Phone está segmentado por países, porque en cada país las normas son distintas y por ende no se puede generalizar la distribución de Apps.

      Así que los desarrolladores de apps, ya sea por este motivo u otros distintos, en ocasiones no ponen sus apps disponibles a ciertos países (esto no tiene que ver con el costo de publicación que siempre es el mismo).

      Es así que si al momento de configurar tu cuenta por ejemplo estableciste que ibas a trabajar con el Marketplace Colombiano, solo las apps disponibles para Colombia te aparecerán.

      Las apps más populares del mundo ya están disponibles para Colombia. Pero otras puede que no. El mercado por defecto es Estados Unidos. Por ende, casi todas las apps se encuentran allí. Así que podemos configurar nuestro teléfono con el marketplace de Estados Unidos y tener acceso a más apps.

      Desventaja frente a escoger el mercado del país en el que vivimos? Que a la hora de comprar apps, vas a tener que usar una tarjeta de crédito oriunda de ese país. Así que si no tienes una tarjeta de crédito internacional, tendrás algunas dificultades. Afortunadamente la gran mayoría de apps más usadas son free.

      Suponiendo que ya arreglaste este problema de la tarjeta de crédito y te inscribiste al marketplace estadounidense, puede pasar que aun así no veas ciertas apps como el mismísimo Adobe PDF Reader!!! A mí me pasó y formateé el teléfono varias veces sin éxito. No la podía bajar.

      Por qué sucedía esto? Sencillamente, porque configuraba el teléfono para una amiga que no es muy buena con el Inglés, así que le puse como idioma por defecto Español.

      Cuando los desarrolladores de Apps suben sus apps al mercado, también eligen el idioma en el que la ponen disponible. Adobe no puso su app en idioma Español. Así que si se detecta que el teléfono está en un idioma no disponible, la app no se dejará descargar.

      Solución: Poner el teléfono en inglés (requerirá reiniciarlo). Descargar todas las apps necesarias y luego si lo deseas, volver al español. Las apps seguirán allí listas para usarse; pero obviamente aparecerán solo en inglés.

      Si eres desarrollador de apps en español, ten esto muy en cuenta a la hora de publicarla; si quisieras por ejemplo alcanzar el gran mercado estadounidense, mejor que le pongas tu versión en inglés a la app, porque de lo contrario ellos no podrán descargarla por más que tu la hayas distribuido en ese país, si no tienen su aparato configurado en español.

    3. WarNov Developer Evangelist

      Estrategias para prevenir rechazos de tu app en el Marketplace de Windows Phone 7

      • 0 Comments

      Abstract:

      Con el pasar del tiempo y las consultas que me han hecho, he recopilado los motivos más frecuentes por los cuales una app de WP7 es rechazada para acceder al Markeplace (mp) después de subirla a través del AppHub. Este post recopila estos motivos y su solución.

      1. Marcas y logos registrados:

      Cuando se usan dentro de la aplicación marcas y logos reconocidos, nos pueden devolver la app para que indiquemos si tenemos permiso para usarlos. Esto se puede indicar en el último paso del proceso de subida de la app, en el espacio que dice Test Notes:

      image

      Estas notas deben ir en inglés y tal como lo recomiendo en el ejemplo, se debe indicar que la empresa dio los permisos adecuados, así como los datos de la persona de contacto que se podría requerir para certificar este permiso.

      2. Uso de GPS

      El uso de GPS como es bien sabido, interviene con la privacidad del usuario, pues se podría comenzar a reportar la ubicación de un usuario sin que este lo haya permitido. Es por esto que si empleamos el api de localización en nuestras apps, debemos proveer claramente un mecanismo para desactivar estas funcionalidades. Además cuando lo hagamos, la aplicación debe seguir funcionando correctamente. Además de esto, se debe proveer una política de empleo de la información de la localización que explique perfectamente al usuario para qué serán usados los datos, de manera que él pueda comprender las implicaciones de autorizar el empleo del GPS en la app. Esta política puede estar incluida en la app, o ser un link a algún recurso externo. Acá les escribo un ejemplo de política:

      La aplicación xxxxx ofrece servicios avanzados de búsqueda, basados en la ubicación del usuario. Los datos de ubicación del usuario son usados exclusivamente para este fin y nunca son compartidos. Sin embargo, si el interés del usuario es que esta aplicación no haga uso de los servicios de localización del teléfono, éstos se pueden deshabilitar en el menú de ajustes de la aplicación; en este caso la utilidad de búsqueda por cercanía quedará deshabilitada y la aplicación continuará funcionando correctamente.

      En este caso deberá de existir un menú de ajustes, donde se puedan deshabilitar estas características:

      image

      3. Screenshots

      Los Screenshots preferiblemente (obligación por ser la mejor opción) se han de capturar desde el emulador que tiene una utilidad para tomar estos screenshots.

      Pero con el emulador sucede que a veces puede estar mostrando el framerate de las imágenes que está mostrando. Si capturamos con esta opción habilitada, nuestra app será rechazada, porque estos elementos no pueden aparecer en los screenshots:

      image

      Esta opción por defecto viene habilitada, así que a la hora de hacer la captura la deshabilitamos desde el archivo: App.xaml.cs:

      image

      Basta solo con poner EnableFrameRateCounter en false.

      4. Lenguaje por defecto de la app

      Cuando creamos una app de WP7, el lenguaje por defecto de la misma está establecido en Inglés. Es por esto que cuando la subimos, el App Hub, allí esperan que pongamos una descripción de la App en inglés:

      image

      Es un error frecuente, porque si efectivamente nuestra app está en español, querremos ponerle descripción en español; pero el App Hub solo nos da la opción de inglés. Así que si ponemos la descripción en un idioma distinto al solicitado, nos rechazarán la app. Como lo mencioné es porque no hemos cambiado la opción de idioma neutral. Para lograrlo, vamos a las propiedades del proyecto y escogemos Assembly Information y allí podremos seleccionar el lenguaje neutral personalizado:

      image

      De esta manera cuando subamos la app al AppHub, nos aparecerá en este caso el idioma español, para poner la descripción.

      En situaciones más avanzadas queremos ofrecer nuestra app en varios idiomas. En otro post estaré mostrando cómo se logra tener localización de múltiples lenguajes. Por ahora veamos que si hacemos esto bien, cuando carguemos el xap al AppHub, observaremos que habrá una versión de toda la información que tenemos que suministrar, por cada lenguaje que hayamos incluido:

      image

      Como observamos en este caso, está seleccionado el idioma inglés y en este ponemos la información requerida. Luego seleccionamos español y procedemos escribiendo la información en el lenguaje adecuado. Recordemos que esto solo aplica cuando intencionalmente escogemos tener dos o más lenguajes para nuestras apps.

      Sabiendo que pueden surgir nuevos motivos de rechazo frecuentes, stay tunned, que aquí estaré citándolos y ofreciendo las posibles soluciones.

    Page 4 of 14 (326 items) «23456»