Sobre lo que no está de moda en el escenario de la movilidad

Hace unos días participando del primer Super Happy Dev House en Colombia, usaba mi espacio en los Lightning Talks para hablar acerca del otro lado de movilidad, el lado no tan divertido y no tan de moda como lo es la tendencia por las apps, apps y más apps.

Bien, resulta que hace unos días, parte de mi trabajo consiste en definir la estrategia de movilidad de la compañia para la que trabajo, en esa aventura me he enfrentado a temas diferentes a los que resultan la preocupación de todos los que buscan entrar a una tienda de aplicaciones y ser exitosos con una aplicación popular, me he encontrado, o más bien re encontrado con el mundo móvil de la empresa, aquel entorno que apalanca procesos de negocio productivos y no tan de cara al cliente externo, si no más bien a los clientes internos de las organizaciones, es decir a todos aquellos que operan en la cadena productiva y que hacen que el producto o servicio final sea posible.

Pues bien, sucede que ahí todo es un poco más diferente. Actualmente las atención de programadores, muchas casas de software y proveedores de tecnología, esta marcada entorno al desarrollo de aplicaciones para las tiendas, esto conlleva una serie de retos entre los cuales están la elección de plataformas nativas o transversales, o bien aplicaciones web para móvil, las curvas de aprendizaje, los constantes cambios de versiones en los sistemas operativos de las plataformas móviles más comunes, el seguimiento de los standares web por parte de los exploradores disposibles en los dispositivos, entre otros.

La razón de todo esto no es más que la ya anunciada masificación del uso de dispositivos móviles (notebooks, ultrabooks, tablets, smartphones, etc...) y la consumerización de IT que está forzando a las organizaciones antes apáticas y aisladas en sus propios negocios, a vincularse a la tarea de ser actores involucrados en la promoción del uso de las tecnologías móviles, antes que en su prohibición en los entornos empresariales.

Pues bien, ese no es el tema ni mucho menos del que vengo a hablar, más bien, quisiera dejarles en el aire algunas ideas sobre otros escenarios de la computación móvil donde dichas preocupaciones o bien pierden validez (a la fecha), o donde sencillamente son aun más inciertas.

El escenario es sencillo de comprender, la movilidad no solo apalanca la masificación de las modas de redes sociales, compartir contenido o tener a mano herramientas ofimáticas, la movilidad abarca temas como poder llevar los escenarios de negocio a la calle, usar dispositivos móviles en lugares agrestes o acompañar procesos de negocios donde se requieren personas de contexturas fisicas fuertes para ser realizadas.

La posibilidad de tener datos en cualquier lugar hace que muchos procesos de negocio de las organizaciones sean suceptibles de ser implementados usando dispositivos móviles, sin embargo allí los retos son un poco diferentes: la resistencia de los dispositivos a los tratos fuertes, la necesidad de accesorios de entrada de datos que permitan la agilidad y comodidad de los trabajadores, antes que el estilo o la elegancia, la necesidad de comunicación por medios diferentes a la telefonía celular, la impresión térmica en sitio, los dispositivos lectores de diferentes códigos estándares, el ahorro de bateria para largas jornadas de trabajo, hacen que los smartphones y tablets tan de moda hoy en día, no tengan la mayor parte de atención en este tipo de escenarios.

Los retos entonces son diferentes, ¿que sistemas operativos, tecnologías o lenguajes hay disponibles? Para pesar de muchos, el 80% (o más) de los dispositivos usados para este tipo de labores y otras de negocio de cara al cliente como los kioskos de publicación de contenido o las terminales de atención al cliente en restaurantes y tiendas, cuentan con sistema operativo Windows, si, Windows CE, Windows Mobile, Windows Embedded, una base instalada que puede poner traspies a cualquier novato que pretenda solucionar las mismas necesidades queriendo usar solo nuevas tecnologias. En estos ambientes las opciones de tecnologías nativas son limitadas, o se usan los lenguajes de Microsoft o bien C++.

