MSDN Blogs
  • WarNov Developer Evangelist

    Cómo seleccionar automáticamente un elemento dentro de un Panorama

    • 0 Comments

    Dice el corresponsal:

    “Hola Walter, como hago en una App WP8 para navegar a una pagina con control panorama y abrir inmediatamente un index diferente a 0. es que tengo un menú y según seleccionen abrir la pagina que tiene el panorama pero el ítem seleccionado. Gracias”

    R./ Suponiendo que tenemos una página inicial con un botón que hace la transferencia a una segunda página panorama, podemos agregarle al llamado de la segunda página un parámetro que nos indique el ítem que deseamos en el panorama:

    private void Button_Click_1(object sender, RoutedEventArgs e)
    {
         NavigationService.Navigate(new Uri
    ("/PanoramaPage1.xaml?item=2",UriKind.Relative)); }

    Luego solo basta manejar el evento OnNavigated de la página de destino, en la cual debemos de haberle dado un nombre al panorama para poderlo referenciar y luego ajustarle el ítem por defecto para cuando se abra la página:

     

    override protected void OnNavigatedTo(NavigationEventArgs e)
    {
        var item = int.Parse(NavigationContext.QueryString["item"]);
        pnrControl.DefaultItem=pnrControl.Items[item];
        base.OnNavigatedTo(e);
    }
    

    y voilà!

    image

  • WarNov Developer Evangelist

    PhotoRanker: Making of a WinRT App

    • 0 Comments

    Este es un post en el que quiero compartirles la experiencia de publicar una app en el store de Windows 8 desde el punto de vista de un desarrollador estándar que ha sufrido en el proceso y ha dejado huella de sus heridas en el código que escribió… mostraré no solo los aspectos técnicos que se tuvieron que superar, sino también los procedimientos de publicación requeridos por el store. Tengan en cuenta sin embargo, que esta no es una guía que enseña a desarrollar apps y que parto del hecho de que ya se sabe como tener una cuenta en el Windows Store, pues tampoco explico cómo se abre una de ellas aquí.

    Objetivo

    PhotoRanker es una app con un único y claro objetivo… como todas las apps deberían ser. El objetivo es poner rating a las fotografías (estrellas) de una forma rápida y eficiente. De esa manera sabes cuáles realmente merecen ser editadas y cuales otras no valen ni un centavo y mejor borrarlas de una.

    Una app debe tener claro su objetivo, para poder de esa manera ser clara en su implementación y clara en su uso. Estamos en un mundo de cientos de miles de apps. En este mundo cada app solo tiene una oportunidad. Si no es buena a primera vista, lo más probable es que genere una desinstalación inmediata. De hecho, personalmente me he visto haciendo eso como consumidor de apps que soy. Así que si no encuentro de inmediato cómo manejar la app, me frustro y le doy uninstall… suerte es que le digo.

    Release Often, Release Fast

    Otra ventaja de tener bien claro el objetivo, es que tu app va a salir rápido al store. No van a pasar eones mientras por fin terminas de implementar las toneladas de funcionalidad que pueden ir pegadas a una app. De hecho, esta app me consumió 9 horas de desarrollo incluyendo dificultades técnicas, ya que no es un simple RSS. Lo importante, es que pude salir al aire pronto con mi app. Esta nueva tendencia de la industria nos lleva al famoso: “Release often. Release fast”. Naturalmente, cuando publicamos nuestra app con su funcionalidad principal claramente establecida, es fácil comenzar a ver los puntos de mejora y extensión para liberar nuevas versiones. Anyway el update de una app no vale nada… solo es necesario subir la nueva versión y por experiencia os digo, que la liberación de un update tarda mucho menos que la del estreno de la app. Además como usuario, uno se siente muy agradado de recibir updates de las apps que usa, pues solo la mera curiosidad de ver qué mejoró, me hace entrar de nuevo a la app. Sentimos entonces como usuarios que el developer está pendiente de la app y que cada vez encontraremos mejoras en ellas; al final esto se ve representado en buenos rating, mercadeo viral y por ende, más descargas.

    Diseño

    Tal vez este sea el requisito más trillado en el tema de apps. Si una app es fea, le va pasando algo parecido a cuando es difícil de manejar: produce frustración y el peor de los males desinstalación, acompañado tal vez de un @#$%^&*( en los reviews, que para nada nos favorece. Para Windows 8 hay muchas guías de diseño. Tener un amigo o socio o equipo diseñador, es lo más recomendado. Pero si somos Hard Die Alone Developers, tal vez tengamos que desarrollar ciertos skills de diseño, para hacer toda la app por nuestra propia cuenta; o al menos los bosquejos de la misma. Para este proceso además de alguito de talento, necesitaremos algunas tools que nos facilitarán la vida.

    Entonces es cuando recomiendo que comiencen a pensar en vectores. Olviden el dibujito jpg…. literalmente no escala y cuando escala se pixela. Recuerdan la premisa de que la app debe ser linda y así se debe ver en cualquier tipo de resolución? Pues bien; una de las grandes características de los gráficos vectoriales es que escalan muy bien y es fácil generarlos para varias resoluciones. Los gráficos vectoriales vienen en versiones como *.SVG que ya es un estándar. Y pueden exportarse fácilmente a los formatos convencionales. Además al igual que los *.PNG, soportan muy bien las transparencias. Desafortunadamente las apps como tal no soportan gráficos *.SVG. Siempre tenemos que pasarles las versiones *.PNG preferiblemente.

    Pero en ese caso, cómo se logra el escalado para cada tipo de resolución?

    Muy sencillo. Windows 8 soporta que pongamos varias versiones de un mismo archivo de imagen en la carpeta en donde los estemos almacenando. La idea es que cada archivo tenga una escala específica para cada tipo de monitor. En Windows 8 se han definido varias escalas. Normal (basada en una pantalla de 1366x768) o 100%, luego viene una mediana que es de 140% y finalmente la grande de 180% que soporta resoluciones HD sin distorsionar las imágenes. Y dependiendo de la resolución detectada, Windows 8 carga automáticamente el archivo adecuado. Nosotros solo lo referenciamos con la raíz del nombre y Windows 8 escoge el adecuado; otra opción es usar la convención de un folder por cada tipo de escala. Entonces al final implementaríamos de alguna de estas dos maneras:

    image

     

    Supongan entonces que se han bajado Visual Studio Express for Windows 8 que es totalmente gratuito y permite comercializar sin problemas las apps que con éste diseñemos. Pues bien… si pagamos 0 por esa herramienta, deberíamos de pagar un montón por una buena herramienta de dibujo y manejo vectorial? Hacerla de piratas y arriesgar nuestra máquina a que se llene de malware tratando de bajar una versión pirata de dicho editor gráfico? Por supuesto que no! Así que en este punto me permito recomendar una gran herramienta free y OSS llamada Inkscape. Con capacidades similares a las de Illustrator, es de manejo muy sencillo y da productividad rápida. La verdad es que yo no sabía mucho de edición de vectores, pero en poco tiempo ya estaba cómodo con la interfaz que me permite manejar capas, hacer operaciones entre objetos (adicionarlos, sustraerlos, intersectarlos), exportar y muchas cosas más. Efectivamente con esa herramienta junto con Paint.Net una tool free creada con .NET y que podría definir como un mspaint con esteroides o PhotoShop light que permite ya manejar los mapas de bits finales (no vectoriales), generé todo el arte requerido para el store de Windows 8, cuando subía a certificación PhotoRanker.

    SiteHeader

    Logo

    entre otras…

    The Store

    Ya que hablamos del arte requerido para el store, algunos puntos al respecto:

    Primero, podría mencionar que es muy fácil ejecutar el proceso de publicación una vez se ha terminado la app. Existe un archivo dentro del proyecto de nuestra app que contiene toda la información relevante con este fin. Ese archivo es el Package.appxmanifest. Visual Studio provee un amigable editor para configurar este archivo antes de subirlo al store. En este, podemos por ejemplo especificar las imágenes de arte a usar para que nuestra app se liste gráficamente en el store, para los tiles, las capacidades de los dispositivos que la app requerirá y muchos otros más.

    oldpackagemanifest

    Vemos allí como se nos piden los diversos archivos de arte y otra metadata para el store. De aquí quiero hacer la primera salvedad. En este diálogo no se nos pide un logo para el store. Así que si no hacemos algo al respecto, nos aparecerá nuestra app con un horrible logo con una X dentro de un cuadrado. Créanlo… a mí me pasó…

    image

    Y así quedará publicada nuestra app. Para corregir esto, lo que debemos hacer es cambiar la imagen existente en Assets\StoreLogo.png, por la imagen personalizada que generalmente es un PNG de 50x50: (tuve que lanzar una nueva versión al store solo por esto)

    StoreLogo

    Afortunadamente, acabo de notar que tras la instalación del Update 1 de Visual Studio 2012, esta situación mejoró sustancialmente al proveerse un nuevo diálogo para este archivo, que permite hasta especificar las imágenes de arte en distinta escala:

    NewPackageManifest

    Vean más detalles en este post.

    Existen muchas otras condiciones para tener en cuenta en la publicación, como las que enumero en este post. Pero luego las leen. Por ahora continuemos con la experiencia en general.

    Versiones y Apps Huérfanas:

    Son ustedes padres desalmados? Por favor  no dejen huérfanas sus apps. No se trata de subirlas y dejarlas en el store sin nadie que las mantenga. Cada minuto que empleen ustedes en hacer una app, es un potencial minuto que puede traerles retorno de la inversión… ganancia. Si dejan su app sin mantener, están desperdiciando esos minutos que invirtieron previamente.

    Pídale a sus amigos que le den opiniones de la app. Qué cosas ven que estaría bien que incluyeran. Ustedes mismos pueden tener sus propias ideas. Comiencen implementando una por una… o si está muy fácil, suban un grupo de tres nuevos features. El Store facilita mucho el proceso. Entre otras cosas, pide que pongan los detalles de las novedades  de la versión.

    Personalmente, le cree un portal a mi app. Lo creé gratuitamente en Windows Azure a través de Windows Azure Websites. En este sitio web, puse una sección de Version History, en la cual muestro la evolución de mi app en cada versión. Esto me permite mostrar que la app está en continua evolución… esto obviamente fideliza a mis actuales usuarios y me trae nuevos. Imaginen que están vendiendo ads publicitarios en sus apps (sé de apps de desarrolladores independientes que han llegado a hacer USD$100.000 en solo ads); en ese caso hay que hacer todo lo posible por que permanezcan con nuestra app. Precisamente esto me lleva al otro punto de este post.

    Cuida tu código:

    Siendo el desarrollador independiente de hoy, querrás estar en permanente movilidad y que el código que hagas vaya contigo a todo lado. Que esté actualizado y que además puedas manejar versionamiento de una manera bastante cómoda…. correcto, te estoy hablando de tener un administrador de código fuente… y sí en Microsoft también ofrecemos un manejador gratuito: Team Foundation Server Express, que gratuitamente les soporta hasta 5 developers. Se lo pueden bajar e instalar, pero yo prefiero usar la versión online que me evita la fatiga de la instalación y me permite tenerlo everywhere. Solo hay que registrarse aquí. Luego de esto, solo queda hacer checkins, checkouts y terminar nuestra app.

    Cuida tus clientes:

    Efectivamente si queremos que nuestra app nos dé ganancia, hay que dar un valor agregado a los usuarios. Por esto es bueno tener un portal dedicado a nuestra app en el que podamos tener flexibilidad para acompañarla con información adicional, avisos, y demás. Una vez tengamos el portal, obviamente es requerido que dentro de nuestra app le demos la posibilidad al usuario de saber que este portal existe y obviamente de acceder al mismo. Un sitio adecuado para esto, es en el About, dentro del charm de settings de la app. No lo vayan a poner grandote en todas las páginas de su app, porque eso no es nice. En el peor de los casos, al menos háganle una página en FB. Es gratis y sirve para enganchar conversaciones que le dan buzz a tu app. Aprovecha los logos oficiales del Windows Store que encuentras aquí para poner el link a tu app en el store (te llega por correo una vez es aprobada; te recomiendo que de una vez le saques un short url pues es complejo) y por favor sigue las reglas de uso de esos logos que están ahí no los vayas a deformar, recortar ni adornar con maripositas.

    Explota la plataforma

    Windows 8 tiene una gran cantidad de features para enamorar al usuario. Es un total desperdicio entonces terminar haciendo apenas una app lectora de rss que no tiene en cuentas estos features. En la creación de PhotoRanker he tratado de incluir la mayor cantidad de features de Windows 8 que tenga sentido para este tipo de app. Algo muy válido eso sí, es que la primera versión salga muy sencilla, pero luego le vamos agregando estos features que realmente harán que nuestros usuarios se sientan muy agradado de usar nuestra app. Por ejemplo, en mi primera versión no soportaba portrait ni snap view mode. Tampoco guardaba settings de la app. Pero ya en la tercera, todo esto está soportado. Y por supuesto la idea es en futuras versiones incorporar más features. Por ejemplo un live tile que muestre fotografías rankeadas con 5 estrellas, la posibilidad de buscar fotografías por número de estrellas usando el charm de search y usar el charm de share para compartir determinada fotografía.

    Modos de presentación:

    Las apps de Windows 8 tienen 3 modos de presentación principales: Full o Landscape, Snap y Portrait. La utilidad de Snap hace mucho sentido en esta app, pues es bien viable que uno por ejemplo esté rankeando sus imágenes mientras ve por ejemplo un video al mismo tiempo. En Windows 8 la mayoría del trabajo de presentación en Snap View se hace automáticamente, pero casi siempre quedan pequeños detalles por corregir. Por ejemplo, en mi app cuando está en fullscreen mode, la fotografía se centra verticalmente:

    image

    Pero al pasar a Snap, si dejo el comportamiento automático, la imagen se reduce también y al ser pequeña, se ve muy afectada por la superposición de las estrellas:

     

    image

    La imagen queda perdida en el control.

    En este caso algunos ajustes adicionales al modo snap son requeridos. Es muy fácil ejecutarlos una vez identificamos el sitio donde se maneja este evento de cambio de posicionamiento:

    public void OnSizeChanged(object sender, Windows.UI.Core.WindowSizeChangedEventArgs args)
    {
    switch (ApplicationView.Value)
    {
    case ApplicationViewState.FullScreenLandscape:
    VisualStateManager.GoToState(this, "Full", false);
    break;
    case ApplicationViewState.Snapped:
    VisualStateManager.GoToState(this, "Snapped", false);
    break;
    case ApplicationViewState.FullScreenPortrait:
    VisualStateManager.GoToState(this, "Portrait", false);
    break;
    default:
    break;
    }
    }

    Como se observa, solo basta interceptar el evento de OnSizeChanged y luego con un sencillo case actuar de acuerdo al cambio experimentado. En este caso, para corregir el pequeño error del snap view, lo que hago es en el respectivo case, cambiar la alineación vertical de la imagen, y ponerla en TOP:

    image

    Ese pequeño cambio que hice, significa una mejora sustancial en la experiencia del usuario, ya que aprovecho mejor el espacio y la imagen se ve completamente despejada. Además noten cómo dejo los controles abajo, de manera que ergonómicamente hablando, están muy accesibles para el usuario. Un inconveniente que experimenté en la vista de Snap View,  fue a través del uso del folder picker cuando está en esta vista. Sucede que si abrimos un folder picker y la app está en snap view, se genera una excepción, porque el folder picker no puede trabajar en este modo. Es por esto que con código debemos obligar a la app a expandirse antes de abrir el folder picker. En este post explico cómo hacerlo.

    Del portrait mode puedo mencionarles que no requirió ningún ajuste porque la auto organización que da WinRT ya es suficiente:

    image

    Pero sí quiero hacer una salvedad y es que no olviden además de manejar el código requerido para portrait dentro del manejador del evento OnSizeChanged, especificar en el Package.appxmanifest que la app soporta portrait mode (yo lo olvidé porque creí que con sólo escribir el código bastaba):

    image

    También les cuento que acabo de notar que aunque controlo muy bien el comportamiento de la ventana principal (donde manipulo las imágenes) en las distintas presentaciones, olvidé controlar la presentación de la primera pantalla en Portrait y Snap, así que se ve algo desquiciado en estos momentos (pruébenlo por ustedes mismos y observen qué cosas deberían corregirse; traten de pensar cómo lo harían). Para la versión 4 estaré corrigiendo esto y agregando un par de funcionalidades más.

    Manejo de Estados:

    Como novedad para la versión 3 de PhotoRanker, incluí que la app recordará en que foto íbamos. De manera que si el usuario se sale de la app o la cierra, cuando vuelva a abrirla, tenga la posibilidad de escoger si arranca desde donde estaba la última vez:

    image

    Como ven, tengo un botón destinado para esto. Así el usuario decide si arranca un trabajo nuevo o continúa con el último que estaba haciendo. Esto es muy útil, pues en realidad le da mucha agilidad a la app. En otros escenarios, no es tan lógico preguntar si se quiere arrancar desde el último estado, sino que de inmediato cuando se vuelve a abrir la app, pasamos a este estado. Aquí en mi app sin embargo, sí quise dar la opción. Otros asuntos que guardo, es por ejemplo la elección del usuario de hacer auto-advance mientras hace rating a las fotos. Esta opción de auto-advance, permite que tan pronto el usuario hace tap sobre una estrella para calificar, la siguiente foto sea cargada inmediata y automáticamente, para agilizar así aún más el proceso. Así pues, el valor de esta opción queda almacenado y la app siempre lo recuerda y usa, hasta que el usuario cambie dicho valor.

    El proceso de almacenamiento de settings y valores de variables es supremamente sencillo:

    Windows.Storage.ApplicationData.Current.
    LocalSettings.Values["AutoAdvance"] = true; Windows.Storage.ApplicationData.Current.
    LocalSettings.Values["LastIndex"] = 45;

    Y recuperar los valores es exactamente igual, eso sí haciendo el respectivo Convert, dado que los valores son almacenados como objetos.

    Splash  Screen Animado

    Una muy buena forma de arrancar impactando con nuestra app, es extendiendo el splash screen para que no sea una simple imagen estática, sino que podemos agregar una animación que “entretenga” al usuario mientras ejecutamos por ejemplo algunas cargas iniciales.

    Por naturaleza el Splash Screen de WinRT no se puede animar. Lo que sí se puede hacer, es una simulación de animación, ubicando una nueva página que inicialmente se vea exactamente igual al Splash Screen y luego allí haciendo las animaciones requeridas.

    Esto es fácil de lograr comprendiendo el mecanismo.

    Sucede que cuando la app arranca, se dispara un evento llamado OnLaunched en el App.xaml.cs. Ese evento trae unos argumentos args. Y dentro de estos argumentos, viene una referencia al SplashScreen que no es más que la imagen que especificamos en el manifiesto de la app para serlo.

    Este objeto splash screen tiene entre otros atributos, un rectángulo llamado ImageLocation que determina exactamente las coordenadas en las que se encuentra la imagen que hemos escogido para mostrar. Obviamente, la importancia de este rectángulo radica en que basados en sus coordenadas, ubicaremos la imagen en una nueva página que es donde ejecutaremos la animación:

     


    var splashImageRect = splash.ImageLocation;
    extendedSplashImage
    .SetValue(Canvas.LeftProperty, splashImageRect.X);
    extendedSplashImage.SetValue(Canvas.TopProperty, splashImageRect.Y);
    extendedSplashImage.Height = splashImageRect.Height;
    extendedSplashImage.Width = splashImageRect.Width;

    De esta manera obtenemos una página idéntica al Splash Screen, sobre la cual ejecutaremos una animación mientras hacemos la carga inicial.

    Asincronía

    Y ya que mencioné animaciones mientras se carga “algo”, de inmediato se me viene a la mente la asincronía. Porque efectivamente estoy hablando de un hecho en el cual asíncronamente se muestra una animación mientras se cargan elementos en memoria por ejemplo. Todo esto sin bloquear la interfaz del usuario, para que éste no sienta que la app es un ladrillo lento y no se aburra… y no desinstale… y recomiende. Es por esto que la asincronía es tan importante en las apps de WinRT. Es un mecanismo súper importante para lograr apps Fast and Fluid. Premisa número 1 de las Windows Store Apps. Sin ella, la interfaz se congelaría a menos de que usaramos complejos procesos con threads y demás.

    Precisamente para aprovechar el splash screen y cargar los settings del usuario, lo que hago es generar una animación, mientras en otro hilo a través de un método asíncrono inicio la ejecución del proceso de carga de una manera muy sencilla.

    Para comprender mejor este tema, les recomiendo este post, donde explico de una manera bien elemental éste proceso.

    De manera similar resuelvo situaciones en las que la app debe tomarse su tiempo, para que el usuario siempre sienta que la app le responde adecuadamente (por ejemplo cuando se lee el directorio con las fotos que se van a rankear)

    Conclusiones

    He tratado en este artículo de mostrar de una manera bastante informal, las principales experiencias que he tenido publicando una app con cierto nivel de complejidad en el Windows Store. La idea es que ustedes se puedan llevar algo de este conocimiento y que además les sirva para tener nuevas ideas a implementar en sus apps.

    Espero a medida de que mi app va evolucionando, ir escribiendo continuaciones a este post que sirvan para enriquecer el conocimiento de la comunidad en cuanto a apps se refiere.

    Las apps, a diferencia de otros tipos de desarrollo, son individualizadas con un dueño perfectamente identificado… por eso afirmo que una app es un hijo digital del developer… es su descendencia.

    Procuremos tener una descendencia remarcable. Sonrisa

  • WarNov Developer Evangelist

    Windows Store: Un análisis

    • 0 Comments

    El Windows Store a un mes de haber sido lanzado, se ha estado convirtiendo en un importante canal de distribución digital de software.

    Este protagonismo entre otras cosas ha causado que empresas independientes como Distimo que se dedican al estudio independiente de la industria de las apps a nivel mundial, lo hayan estudiado, considerándolo un importante actor en el mercado.

    Este artículo está basado en los estudios publicados por Distimo para el fin de Noviembre de 2012, sobre nuestro store. Esto, con el fin de mostrar un punto de vista no sesgado, sino imparcial, toda vez que la firma mencionada es independiente de cualquier proveedor de tiendas de Apps online.

    Los principales hallazgos incluyen:

    1. Hasta hoy, el número diario de descargas de las 300 apps más importantes del Windows Store, es tres veces mayor al que se experimenta con las 300 Apps más populares del Apple Mac App Store. Sin embargo, al mirar las apps pagas, se están comprando más en éste último. No obstante, es de notarse que ya están comenzando a arribar apps como Angry Birds, Fruit Ninja y Microsoft Office que pueden cambiar rápidamente esta proporción:

    image

    2. Microsoft está haciendo un gran trabajo para darle mayor visibilidad al contenido local en el store. En general, 10% de todas las Apps en los ranking locales, son apps locales. Y esta tasa aumenta viendo países pequeños. Por ejemplo en Japón, el 41% de las top apps son locales.

    3. El Windows Store presenta hoy 21.183 apps en total. De estas solo el 65% están disponibles en Estados Unidos. Aquí para efectos comparativos, cabe mencionar que en el resto de stores, la proporción es de 85%. De estas, 21.129 están disponibles para x86, 21.175 para x64 y 19.657 para ARM.

    4. El Windows Store, ha sido el que ha tenidos más apps disponibles tras su primer mes de lanzamiento (20K). El número para la Apple Mac App Store fue de solo 13K.

    5. Comparación con otros mercados:

    image

    Obsérvese por ejemplo que en solo un mes, el Windows Store ha mostrado tener más apps que todo el Apple Mac App Store durante casi dos años.

    6. Paid vs Free:
    Según el estudio, el Windows Store es aquel con una mayor proporción de apps free: 86% En el Google Play, el porcentaje es de 35% y en el Apple Mac App Store es del 16%.

    7. Porcentaje de Apps locales populares

    image

    Aquí resulta bien interesante mostrar por ejemplo que en Colombia ya se está proporcionando mucho impulso a las apps locales.

    8. Top 10 de publishers a nivel Mundial:

    image

    9. Top 10 de Apps en Colombia

    image


    10. Conclusiones

    “Observando estos primeros hallazgos acerca del Windows Store, es claro que existe mucho potencial y esto no es solo debido a que el número de consumidores crecerá inmensamente debido al gran alcance que tiene Windows, sino también debido a que Microsoft se ha apropiado de las mejores prácticas en la industria de apps y las ha implementado bien. Dividir el mercado del desktop y las tablets y además estableciendo un alto foco en el contenido local, también es una estrategia promisoria.¨

  • WarNov Developer Evangelist

    Tarde de Tecnología

    • 0 Comments

    Este jueves 22 de noviembre estaremos en Cali en una edición más de nuestro Microsoft Tech Day.

    Tendremos como es acostumbrado, dos tracks. Uno de Developers y otro de ITPros. La programación es esta:

    image

    En cuanto al tema de desarrollo, estaremos viendo dos temas muy importantes que tienen que ver con el mundo de servicios para nuestras apps. La primera parte, nos mostrará servicios móviles provistos por Window Azure pensando precisamente en las apps, otorgándonos facilidades para la autenticación, notificaciones y almacenamiento. Luego veremos el nuevo framework de WebAPI que nos permite hacer servicios Web basados en REST de una manera bastante sencilla, y como ejemplo veremos cómo almacenar archivos de manera segura, desde nuestras apps a la nube de Windows Azure.

    No se lo pierdan, en el Hotel Sheraton.

    Regístrense gratis aquí.

  • WarNov Developer Evangelist

    Usando WebAPI para generar Azure SAS para tus apps

    • 0 Comments

    He venido escribiendo una serie de posts acerca de los diversos mecanismos que existen para poder subir archivos desde nuestras apps de Windows 8 o de Windows Phone a Windows Azure.

    En este artículo explico por qué es importante un mecanismo que nos permita autorizar solo por un tiempo determinado manejar un archive determinado en el Storage de Azure, de manera que no expongamos nuestra información de cuenta de storage a que un hacker la pueda descubrir hacienda ingeniería inversa de nuestras apps. Este mecanismo es lo que se conoce como Shared Access Signature de Windows Azure y no es más que una URL que tiene validez temporal, con la cual podemos consultar un archive, eliminarlo, modificarlo o crearlo.

    En este otro artículo, muestro cómo podemos usar los Mobile Services de Windows Azure para poder obtener dichas SAS. Es un mecanismo que nos permite ahorrarnos tener web servers y que escala muy bien, porque maneja muy poca transferencia. Además nos economiza la administración. Todo esto, versus tener un servicio web que reciba las fotografías y las envíe al storage de Windows Azure, ya que toda la responsabilidad de ese servicio recae sobre nosotros.

     

    image*Azure + Web + Apps

    Estas ventajas son muy válidas. Pero sucede que para poder ejecutar los Mobile Services, se requiere por el momento, tener una base de datos de SQL Azure, y esto puede generar costos adicionales. Además, Mobile Services se encuentra en etapa de preview, por lo que salir a producción usándolos, puede ser riesgoso.

    Por estos motivos, he creado este post, en el que explico una manera alternativa para que nuestras apps puedan acceder a las codiciadas SAS, para poder subir archivos a Azure.

    Dado que las SAS son fácilmente generables a través del API de Storage de Azure: Microsoft.WindowsAzure.StorageClient,  es muy fácil pensar en un servicio Web que use esta API para retornar la SAS, dado un nombre de blob determinado. Y es esto precísamente lo que vamos a hacer. Pero será un servicio web muy liviano y además que permita un fácil acceso desde diversas plataformas. Todo esto se logra gracias a WebAPI. Un framework basado en ASP.NET para poder exponer construir de manera sencilla Servicios HTTP disponibles para una gran variedad de clientes que manejan REST.

    Como el framework es muy liviano y el proceso a ejecutar también lo es (solo se recibe una palabra y se retorna una URL), entonces es totalmente plausible que éste servicio se despliegue en un par instancias pequeñas de Windows Azure y soporte muy buena carga. De hecho, cuando los Windows Azure WebSites ya salgan de preview y comiencen a estar en producción, tendremos una alternativa aún más económica ya que está basada en servidores compartidos que luego pueden escalar y convertirse en servidores dedicados si las exigencias de nuestras apps así lo demandan. De hecho, algo que hoy en día existe que es la posibilidad de tener hasta 10 WebSites gratuitos, se mantendrá cuando el servicio pase a producción. En ambos casos (tanto con Cloud Services como con WebSites), nos ahorramos el despliegue de una Base de Datos y tenemos un poco más de control que con los Mobile Services.

    Aprovecho en este punto entonces para hacer notar que he mostrado varias opciones y ninguna de ellas es la absolutamente recomendable para todos los casos. Las condiciones de cada problema son particulares y por ende lo son sus soluciones. Mi misión es mostrarles las posibilidades. La de ustedes, elegir inteligentemente.

    Entonces continuando con nuestra solución basada en WebAPI tenemos nuestro controlador:

    SERVER:

    public class SASController : ApiController
    {
    
        //Esto es solo un ejemplo y pongo aquí directamente
        //los datos de la cuenta de acceso. 
        //Estos deberían estar en el config encriptados.
        static CloudStorageAccount _account;
        static bool _accountSet=false;
    
        //En bien se construye la clase, se trata de ajustar
        //la cuenta de almacenamiento de Azure
        static SASController()
        {
            string accountName = "tunombredecuenta";
            string pak = "fP4fXF9Vg...";
            _accountSet = CloudStorageAccount.TryParse(
                String.Format("DefaultEndpointsProtocol=https;"+
                "AccountName={0};AccountKey={1}",
                accountName,
                pak), out _account);
        }
    
    
        // GET api/sas/nombredeblob
        public string GetSAS(string id)
        {
            //Si la cuenta ha sido ajustada correctamente
            if (_accountSet)
            {
                //Creamos un container por defecto. 
                //Se puede trabajar tambien como parámetro
                var container = _account
                    .CreateCloudBlobClient()
                    .GetContainerReference("testcontainer");
                container.CreateIfNotExist();
    
                //Obtenemos una referencia al blob que se subirá
                var blob = container.GetBlobReference(id);
    
                //Creamos la sas que da permiso únicamente 
                //para ese blob, y solo por dos minutos
                //qué seguro no?
                var sas = blob.GetSharedAccessSignature
    (new SharedAccessPolicy() { Permissions = SharedAccessPermissions.Read | SharedAccessPermissions.Write, SharedAccessExpiryTime = DateTime.UtcNow +
    TimeSpan.FromMinutes(2) }); //Armamos la url en la cual podremos
    //poner el blob desde el cliente
    return blob.Uri.AbsoluteUri + sas; } else return "The API has not been configurated yet, "+ "pray to the heavens for them to configure it"; } }

    Vemos como solo bastó importar la librería del API de Storage, inicializar la cuenta de almacenamiento a través de un constructor estático y luego en la acción Get del controlador SAS usar la cuenta inicializada para producir la SAS basados en el nombre del blob que nos llega como parámetro “id”. Le dejé ese nombre para hacer prevalecer el paradigma de “Convention over Configuration”que al igual que en MVC, está muy presente en WebAPI.

    Vemos cómo es posible configurar el tipo y tiempo de acceso que otorgará la SAS. Todo eso queda incluido en la URL que se retorna al cliente. Algo del tipo: https://cuenta.blob.core.windows.net/img/archivo.jpg?sv=201324kjn,mnetc

    Con esta URL luego el cliente lo único que tiene que hacer es instanciar un HTTPClient y a través de este, poner el contenido del archivo con los headers específicos en dicha URL. Veámos el código de una app de Win8 para este fin:

    CLIENT

     

    //Escogemos el archivo
    var filePicker = new FileOpenPicker();
    filePicker.FileTypeFilter.Add(".jpg");
    var file = await filePicker.PickSingleFileAsync();
    
    if(file!=null)
    {
        //Con un cliente http nos comunicamos
        //al web api para bajar la SAS
        //luego con ese mismo cliente subimos el archivo
        using (var client = new HttpClient())
        {
            //Bajando la SAS
            var sas = await client.GetStringAsync
                ("http://localhost:47805/api/sas/" + file.Name);
            sas = sas.Substring(1, sas.Length - 2);
    
            //Cargamos la imagen con el HttpClient al blob 
            //service usando la SAS obtenida desde WebAPI
    
            //Obtenemos el stream de un storage file definido anteriormente
            using (var fileStream = await file.OpenStreamForReadAsync())
            {
                var content = new StreamContent(fileStream);
                content.Headers.Add("Content-Type", file.ContentType);
                content.Headers.Add("x-ms-blob-type", "BlockBlob");
    ”
    //Con el PutAsync, enviamos el archivo a Azure //a través de la URL autorizadora que está en SAS using (var uploadResponse = await client.PutAsync(new Uri(sas), content)) { //Agregar cualquier post proceso adicional } } } }

    Con el HTTPClient hemos descargado la SAS luego de tener el archivo escogido con su nombre identificado y luego aprovechamos ese mismo HTTPClient para poner el contenido del archivo al cual le hemos añadido unos headers para que pueda ser manejado correctamente por los Servicios REST del storage de Azure. Es importante notar aquí que la transferencia del archivo se realiza directamente desde el cliente a los Servicios de storage de Azure. El servicio web solo da la SAS. Esto es económico, veloz y escalable.

    Quise usar el anterior ejemplo para mostrar un escenario de uso de WebAPI. Pero a decir verdad, hay otra manera aún más liviana de lograrlo y es a través del uso de un manejador genérico de ASP.NET o ASHX. Un ASHX solo requiere de la Plataforma más elemental de ASP.NET (no requiere un motor de ruteo por ejemplo) para funcionar y lo hace también a través de la versatilidad de HTTP. Además el código es idéntico, except que el nombre del blob ya no va embebido en la ruta del request sino como un parámetro del querystring y el método como tal ya no va como una acción dentro del controller, sino como el ProcessRequest del handler.

    Summary:

    En conclusión, hemos visto cómo producir SAS desde Servicios web basados en HTTP, como lo proveen la WebAPI y los Generic Handlers. Luego vimos cómo usar esas SAS para poder subir archivos desde nuestras apps a Azure.

     

  • WarNov Developer Evangelist

    Adicionando archivos de Apps al Storage de Azure con Mobile Services

    • 0 Comments
     
    Los Windows Azure Mobile Services, proveen un mecanismo para permitir que clientes móviles (por ahora Windows 8, Windows Phone y iOS) se conecten a Windows Azure para almacenar y leer información tabular. Además ofrecen funcionalidad de push notifications, logging y autenticación.

    Pero cómo benefician estos servicios a la necesidad de poder almacenar archivos en el storage?

    En este post están los detalles que permiten justificar que para acceder a una cuenta de Storage desde un dispositivo es muy riesgoso dejar allí los datos de la cuenta de Azure, pues pueden ser extraídos con Ingeniería Inversa. Además de que el acceso se dificulta por falta de un API que abstraiga el acceso a REST directo. Windows Azure entonces dispone de un mecanismo llamado “Shared Access Signature” o SAS, que proporciona unas credenciales temporales para que se pueda acceder al storage.
        
    Tener un servicio Web que reciba las imágenes y desde su memoria las suba al storage de Azure de manera segura, es una opción, pero muy poco escalable, porque puede que miles de usuarios quieran subir sus fotos. Disminuir la carga del web server haciendo solo que exponga las credenciales SAS a los dispositivos para que estos luego puedan acceder directa y fácilmente al storage es mejor opción, pero sigue siendo algo cara, pues requiere un web server y un desarrollo asociado, así como todo el overhead de mantenimiento.
        
    Entonces la idea es aprovechar los Mobile Services para obtener esta SAS.
        
    No obstante, en las funcionalidades que mencioné, en ninguna está la del suministro de la SAS. Pero aquí es donde la imaginación y el ingenio juegan parte importante. Lo que sí mencioné es que se puede acceder a unas tablas a leerlas o modificarlas. Para ello se han dispuesto unas APIs especialmente diseñadas para WP y WinRT; hasta para iOS hay versión. Y en las tres plataformas pueden ser incluidas y usadas sin ningún problema de funcionamiento ni certificación cuando la app se sube al store. Pues bien, las operaciones CRUD que hacemos sobre estas tablas (que se pueden diseñar desde el portal de administración de Azure sin código alguno), están sujetas a que se ejecuten triggers que se dispararán cuando nosotros lo especifiquemos. Por ejemplo, cuando haya una inserción. En últimas esto se puede tomar como un servicio web asíncrono, en el cual insertamos un request en la tabla y luego la volvemos a consultar para ver la respuesta obtenida, que obviamente se encontrará en otra columna.
        
    El primer paso entonces, es crear el Mobile Service en el portal de Windows Azure. Esto es totalmente gratuito. Solo es requerido crear una cuenta, cosa que también es gratis. Un paso a paso muy bien elaborado lo pueden encontrar aquí.
        
    Básicamente lo que hicimos en ese paso a paso, fue crear el servicio y luego desde el portal, usar unas funcionalidades muy útiles que tenemos allí, como la de crear automáticamente nuestra primera tabla de datos. Y luego bajarnos una solución preconstruida que va a consumir esa tabla. Esa solución puede ser para phone, Windows 8 o iOS.
        
    clip_image002
    Obviamente, también podemos conectarnos a apps existentes. No solo a nuevas. Con este fin el portal nos suministra un código con una clave que debe tener la app para poderse conectar. Este código en el caso de Windows 8 por ejemplo, se pone en el App.xaml.cs:
    //This MobileServiceClient has been configured to communicate
    //with your Mobile Service's url and application key.
    //You're all set to start working with your Mobile Service!
    public static MobileServiceClient MobileService =
    new MobileServiceClient( "https://warserv.azure-mobile.net/", "ElSmsvstPUsdXWsHJqFteqhkLxDVcdr15" );

    Obviamente para que el código nos funcione, debemos de haber referenciado la dll que contiene el tipo MobileServiceClient. Esta dll ya viene agregada si nos bajamos la solución de ejemplo del portal. Si estamos habilitando una solución preexistente, la incluimos manualmente. Se llama Windows.Azure.Mobile.Services.Managed.Client y queda disponible luego de que instalemos el Mobile Services SDK.

    Después de esto, nuestra app ya queda lista para conectarse directamente con el servicio y empezar por ejemplo a hacer inserciones en la tabla que construimos en el paso a paso (o cualquier otra tabla que creemos dentro del servicio usando el portal).
        
    Ahora lo que haremos es generar el trigger para nuestro servicio, de manera que cada vez que exista un insert, se dispare una rutina que nos retorne dentro de ese registro insertado, la SAS que necesitamos. Esta rutina la debemos escribir con Javascript, que se ejecutará en el server, a través de un editor online que tenemos en el portal. Para acceder a ese editor, ubicamos nuestro servicio y luego allí escogemos la tabla en cuestión (1). Después vamos a SCRIPT (2) y finalmente escogemos la operación (Insert) de esta manera, ejecutaremos la acción especificada en el script con cada insert que hagamos en la tabla.
        
    clip_image003
        
    El código del script lo pueden descargar de aquí. Y la parte más importante del mismo es ésta:
       
    function insert(item, user, request) {
        var accountName = '<SU NOMBRE DE CUENTA>';
        var accountKey = '<SU PAK>';
    
        //Note: this code assumes the container already 
    //exists in blob storage. //If you wish to dynamically create the container then implement
    //guidance here -
    //http://msdn.microsoft.com/en-us/library/windowsazure/dd179468.aspx
    var container = 'test'; var imageName = item.ImageName; item.SAS = getBlobSharedAccessSignature(accountName,
    accountKey, container, imageName); request.execute(); }
    Como ven, tienen que poner los datos de la cuenta en los placeholders. También se aprecia que el ítem insertado viene como parámetro. Y que luego a ese ítem se le ajusta la propiedad SAS con una función que recibe el nombre de la cuenta, la clave, el contenedor y la imagen. Esto nos va a retornar una SAS que no es más que una URL que contiene unos permisos temporales implícitos, para que luego a esa URL podamos subir un archivo de nombre item.ImageName. Al final, vemos como se ejecuta el request y es en este momento cuando se inserta el registro como tal en la tabla del servicio. Además el ítem actualizado baja al cliente automáticamente y desde allí podremos consultar el valor de la SAS.
        
    Entonces, para el manejo desde nuestra app, necesitamos una clase que nos represente al ítem:
        //la estructura de la tabla que tenemos
        //en el Mobile Service. 
        //Es una clase generada por nosotros 
        //de acuerdo a nuestras necesidades.
        public class TodoItem
        {
            public int Id { get; set; }
    
            [DataMember(Name = "text")]
            public string Text { get; set; }
    
            [DataMember(Name = "ImageName")]
            public string ImageName { get; set; }
    
            //Es en este campo, donde quedará almacenada la SAS
            [DataMember(Name = "SAS")]
            public string SAS { get; set; }
    
            [DataMember(Name = "complete")]
            public bool Complete { get; set; }
        }
    
    Esta clase la creamos con los campos por defecto que se crean las tablas en Mobile Services, y le agregamos los campos requeridos.
        
    Luego de esto, cuando ya tenemos el archivo que queremos subir a la nube, lo que hacemos, es crear una inserción en la tabla:
    StorageFile file = await openPicker.PickSingleFileAsync();
    if (file != null)
    {
        //agrega un item a la tabla de Mobile Service, disparando un trigger
        //que retorna el item.SAS, como un valor en otra columna de la tabla,
    //que se transfiere automáticamente al ítem.
    var todoItem = new TodoItem() { Text = "test image",
    ImageName = file.Name }; await todoTable.InsertAsync(todoItem); items.Add(todoItem); //Cargamos la imagen con el HttpClient al blob //service usando la SAS generada en item.SAS using (var client = new HttpClient()) { //Obtenemos el stream de un storage file definido anteriormente using (var fileStream = await file.OpenStreamForReadAsync()) { var content = new StreamContent(fileStream); content.Headers.Add("Content-Type", file.ContentType); content.Headers.Add("x-ms-blob-type", "BlockBlob"); //Con el PutAsync, enviamos el archivo a Azure //a través de la URL autorizadora que está en SAS de la forma: //"https://--------------.blob.core.windows.net/test/
    //androidsmartglass.jpg?etc //donde etc es la cadena de validación
    using (var uploadResponse = await client.PutAsync(new Uri(todoItem.SAS), content)) { //Agregar cualquier post proceso adicional } } } }

    De esta manera, ya habremos podido subir nuestro archivo al storage de Azure, desde un cliente móvil, sin arriesgar nuestra cuenta de storage, sin sobrecostos por Servidores Web y de una manera absolutamente escalable, porque este request en total pesa menos de 1Kb. Mucho menos de lo que sería subir la imagen a un servidor, para que desde allí de manera segura se pudiese enviar al storage. Ahora, el envío es directo, de manera que es más rápido!

    En síntesis, hemos visto como entre las bondades de los Windows Azure Mobile Services, podemos contar con la capacidad de generar servicios sencillos basados en código de servidor escrito con Javascript que como input puede recibir un registro en las tablas de datos y como output una respuesta que queda almacenada en ellas en otra columna distinta. Si adicionamos a esto un trigger para cada inserción, obtendremos una respuesta asíncrona que hace que el Javascript que hemos escrito actuando sobre las APIs de Azure, permita entre otras cosas generar claves SAS, útiles para que dispositivos puedan acceder de manera segura y directa al storage.
  • WarNov Developer Evangelist

    Azure como backend de storage para Windows Apps y el poder de los Mobile Services

    • 2 Comments

    Con Windows Apps, me refiero a apps para el Windows Store y para el Windows Phone Store.

    El conocimiento promedio que tenemos hoy en día de Azure y de Cloud Computing, nos indica que una gran alternativa para las necesidades de storage que tienen las apps, efectivamente es el storage de Azure. Y uno va y mira y sí… efectivamente así es. Pero hay que tener en cuenta ciertos detallitos en los que podemos pecar por ir muy a la ligera.

    Si queremos ofrecer almacenamiento en nuestra app a través de una cuenta de Azure, lo primero que se nos vendría a la mente es: fácil, uso el API de Storage y la accedo desde mi app. Pero esto tiene dos implicaciones:

    http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-28-02-metablogapi/2816.image_5F00_32AEF2F2.png

    1. El soporte que se le da a la API desde las plataformas de desarrollo de WP y de WinRT: En este caso, lamento informar que el Microsoft.WindowsAzure.StorageClient.dll aún no está disponible para estas plataformas, pese a que en Web, WinForms, WPF, WCF y demás sí es completamente accesible. Esto nos deja con una sola alternativa y es la de usar REST puro y duro para acceder al storage de Azure. Es decir, crear clientes HTTP dentro de del código de la app y configurarlos para hacer un request REST sobre la API del storage (recordemos que esta API es nativa REST y por ende se puede acceder de esta manera). Tanto en WP como en WinRT es completamente viable esto, ya que tenemos las clases adecuadas. Sin embargo, configurar estos clientes no es fácil ni amigable. Algunos acercamientos como la librería Windows Azure Storage Client para Windows Phone disponible a través de NuGet, pueden ayudar a alivianar la tarea, encapsulando todos estos llamados. Desafortunadamente hoy no tenemos una equivalencia para WinRT. Tal vez mediante agunos hacks, uno pudiera usar esta de phone con Windows 8. Pero entonces viene el 2do. Punto a tener en cuenta:

    2. Independientemente de que hagamos los llamados a través de REST puro o usando una librería como la citada en phone, siempre debemos incluir la información de la cuenta para poder tener acceso a Azure. Tradicionalmente esto no es un gran problema, y digo tradicionalmente refiriéndome al hecho de que si estamos acostumbrados a crear aplicaciones de servidor que acceden a Azure, sabemos que los datos de la cuenta (nombre y clave) están “seguros” en nuestros servidores que están detrás de unos balanceadores de carga y unos proxies que lo protegen. Pero en el caso de las apps…. Te sentirías seguro sabiendo que el nombre y clave de tu cuenta de Azure está “quemado” en una app que probablemente hayan bajado cientos o miles de usuarios? Cualquier usuario malicioso, podría hacer ingeniería inversa de la app para extraer los datos de la cuenta (y aunque es complicado, no es imposible).

    Entonces, no hay una API oficial y tampoco es seguro embeber los datos de la cuenta en los clientes. Así que entonces la solución que se viene a la cabeza es: Hagamos servicios web!

    De esa manera, dado que WinRT y WP, tienen completo soporte a servicios web se podrán subir los archivos al servidor web y éste, que sí tiene el poder de usar la API de Storage de Azure, tendrá muy cómodo pasar estos archivos a la nube. Además, los datos de cuenta estarán seguros dentro del server, pues los clientes solo necesitan saber la dirección del servicio web.

    Pero realmente es esto lo que queremos? Tener un servidor Web, tiene costos asociados. Además tendríamos una sobrecarga sobre esos servidores recibiendo imágenes de Raimundo y todo el mundo. Por lo tanto requeriríamos varios servidores y los costos se elevarían enormemente. Sumémosle además el hecho de que el storage de Azure se puede acceder directamente y nos ahorraríamos todos esos costos.

    Entonces… cuál sería la solución apropiada?

    Se imaginan un mecanismo en el cual cada app pudiera tener un permisito que dure solo el tiempo requerido para ejecutar la acción necesaria sobre el storage y que luego ya no sea válida? En ese caso, por más que el hacker obtenga la clave, cuando lo haga, ya no le servirá de mucho.

    Pues para sus cuentas, les informo que Azure soporta el acceso al storage a través de este mecanismo, que particularmente se llama “Shared Access Signature” o SAS.

    Obviamente, para poder generar una SAS, se requiere tener los datos de la cuenta. Y volvemos al mismo sitio: no queremos exponer esos datos. Pero hay algo bueno! Si creamos un servicio web que nos retorne esa SAS (menos de 1K de tamaño), tendremos mucha menos sobrecarga que cuando usamos web services para transferir imágenes. En este caso, solo requeriremos una pequeña respuesta del server con la SAS y ésta la usaremos para que a través de un llamado HTTP (ésta vez mucho más sencillo que cuando se desea usar los datos de la cuenta nativa, ya que este requiere ser asegurado) en el que referenciamos dicha SAS podamos ejecutar la acción requerida sobre el storage (por ejemplo subir o bajar un archivo de los blobs, o consultar un registro de las tablas) sin necesidad de suministrar al cliente los datos de la cuenta.

    Entonces se podría decir que hallamos la solución! Ponemos un servicio Web a repartir SAS a las apps. Tal vez el servicio web haga alguna validación para decidir si responde positivamente al llamado. Y listo. La logramos!

    Esta situación la podríamos optimizar aún más. Dado que ahora la carga no será tan fuerte, podríamos entrar a analizar la posibilidad de usar web servers compartidos, disminuyendo enormemente los costos. Pero aquí tendremos que entrar a balancear costo contra disponibilidad.

    No sería mejor entonces tener un servicio pre-construido en la nube que ya nos proveyera la capacidad de emitir las SAS a las apps? Que nos quitara la necesidad de crear todo un web server para este fin?

    Sí, existe! Son los Windows Azure Mobile Services. Sevidores configurados para que clientes con una clave definida puedan entrar a escribir en unas tablas que quedan disponibles para este fin. Adicionalmente, también ofrecen servicios de Push Notifications y sobre ambos se pueden establecer estrategias para que solo usuarios autenticados puedan acceder a estos servicios.

    Subyacentemente, los Mobile Services tienen servidores web compartidos o dedicados que cuestan menos que los Web Sites de Azure. De hecho, hoy en día, se pueden tener hasta 10 Mobile Services gratuitamente. Estos servidores subyacentes, se pueden escalar a discreción. Aunque entonces parece que es lo mismo que tener los Web Servers tradicionales, la ventaja es que no tenemos que desplegar ningún código para que funcionen. La funcionalidad ya está en producción.

    No obstante, en las funcionalidades que mencioné, en ninguna está la del suministro de la SAS. Pero aquí es donde la imaginación u el ingenio juegan parte importante. Lo que sí mencioné es que se puede acceder a unas tablas a leerlas o modificarlas. Para ello se han dispuesto unas APIs especialmente diseñadas para WP y WinRT; hasta para iOS hay versión. Y en las tres plataformas pueden ser incluidas y usadas sin ningún problema de funcionamiento ni certificación cuando la app se sube al store. Pues bien, las operaciones CRUD que hacemos sobre estas tablas (que se pueden diseñar desde el portal de administración de Azure sin código alguno), están sujetas a que se ejecuten triggers que se disparán cuando nosotros lo especifiquemos. Por ejemplo, cuando haya una inserción. En últimas esto se puede tomar como un servicio web asíncrono, en el cual insertamos un request en la tabla y luego la volvemos a consultar para ver la respuesta obtenida, que obviamente se encontrará en otra columna.

    De esta manera, imaginen entonces que queremos subir una imagen al blob storage de Azure. Así que a modo de request, insertamos el nombre de esa imagen en una tabla de un Mobile Service previamente configurado, a través de las apis mencionadas.

    El servicio tiene un trigger sobre las inserciones. Y ese trigger detecta que hubo una inserción. Entonces ejecuta un código de servidor basado en Node.js (Javascript en el Server). Este código es suministrado por nosotros. Lo escribimos en el portal de administración de Azure; en la sección de configuración del servicio. Es así como podemos escribir un código que nos inserte en el mismo registro de la tabla la SAS que requerimos para acceder al container en el que queremos poner el archivo. Entonces cuando ordenamos la inserción asíncrona, pasamos el ítem a insertar y cuando termina esa inserción, podemos obervar que el ítem ya traerá la SAS que hemos generado.

    Luego usando esa SAS subimos el blob con tres líneas de código y ya está!

    En síntesis:

    Para poder acceder al storage de Azure desde apps sobre las cuales no tenemos control una vez han sido descargadas de las distintas tiendas de aplicaciones, la mejor alternativas es usar las SAS de Azure. La alternativa más cómoda y económica para obtener esas SAS, viene siendo los Mobile Services de Azure a través de las tablas de datos, ya que se proveen APIs de acceso a esas tablas que funcionan muy bien en WP7, Win8 y iOS. Con la SAS accedemos de manera segura para todos al storage.

    Una vez comprendido esto, continuemos con un paso a paso de cómo desplegar una solución de este tipo, en este post:

    Cómo adicionar archivos al Blob Storage de Windows Azure desde Windows Apps, a través de Mobile Services.

  • WarNov Developer Evangelist

    SQL Azure BACPAC - DB BACKUP en la nube (Nuevo Portal)

    • 0 Comments

    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 Nuevo portal de Administración Windows Azure, en la sección de Bases de Datos, existe una opción para exportar una db existente, lo que nos produce un archive BACPAC que es almacenado en una de nuestras cuentas de almacenamiento de Azure. Además cuando se va a crear una nueva DB, se da la opción de importarla desde un BACPAC existente.

     

    Por ejemplo para exporter, nos ubicamos sobre la db a exporter y le damos click o tap a Export, lo que nos muestra el siguiente cuadro de diálogo:


    newbacpac


    Esta operación requiere una cuenta de almacenamiento de Windows Azure para guardar esa copia BACPAC en el blob storage. En este caso, debemos especificar los datos de la cuenta y el container dentro de esa cuenta donde va a quedar la copia BACPAC.

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

    image

        

    Una vez creada la copia, podemos importer a través del botón que tiene ese nombre en la sección de Databases del portal, o a través de las opciones de crear una nueva DB:

    newimport1

    Luego de esto específicamos la ruta dentro del almacenamiento de Azure  donde dejamos el bacpac.

    newimport2


    newimport3

    Luego de esto, comienza la importación de la DB

    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

    Cómo agregar y consultar info personalizada a Bing Maps

    • 0 Comments

    Bing Maps tiene abiertos sus servicios de mapeo, para que los desarrolladores puedan hacer uso de ellos. Como vemos en esa breve reseña del servicio, se tiene un tipo de cuenta gratuita (developer) para trabajar con estos servicios y otra paga (Enterprise).

    Cuando trabajamos con una cuenta de developer, solo podemos usar datos que ya tiene Bing Maps en sus bases de datos. Pero puede que nuestra necesidad de negocio requiera mapear puntos propios del negocio que no están en Bing Maps. Por ejemplo para tenerlos en un caché y que se dibujen siempre sin necesidad de requests adicionales a los servidores. Puede que además necesitemos obtener información personalizada y extendida de esos puntos personalizados y queramos hacver consultas sobre esa información. En ese caso, deberemos subir nuestra información a Bing Maps. Esta funcionalidad es brindada por Bing Spatial Data Services que solo es accesible en la versión Enterprise.

    Estos servicios proveen la funcionalidad de tener puntos de interés preestablecidos a través de fuentes de datos propias y generar diversas consultas tradicionales o geoespaciales sobre ellos. Aquí podemos encontrar algunos ejemplos de las implementaciones posibles.

     

    Las fuentes de datos personalizadas son accesibles muy fácilmente a través de directorios online que contienen ubicaciones (lat/long, campos de dirección y otros campos personalizados). Estos son creados cuando subimos y publicamos un archivo que contiene estos datos en un esquema estándar. Esto se hace a través del portal de Bing Maps o con el uso del API de administración de fuentes de datos.

    En conclusión, para poder manejar nuestros propios puntos como si fueran originarios de Bing Maps, hemos de subirlos a la nube de Bing Maps, a través de Bing Maps Data Services; una solución solo disponible para usuarios de tipo Enterprise.

  • WarNov Developer Evangelist

    Obteniendo lo mejor de Bing Maps en la Web

    • 1 Comments

    Los servicios de Mapas de Bing para desarrolladores nos ofrecen un conjunto enriquecido de herramientas para crear grandes experiencias basadas en mapas. Estos servicios están disponibles a través del veloz control de AJAX, una API de servicios basada en REST, un SDK para crear mash-ups y además SDKs móviles para Windows Phone, Android, iOS y  Windows 8.

    Enfocándonos ya en la alternativa para la web, a través del control de AJAX, existe un gran conjunto de operaciones disponibles que pueden apreciarse en vivo aquí. Podemos ver cómo se pueden crear mapas con sus opciones, añadir pushpins, figuras, capas, infoboxes, hacer consultas, ejecutar geolocalización, visualizar tráfico y direcciones para llegar, administrar datos espaciales y muchos más.

    Para usar estos servicios gratuitamente, se puede crear una cuenta de developer for free que permite el acceso a todas estas características siempre y cuando sea para sitios web públicos no protegidos con password con 125,000 sesiones o 500,000 transacciones por año. Esta es una excelente alternativa para probar los servicios, o usarlos en sitios públicos de un uso no tan alto.

    Sin embargo, ya en ambientes empresariales o de servicios a consumidores masivos, estos límites son sobrepasados y se requiere una alternativa más amplia. Esta se obtiene a través de una cuenta de tipo Enterprise, que es paga.

    Además de los límites de uso, otras ventajas que tienen las cuentas Enterprise las podemos encontrar aquí.

  • WarNov Developer Evangelist

    Cómo cambiar el nombre de una suscripción de Azure

    • 0 Comments

    Si ustedes como yo han tenido que manejar muchas cuentas y suscripciones de Azure al tiempo, habrán observado que muchas veces las suscripciones quedan con el mismo nombre y luego se hace muy difícil identificar cuál es cuál. Por ejemplo manejando las tools para consola bien sea desde Windows, Linux o MAC.

    Bien, esto se puede corregir sencillamente cambiando el nombre de la suscripción desde el portal de administración: https://account.windowsazure.com/subscriptions

    Allí se debe ingresar con la cuenta a través de la cual se adquirió el servicio (no es posible usar una cuenta de administrador asociada). Damos click sobre la suscripción que deseamos modificar y esto nos lleva al sumario de dicha suscripción. Al final de la página encontramos un conjunto de acciones disponibles:

    image

    De esas acciones escogemos Edit Subscription Details

    Y allí podremos cambiar el nombre de la suscripción y el administrador de la misma:

    image 

  • WarNov Developer Evangelist

    Usa el simulador de Windows 8 a discreción

    • 0 Comments

    Solo para recapitular un poco, recordemos que en Windows Phone, la aplicación que simula al aparato para poder hacer pruebas, se llama Emulator. La de Windows 8 se llama Simulator.

    El Emulator queda agregado al menú inicio automáticamente, tras la instalación del SDK, de manera que para abrirlo tanto en Windows 7 como en Windows 8 basta con escribir en el search: Emulator y luego seleccionarlo. Esto nos abre inmediatamente el emulador.

    Sin embargo, con Windows 8 no sucede esto. El Simulator, no queda agregado al menú inicio. Pero esto no quiere decir que no se pueda ejecutar independientemente de Visual Studio. Lo único que debes hacer es buscarlo y anclarlo de esta ruta si quieres:

    C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Simulator\11.0\Microsoft.Windows.Simulator.exe

    Para qué correr el simulador independientemente?

    image

    Esto te puede ser útil para sacar screen shots de las pantallas de la interfaz moderna, o probar apps de las que solo te han pasado el paquete, desde un entorno simulado en el que puedes cambiar resoluciones y demás.

  • WarNov Developer Evangelist

    Windows Apps: Para qué países debería publicarlas?

    • 2 Comments

    El Windows Store y el Windows Phone Store, nos permiten escoger los países en los que nuestras apps estarán disponibles. Podemos escoger uno o varios. Esta segmentación de países existe porque a veces queremos que nuestras apps estén en un solo país o en determinados países y además porque las leyes y costumbres de diversos países pueden provocar que el contenido de ciertas apps sea inaceptable.

    Esto nos lleva a que en general, cuando publicamos nuestra app, escojamos solo publicarla para el país objetivo, que la mayoría de las veces es el país del Desarrollo. Por decir algo, un desarrollador Colombiano, escoge publicar su app en Colombia únicamente.

    Esto no está mal, pero podría estar mejor… por qué?

    La mayoría de las apps están creadas en EEUU. Y los desarrolladores de allí, las han puesto solo disponibles para ese país. De manera que usuarios del resto del mundo que tengan configurado su store para sus países de origen (con un procedimiento como el descrito aquí), no las podrán ver. Es así como varios usuarios optarán por cambiar la región de su store a EEUU y de esa manera poder acceder a esas apps. Esto implica obviamente, que dejarán de ver las apps que solo estén creadas para el país de origen y no estén validadas para estar en EEUU.

    Entonces es aquí donde debemos tener en cuenta que si queremos que esos usuarios también encuentren nuestras apps, deberemos publicar nuestra app en EEUU también, aparte de haber seleccionado también nuestro país de origen. De esta manera aseguramos que tanto usuarios que tengan sus máquinas configuradas con nuestro país de origen, como aquellos que la hayan cambiado a EEUU, puedan encontrar la app.

    mapapp

    Desventajas? Ninguna. Podría pensarse que al poner la app en EEUU tendríamos crear una versión en Inglés para la misma. Pero este no es el caso. Podemos poner apps en cualquier idioma sobre cualquier país.

    En conclusión, si quieres que tus apps sean más visibles, aparte de ponerlas disponibles para los países target, piensa la posibilidad de ponerla disponible también para EEUU.

  • WarNov Developer Evangelist

    No encuentro apps de Windows 8 que mi amigo si tiene!

    • 2 Comments

    Cuando un desarrollador crea una app para Windows 8 y la va a publicar en el Windows Store, éste tiene la oportunidad de escoger el país o países para los cuales la quiere publicar. La mayor cantidad de apps (entre ellas las más populares), están publicadas solo para EEUU, por ejemplo. Entonces para poder accede a ellas, debemos modificar la ubicación de nuestra máquina, al menos mientras estas son descargadas. Luego podemos cambiar nuevamente la ubicación sin que las apps ya instaladas se vean afectadas. Ellas seguirán funcionando correctamente.

    Entonces por ejemplo si tu amigo tiene la app de eBay y tú no la encuentras, probablemente es porque a la hora de instalarla tu amigo tenía su Windows 8 localizado en Estados Unidos, y puede que tú por ejemplo lo tengas localizado en Colombia. Lo que tienes que hacer entonces es abrir el cuadro de diálogo de Location, buscando “region” en Settings y escogiendo “Region”

    image

    Esto te llevará a este cuadro de diálogo:

    Capture

    Y de aquí escogemos la región deseada:

    image

    Damos Apply, OK y luego volvemos a buscar la app que queremos.

     

    Ten en cuenta eso sí, que también te puede pasar el efecto contrario. Es decir: Dejaste tu Windows 8 en Estados Unido como Home Location por ejemplo y luego quieres instalar una app local que el desarrollador solo dispuso para Colombia. En ese caso, no la verás. Lo bueno eso sí, es que ya sabes cómo cambiar la ubicación a tu discreción!

  • WarNov Developer Evangelist

    Un Par de Curiosidades acerca del Snap View en Windows 8

    • 0 Comments

    La primera, es orientada a usuarios finales: Sabían que pueden cambiar el estado Snap de una App a través del teclado, sencillamente presionando Windows + .   (tecla Windows más tecla punto)

    Aquí aprovecho para contarles los shortcuts que más uso en Windows 8:

    • Windows+F para buscar de inmediato
    • Windows+I para pasar a settings de inmediato (allí encuentro el menu de apagar, por ejemplo)
    • Windows+C para abrir los charms y hacer por ejemplo un share
    • Windows+Z para abrir el appbar de una app, y ejecutar los comandos disponibles

    La segunda curiosidad es más orientada a desarrolladores y nos muestra cómo podemos obligar a restaurar la vista desde un estado de snap a un estado full, a través de código:

     

                //
                Windows.UI.ViewManagement.ApplicationView.TryUnsnap();
                //

    Pero… con qué fin?

    Sucede que en ocasiones ciertas funcionalidades de nuestras apps no funcionan o se ven correctamente en una visa de Snap por más que tratemos de contraer el espacio usado. En estos casos, recomiendo que cuando el usuario escoja dicha funcionalidad, tal vez mediante un tap, entonces obliguemos a la interfaz a expandirse para lograr el cometido.

  • WarNov Developer Evangelist

    3 Reglas de Oro para manejar archivos desde el código

    • 0 Comments
    Los archivos son elementos externos a los programas. De hecho, residen en elementos físicos que están fuera de los espacios lógicos de las apps o aplicaciones. Por ende, muchas situaciones inesperadas pueden ocurrir al trabajar con ellos. Aquí una tres puntos a tener en cuenta cuando manejamos archivos desde nuestros desarrollos, que no solo aplican para el sistema de archivos tradicional, sino también para el Isolated Storage de Windows Phone y el Local Storage de Windows 8.
    1. Las operaciones con archivos siempre deberían ir enmarcadas en un bloque try-catch para prevenir que excepciones inesperadas lleguen al usuario. Y en la medida de lo posible, cada excepción probable, ha de ser manejada por separado.
    2. Las operaciones con archivos siempre deberían ir enmarcadas en una sentencia Using, dado que esto provee una sintaxis conveniente que asegura una liberación de recursos efectiva. En el caso siguiente, vemos que no tenemos que preocuparnos por hacer dispose de los manejadores de stream. Esto también aplica por ejemplo a cadenas de conexión a bases de datos, que se pueden crear dentro de un using.
      using System;
      using System.IO;
      class Test
      {
          static void Main()
          {
              using (TextWriter w = File.CreateText("log.txt"))
              {
                  w.WriteLine("This is line one");
                  w.WriteLine("This is line two");
              }
              using (TextReader r = File.OpenText("log.txt"))
              {
                  string s;
                  while ((s = r.ReadLine()) != null)
                  {
                      Console.WriteLine(s);
                  }
              }
          }
      }
    3. Antes de usar un directorio o un archivo, chequee que éste existe. Las apis generalmente proporcionan elementos como File.Exists(); y Directory.Exists();
  • WarNov Developer Evangelist

    Algunas Verdades Útiles del Isolated Storage en Windows Phone 7

    • 0 Comments
    El Isolated Storage es el mecanismo ofrecido por Windows Phone para permitir que mantengamos el estado de nuestras apps, dado que para proteger el hardware, el software y al usuario de software malintencionado, el sistema de archivos convencional ha sido modificado para ser un esquema protegido en el cual una app no puede acceder a espacio de memoria física ni lógica de otras apps. Es así como el almacenamiento de cada app está completamente aislado de los espacios de almacenamiento de los demás y por eso recibe este nombre.

    Abundan posts y artículos que enseñan a usar el Isolated Storage: cómo almacenar y leer archivos y demás. Pero este post está dedicado a hablar de las circunstancias especiales que rodean al Isolated Storage y que en general solo la práctica lleva a concluirlas.

     

     
    • Si los espacios de almacenamiento están aislados, entonces cómo hacemos para que dos o más apps compartan datos?
      • En este caso la recomendación es almacenar los datos en la web o cloud, bien sea a través de web services o web apis.
    • Qué pasa con mi Isolated Storage, cuando le hago un update a la app? Se borra?
      • El Isolated Storage permanece intacto, así que la nueva versión de la app podrá seguir accediendo a los datos previamente guardados. Eso sí hay que tener en cuenta que si la app es desinstalada por parte del usuario, en ese caso el Isolated Storage desaparecerá. Por lo tanto si se desean mantener los datos, se recomienda hacer un update sencillo de la app, sin desinstalarla previamente.
      • Lo que si hay que tener MUY en cuenta, es que la nueva versión de la app esté capacitada para leer correctamente la data que estaba en el Iso; porque por ejemplo puede suceder que hayan serializado una clase en el Iso y luego en la nueva versión la estructura de la clase puede haber cambiado, lo que imposibilitará recuperar los datos almacenados. El desarrollador debe asegurarse de que todo funciona antes de subir la nueva versión de la app.
    • Qué cantidad de espacio tengo disponible en el Isolated Storage para mi app?
      • Tanta como para no ocupar más del 90% del espacio del teléfono.

    A pesar de que el Isolated Storage no es el FileSystem tradicional que conocemos, todas las buenas prácticas para manejar un sistema de archivos aplican. Las pueden observar en este post.

    • WarNov Developer Evangelist

      Soporte de Emergencia en Windows Azure

      • 0 Comments

      Este post es para responder a la pregunta:

      Qué pasa si tengo un caso de soporte supremamente urgente en Windows Azure? Cómo lo obtengo?

      Si estás en Colombia De lunes a Viernes y de 09:00 a 17:00, puedes llamar al 01-800-5-1-81409 donde te atenderán en ingles o en español.

      Si estás fuera de este horario, puedes llamar a Estados Unidos, donde te atenderán 24/7 en inglés: 1 (866) 676 6546.

      Otras opciones incluyen poner casos de soporte online en esta dirección.

    • WarNov Developer Evangelist

      SQLite: DB Locales en Win8

      • 5 Comments

      Hoy estuve charlando con Sorey Garcia acerca de la app que está creando para el lanzamiento de Windows 8. Me contaba que estaba implementando mucho en el backend, por que estaba siendo muy difícil para ella manejar información estructurada del lado del cliente, dado que la promesa de SQLite, que era la tecnología que se había puesto disponible por parte de terceros para este tipo de manejos, aún no estaba claramente desarrollada… sin embargo, eso hoy ya ha cambiado, y se lo hice saber:

      - Niña, hoy en día ya está completamente implementado!!!
      le dije… ella muy juiciosa y proactiva me respondió:
      - Súper! Voy a estudiarlo y a hacer un post, porque ya hace rato no escribo…
      - Eso sería excelente… - musité…
      - Porque yo iba a escribir ese post… te parece más bien si te invito al mío con el post que escribas??
      A ella le gusto la idea, y aquí está su post acerca de cómo usar SQLite en Win8:

      _________________________________________

      Sorey says:


      Aprovechando que hoy ando trabajando por estos días con Windows 8, hoy les traigo este tema que nos hizo sufrir a más de uno mientras esperábamos el RTM, en realidad esperábamos ansiosamente el wrapper de SQLite sin saberlo.

      SQLite es una biblioteca de software que implementa una en sí misma, sin servidor, sin necesidad de configuración, el motor de base de datos transaccional de SQL y su código fuente para SQLite es de dominio público.

      Pues bien, SQLite ahora está disponible para nuestras aplicaciones Windows 8 que requieren almacenamiento estructurado local. El dolor que teníamos es que hasta ahora no existía una implementación de un wrapper estable y aprobado por Microsoft, que nos permitiera usarlo en nuestras apps. Soy enfática en el tema de aprobado por Microsoft puesto que ya habían varias implementaciones por ahí que muchos estaban usando, sin embargo al enviar nuestras aplicaciones a ser certificadas para publicarse en el Windows Store, estas podían recibir observaciones. Sin embargo ya la librería oficial escrita en C++ y que nos provee todo el poder y funcionalidad de SQLite está disponible para nuestras apps.

      A continuación voy a hacer un ejemplo sencillo, paso a paso, mostrando como usarlo en una aplicación  Windows 8, este ejemplo está basado en el artículo publicado por Tim Heuer, una de mis fuentes recurrentes.

      Aclaro y soy muy enfática en ello, de la interfaz que use en el ejemplo, nada que ver con como debería ser una aplicación Windows 8, en este caso el ejemplo está más centrado en como usar SQLite.

      En primer lugar debemos instalar la extensión que nos permite usar la librería de C++ creada por el equipo de Windows. La encontramos en Tools > Extensions and Updates


      Luego buscamos los componentes en línea SQLite for Windows Runtime y la descargamos para que sea instalada en nuestra máquina.


      Se nos pide una confirmación, que aceptamos para proceder con la instalación.

       
      Visual Studio nos notifica que debemos reiniciar para que la extensión sea tomada.
       
       
      Reiniciamos y abrimos nuestro proyecto y seleccionamos la opción de añadir referencias.
       
       
      Debemos seleccionar SQLite y Microsoft Visual C++ Runtime para que la librería funcione correctamente.


      En mi caso Visual Studio reportaba un error, ya que debía seleccionar una plataforma específica a pesar de que en realidad se nombran todas las posibles en el mismo mensaje de error.
       

      Para corregir ingresamos a las propiedades del proyecto

       
      Y seleccionamos en la sección Build, la plataforma de destino.

       
      Ahora bien,  en este punto si tenemos el conocimiento podríamos acceder a la librería y usarla, sin embargo lo recomendado es buscar algún Wraper existente en C# como es mi caso, para no tener que lidiar con esto si no sabemos como hacerlo. Muchos de esos wraper se encuentran disponibles en NuGet. Si usamos VB debemos continuar los pasos hasta añadir el código del wraper, y compilar una librería en C# y luego referenciar esta desde nuestro proyecto VB.
       
      Para iniciar la instalación del wraper verificamos en las extensiones si lo tenemos instalado y si no procedemos a hacerlo igual que se hizo con el SQLite.
       

      Ahora bien ingresamos a NuGet para buscar un wrapper adecuado para nuestra aplicación.
       

      El wrapper recomendado en el artículo de base de este post es sqlite-net, lo seleccionamos e instalamos.
       

      Se nos pide seleccionar en que aplicación vamos a añadir el código, en este caso solo tengo un proyecto.
       
       
      Lo que sucede es que añaden dos API a nuestro código, una de ellas es una API que usa  Async , palabra que si no entiendes a este instante te recomiendo estudiar en Channel 9 o en el Blog de Walter Novoa
       
      En este post usaré Async, si quieres ver como usar la otra API, puedes ver el post de Tim Heuer o bien leer la documentación en español del Windows Developer Center

       
      Para esto también es muy importante tener los conceptos de objetos y ORM claros en tu cabeza. De hecho empezamos nuestro ejemplo construyendo la clase que mapea con la estructura de nuestra tabla de ejemplo. No debemos confundir la clase con la tabla, la tabla de hecho no la veremos, sin embargo es la clase quien nos ayudará a que finalmente se cree la tabla (esto solo suena enredado si no tienes claros los conceptos que te mencioné)
       
      La clase es sencilla, sin embargo podrás ver unos decoradores sobre ella
       
      Otros decoradores pueden ser AutoIncrement, MaxLength(30).

      Ahora creamos nuestra interfaz sencilla, les comparto el Document Outline para que se guien.
       

       
      Tambien pueden ver el XAML del formulario. Solo recuerden que hacer una aplicación Windows 8 requiere de mucho más, pero es bueno iniciar desde lo fácil.
       
      Aprovecho para recomendarles que aprendan a manejar Blend, de verdad es una gran herramienta para abstraernos un poco del arduo trabajo de hacer XAML, sin embargo es igual de importante entender y saber modifical el XAML cuando algo va mal.
       
       
      Ahora va el código del botón insertar como ven es bastante sencillo de usar cuando ya tienes el wrapper correcto.
       
       
      Aquí la aplicación funcionando.

       
      Luego tenemos el botón consultar que lleva un ListView los items de la base de datos, bastante sencillo tambien.

       
      Aqui vemos la aplicación mostrando los nombres registrados.

       
      Recuerden que hay mucho que hacer con respecto a las listas, y en XAML si sabemos manejar los enlaces correctamente podemos mostrar más información sin hacer más código, veamos un ejemplo de esto para terminar.
       
      Pueden modificar el DataTemplate del ListView así:


      Como mostraremos todo el objeto y no solo una parte de el modificamos el código.

       
      Y de esta forma podemos tener una lista con más forma, que de hecho podemos editar mucho mejor si usamos Expression Blend.

       
      Espero que este corto ejemplo les resulte de mucha utilidad. Nos vemos la próxima.
      ______________________________________________
       
       
      WarNov Says: Para estar al tanto de muchos otros posts muy buenos como este, les recomiendo que visiten el blog de Sorey.
       

      Sorey García es líder de la comunidad Avanet, MCS Gold en Colombia con especialidad de Windows Phone,
      Organizadora de Eventos como el Barcamp Medellin
      y también lidera la investigación tecnológica en su actual empleo.
    • WarNov Developer Evangelist

      Visual Studio 2012 – El Lanzamiento!

      • 0 Comments

      Para mí, Visual Studio no es solo un IDE. Es todo un micromundo al que me voy a vivir por noches enteras cuando inmerso en él, desarrollo soluciones que le van a hacer la vida más fácil a muchas personas.

      image

      Es una de las más poderosas herramientas para desarrollo construida por la humanidad y es fácil concluirlo si analizamos todo lo que nos ofrece:
      Desarrollo de aplicaciones de Consola, de Windows Forms, WPF, Silverlight, Web Sites, Web Applications, Web Services, Windows Services, Librerías de Clase, Windows Store Apps, Cloud Computing, Windows Phone, XBOX, DirectX, Office, Reporting Services, Sharepoint, Workflow y Lightswitch.

      Permite el desarrollo nativo y administrado para todas las plataformas soportadas por Microsoft Windows, Windows Mobile, Windows CE, Windows Phone, .NET Famework, .NET Compact Framework, Microsoft Silverlight y WinRT.

      El poderoso editor de código soporta IntelliSense y code refactoring para un desarrollo veloz y seguro. Además el debugger integrado puede funcionar a nivel de código y a nivel de máquina. Juntemos esto con los excelentes diseñadores: de interfaz gráfica, de web, clases, esquema de bases de datos, y ahora hasta Blend para Store Apps es incluido en el paquete sin instalar nada más!

      Y hay más: Soporte a diversos lenguajes: C/C++, VB.NET, C#, F#, motores de visualización web como HTML Simple, ASP.NET, ASP.NET MVC, y Razor y a través de instalaciones adicionales, M, Python, Ruby y muchos más. Además soporte a HTML, XHTML, HTML5, XML/XSLT, JavaScript, JSON y CSS3.

      Por si fuera poco, es totalmente extensible, con más de 3300 extensiones y plugins disponibles para descargar en la galería online; de manera que cada vez más y más funcionalidades se agregan a este micro mundo de desarrollo. Gracias a estos plugins es muy fácil en cualquier momento descargar componentes con código pre escrito, utilidades, herramientas y acceso por ejemplo a plataformas Open Source independientes como GitHub para administrar código fuente.

      Y hablando de administración de código fuente, basado en Visual Studio fue construido Team Foundation Server. Un servidor que se adapta perfectamente al IDE para poder hacer planeación y seguimiento del proyecto, así como control de código fuente, de ítems de trabajo y de evolución del proyecto, todo con una variedad de metodologías que incluyen tanto las ágiles como las convencionales.

      Visual Studio viene en todos los sabores de licenciamiento. Gratuito con: Versiones Express, Versiones Trial, Dreamspark, BizSpark, WebSiteSpark y las versiones con costo a través de las suscripciones MSDN.

      La historia de Visual Studio como IDE se remonta a Abril de 1995 cuando con la versión interna 4.0 se integraron por primera vez Visual Basic, Visual C++, Visual FoxPro y Visual SourceSafe. Ahora estamos con la versión interna 11.0 que con nombre Visual Studio 2012, se suma a todos los lanzamientos sin precedentes que hemos tenido este año, incluyendo mejoras como: Soporte a Windows Store Apps, LigthSwitch y Blend incluidos, editor de código completamente mejorado, exploradores renovados, mejoras en los editores web e inclusiones para tecnologías web modernas y muchas otras más, que pueden encontrar en este post. No se pierdan el lanzamiento online que estaremos presenciando el 12 de Septiembre.

    • WarNov Developer Evangelist

      Lidiando con la DeveloperStorage account en Azure

      • 0 Comments

      Todos sabemos que en Windows Azure existe una simulador de cómputo y otro del storage. Y que el simulador de storage usa tecnología SQL Server (puede estar en uno full, en una versión Express o hasta en LocalDB!

      Sabemos que si creamos un Cloud Service convencional, éste se autoconfigura para usar el Storage Emulator y luego uno cambia la conexión con datos de una cadena real.

      Pero si estamos hacienda una solución Azure bien personalizada (por ejemplo una app de consola que se conecta a Azure), entonces cómo hacemos para configurar este DevelopmentStorage manualmente?

      Primero un dato curioso y bien interesante:

      La Developer Storage Account tiene un nombre y un PAK (Primary Acces Key) bien definidos! Y son los mismos en cualquier lado que se use… por eso es obvio que no debemos usarla para producción. Pues bien, esos datos son:

      Account name: devstoreaccount1
      Account key: Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==

      Entonces ya tendríamos mucha de la información para armar la cadena de conexión manualmente… sin embargo, una conexión al storage de Azure es de la forma:

      "DefaultEndpointsProtocol={0};AccountName={1};AccountKey={2}"

      Así que nos faltaría indicar el DefaultEndpointsProtocol (en general es http o https); pero el Development Storage no soporta HTTP, así que no podríamos poner nada… la solución que nos da el SDK es que sencillamente como cadena de conexión escribamos: UseDevelopmentStorage=true así, sin clave, tal como aparece… de esta manera, nuestro proyecto siempre la tomará como la cuenta de acceso al Development Storage.

       

      Cuando ya necesitemos probar contra el storage real en Azure, ahí sí que tendremos un nombre y una PAK. Además decidiremos si enviamos por http o https. Y en ese caso, solo será necesario reemplazar los placeholders en la sentencia que describí. Al final en C# podríamos escribir:

      if (!CloudStorageAccount.TryParse(strConnection, out _storageAccount))

      Entonces si strConnection viene con el formato adecuado, el TryParse funciona y la cuenta de almacenamiento ya queda instanciada en _storageAccount, desde donde se podrán crear los clients de blobs, colas y tablas, independientemente si hemos pasado la cadena de DevelopmentStorage o la de un Storage en Azure.

      Para finalizar, si no requerimos comportamiento dinámico y sabemos que solo usaremos por ahora la cuenta del DevelopmentStorage podemos sencíllamente escribir:

      var account = CloudStorageAccount.DevelopmentStorageAccount;
    • WarNov Developer Evangelist

      Visual Studio 2012: What’s New.

      • 0 Comments

      Ya habrán leído en mi editorial para este mes del flash de MSDN por qué Visual Studio es todo un templo para desarrolladores.

      Tal como lo mencioné en ese post, aquí quiero profundizar acerca de solo algunas de las novedades que nos esperan con la versión Visual Studio 2012.

      Nuevo explorador de soluciones:

      Veamos un video que nos muestra sus nuevas características:

      Mejoras Generales:

      clip_image002

      La más obvia de todas, es la inclusión de los tipos de proyectos para Windows Store (apps WinRT). Para
      soportar estas apps, Blend ahora es incluido en la instalación de Visual Studio.

      Mejoras para el desarrollo Web:

      Nuevos templates, mejoras a los editores de HTML y CSS, inspector de páginas en vivo que muestra que parte de la página corresponde al código que se está viendo y nuevas herramientas de publicación. Grandes mejoras en el soporte a Javascript (IntelliSense, DOM Explorer y consola JavaScript).

      clip_image004

      Windows Phone 8:

      En bien sea liberado el SDK de WP8, el IDE lo soportará plenamente. Recordemos que se podrá elegir a que versión de Phone se quiere compilar: Windows Phone 7.X y 8.

      Windows Azure:

      Las mejoras incluyen soporte a caching distribuido, nuevas opciones de publicación, nuevos template4s y una instalación más liviana. Además integrándose con Team Foundation Server, se pueden generar escenarios de integración y despliegue continuo.

      Aplicaciones de Negocio

      Aquí hay grandes innovaciones. Por ejemplo en Sharepoint tenemos nuevos diseñadores para listas y tipos de contenido, nuevos templates para columnas y páginas Silverlight, así como nuevas opciones de despliegue. Adicionalmente ahora tiene características de ALM disponibles como profiling de performance, pruebas unitarias e IntelliTrace. Por si fuera poco, estrenamos un nuevo modelo de apps para Office y Sharepoint 2013 en el cual apps hechas por developers pueden ser hospedadas en el cloud (Office 365) usando tecnologías web para desarrollarlas. Visual Studio 2012 da soporte al desarrollo de estas apps a través de las Microsoft Office Developer Tools for Visual Studio 2012 – Preview. Y finalmente LightSwitch está disponible como parte de Visual Studio Professional, Premium y Ultimate. Ahora con un nuevo tema y la habilidad de acceder a fuentes de datos OData, integración con Active Directory y nuevos tipos de negocio. Más de LightSwitch aquí.

      Performance

      Entre muchos otros aspectos, por ejemplo el tiempo de carga de soluciones ha disminuido enormemente en VS2012:

      clip_image005

      ALM:

      Muchas son las mejoras en este sentido, sobretodo la integración con TFS, la inclusión de Pruebas xploratorias (Agile testing) y el soporte a distintos frameworks de pruebas tanto propios como de terceros: xUnit.net y NUnit entre otros, todos con soporte en el nuevo Test Explorer.

      clip_image007

      Lo visto hasta ahora, es apenas un ápice de todas las novedades incluidas en Visual Studio 2012. Para una referencia completa, visiten msdn.

    • WarNov Developer Evangelist

      Entrevista a WarNov para el boletín de MSDN Latam

      • 0 Comments

      Este es el copy de la entrevista que me hizo el equipo de Flash MSDN Latam, respecto a mi trabajo en Microsoft; refleja un poco de mi historia profesional al día de hoy:

       

      MSDN: ¿Quién eres en tus propias palabras?  

      warfboksmall 200x200

       WarNov: Soy una persona que ha moldeado su vida en torno a la tecnología a tal punto que mi trabajo que es precisamente sobre tecnología, para mí no es un trabajo sino más bien un hobbie que disfruto plenamente a cada momento. Adicionalmente soy alguien a quien le encanta aprender cada vez más sobre nuevos temas y sobretodo compartir ese conocimiento. Además me gusta mucho ayudar a que las personas puedan desplegar su potencial a través de ese conocimiento o de herramientas que yo pueda proveerles.


      MSDN: ¿Qué ha sido lo que te ha motivado para trabajar con tecnologías Microsoft?   WarNov: Inicié a trabajar con tecnologías Microsoft desde 2001 en medio de la universidad. Estudié en la Nacional de Colombia y allí no era muy bienvenido Microsoft en ese entonces. Pero de un modo u otro, se colaron unas cuantas copias licenciadas de Visual Studio .NET. Creo que a través de lo que se llamaba Células .NET en ese entonces llegaron a mis manos y empecé de ceros a leer la documentación de MSDN que venía en esos CDs (el internet todavía era precario). Noté la gran productividad, solidez y documentación que me proveían estas herramientas (antes había tenido que trabajar con C++ y Java en distintos entornos… pero de lejos Visual Studio .NET se los llevaba a todos). De ahí en adelante, luché para poder presentar todos mis trabajos en .NET y así me gradué con fuertes conocimientos en esta tecnología que cada vez se fueron acrecentando más y más al conocer todo el mundo de opciones que hoy día ofrecemos a la comunidad y a la industria.

       

      MSDN: ¿Cuál es el punto más fuerte que quisieras resaltar acerca del nuevo sistema operativo Windows 8?

      WarNov: Windows 8 es el mayor representante de la gran transformación que estamos teniendo dentro de Microsoft. Del nuevo aire que respiramos y que ha logrado tantos éxitos y tantos lanzamientos en un solo año. Del nuevo enfoque que estamos adquiriendo centrado al Cloud y al usuario final obviamente.

      Esto se ve reflejado en la totalmente nueva experiencia de usuario ofrecida. De hecho, cada vez que hago demos, me siento muy orgulloso de que además de poder mostrar que tenemos todos los features a los que ya estamos acostumbrados con las Tablet adicionales, puedo mostrar que cada uno de esos features mejora lo que había anteriormente. Pero eso no es nada… luego paso a mostrar que nos trae una gran cantidad de innovaciones no vistas anteriormente, como un share totalmente transversal a todas las apps que permite que éstas estén en contacto permanente con otras apps y con el sistema, un search para buscar dentro de una app desde cualquier parte de Windows, o el snap view que nos permite tener dos apps en la pantalla al mismo tiempo, entre muchos otros.

       

      MSDN: Cuéntanos cuáles crees que son las tres fortalezas del nuevo paquete de desarrollo de Visual Studio 2012

       

       

      WarNov: La más importante diría yo: El soporte para desarrollo de Apps WinRT; esto, entre otras, trae como consecuencia que Blend se incluya también en la instalación de Visual Studio, sin costo adicional!   
      Soporte a GIT. Cada vez logramos abrir más nuestros productos y tecnologías al mundo. Es así como ahora nativamente vamos a poder hacer push de nuestro código desde Visual Studio a repositorios de naturaleza Open Source, como GIT.
      Lightswitch nativo: La poderosa herramienta de desarrollo rápido de aplicaciones basadas en formularios y datos, ahora viene out of the box con Visual Studio y no hay que comprarla aparte. Además, ahora soporta HTML5 para llegar a todo lado.

      Son muchas más las ventajas y precisamente estaré escribiendo un post al respecto.

       

       

      MSDN: ¿Qué le recomendarías a los Desarrolladores que estén comenzando su carrera profesional y desean utilizar tecnologías Microsoft dentro de su organización?  



      WarNov: La clave está en leer. Leer bien. Leer y desarrollar. Hay que leer mucho para llegar a ser brillante en esta profesión (y en muchas otras). Microsoft afortunadamente tiene teras de documentación en la Web… MSDN tiene que ser su biblia técnica. Es de notar que el idioma por defecto de la literatura tecnológica de desarrollo es el inglés. Así que un buen developer debería esforzarse bastante por tener un buen nivel en el manejo de este idioma.
      No se angustien ni pierdan oportunidades con mitos irreales acerca de que Microsoft es cerrado, privativo o costoso. Si quieren arrancar hay muchas alternativas con las que pueden tener nuestras herramientas sin costo: Versiones Express, Versiones Trial, Dreamspark, BizSpark, WebSiteSpark. En Microsoft los apoyamos en sus inicios para que puedan crecer sin costo… luego cuando ya sean una empresa grande, allí si comenzaremos a hablar de licenciamiento.

       


      MSDN: Para un desarrollador que está trabajando en una nueva aplicación, ¿qué le recomendarías? ¿desarrollo para la maquina cliente, para web, o nube?



       WarNov: Esta es la pregunta que quizá más fácilmente origina un depende.
      Hoy en día está de moda el desarrollo de apps. Hace un año era la nube. Hace dos era la web. Pero la industria del software no es cuestión de moda, sino de soluciones adecuadas. La recomendación por ende, viene entonces dada por los requisitos del cliente y sería muy extenso mencionar aquí cuando usar cada tipo de enfoque. Lo que sí puedo mencionar, es que los tres enfoques son muy válidos hoy en día.

      No obstante, me gustaría recomendar que los nuevos desarrolladores aprendan acerca del desarrollo de apps, pues esto es el fiel reflejo de la evolución de la industria y habrá mucha ocupación para aquellos que sepan de esto. Además, luego será fácil aprender otro tipo de tecnologías como la web, o de backend como Cloud Computing.

      MSDN: ¿Qué  experiencia laboral interesante sobre desarrollo con tecnologías Microsoft puedes compartir con la comunidad?

      WarNovCodonosor Full Desktop
       
      WarNov: Toda mi experiencia laboral ha sido con Microsoft, desde 2001 cuando descubrí Microsoft Access. Hice un aplicativo de manejo de cartera para vendedores puerta a puerta a crédito. Abandoné la universidad que apenas acababa de empezar para correr mi empresa. Esto me permitió viajar por todo el país vendiendo mi solución, y nunca me llamaron por soporte. De resto para resaltar puedo contarles que luego trabajé desde Colombia para una empresa de Estados Unidos y allí tuve la oportunidad de crear el lenguaje APL.NET que era una adaptación del lenguaje APL (basado en signos y orientado al campo financiero y de actuaría) para que fuese CLS compliant; es decir que fuera otro de los muchos lenguajes de la familia .NET, lo que lo modernizó y amplió su espectro de acción. Luego de esto trabajé ya como desarrollador en una casa de software, donde pasé a ser líder técnico y luego arquitecto de soluciones .NET. De allí pasé a otra empresa de publicidad a ser arquitecto de portales de páginas amarillas y luego comencé a trabaja en Microsoft, donde he ganado algunos premios :)

      MSDN: Hace poco obtuviste un reconocimiento muy importante en tu carrera profesional, ¿puedes compartir con nosotros los detalles?

      image
       
      WarNov: El MGX es como la fiesta internacional de Microsoft que cada año reúne a 20K de los casi 100K empleados que hay en el mundo. Allí entre otras muchas actividades se premian a los empleados más destacados. Un día del evento estaba yo sentado por allá en la última fila, cuando estaban premiando a los mejores en su cargo a nivel mundial. Y cuál no sería mi sorpresa, cuando me mencionaron como el ganador al premio de mejor Developer Evangelist del Mundo! No lo podía creer mientras recorría todo el camino para ir a recibir el trofeo. Para mí este ha sido uno de los más importantes logros a nivel profesional en mi carrera.


      MSDN: Hablando sobre Surface, ¿Cuál es el potencial de las aplicaciones para nuestra región?



      WarNov: Surface es nuestro propio dispositivo creado para brillar con Windows 8. En principio va a estar disponible en Estados Unidos. Pero mientras llega a nuestra región, tendremos innumerables dispositivos de los fabricantes tradicionales como Dell, Acer, ASUS, Lenovo, Samsung y muchos más. Solo en Colombia se espera que durante el próximo año se vendan más de 3 millones de dispositivos.

      Todos esos dispositivos serán una vitrina para las apps WinRT. Entonces es un gran momento para ser desarrollador de dichas apps, pues claramente si construimos la app adecuada, podríamos llegar a resolver de una vez por todas, nuestra vida financiera de esta manera. El Windows Store estará abierto para todo el mundo. Así que hasta el developer del pueblo más apartado en los andes podrá subir su app y venderla en todo el mundo. Realmente las posibilidades que se abren solo son limitadas por nuestra imaginación y empeño para desarrollar apps.

       

      MSDN: Nombra 3 recursos indispensables que quieras recomendarle a la comunidad


      WarNov: El newsletter de MSDN de la región nos mantiene actualizados con artículos muy importantes que provienen de todo el continente y lo mejor, en nuestro idioma. Cuando estaba arrancando mi carrera era mi principal fuente de actualización.
      La cuenta de twitter @msdevcol está dedicada sustancialmente a promulgar información acerca de nuevos artículos producidos por la comunidad de desarrolladores Microsoft de Colombia
      El portal de MSDN. Tengo la firme convicción que allí es donde se hacen los Developers más tesos de la industria.

    • 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

      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!

    Page 3 of 14 (326 items) 12345»