Planificando las bases de una aplicación windows phone

Sorey García (@soreygarcia) http://blog.soreygarcia.me

Planificando las bases de una aplicación Windows Phone

Es común que en muchas ocasiones cuando se desea aprender Windows Phone, se encuentre gran cantidad

de recursos de desarrollo y otra cantidad de guías de diseño sobre cómo aplicar Moder UI, incluso

excelentes ejemplos del mismo en los productos disponibles en la tienda de aplicaciones. Sin embargo

quienes construimos aplicaciones para Windows Phone, entendemos que hay un paso intermedio del que

no se habla tanto, porque incluso simplemente se da por sentada su comprensión.

Quienes tienen experiencia con los elementos básicos de la programación con XAML en WPF, Silverlight,

Windows Phone y Windows 8, reconocen con facilidad el paso intermedio, sin embargo en mi experiencia

tratando de enseñar la plataforma a desarrolladores principiantes en el tema, e incluso desarrolladores de

otras plataformas que aún no trabajan con enfoques como MVC, un paso queda en el implícito, y es la

construcción de las Vistas Modelo.

Independiente de si aplicaremos o no MVVM en su totalidad, o incluso la forma de implementación que

decidamos realizar de este, las Vistas Modelo son la base de nuestra aplicación, y esa expresión es literal.

Algo mucho más visual con lo que podríamos asociarlo es el esqueleto humano ¿Sería posible imaginar un

cuerpo humano sin esqueleto? La misma sensación podría tenerse de tu aplicación si no se realiza

correctamente la planificación de las Vistas Modelo.

Contar con la definición de estas estructuras hace más consciente al desarrollador de la necesidad de

obtener las fuentes de datos que las alimentan desde el back-end y ofrece lo necesario para aprovechar al

máximo las características de Blend, en especial sus datos autogenerados, y su capacidad de establecer

enlaces fácilmente sin intervenir el código XAML, un enfoque que es útil incluso cuando se cuenta con el

apoyo de un diseñador en los equipos de trabajo, puesto que las Vista Modelo mejoran la comunicación

con el diseñador para hacerle saber cuáles son los datos que a proveerle, y viceversa, si el diseñador requiere

algo, va a solicitar incluir en una Vista Modelo la propiedad necesaria, sin necesidad de conocer la lógica

de negocio o el back-end de nuestra aplicación, logrando así una separación entre estas dos tareas. La meta

del programador será colocar en los contenedores definidos los datos que se requieren.

Antes de continuar con el artículo me es preciso aclarar que usar Blend no debe alejarnos del hecho de

entender con claridad todos los elementos y conceptos asociados a XAML, usar Blend correctamente puede

ayudarnos a ser altamente productivos, sin embargo en ocasiones, sobre todo cuando no somos tan hábiles

manejándolo, es bueno tener discernimiento para revisar el código que se está generando. Mi consejo con

Blend, paciencia y calma, con el tiempo construir interfaces se convierte en una tarea bastante divertida y

sencilla, aún para quienes solo somos programadores.

Como si fueran planos

Cuando estás planificando una aplicación, la situación es bastante similar a como se construyen los planos

de una edificación, sin embargo es obvio que lo primero que imaginamos es lo externo, aquello que

podemos visualizar. Vamos a realizar un ejemplo corto usando una aplicación que se encuentra en

planificación, Pomori (Tomates en Italiano).

http://twitter.com/soreygarcia

http://blog.soreygarcia.me/


Imaginar cómo queremos que se vea la aplicación es bastante fácil, unos usan dibujos a lápiz, otras

herramientas, cualquiera práctica es válida, lo importante siempre es planificar antes de escribir código y

el primer paso recomendado es entender el escenario general de la aplicación para hacernos una idea de

los contenedores a crear.

Las Vista Modelo, no son más que las clases que enlazaremos a nuestras vistas (Páginas de XAML) para

hacer que se muestren los datos, también para que se transporten dichos datos hasta las clases

encargadas de procesarlos, sin poner mucho código tras estas páginas o vistas. La razón puede entenderse