Ahora, en este escenario surgen varias preguntas, ¿Hasta cuando la plataforma de Microsoft va a tener este nivel de cubrimiento del mundo móvil corporativo, siendo que el mismo Microsoft hoy trabaja sobre Windows 8, y lo ofrece como una excelente plataforma de liviana y moderna? ¿Que piensan los fabricantes de este tipo de dispositivos, continuarán con este sistema operativo, irán rumbo a Windows 8? ¿Optarán por alternativas como Android para estos dispositivos en el futuro? ¿Cuán inmediato es ese futuro? ¿Estarán los clientes dispuestos a migrar su base instalada por un cambio de sistema operativo? ¿A qué costo humano y económico?

Pues bien, en este escenario nos encontramos que una opción prudente podrían ser las herramientas que ofrecen una solución transversal, haga su aplicación una vez, use HTML5 y algún lenguaje complementario y publique en todos los dispositivos y sistemas operativos, tanto los nuevos dirigidos a aplicaciones, como los de base de negocio como Window CE, Embedded y demás.

Eso suena bien, uno se emociona y piensa, ¡Genial! Suplimos las necesidades actuales y estamos preparados por si el escenario cambia. Pero es demasiado bueno para ser cierto, los retos son montones, hay cantidad de plataformas de ese tipo, seleccionar cual es la empresa correcta, el soporte correcto y si tendrán futuro, es un problema. Además dichas plataformas tienen un alcance limitado, y pueden acceder a algunas cosas en común en los dispositivos, no en todos tendrán acceso a todo lo que hay disponible, y eso habrá que tenerlo en cuenta.

Por otro lado, el lenguaje base cual será, C++, C#, Ruby, Javascript, o cualquier otro, lo típico para la interfaz HTML5. ¿Cuantos desarrolladores hay con ese tipo de conocimiento mixto? Pero la última es aún mejor, ¿cuantos de esos que saben lo que se necesita están dispuestos a trabajar en una empresa?, sabiendo que pueden ser emprendedores en estos nuevos escenarios que tantas oportunidades están ofreciendo a quienes, siendo pocos como ellos, pueden emprender por su cuenta.

Definitivamente, el escenario, está lleno de incertidumbres, de temas que muchos quizá ni tienen en mente que deben considerar y que podrían resultar un verdadero dolor de cabeza. 

Creo que solo alcanzo a dar pequeñas luces de aquellas cosas a las que se enfrenta una compañia hoy en día tratando de definir su estrategia futura en un momento donde todo evoluciona y cualquier cosa puede pasar súbitamente y dejar a tecnologías y compañías en posiciones de ventaja o desventaja que pueden afectar nuestras elecciones tecnológicas. Mi recomendación es, tómese su tiempo, estudie su propio escenario y ecosistema, no hay una regla general para abordar esta situación, pregúntese cual es el conocimiento disponible, a donde se dirige su organización, que persiguen y cuales son sus retos futuros, y sobre todo, cuanto está dispuesta a invertir la administración en tomar una estrategia moderna y disruptiva, o cuan austera puede ser.

No tengo ni mucho menos útlimas palabras en esto, así que cualquiera de sus comentarios, será bien recibido para bien y en absoluto aprendizaje.

Hasta la próxima.

Sorey

Gestión de configuración con Github para Windows en las aulas de clase

"Advertencia para antes de leer este post: Si usted es experto o amante de Git, evítese molestias, este post va dirigido a proponer una actividad en el aula de clase y a un público que recién empieza en el ámbito de la programación e ingeniería de software. Además no pretende ser un instructivo de Git, Github o Bitbucket, solo una propuesta de una posible buena práctica. La herramienta es solo una elección que hace esta actividad menos compleja en el aula de clase."

Ultimamente tratando de entrar menos de palabra y más de acción con pequeños aportes al conocimiento libre y código abierto, he empezado a usar Github y Bitbucket por consejo de mis buenos amigos @hernandgr y @orendon

Este post se debe a que la interfaz y herramientas disponibles para Github me enamoró (con sus ojos pueden ver este blog y entender por qué) y solo es registrarse para verlo

