MSDN Blogs
  • WarNov Developer Evangelist

    Autodocumentación .NET: XMLDoc+GhostDoc+Sandcastle

    • 5 Comments

    Sin documentación, el software nace, crece, se vuelve spaghetti, desquicia a los developers y todos mueren.

    Aquí una guía súper rápida para que la documentación no sea un pain, y además tener el motivador de que al final vamos a poder tener páginas de documentación estilo MSDN, usando la última versión de Visual Studio: la 2012.

    Ingredientes:

    • Visual Studio 2012
      • No necesita presentación
    • Ghost Doc
      • Es una extensión para Visual Studio que genera comentarios de documentación XML automáticamente para métodos y propiedades, basándose en su tipo, parámetros, nombre y otra información contextual. Es un addin que además desinstala automáticamente versiones anteriores y las actualize con las nuevas que estemos instalando.
    • Sandcastle Help File Builder
      • Sandcastle es una herramienta creada por Microsoft y publicada Open Source en Codeplex para crear documentación Estilo MSD basándose en los assemblies .NET y sus comentarios XML asociados. Es un tool basado en línea de comandos y no tiene una GUI pre-definida. Así que la curva de aprendizaje es alta. Afortunadamente la aplicación Sandcastle Help Builder ha sido construida sobre Sandcastle para proveer un fácil manejo de todas las opciones que tiene Sandcastle, de tal manera que el uso sea parecido al del antiguo NDoc.
        La instalación de esta aplicación requiere varios paquetes preinstalados y configurados. Por eso viene con un wizard bastante amigable que ayuda a la configuración.

    Una vez tenemos todo instalado, pasemos a observar cómo generar la documentación!

  • 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

    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

    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

    Publicación de WinRT Apps al Windows Store

    • 0 Comments

    UPDATE: Me han preguntado bastante por los costos de la suscripción. En Colombia, para individuos es de COP$90.000 y para companies es de COP$180.000

    Capture

    En esta ocasión me complace invitar a mi blog a uno de nuestros MCS: Róbinson Moscoso. Quien hace parte del core de la comunidad BDotNet y además de su amplio trabajo con la comunidad, es emprendedor y también pasó por los laboratorios de excelencia de Apps WinRT que ejecutamos en Colombia son su App Sipse Microfinanzas, con la que adquirió gran experiencia en el desarrollo de apps para el Windows Store y además ganó un token para acceder al store gratuitamente por un año.

    Hoy nos cuenta su experiencia, acerca de los pasos que se han de seguir para subir una app al Windows Store:

    Dentro de las oportunidades que se vienen con Windows 8 es la de poder ofrecer nuestras aplicaciones a través del Windows app store. En este artículo veremos los pasos para subir nuestras apps:

    1. Registro:

    Lo primero es ir al Windows Dev Center (http://msdn.microsoft.com/en-us/windows/apps) e iniciar sesión con el live id.
    Seguido vamos a la opción de Dashboard, en la cual iniciamos el proceso de registro, seleccionando el país en el que nos encontramos, para nuestro caso “Colombia”


    clip_image001


    Una vez en la ventana de registro llenamos la información correspondiente. Para tener en cuenta, el código postal lo podemos encontrar en la página de 4-72 (aplica para Colombia: http://190.26.208.149/CodigosPostales/Index.html#app=76ee&4817-selectedIndex=1)


    clip_image002


    Una vez hacemos clic en siguiente debemos leer y aceptar el contrato (Application Development Agreement)
    clip_image003

     

    2. PRECIO y pago

    En la página se nos especifica el precio a pagar por el registro, si se tiene un código se puede incluir en esta parte.


    clip_image004


    Una vez se hace clic en siguiente se activa la ventana de pago, en la cual registramos la información de una Tarjeta de Crédito por medio de la cual se hará el pago.


    clip_image005


    Una vez registrados los datos del medio de pago se debe hacer la confirmación de la compra:


    clip_image006


    Una vez realizados estos pasos nos llega un correo de conformación de la creación de la cuenta y del pago realizado. Ahora ya podemos iniciar nuestro trabajo en el dashboard


    clip_image007

     

    3. SUBIR UNA APP

    Una vez ingresamos al Dash Board podemos iniciar con el proceso de carga de nuestra aplicación, para ello utilizamos el link Submit an app:


    clip_image008


    Para subir la app nos pide los siguientes pasos:


    clip_image009

    • App Name

    Se debe reservar el nombre que tendrá la app.


    clip_image010


    clip_image011

    • Selling details (Opciones para la venta)

    En esta opción se determina el precio, y si aplica en periodo de prueba de la app, para nuestro caso nuestra app será gratis (Free).
    Además en esta opción se debe seleccionar en que mercados quedará disponible, teniendo en cuenta las opciones y palabras que tiene nuestra app, pues una palabra común en el dialecto colombiano, puede ser mal vista en otra región, lo cual puede causas que la app no sea subida al app store.


    clip_image012


    También se debe seleccionar la fecha en que será lanzada nuestra app, la primera opción es publicarla una vez pase el proceso certificación. 
    Igualmente se debe seleccionar la categoría sobre la cual se alojará la app, en mi caso “Business” .
    Se debe también seleccionar si la app requiere para funcionar algunas especificaciones de hardware, particularmente si el dispositivo debe tener alguna versión de DirectX o si requiere dispositivos con más de 2GB de RAM.
    Se debe seleccionar si la app  cumple con las directrices de accesibilidad, importante tener en cuenta que si la app no cumple con alguna de las opciones de accesibilidad descritas en la guía y es seleccionada esta opción, la app no será certificada.


    clip_image013

    • Características avanzadas

    clip_image014


    En este apartado configuramos

    1. si la app y cuenta con  “Push notifications and Live Connect services”  los cuales deben ser configurados antes de subir la app para la certificacion.

    2. “In-app offers” si se quiere configurar ofertas dentro de la aplicación.

    • Audiencia a quien va dirigida la app (Age rating and rating certificates)

    Se debe seleccionar para que público puede estar disponible la app, hay que tener en cuenta que Windows Store no permite subir aplicaciones explicitas para adultos únicamente (por ejemplo apps de contenido sexual)

    clip_image015

    • Criptografía (Cryptography)

    Permite especificar si la app usa encriptación.
    clip_image016

    • Paquetes

    Es necesario subir el paquete de nuestra app, este paquete se puede crear a través de Visual Studio (proximante publicaré un post al respecto)
    clip_image017

    • Descripción

    Una ves tenemos los paquetes subidos, precedemos a dar una descripción de nuestra app, en la cual se pide:

    1. Descripción de la app, que será el texto que leerán nuestros usuarios antes de descargar la app
    2. App Features (Características)
    3. Keywords (Palabras clave)
    4. Description of update (descripción de la actualización)
    5. Copyright and trademark (Derechos de autor)
    6. Additional license terms (Términos adicionales de la licencia)
    7. Screenshots (pantallazos)
    8. Promotional images (imágenes promocionales)
    9. Recommended hardware (Hardware recomendado)
    10. Website
    11. Support contact info (Información de contacto para soporte)
    12. Privacy policy ( Política de privacidad)

    clip_image018

    • Notas a los probadores (Notes to testers)

    Permite escribir información que ayuda a los probadores a entender y a utilizar la aplicación. La información ingresada en esta parte no será vista por los usuarios de la app.

    clip_image019

    4. Enviar la app para certificación

    Una vez se han completado todos los pasos se habilita la opción de enviar la app para la respectiva certificación.


    clip_image020


    Y finalize Robinson diciéndonos: “Bueno, espero sea de utilidad este pequeño tutorial sobre el proceso de carga de nuestras apps”

     

    Este mismo tutorial, así como muchos otros posts interesantes adicionales, los pueden encontrar en el blog de Robinson.

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

Page 1 of 1 (6 items)