más fácilmente cuando pensamos en que llevaremos la aplicación a Windows 8, entre más código

creemos en las vistas, portar nuestra aplicación llevará más trabajo, pero a diferencia de los edificios, si

tenemos un armazón bien construido, en software podremos colocar cualquier piel, o más técnicamente,

crear diferentes vista, reutilizando la mayor cantidad de código posible, gracias a que XAML logra

enlazarse con nuestros contenedores aunque cambiemos la forma de las vistas.

Ahora bien, para empezar a entender cómo va la aplicación, uno de los elementos más importantes es el

mapa visual de navegación. El que se muestra a continuación es de la aplicación que estamos usando

como ejemplo.




ADD/MODIFY TASK

SETTINGS

SPLASH

ABOUT

TASK S LIST

PRODUCTIVITY REPORT

La practica más común consiste en definir una clase principal la cual es la contenedora de todas las

instancias de las demás clases contenedoras que usa nuestra aplicación, como contenedoras no se debe

entender más que las Vista Modelo.

Al observar la navegación y el prototipo podría estarse tentados a pensar en definir una clase como

contenedor principal que tiene asociada una lista de tareas.

Esto no está mal, pero si se revisa con detenimiento el prototipo y la navegación, se puede observar que

la ventana principal es un Pivot que tiene tareas según su fecha y estado. En “To Do” estarán todas las

tareas antes de la fecha actual, en “Doing” estarán las tareas qué están en curso en la fecha actual, y en

“Done” las tareas finalizadas.

class Class Model

MainViewModel TaskViewModel




Para que el enlace refleje la manera como están contenidos los datos debemos añadir entonces algo

más, una clase contenedora que tenga listas de tareas, de tal forma que los enlaces a través del XAML se

establezcan de manera jerárquica.

La clase principal estará enlazada a las vistas, y si esto no es comprensible hay que detenerse a

entenderlo. Cualquiera podría pensar de la imagen anterior, que si el MainViewModel está enlazado a la

pantalla principal de la aplicación, la ventana de adicionar o modificar una tarea, estaría enlazada en

consecuencia a su propia Vista Modelo, es decir a TaskViewModel. Pero si hemos leido con

detenimiento, se mencionó antes que MainViewModel contenia las instancias de los clases

contenedoras, por lo que la idea es enlazarse a los objetos que se construyen en tiempo de ejecución y

que estarán en memoria.

Para entender esto, es necesario que detallemos las propiedades de las clases que definimos en primera

instancia.

class Class Model

CategoryViewModel TaskViewModel

MainViewModel

Task's List

«boundary»

Add/Modify Task

«boundary»

«binding»

«binding»




Si se está analizando contra los prototipos podríamos preguntarse de donde va a salir el tiempo por

ejemplo, en este caso hace falta conocer que la duración de los pomodoros es estandar así que sería un

calculo, así que se puede optar por obviar el atributo en la VistaModelo, solo se necesitaria en la vista

enlazar un Converter que transforme la cantidad de Pomodori en tiempo con base a la configuración que

el usuario tenga de la aplicación, es algo con lo que es más fácil familiarizarse cuando tienes los conceptos

básicos de XAML bien interiorizados.

Otra observación a realizar es que nuestra clase MainViewModel tiene además un atributo con la Tarea

que fue seleccionada para editar en la pantalla de Adicioar o Editar Tareas, y ahí es donde logra entenderse

la razón de que las pantallas esten enlazadas con MainViewModel y no con TaskViewModel, ya que

alguien más debe instanciar TaskViewModel para poder enlazarla contra una vista o página, y al enlazar

además sus comandos a las vistas estos podrán ser usados.

Manos a la obra

Planear es excelente, sin embargo para los desarrolladores, siempre es más divertido pasar a la

construcción. Para ello usaremos Blend, una de las metas es lograr que el diseño quede lo más similar

posible, cosa que veremos cuando la aplicación este disponible en la tienda. La meta propuesta en este

artículo, es que toda nuestra planificación sirva para algo un poco más allá de solo imaginar.

Es necesario empezar por materializar las clases que planeadas, no sin antes olvidar que estas deben