Soy de las que piensa, que a un programador pro o de los que les gusta todo a bajo nivel y sentirse lo máximo, les encantan las cosas de consolas y tener que aprenderse mil comandos para poder interactuar con las herramientas.

Yo no manejo ni amor ni odio por el tema, pero si puedo ser absolutamente productiva dando un par de clicks y llegando al mismo resultado, me parece bueno en variado ámbito. Sin embargo el tema en este post es plantear una actividad que puede llevar a acercar a los programadores Junior no solo a tener la costumbre de compartir su código, si no de aprender sobre buenas prácticas como lo es la gestión de la configuración.

"Se denomina Gestión de la Configuración al conjunto de procesos destinados a asegurar la calidad de todo producto obtenido durante cualquiera de las etapas del desarrollo de un Sistema de Información (S.I.), a través del estricto control de los cambios realizados sobre los mismos y de la disponibilidad constante de una versión estable de cada elemento para toda persona involucrada en el citado desarrollo. 

Estos dos elementos (control de cambios y control de versiones de todos los elementos del S.I.) facilitan también el mantenimiento de los sistemas al proporcionar una imagen detallada del sistema en cada etapa del desarrollo. La gestión de la configuración se realiza durante todas las fases del desarrollo de un sistema de información, incluyendo el mantenimiento y control de cambios, una vez realizada la puesta en producción." Wikipedia

Hay buenas soluciones que nacen de problemas, y este semestre me encontre con uno en mi salón de clase, ese de como hacer que la gente deje las excusas de yo si envíe la tarea y demás, y buscando como hacerlo recordé que Github tiene un tool específico para Windows y muy al modo de Microsoft es bien fácil de manejar y se vé sencillamente simple como para llevarlo al salón de clase

En este post no hablaré de nada específico, es de hecho más una invitación a los programadores a aprender a usar herramientas de este tipo y aprender sobre practicas profesionales como para hacer software, como lo es la gestión de la configuración, además de un llamado a los docentes para que llevemos herramientas y prácticas actualizadas al salón de clase.

Para quienes quieren hacer gestión de configuración de sus proyectos sin compartir, la opción es Bitbucket, el cual puede accederse a travéz de Github para Windows siempre que el repositorio soporte Git (Gracias Rafael), la que uso con tutoria de @hernandgr no son tan amigables, pero son muy buenas también, y son Mercurial y Tortoise HG y VisualHG como plugin para Visual Studio.

Les comparto la guía que hice para mis estudiantes y para algún profesor que quiera intentarlo, esto es para mi el primer intento, ya les contaré las lecciones aprendidas.

Espero les sea útil, hasta la próxima

Hasta pronto.
Sorey

Construyendo las Vistas a partir de las Vista Modelo para MVVM en Windows Phone

Avanzando con el post anterior, un video montando el estilo y creando las vistas de nuestro lector RSS con MVVM en Windows Phone

Creando estilo y vistas para el lector de la serie MVVM from Sorey Garcia on Vimeo.

El código de la aplicación se está publicando en Github:
https://github.com/soreygarcia/RssReader

Nos vemos la próxima

Sorey

Construyendo las Vistas a partir de las Vista Modelo para MVVM en Windows Phone

Si recién llegas a este post, recuerda que hace parte de una serie, así que te invito a ponerte al día hasta el post anterior.

Bueno antes de continuar con otra parte divertida de todo esto, definiré cuales funcionalidades implementar en esta etapa para generar un producto pronto (Minimum viable product). Las funciones seleccionadas serán dos: mostrar en línea la lista de post desde un rss y la lista de tweets vía rss, al clickear en cada item navegaremos al explorador con su link asociado. 

Recuerden terminar la meta propuesta en el anterior post, de crear las Vista Modelo propuestas en el UML, antes de continuar.

Aquí les dejo como se vería MainViewModel si seguimos la estructura propuesta como ejemplo en el código autogenerado.

Como ven conserve el método LoadData sugerido en la plantilla. Nos aseguramos que todo compile perfectamente y estamos listos para crear nuestros datos de ejemplo en Expression Blend. Podrá quedar una pequeña "Advertencia" (no error) alertando que los datos de ejemplo no existen, pero lo solucionaremos cuando creemos nuestra propias vistas.

Si no sabes crear los datos de ejemplo te invito a revisar el video de ejemplo que cree para mostrar como se configuran. Debes tener en cuenta es que esta vez no vas a configurar manualmente los campos de los datos de ejemplo, si no que usarás la opción crear datos de ejemplo desde una clase:

Luego de esto se te pedirá que selecciones la clase desde donde se generan los datos de ejemplo y seleccionarás MainViewModel

En la pestaña de datos podras ver la estructura que creaste para esta clase

Y en el árbol de proyectos podrás ver que se volvió a generar el archivo de datos de ejemplo que habiamos borrado en pasos anteriores, pero está vez generó los datos de ejemplo con la estructura que necesitamos.

Recuerden que a diferencia de los datos de ejemplo generados manualmente, los datos generados a partir de una clase, no se ven en tiempo de ejecución a menos que cambiemos manualmente esta configuración.

No olviden guardar antes de regresar a Visual Studio y de aceptar que el proyecto en Visual Studio se recargue para mostrar los cambios hechos en Expression Blend.

Además recuerden que si añaden campos a las clases y quieren que se generen datos de ejemplo deben borrar el archivo de datos de ejemplo y repetir el proceso, esto no alterará en ninguna forma el código, pero en Expression Blend deben vincular los datos de ejemplo a las vistas nuevamente para que se refresque la vista de diseño.

Por lo pronto, si estas siguiendo ordenamente este tutorial el reto es empezar a ensamblar las vistas con los datos de ejemplo que se generaron. Para ello recuerden ver el video de ejemplo. El próximo post de la serie, será un video creando las listas y ensamblando el estilo

El código de la aplicación se está publicando en Github:
https://github.com/soreygarcia/RssReader

Nos vemos la próxima, éxitos con el reto.

Sorey

Ensamblando la infraestructura de Vistas a Vista Modelo en MVVM usando Windows Phone

Bueno, siendo que en el post anterior ya tomamos decisiones de diseño, es el momento de empezar a ensamblar nuestro proyecto, vamos a crear una aplicación con base en la plantilla de panorama

Bueno ahora voy a proponerles una estructura para un proyecto, primero se los enseño y luego hago las aclaraciones.

 

Como pueden ver, yo creo dos proyectos o assemblies, RssReader.UI el cual es nuestro proyecto de tipo panorama y RssReader.UI.Logic el cual es una librería de clases. Si bien puede trabajarse todo en un solo proyecto, varias razones me parecen agradables de acostumbrarse a trabajar así, si quisieramos trasladarnos a una libreria portable para Windows 8 y Windows Phone 8, seguro desde esta estructura sería más provechoso que empezar a serapar las vistas de ambas aplicaciones, y tambien cuando trabajamos de mano de un diseñador, es más facil establecerle los limites, los lugares que no debe tocar, y el espacio donde el es totalmente libre. Por otro lado simplemente es personal, a mi me parece más ordenado.

Otra cosa que podrán notar es que en el proyecto panorama se han creado unas carpetas por defecto, lo que podemos hacer para no perder la estructura creada es pasar las clases a la libreria en la carpeta correspondiente ViewModels, añadir la referencia entre los assemblies.

No se olviden de completar los namespace de las clases, por RssReader.UI.Logic.ViewModels

Además habrán 2 errores de código que corregiremos haciendo referencia al nuevo espacio de nombres al que pertenece la clase.

En este punto estamos listos para crear nuestras propias clases Vista Modelo, del post anterior

Si llegaramos a observar las clases MainViewModel e ItemViewModel que fueron creadas por la plantilla, vamos a notar que ambas además de heredar de INotifyPropertyChanged implementan la interfaz a través de un evento y un método que es el responsable de notificar los cambios a la interfaz.

 