implementar INotifyPropertyChanged para poder enlazar sus propiedades y notificar los cambios de las

mismas a las vistas, y además que las propiedades a enlazar deben ser completas, no implícitas, y que las

listas de objetos deben ser ObservableCollection.

class Class Model

CategoryViewModel

+ Identifier :int

+ Name :string

+ Tasks :ObservableCollection<TaskViewModel>

TaskViewModel

+ Identifier :int

+ Name :string

+ PlannedDate :DateTime

+ Pomori :int

+ Status :TaskStatus

+ Delete() :void

+ Save() :void

MainViewModel

+ SelectedTask :TaskViewModel

+ TasksByCategory :ObservableCollection<CategoryViewModel>




Terminada esta labor en Blend creamos un set de datos de ejemplo o Sample Data, con base en una clase,

por supuesto en MainViewModel.

Posteriormente enlazamos el LayoutRoot de nuestra MainPage a los datos de ejemplo.

Debemos asegurarnos además de que el contexto de cada uno de los PivotItem es uno de los items de la

lista de categorias..




En este es necesario mencionar, que esta forma es solo una de las maneras de hacerlo, otra persona pudo

haber optado por ejemplo por crear en MainViewModel, tres listas de tareas y enlazar cada una de ellas

a los PivotItem y eso es igualmente válido

Despues de que los PivotItem tengan asignados sus DataContext, crear enlaces en Blend, es tan simple

como arrastrarlos.

O como en el caso del nombre de la categoria, enlazarlos a cada propiedad.




El efecto rápido muestra una plantilla por defecto con los datos autogenerados por Blend.




Es nuestra tarea completa el diseño hasta dejarlo lo más similar posible al diseño inicial planteado.

Hasta este punto parece claro, sin embargo es necesario recordar dos cosas, los datos autogenerados por

Blend con base a una clase, no están disponibles en tiendo de diseño, de hecho no tendría mucho sentido

en esta aplicación, deben ser los datos de cada uno de los usuarios los que se carguen, así que hace falta

conocer en qué momento se crea la instancia del MainViewModel que se cargará con datos en tiempo de

ejecución.

La práctica propuesta en las plantillas por defecto de las plantillas tipo Panorama y Pivot consiste en crear

una propiedad estática en App.cs de tal manera que siendo la clase App el contexto general de nuestra

aplicación, dicha propiedad a su vez este siempre disponible.




Faltaría asignar dicha instancia a la página principal, y eso también está disponible como ejemplo en las

plantillas. Lo que debe hacerse es asignar al contexto de la página la instancia contenida en App.

Si se intentan quemar datos en el constructor de MainViewModel o iniciar la carga de datos en el Loaded

de cada una de las páginas, se podrá observar como no es necesaria ninguna otra línea de código para

asignar a las páginas o vistas dichos datos, siempre y cuando estemos alimentando en tiempo de ejecución

los objetos correctos.

Les reitero mi consejo de antes, las herramientas disponibles para el desarrollo de tecnologías Microsoft

buscan hacer a los profesionales bastante productivos, sin embargo usarlas no debe en ningún momento

apartarlos de la necesidad de entender los conceptos fundamentales, tal como las bases de una

aplicación, un desarrollador necesita excelentes bases para entender lo que está haciendo con las

herramientas y de esa manera construir excelentes productos.

Para finalizar, es un buen ejercicio planificar tu propia aplicación, si no la tienes, parte de esta aplicación

está sin planificar en el documento. ¿Qué otras clases construiría? ¿Cómo las enlazaría? Por otra parte, si

se pregunta si las Vistas Modelo sirven para las aplicaciones en Windows 8, podemos confirmar que si

sirven. Hacer un buen trabajo con las aplicaciones desde el principio, lo único que facilitará es que sea

mucho más fácil de escalarla y portarla. ¡A planificar entonces y crear buenas bases para poder crecer!

Sorey Bibiana García Zapata

@soreygarcia




Planificando las bases de una aplicación windows phone

Technology

Transcript of Planificando las bases de una aplicación windows phone