Ya que este método es común para esas y todas las Vista Modelo que creemos, lo que podemos hacer es crear una clase adicional que implemente este método y que todas nuestras Vista Model hereden de ella. Hablando en UML esto sería más o menos así:

 

Como ven, es mi costumbre adicionar 2 propiedades adicionales en esta clase comun, estas nos ayudarán más adelante a comunicar mensajes desde la vista modelo mientras se está realizando una operación. Si miramos nuestra clase en código habrá quedado de esta forma:

Como pueden ver al método NotifyPropertyChanged le fue alterado el alcance para que sea protegido, esto es para que las clases hijas de BindableBase puedan acceder a el.

Además debemos tener en cuenta que las propiedades que deseemos usar para enlazar con nuestras Vistas deben ser full properties o propiedades completas e invocar en el set de la propiedad el nombre de la propiedad que se está cambiando.

La invocación a la notificación de cambio puede realizarse desde otros sitios, esta es la forma general, ya que el cambio se notificará cuando se establezca o cambie el valor de la propiedad. Para Windows 8 y Windows Phone 8 existe una forma de no "quemar" o dejar fijo el nombre de la propiedad, y lo pueden leer en el post de Walter Novoa.

No olviden cambiar el lugar de donde hereda MainViewModel e ItemViewModel para que sea BindableBase.

Siguendo estas indicaciones y el diagrama UML para el siguiente post, debemos tener ya nuestras Vistas Modelo implementadas. No olviden fijarse bien en el diagrama y que las listas deben ser de tipo ObservableCollection.

Una última anotación para finalizar tiene que ver con el código de ejemplo que encontrarán en las clases que se crearon por defecto tiene algo adicional en el set, y es que verifican que el valor de la variable asociada haya cambiado para notificar el cambio. 

En algunos escenarios cuando movemos mucho los objetos en memoria nos puede pasar que al enlazar algún objeto no se refresque un dato, y podemos tardar un buen tiempo en identificar que esta es la razón, la elección es de escenario, si vamos a dejarlo como lo proponen en este código auto generado, es bueno ser conscientes de que ahí está.

A partir de este post, el código de la aplicación quedará publicado en Github: 

https://github.com/soreygarcia/RssReader

Nos vemos la próxima.

Sorey

Planeando el lector RSS para MVVM usando Windows Phone

Después de haber entendido un poco sobre MVVM en el primer post sigue mi parte favorita planear el estilo de la aplicación. Esto a parte de ser tierno y divertido, va muy de mano con alinearse al nuevo estilo de interfaces propuesto para Windows Phone y Windows 8, pero además como veremos en este post servirá para crear parte de nuestras clases Vista Modelo. Así que empecemos.

Eligiendo el estilo

Lo primero será elegir el estilo base, el icono, el mosaico y la pantalla de inicio de nuestra aplicación. Recuerden que para esto uso Inkscape y que pueden encontrar un video de ejemplo en mi blog o tambien el post de ideas para aplicar el estilo metro.

Notarán que adicionalmente he creado unos íconos que tienen un fondo gris, el gris siempre lo dejo como temporal, ya que lo uso para dar las dimensiones que quiero a la imagen.

Los iconos blancos son de 48 x 48 y los uso para iconos de la barra de aplicación o Application Bar, las imagenes dentro no deben ser de más de 26 X 26 para dejar espacio al circulo propio de estos botones. Los otros iconos son para poner un adorno a los títulos del panorama que ya verán más adelante.

No sé ustedes, si yo tengo una interfaz agradable trabajo mejor :)

Este es el momento de soñar (en mi caso por que es mi aplicación), cuando tenemos un cliente es momento de acordar como se verá nuestra aplicación. 

Veamos cuales son los retos del sueño, en primer lugar hay que generar bastantes elementos gráficos y ni que decir de los estilos.

¿Qué eso que tiene que ver con MVVM? Cada cosas que vemos aquí tendrá una implicación en la implementación, y detalles como usar un corazón cuando un item es favorito o usar imágenes diferentes segun el tipo de item del rss va a ser algo que nos facilitará el implementar bien las propiedades que enlazamos.

Con respecto al estilo, puse un ejemplo que no voy a implementar en la imagen, cuando se da compartir, pero es más por colocar un ejemplo de cuanto podemos complicarnos, si lo notan bien la imagen cuando el item de twitter está seleccionada cambia, para hacerlo más sencillo implementaré el sombreado en el ejemplo de la lista de post, el cual no cambia la imagen asociada al item. Sin embargo, reto para el final de la serie de post, será implementar el estilo propuesto en la imagen ¿qué tal? Es simple, veremos como les va, pero mejor después de aprender ;)

Otra anotación muy importante para el estilo, aprovechando este post, es definir si permitiremos que nuestra aplicación cambie de color cuando se cambia el tema de fondo en el dispositivo. Si bien esto quedaría muy bien, implica mucho más tiempo cuidando que todo vaya bien en ambos estilos y en ocasiones crear estilos que cambien de acuerdo al tema, así que yo lo pensaría dos veces ;

En esta aplicación no vamos a intentarlo, la razón es que la verdad no se vé muy bien :S

 
Ahora planeamos las demás ventanas de nuestra aplicación, son simples prototipos, algunas cosas no quedarán o se pueden hacer por etapas.

Planeando la aplicación
 
Hasta este punto hemos estado pensando en nuestras Vistas, nada de implementación, esto mismo se podría hacer con lapiz y papel, usando plantillas para prototipos. Con estas vistas podemos empezar a planear algo de lo que serán nuestras Vista Modelo.

Una manera más formal de mirar el tema de planear la aplicación puede encontrarse en el Blog de Arturo Toledo, en el cual nos explica sobre Arquitectura de la Información en una aplicación Windows Phone. En esta imagen tomada desde ese post, nos podemos hacer una idea global sobre como deberíamos planificar por ejemplo la navegación

Noten que la navegación es planificada de forma lineal, cada camino conduce a una ruta de páginas a través de las cuales el usuario avanza o retrocede, y debemos cuidar que esto sea intuitivo y que no se los usuarios no se pierdan a través de ellas.

Para quienes quieran explorar alternativas a este tipo de navegación, exíste una forma de evitarlo, y la explica Josue Yeray en su blog.

Por otro lado y continuando en nuestro post, las Vista Modelo deben ser pensadas no en terminos de las pantallas que usamos si no en terminos de los elementos que manejan nuestras pantallas. Si observamos con detenimiento nuestra planeación veremos que nuestra ventana o panorama principal, tiene tres listas, y existe otra lista adicional de mensajes de visitantes, por lo que nuestras vistas modelo iniciales en UML podrían ser las siguientes:

Si han creado un proyecto tipo panorama o pivot, verán que cuando las plantillas se crean, una estructura similar a estar se crea tambien en clases de ejemplo. Esto lo veremos cuando empecemos a implementar nuestra aplicación.

Como podemos observar, el MainViewModel no refiere unicamente a la pantalla principal, de hecho esta clase sirve como el contexto general de la aplicación y las propiedades de esta sirven para reflejar muchos comportamientos generales. En el ejemplo que les refiero de las plantillas por defecto se encuentra generalmente una propiedad denominada IsDataLoaded, que ayuda a controlar que cuando la aplicación se recupera de un segundo plando, si los datos se encuentran aún en memoria estos no vuelvan a intentar cargarse.

Otra propiedad que añadiré para poder iniciar en el siguiente post el montaje de nuestra aplicación es el item seleccionado, el cual nos ayudará a mostrar los datos en la pantalla de detalle de un item.

Además de esto debemos tener en cuenta, que nuestras Vistas Modelo deben heredar de la clase INotifyPropertyChanged, interfaz que a su vez obliga a nuestra clase a implementar un evento que permitirá a las Vista Model, reportar los cambios en los datos y estructuras a las Vistas y que las listas que queremos mostrar en nuestra interfaces deben ser de tipo ObservableCollection. Estos son temas de infraestructura del patrón que abordaremos en el siguiente post.

Por lo pronto nuestro modelo UML de Vistas Modelo se vería de la siguiente forma:

Si tienen dudas agradezco sus comentarios, realizar actualizaciones a los post es importante para que podamos comprender el tema. Si eres un experto en esto y andas leyendo por aquí y ves alguna equivocación, también agradeceré profundamente tus constructivos comentarios.

Nos vemos en el siguiente post.

Sorey

Aprendiendo MVVM en Windows Phone

Recordando un poco una vieja promesa vamos a iniciar una pequeña serie de post a través de los cuales vamos a dar un paso más en esto de aprender Windows Phone, un paso que seguro podrá ayudar además a entrar en el mundo del desarrollo de aplicaciones para Windows 8 usando XAML.

El nuevo reto es aprender el patrón MVVM (Modelo Vista, Vista Modelo) y para esto vamos a empezar de cero el lector RSS que habiamos construido antes, aprendiendo y repasando cosas en el camino. Seguro no soy la más experta en esto, pero espero que la sencilla implementación de MVVM que vamos a realizar sirva a principiantes a empezar el camino del desarrollo de aplicaciones más profesionales.

Nota Importante: Si recién estás aprendiendo Windows Phone te recomiendo mirar los tutoriales en video de la Serie Windows Phone y los Hands on Labs creados para la Maratón de Windows Phone en Colombia. Esta serie de post no será tan detallada ya que asumiré que ya se tienen conocimientos previos.

Vamos a empezar por dibujarnos un mapa mental de un escenario típico de una aplicación móvil, detallando un poco más en la parte del dispositivo, la notación es UML (Perdón a los amantes de UML por lo minimalista)

 

Ahora bien, el principal problema al que nos enfrentamos es que tanto entendemos lo que vemos, y que de toda esa complejidad se derive nuestra necesidad de usar MVVM para mejorar la experiencia de los usuarios en nuestras aplicaciones. 

Otra nota importante: Si no entiendes la mayoría de cosas que ves, te recomiendo ver al menos la presentación de Aplicaciones Distribuidas que tiene la teoría correspondiente y el primero de los videos de Programación en Capas que hice alguna vez, ya tiene su tiempo, pero al inicio conceptualmente puede servirte bastante.

Resumiré de forma atrevida el tema, diciendo que, el que no podamos controlar lo que sucede cuando hacemos una invocación a través de una red (internet o local) desde nuestros dispositivos, hace que nos veamos en la necesidad de que nuestras aplicaciones respondan y notifiquen a través de la interfaz de usuario lo que está ocurriendo o minimamente que muestren un mensaje indicando que aun estamos trabajando y debemos esperar, hoy en día eso es minimamente lo que espera un usuario, que tal fácil es de lograr de la forma adecuada lleva a cosas que hay que aprender.

Esta es una necesidad típica que se experimenta hace tiempo en la llamada Web 2.0 que ha creado una nueva tendencia en los usuarios de ser más exigentes con las experiencias que ofrecen las interfaces en todo tipo de aplicaciones, por lo que hoy en día muchos pueden estar familiarizados ya con el concepto puesto que han usado el patrón MVC (Modelo Vista Controlador).

Para empezar entonces debemos tener en cuenta 2 puntos, el primero es que trabajar con MVVM nos crea 3 capas lógicas dentro de una capa que conocemos como "Presentación" en el modelo tradicional de Programación en Capas, el segundo, dependiente de este primer punto, es que en estas capas abandonamos de cierta forma los llamados a métodos que estamos acostumbrados a realizar, ya que invocamos métodos que no tienen un retorno directo, si no que envian notificaciones usando eventos y delegados. ¿Que, qué? Si, eso mismo, de entender estas dos ideas es que se va a tratar esta serie de post, la siguiente imagen es el reflejo de lo que dije, y si miran bien es una de las partes del despliegue que les mostré previamente:

Para quienes les gusta leer en inglés, la imagen pertenece al libro gratuito "Developing an Advanced Windows Phone 7.5 App that Connects to the Cloud" publicado por Microsoft, una fuente increible para desarrolladores con ya conocimientos, si te pierdes allá, aquí te espero de vuelta.

Vamos a empezar resumiendo de manera muy sencilla las responsabilidades de las 3 capas lógicas que éxisten dentro de MVVM y poco a poco en la serie de post iremos entendiendo los detalles de cada una. (A los expertos en MVVM espero no molestarlos igual con mi minimalismo, esto es para principiantes)

Vista: La vista es la responsable de contener todos nuestras interfaces de usuario, en el caso de Windows Phone todos los elementos que contienen el marcado XAML. Aqui nos preocuparemos exclusivamente por lo que ve el usuario (etiquetas, listas, cuadros de mensajes, cajas de texto, etc...) y los elementos con los que interactúa para solicitar acciones a la aplicación (botones, gestos, menus, etc...). Ojo, que no nos preocupamos por el código que se ejecuta cuando el usuario solicita algo, solo por proveer el mecanismo para que el usuario pueda solicitarlo.

En este punto cabe aclarar que cada XAML tiene su Code Behind, la mayoría de desarrolladores .NET estan acostumbrados a usar este código que se genera automáticamente al presionar los controles, para implementar allí lógica de la interfaz, y otros un poco menos experimentados lo usan incluso para procesar lógica de negocio. 

Si bien MVVM no implica cero Code Behind, si nos lleva necesariamente a usarlo muchisimo menos, sobre todo cuando los controles que usamos tienen la posibilidad de ser usados por el patrón naturalmente. 

Por ejemplo (espero no sea un error de mi parte), el Application Bar de Windows Phone 7.5 no permite enlazarlo a las Vistas Modelos a través de comandos (terminos que detallaremos luego), razón por la cual tenemos que implementar algo de Code Behind si queremos dar un comportamiento apropiado a los llamados asincrónicos desde un botón o menú del Application Bar.

Vista Modelo: Estas clases son las encargadas de notificar a las vistas los datos que deben mostrarse o actualizarse y solicitar al modelo cargar datos desde las fuentes de datos. Sin embargo su principal función será tomar los datos que entrega el modelo y traducirlos en estructuras de datos que las vistas puedan mostrar, es allí donde todo se vuelve mágico, si pensamos correctamente en cuales estructuras crear para nuestra aplicación.

Modelo: Esta clases son las encargadas de acceder a las fuentes de datos bien sean locales (en el dispositivo) o remotas, de ahí que necesitemos entender el primer diagráma que les mostré al inicio del post.  

Tener fuentes locales es sencillo, hay cientos de tutoriales que enseñan a hacerlo, sin embargo la tendencia actual de las aplicaciones nos llevan a tener aplicaciones conectadas a la nube, y bien alojados en un servidor o hosting tradicional, y este esquema implica tener una aplicación desplegada y disponible para consultar y modificar los datos centrales. Qué tan escalable sea tu aplicación ante un crecimiento inesperado, dependerá mucho más de que tanto hiciste ahí, en tu backend.

Además es importante considerar, que los llamados que hace el modelo a servicios remotos, deben ser realizados en forma asincrónica, y que hay comportamientos de las interfaces que pueden requerir que se desarrollen servicios que despachen a los dispositivos la cantidad de datos apropiada y de acuerdo a las solicitudes de los usuarios, puesto que debemos considerar que muchos de ellos usan las aplicaciones a través de planes de datos con cobro por bytes, cuantos bytes consumen desde nuestroa aplicación es importante, si queremos no queremos quejas al respecto por parte de los usuarios de nuestras aplicaciones.

Bien, por este post, de mi parte es todo.

Les comparto un post con una explicación muy agradable del patrón MVVM y para quienes quieran ir un poco más rápido que mis post, les recomiendo empezar por este video de Josue Yeray, tiene su tiempo pero seguramente despues de verlo varias veces con atención encontrarán que en realidad no es tan dificil.

Nos vemos la próxima

Sorey ;)