Migrar código de Windows 8 a Windows Phone 8

Como he comentado en alguna entrada anterior, recientemente tuvimos la ocasión de liberar aTareado para Windows 8.

Una de las primeras tareas a llevar a cabo, incluso antes de abordar nuevas funcionalidades, consiste en re-organizar el código y dejarlo preparado para poder sacar el máximo provecho en Windows Phone 8 al trabajo realizado en Windows 8. De esta manera, las nuevas funcionalidades estarán disponibles con más rapidez en ambos sistemas y podremos disponer de una versión en ambos sistemas con la mayor cantidad de código compartido posible.

aTareado surgió como un ejercicio de aprendizaje para crear aplicaciones de la Tienda de Aplicaciones de Windows, así que algunas decisiones de diseño (y me refiero a diseño técnico de la aplicación) han sido tomadas sin tener más propósito que el mero aprendizaje. En consecuencia, tras revisar un poco dichas decisiones, hay algunos problemas que habrá que tratar (en concreto para aTareado, que es muy sencillo, la lista puede variar de una aplicación a otra)

  • El modelo de la vista está en el mismo proyecto que la vista, lo que va a dificultar la reutilización del mismo en un proyecto de Windows Phone. Será necesario sacarlo a una biblioteca portable para su reutilización en ambas versiones.
  • El almacenamiento se encuentra demasiado acoplado a la fuente de datos. En Windows 8 y Windows Phone 8 el sistema de almacenamiento es diferente, con lo que este acoplamiento es bastante poco recomendable. Habrá que crear abstracciones para el repositorio que nos permita sacar versiones diferentes para ambos sistemas operativos.
  • El modelo de la vista hace uso de clases comunes que están demasiado relacionadas con clases de utilidad de Windows 8, así que para reutilizar el modelo de la vista en una versión de Windows Phone 8 habrá que crear algún tipo de abstracción para definir funcionalidades generícas, existentes en sistemas operativos diferentes.

Por otro lado, hay algunas decisiones que pueden simplificar la reutilización del código entre las versiones de Windows 8 y Windows Phone 8.

  • Parte del aprendizaje estaba enfocado en el patrón de diseño MVVM con lo que ya existe una separación clara entre la vista y el modelo de la vista, lo cual facilitará reutilizar este último en una versión de Windows Phone 8.
  • De entre de las posibles implementaciones de MVVM escogimos MVVM Light, que tiene versiones portables que pueden reutilizarse con facilidad en Windows 8 y Windows Phone 8.
  • La implementación de MVVM hace uso extensivo del patrón de diseño de Inversión de Control (IoC) lo que simplifica enormemente aprovechar abstracciones ya creadas para implementar versiones en sistemas operativos diferentes sin necesidad de tocar demasiado el código. Además la utilización de este patrón simplifica las pruebas unitarias y con poco esfuerzo podremos aprovechar el trabajo ya hecho para probar las clases nuevas que creemos para la versión de Windows Phone 8.
  • Para la serialización de datos se ha utilizado la biblioteca Newtonsoft.Json que también tiene sus versiones portables.

Reutilización W8 /WP8

La siguiente lista no es exahustiva, de hecho se limita a enumerar las consideraciones que hemos tenido que tener en cuenta al tratar de sacar el máximo provecho al código de aTareado.

Separación de Responsabilidades en la Vista

Si quieres sacarle el máximo provecho a tu aplicación en ambos mundos, empieza planteándote que un patrón de diseño que separe claramente la presentación de la lógica de presentación va ser de enorme ayuda, al fin y al cabo el XAML de Windows 8 y el XAML de Windows Phone 8 no son iguales. En este mundillo, esto lo consigues (con más o menos facilidad) utilizando MVVM.

Es buena idea que te lleves el modelo y la vista del modelo a bibliotecas portables de clases ya que con ese sencillo planteamiento ya tienes una buena base que compartir entre tus diferentes proyectos (W8 y WP8)

Es decir, partimos de algo parecido a esto:

image

Para terminar en algo similar a esto otro:

image

En realidad, parece que la cosa se ha complicado mucho (y es cierto) pero sólo porque el punto de partida era casi trivial.

A la hora de llevarnos el modelo y el modelo de la vista a bibliotecas portables partiendo de una versión en W8, la utilización de la versión portable MVVM Light ha sido de gran ayuda, pero tampoco ha estado exenta de problemas. El mayor problema encontrado aquí deriva de un pequeño bug en NuGet.

Cuando haces referencia a la MVVMLight (PCL) a través de NuGet, se realiza un cambio en la configuración de tu biblioteca de clases introduciendo una referencia al Runtime que no debería de introducirse. La solución es sencilla, simplemente elimina dicha referencia del fichero de configuración (puedes comprobar más detalles aquí).

Abstracción de Funcionalidades del SO

Por otro lado la utilización de patrones como IoC favorece enormemente el desacoplamiento entre clases. Así que, es una magnífica idea que construyas una biblioteca de clases portable donde definir todas las abstracciones (interfaces, fundamentalemente) y una biblioteca específica por Sistema Operativo donde implementen los servicios que se definen en la biblioteca de abstracciones. Tal y como se indicada en el gráfico anterior, parece que la cosa se ha complicado bastante. Pues bien, se ha complicado, pero esta complicación no es muy grande y simplifica enormemente el mantenimiento de ambas versiones.

Si ya estás utilizando MVVM Light en tus proyectos, seguro que estás familiarizado con la clase ViewModelLocator que es la que hace un uso exahustivo de los contenedores y localizadores de dependencias; además se encarga de registrar la correcta implementación del modelo de la vista. El ViewModelLocator puede registrar también las correctas implementaciones de las abstracciones (es decir, el ViewModelLocator registrará las versiones de W8 o de WP8 de dichas abstracciones). Hay un buen ejemplo aquí, donde pueden encontrarse ejemplos simples de estos conceptos.

Mensajes, mensajes, mensajes

Como sabéis, MVVM consigue desacoplamiento mediante un par de elementos fundamentales. Uno es el DataBinding y el otro es el itercambio de Mensajes entre los diferentes elementos del diseño.

No solo se utilizan como parte del DataBinding para avisar a la Vista que una propiedad ha cambiado, también pueden (deben) ser utilizados para comunicar algunos objetos sin que haya acoplamiento entre ellos.

Un Ejemplo de Mensaje

Supongamos que necesito un temporizador que dispare un evento de forma periódica. Cada sistema operativo suele disponer de clases que implementan estos temporizadores, además estas clases suelen venir por “duplicado” según estén diseñadas para interactuar con las vistas (ya que se ejecutan en el hilo de UI) o bien si están diseñadas para temporizar alguna acción que ha de ejecutarse en un hilo separado de la presentación.

Para evitar un diseño complicado y reutilizable en dos sistemas operativos diferentes, es perfectamente posible definir una clase que represente un mensaje de temporización. MVVM Light contiene una clase encargada de propagar mensajes de manera muy sencilla y desacoplada. Así pues, si nuestro modelo de vista tiene que reaccionar a mensajes del temporizador, simplemente lo subscribiremos a dichos mensajes y en la implementación específica del sistema operativo, nos limitaremos a lanzar dicho mensaje en cada pulsación del temporizador. De esta manera, el temporizador estará definido en una biblioteca de clases específica para el sistema operativo y la comunicación con el modelo de la vista se realizará, de forma desacoplada, a través del Messenger.

Este tipo de diseños permiten el desacoplamiento, pero vienen a un coste en la mantenibilidad ya que es muy difícil dar seguimiento a qué objetos se suscriben/desuscriben a qué mensajes y bajo qué condiciones lo hacen. De esta manera realizara pruebas unitarias que validen este comportamiento no es trivial.

En Resumen

Conseguir una versión “portable” de aTareado no ha sido complicado, pero ha requerido cierto esfuerzo de pruebas y refactorización. Las mayores dificultades han venido de un par de problemas relacionados uno con el diseño del código de aTareado y otro con un bug en NuGet, la mayor parte del trabajo ha venido a la hora de probar todo de nuevo.

Si tienes previsto crear una aplicación para WP8 o para W8, antes de comenzar hazte una sencilla pregunta. ¿La quiero para ambos sistemas operativos? Si la respuesta es sí, toma como referencia estos sencillos pasos a la hora de hacer el diseño y te simplificará la vida. Si la respuesta es no, hazte otra pregunta: ¿Seguro?

Subiendo aTareado al App. Store

Ha habido cierta cantidad de trabajo por detrás, pero aTareado ya está disponible en el App. Store.

846x468

aTareado se trata de una pequeña aplicación que nació con la única intención de permitirme practicar para aprender algunos de los entresijos de la programación de Aplicaciones de la Tienda de Windows 8 (Windows 8 AppStore Applications).

Permite realizar una gestión muy sencilla de tareas personales, añadiendo nuevas tareas, permitiendo su clasificación (¡hasta 100 categorías diferentes!) y seguimiento de forma sencilla e intuitiva.

screenshot_05032013_092430

Esta aplicación es fruto del trabajo de varias personas que han aportado sus ideas (gracias  a los amigos Rafa, Íñigo, Dannan y Javi) y también su esfuerzo como es el caso de Dannan que, además de aportar sus ideas, se ha encargado del diseño de la interfaz y del logotipo y que, en mi humilde opinión, ha realizado un excelente trabajo. O el propio Rafa que está aprendiendo por su lado la programación en Android utilizando: ¡aTareado!

screenshot_05032013_092722

screenshot_05032013_092748

Lecciones aprendidas

Primero de todo: organización.

Por mucho desarrollo amateur que se trate, hacer las cosas bien puede tener cierto coste relativo a tiempo y esfuerzo en una primera etapa.

La utilización de un control de código fuente ha sido fundamental. En mi caso, he hecho uso del Team Foundation Service, que es una mágnifica herramienta gratuita (para equipos reducidos) disponible en la nube.

Uno podría pensar que en situaciones tan triviales como las del desarrollo de una aplicación como esta, en las que las personas que desarrollan son uno mismo, hacer uso de una herramienta como TFS es innecesario. Pero no es así.

TFS permite no sólo realizar una magnífica gestión del código fuente de tu aplicación, también proporciona herramientas para la planificación y seguimiento del ciclo de vida de tu aplicación (ALM, o Application Lifecycle Management). En este caso, ha sido de gran utilidad para que un grupo de amigos documente de manera muy sencilla los requisitos que nuestra pequeña herramienta va a utilizar, genere seguimiento de los mismos (el avance lo vamos a dejar de lado, porque la vida profesional y personal deja poco espacio para este tipo de aficiones) así cómo la creación y seguimiento de nuevas incidencias (parte en la que Rafa ha resultado ser un auténtico crack)

Segundo: el conocimiento

Programar aplicaciones Windows 8 del App Store no es difícil, pero requiere cierta curva de aprendizaje.

El Framework

Si bien programas aplicaciones de la Tienda de Windows utilizando el Framework .NET 4.5, la realidad es que no tienes al alcance de tu mano el Framework Completo si no un subconjunto y un no tan pequeño recubrimiento alrededor del mismo.

No puedes hacer todo lo que estás acostumbrado a hacer. Muchas cosas tienen planteamientos diferentes y, en general más restrictivos (como, por poner un ejemplo, el acceso a ficheros) y otros aspectos sencillamente están fuera de tu alcance con este subconjunto de APIS que se pone a tu disposición como programador. ¿Es esto malo? Bueno, la discusión está bastante manida y no tengo nada nuevo que añadir a la misma, pero es la dicotomía entre la “protección” del usuario frente a la “libertad” del programador.

Me permito el lujo de poner “protección y “libertad” entre comillas ya que son aspectos un tanto controvertidos. ¿Nececsita el usuario ser protegido? Y, si es el caso, esta protección ¿no puede llevar fácilmente a una sobre-protección y, en consecuencia a una limitación de lo que el usuario puede hacer con la máquina y el sistema operativos que ha pagado? Y, por el otro lado. ¿Tiene el programador la “libertad” de hacer lo que quiera? Dejadme que os ponga un ejemplo: ¿Cuántas veces habéis tenido que aceptar que una aplicación acceda a tu localización y a internet sin que haya una causa funcional que justifique dichas capacidades? ¿Para qué quiere el programador acceder a mi localización y a internet si la aplicación lo único que hace, en principio, es encender el led de mi terminal?

El Lenguaje Visual y el Diseño

Es de sobra sabido que Windows 8 incluye un nuevo lenguaje de diseño, entendido como el conjunto de reglas, guías y prácticas a seguir para mostrar la información al usuario y para facilitarle al mismo el acceso y modificación de los datos que muestra su aplicación.

Este lenguaje, conocido como Modern UI tiene sus ventajas, pero también sus limitaciones ya que obliga a plantearse cosas de manera muy diferente a cómo un diseñador lo ha venido haciendo previamente (y si no que se lo digan a Dannan).

Comprender este lenguaje y crear un diseño partiendo de él es uno de los primeros puntos a tener claros.

El Lenguaje de Programación para la Interfaz Gráfica

Ahora sí, estamos hablando de XAML. Mi experiencia como programador no me ha llevado a cruzarme con este lenguaje de marcado hasta que no me he metido en esta pequeña aventura. La primera consecuencia de este punto es que el 80% de mi tiempo se ha ido en tratar de averiguar cómo hacer esto o aquello con XAML.

Si además le sumamos el hecho de que algunas características disponibles en WPF o Silverlight no lo están en el subconjunto de XAML que nos proporciona Windows 8, el desafío se ha presentado todavía más interesante.

Conclusión, si no sabes XAML y estás interesado en realizar Aplicaciones de la Tienda de Windows 8 debes de plantearte dos alternativas:

HTML + Javascript: Si ya dispones de esos conocimientos, probablemente tu curva de aprendizaje se reduzca.

XAML /C# XAML /VB.NET o XAML /C++: Esta alternativa requiere conocimientos en ambos lenguajes de cada pareja. En mi caso, la elección fue esta sencillamente por los prejuicios (fundados, siempre desde mi punto de vista, por supuesto) que tengo sobre Javascript. Si no conoces XAML asume que tu curva de aprendizaje será pronunciada en cuanto quieras que tu aplicación se distinga de alguna manera del resto.

Tercero: Las Ganas

Aprender es un reto, y sin ánimo de entrar en filosofías baratas, también es una forma de plantearte tú vida. Sin aprendizaje hay estancamiento y el estancamiento es una situación que en ocasiones puede resultar cómoda, pero que en el medio plazo (por no decir en el corto) lleva a un único sitio: “a ninguna parte”.

Evidentemente realizar aplicaciones es apasionante, pero también requiere esfuerzo. Sin la energía y las ganas, es muy difícil sacar cualquier proyecto adelante.

¿Y ahora qué?

Pues que aTareado ya está en el Store y, como no puede ser de otra manera, tiene bugs (algunos pequeños y otros no tanto). Además, ahora mismo proporciona una funcionalidad completa, pero sencilla en extremo. ¿No sería bueno poder organizar las tareas en listas? ¿Quizá poner avisos? ¿O integrarlas con el calendario? ¡Eh, que no hemos puesto tareas recurrentes! ¿Oye, y si pudiéramos hacer GTD con aTareado? ¿Y ponerle un módulo de Pomodoro? ¿Para cuándo la versión de Windows Phone y de Android?

Como véis, hay ganas.

¿Habrá tiempo?

¿Mostrar el cursor en un TextBox?

Mucho tiempo sin poner nada en el blog. Demasiado.

Probablemente siga durante una temporada sin poder contribuir de forma regular, pero vamos a intentar de que sea información útil (subrayemos intentar).

Durante los últimos meses he estado trabajando en un proyecto personal con un grupo de amigos. Espero que pronto pueda subir una entrada en este blog, de momento diré que estoy un poco aTareado.

Al grano. ¿Qué pasa con los cursores (caret)?

Dejadme que os sitúe: Windows 8 App Store y sus pequeñas cosillas (con el tiempo estoy descubriendo que no le faltan pequeñas cosillas)

Estamos en fase de pruebas y, repentinamente me llega una pequeña incidencia (pequeña por ser trivial en apariencia): “Oye, Juan, que el cursor no se ve cuando el campo de texto coge el foco y empiezo a escribir en él”

image

Vaya, claro. ¡Cómo va a verse si tiene un feo color negro sobre un fondo azul oscuro! Nada, no nos preocupemos. Bastará con dar con la propiedad o estilo que afecte al cursor (caret), y de paso al aspa de borrado, y la cambiamos de negro a blanco. ¿Verdad?

Pues no.

Dicho sea de paso que el aspa de borrado sí puede tocarse, pero no ocurre lo mismo con el cursor, tal y como puede verse aquí.

La referencia tiene casi medio año en el momento en que esta entrada se escribe y, sigo sin encontrar nada que lo contradiga en la procelosa web.

Así que. ¿Qué hacer?

Pues bien habrá que conformarse (de momento) con una solución un tanto desagradable: Cambiemos el fondo del cuadro de texto cuando el mismo tenga el foco.

Dicho y hecho.

Vamos a hacerlo de dos formas. Una utilizando únicamente XAML y la otra con unas pocas líneas de código que escribiremos por detrás.

Con la ayuda de Blend

Esta forma es muy sencilla y rápida. Primero, con la ayuda de Visual Studio (más porque lo tengo ya abierto que porque sea la única forma). Pulsaré con el botón derecho sobre el control y crearé una copia de la plantilla del mismo.

image

Una vez creada la copia podemos seguir en Visual Studio, pero os recomiendo que paséis a Blend donde podremos editar las propiedades según el estado visual de manera más sencilla (el paso descrito en el párrafo anterior también puede realizarse en Blend, por supuesto).

image

Pues bien, ya tenemos Blend mostrándonos la plantilla del control.

image

Centrémonos en la esquina superior izquierda, donde se enumeran los estados visuales del control. Concretamente, nos fijaremos en el estado visual “Focused”.

Una vez seleccionamos dicho estado, Blend se pone a “grabar” los cambios que realicemos sobre las propiedades del control. Concretamente nos centraremos en dos elementos del control de texto: “BackgroundElement” y “ContentElement”

image

En mi caso he creado un color blanco con transparencia, he creado un recurso para dicho color (luego veremos por qué) y se lo he asignado al fondo “background”.

Lo mismo para el color del texto (originalmente blanco). He creado un color negro, he creado un recurso para dicho color (de nuevo, un poco más adelante veremos por qué) y se lo he asignado al color de la fuente “foreground”.

image

Como veis, con muy poco esfuerzo hemos conseguido el objetivo secundario (no he cambiado el color del cursor, pero al menos consigo que se vea):

image

image

Con la ayuda de unas líneas de código

Sin embargo, no todos los controles de texto en la aplicación son TextBox, en algún punto del desarrollo decidimos introducir unos controles de terceros sobre los que la creación de la plantilla con Blend no nos proporciona el resultado adecuado. ¿Qué hacer entonces?

Escribamos un poquito de código, que no se nos caerán los anillos.

Lo primero es crear una clase que herede de la clase que representa el control de texto.

public sealed class MiTextBoxExt : TextBoxExtDeOtros
    {
        #region Constructor

        static MiTextBoxExt()
        {
            ResourceDictionary dict = new ResourceDictionary();
            dict.Source = new Uri("ms-appx:///Themes/TextBoxTemplate.xaml");

            FOCUSED_BACKGROUND_COLOR = dict["FocusedTextBoxBackground"] as SolidColorBrush;
            FOCUSED_FOREGROUND_COLOR = dict["FocusedTextBoxForeground"] as SolidColorBrush;
        }

        /// <summary>
        /// Constructor por defecto de la clase
        /// </summary>
        public MiTextBoxExt(): base()
        {
        }
        #endregion

        #region Miembros Protegidos

        protected override void OnGotFocus(Windows.UI.Xaml.RoutedEventArgs e)
        {
            base.OnGotFocus(e);

            _previousBackground = this.Background as SolidColorBrush;
            _previousForeground = this.Foreground as SolidColorBrush;

            this.Background = FOCUSED_BACKGROUND_COLOR;
            this.Foreground = FOCUSED_FOREGROUND_COLOR;
        }

        protected override void OnLostFocus(Windows.UI.Xaml.RoutedEventArgs e)
        {
            base.OnLostFocus(e);

            this.Background = _previousBackground;
            this.Foreground = _previousForeground;
        }

        #endregion

        #region Miembros Privados

        //Brush 
        private static readonly SolidColorBrush FOCUSED_BACKGROUND_COLOR;
        private static readonly SolidColorBrush FOCUSED_FOREGROUND_COLOR;

        private SolidColorBrush _previousForeground;
        private SolidColorBrush _previousBackground;
        #endregion
    }

Como se puede ver la solución es muy sencilla.

  1. Recuperamos del diccionario de recursos los colores definidos en el método anterior (así, si cambiamos el estilo no será necesario cambiar el código)
  2. Cuando el control toma el foco se almacenan los colores de fondo y fuente originales para luego poderlos restaurar con comodidad.
  3. Cuando el control pierde el foco, simplemente restaura los colores previamente almacenados.

Conclusión

Pues que no hemos solucionado el problema, pero hemos encontrado una forma de evitarlo.

¿Sabe alguien alguna forma mejor?

Windows 8: Terminando Apps.

Un detalle interesante sobre el ciclo de vida de las aplicaciones Windows 8 (del que ya hablé brevemente aquí) es que al estado “Terminado” puede llegarse por varias razones.

Un paseo por la vida de…

Ya hemos visto en otras ocasiones el ciclo de vida de una aplicación del App. Store.

image_thumb[1]

La aplicación del App. Store que se encuentra en pantalla es aquella que se está llevando el tiempo de procesador (no es cierto del todo, pero a efectos de esta entrada, nos sirve la simplificación). Si el usuario cambia de aplicación, la que estaba en ejecución pasa a estado “Suspendida” y la que el usuario acaba de arrancar pasa a estado “En Ejecución”.

Sin embargo, no es lo mismo que una aplicación pase al estado “Terminada” porque el S.O. reclame los recursos que esta ocupa mientras está suspendida (e.d. reclame la memoria ocupada) que una aplicación pase al estado “Terminada” porque el usuario decida finalizarala (ya sea utilizando Ctrl Alt+F4 o arrastrándola a la parte inferior de la pantalla). En el segundo caso no queda rastro de la aplicación en la interfaz de usuario, en el primer caso todavía aparece la aplicación en la zona izquierda de la pantalla, tal y como estaría si la aplicación siguiera suspendida y no terminada (y si lo piensas es normal, el usuario no tienen por qué saber que el S.O. ha terminado la aplicación y, si esta desaparece sin motivo aparente de la parte izquierda de la pantalla, la sensación del usuario sería que algo no marcha del todo bien en su dispositivo).

I’ll be back.

Pues sí, tal y como dijo Terminator: “volveré”, pero no de cualquier manera. Cuando una aplicación pasa del estado “suspendida” al estado “running” debería de ser capaz de restaurar el estado en que se encontraba previamente (supongo que aquí no tendremos discusión). Cuando una aplicación es terminada por el usuario, no existe motivo aparente para querer volver al mismo estado donde la aplicación se encontraba antes de ser finalizada (bueno, salvo que tu aplicación ofrezca esta característica al usuario, claro está). Pero. ¿Qué pasa cuando una aplicación suspendida es finalizada por el SO y posteriormente vuelta a poner en marcha por el usuario?

Pues bien, seamos coherentes con el comportamiento del SO. Si Windows 8 pretende que todo siga como si la aplicación nunca hubiera sido terminada (al fin y al cabo, su tile sigue disponible en la zona izquierda de la pantalla), nuestra aplicación debería de ser capaz de restaurar el estado como si volviera de “suspendida” en vez de “terminada”.

¿Pero, es posible determinar durante el arranque si una aplicación fue terminada por el SO o por el usuario?

Pues sí, y es bastante fácil.

   1: if (args.PreviousExecutionState == ApplicationExecutionState.ClosedByUser)

   2: {

   3:     // Comprobar aquí si el usuario quiere que se recuerde su estado anterior de navegación    

   4:     // Y si así es, entonces cargar dicho estado.

   5: }

En definitiva. Parte de la filosofía que se esconde tras las aplicaciones disponibles en la nueva Tienda de Windows 8 es proporcionar coherencia en la experiencia de usuario en su nuevo dispositivo. Es interesante estar pendiente de estos pequeños detalles para proporcionar dicho grado de coherencia.

Depurando una aplicación Windows 8

Llevaba ya mucho tiempo sin escribir ninguna entrada, así que este es un buen momento para retomar el hábito.

Recientemente he estado revisando el desarrollo de aplicaciones Windows 8 (utilizando WinRT).

Existen algunas semejanzas con las experiencias previas en Windows Phone 7.5, pero no nos engañemos, son semejanzas superficiales. Sin embargo, sí es cierto que el ciclo de vida de las Aplicaciones de Tienda de Windows 8 (madre mía, menudo nombre) es prácticamente idéntico al ciclo de vida de aplicaciones Windows Phone.

El Ciclo de Vida

Nos encontramos con el siguiente conjunto de estados.

image

Como podéis ver, prácticamente idéntico al ciclo de vida de aplicaciones Windows Phone 7.5

De nuevo cabe destacar que, una vez una aplicación ha sido suspendida, no hay garantía de que vuelva a pasar a “en ejecución” ya que el S.O. puede decidir descargarla de memoria en cualquier momento.

Depurando los cambios de estado

Una de las las facilidades que se encuentra con Visual Studio 2012 a la hora de depurar aplicaciones Windows 8 es la posibilidad de mandar mensajes a la aplicación que nos servirán para depurarla cuando lleguen los cambios de estado. ¿De qué forma? Pues nada más sencillo.

image

A un simple click de ratón tenemos la posibilidad de enviar nuestra aplicación de el estado “en ejecución” a “suspendida”, de “suspendida” de vuelta a “en ejecución” y, por último ya sea desde el estado “en ejecución” o “suspendida” a “terminada”.

Actualización: ¿Y dónde puedo encontrar esta ayuda para la depuración? Pues simplemente hay que activar la barra de herramientas “Ubicación de Depuración” o “Debug Location”.

Magnífica ayuda para comprobar que nuestra aplicación es capaz de guardar el estado y recuperarlo correctamente.

Windows 8 – Control de Usuario

Mientras espero pacientemente a que pueda seguir programando mi teléfono móvil con Windows 8 y Visual Studio 2012

image

(Sí, ya sé que Windows 8 trae Hyper-V y podría instalarme una máquina virtual con Windows 7 y Visual Studio 2010).

Como decía, mientras tanto, he optado por empezar a explorar las posibilidades que tengo para programar aplicaciones XAML sobre Windows 8.

XAML (mi desconocimiento sobre…)

Lo primero es decir que no tengo mucha experiencia con WPF, así que con la idea de hacer una aplicación sencilla en la cabeza me he lanzado a ello.

Visual Studio 2012 permite comenzar con varias plantillas de aplicación para la tienda de Windows

  • Una aplicación vacía formada por una única pantalla sin contenido.

image

  • Una aplicación de cuadrícula organizada en tres pantallas y pensada en mostrar desde agrupaciones de elementos hasta los detalles de un elemento perteneciente a uno de los grupos

image

  • Una aplicación dividida que está organizada en dos pantallas, muy similar a la anterior en la que se muestran grupos de elementos en una pantalla y los elementos que pertenecen a un grupo junto con el detalle del elemento seleccionado en la otra pantalla.

image

Mi elección (con la idea de evitar complejidades en el primer contacto) ha sido la aplicación vacía.

Bibliotecas Portables

Mi objetivo es crear una aplicación donde el usuario puede ir creando de forma dinámica nodos que pueden tener relaciones entre sí (a modo de grafo).

Para ello he creado una biblioteca de clases donde he implementado la estructura de datos del grafo (así recuerdo un poco los estudios de la Universidad).

Una de las nuevas características que trae consigo el .NET Framework 4.5 es la Biblioteca Portable de Clases que te permite crear un ensamblado que puede ser reutilizado en diferentes tecnologías y dispositivos. Con este tipo de bibliotecas, puedo disponer de una colección de componentes que podré utilizar tanto en mis proyectos de Windows Phone (7.x y 8) y en mis proyectos basados en Windows 8. ¡Por fin!

image

Mi Primer Control de Usuario

El siguiente paso consiste en crear un control personalizado que me permita representar los nodos de un grafo.

Nada más sencillo ¿Verdad? (Pues, cosas de lo más triviales me han dado ciertos dolores de cabeza).

Lo primero, añadir a mi proyecto de Windows 8 un nuevo control. ¿Cuál escoger?

image

Tenemos dos tipos de controles.

  1. Controles con plantilla (Templated Controls)
  2. Controles de usuario (User Controls)

Bien, no voy a entrar ahora en diferencias entre unos y otros (todavía las estoy digiriendo). Como de lo que se trata es de aprender he optado por el camino del medio. ¡He implementado los dos tipos!

Mi objetivo es mostrar (en primera instancia) un rectángulo con un título, un área de texto descriptiva y una url que permita navegar a otro punto con más información (ese otro punto puede ser una web o una página de la propia aplicación. ¿Quién sabe?)

Algo de este estilo.

image

El proceso ha sido relativamente sencillo. Primero crear la estructura XAML que lo defina (esencialmente un grid con tres filas)

   1: <UserControl

   2:     x:Class="Jdmveira.Controls.NodeControl"

   3:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   4:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   5:     xmlns:local="using:Jdmveira.Controls"

   6:     xmlns:d="http://schemas.microsoft.com/expression/blend/2008"

   7:     xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"

   8:     mc:Ignorable="d"

   9:     d:DesignHeight="400"

  10:     d:DesignWidth="300">

  11:

  12:     <UserControl.Resources>

  13:         <Style x:Key="MainBorderDefaultNodeStyle" TargetType="Border">

  14:             <Setter Property="BorderThickness" Value="3" />

  15:             <Setter Property="CornerRadius" Value="1" />

  16:         </Style>

  17:

  18:         <Style x:Key="InnerBorderDefaultNodeStyle" TargetType="Border">

  19:             <Setter Property="BorderThickness" Value="2" />

  20:             <Setter Property="CornerRadius" Value="1" />

  21:         </Style>

  22:     </UserControl.Resources>

  23:

  24:     <Grid x:Name="CtrlMainLayout">

  25:         <Border x:Name="MainBorder" Style="{StaticResource MainBorderDefaultNodeStyle}">

  26:

  27:             <Border.BorderBrush>

  28:                 <SolidColorBrush x:Name="MainBorderColor" Color="#FF0067BD" />

  29:             </Border.BorderBrush>

  30:

  31:             <Border Style="{StaticResource InnerBorderDefaultNodeStyle}">

  32:

  33:                 <Border.BorderBrush>

  34:                     <SolidColorBrush x:Name="InnerBorderColor" Color="#FF84C7FF" />

  35:                 </Border.BorderBrush>

  36:

  37:                 <Grid MinHeight="150"

  38:                   MinWidth="150">

  39:                     <Grid.RowDefinitions>

  40:                         <RowDefinition Height="10*"/>

  41:                         <RowDefinition Height="50*"/>

  42:                         <RowDefinition Height="10*"/>

  43:                     </Grid.RowDefinitions>

  44:

  45:                     <TextBlock

  46:                         x:Name="TitleBlock"

  47:                         Margin="0"

  48:                         Text="Prueba"

  49:                         FontSize="24"

  50:                         Padding="6,2,0,0"

  51:                         Foreground="Black"

  52:                         Grid.Row="0">

  53:

  54:                     </TextBlock>

  55:

  56:                     <Rectangle

  57:                         Grid.Row="0"

  58:                         Fill="{StaticResource NodeCaptionBackground}"

  59:                         Canvas.ZIndex="-1"/>

  60:

  61:                     <TextBlock

  62:                         x:Name="DescriptionBlock"

  63:                         Text="Texto descriptivo que podría ocupar perfectamente más de una línea"

  64:                         TextWrapping="Wrap"

  65:                         Padding="4,4,4,0"

  66:                         Foreground="Black"

  67:                         Grid.Row="1"/>

  68:

  69:                     <Rectangle Grid.Row="1" Fill="White" Canvas.ZIndex="-1" />

  70:

  71:                     <HyperlinkButton

  72:                         x:Name="LinkMoreInfo"

  73:                         VerticalAlignment="Bottom"

  74:                         Grid.Row="2" HorizontalAlignment="Right">www.bing.es</HyperlinkButton>

  75:

  76:                         <Rectangle Grid.Row="2" Fill="White" Canvas.ZIndex="-1" />

  77:                 </Grid>

  78:             </Border>

  79:         </Border>

  80:         <Grid x:Name="GridShadows" Margin="-2,-2,-6,-6">

  81:             <Rectangle Stroke="Black" Margin="5" RadiusX="7" RadiusY="7" Opacity="0.3"/>

  82:             <Rectangle Stroke="Black" Margin="4" RadiusX="8" RadiusY="8" Opacity="0.25"/>

  83:             <Rectangle Stroke="Black" Margin="3" RadiusX="9" RadiusY="9" Opacity="0.2"/>

  84:             <Rectangle Stroke="Black" Margin="2" RadiusX="10" RadiusY="10" Opacity="0.15"/>

  85:             <Rectangle Stroke="Black" Margin="1" RadiusX="11" RadiusY="11" Opacity="0.1"/>

  86:             <Rectangle Stroke="Black" Margin="-37,0,37,0" RadiusX="12" RadiusY="12" Opacity="0.05"/>

  87:         </Grid>

  88:     </Grid>

  89: </UserControl>

Las diferencias para ambos han sido que el control de usuario tiene el XAML fuertemente asociado a la clase que implementa el control (el code behind, vamos), mientras que en el caso del control de plantilla define un fichero aparte con la correspondiente plantilla para cambiar el aspecto del control (Template)

   1: <Style x:Name="EstiloNodoGridView" TargetType="local:NodeControl2">

   2:     <Setter Property="Template">

   3:         <Setter.Value>

   4:             <ControlTemplate TargetType="local:NodeControl2">

   5:                 <Grid x:Name="CtrlMainLayout">

   6:                     <Border x:Name="MainBorder" Style="{StaticResource MainBorderDefaultNodeStyle}">

   7:

   8:                         <Border.BorderBrush>

   9:                             <SolidColorBrush x:Name="MainBorderColor" Color="#FF0067BD" />

  10:                         </Border.BorderBrush>

  11:

  12:                         <Border Style="{StaticResource InnerBorderDefaultNodeStyle}">

  13:

  14:                             <Border.BorderBrush>

  15:                                 <SolidColorBrush x:Name="InnerBorderColor" Color="#FF84C7FF" />

  16:                             </Border.BorderBrush>

  17:

  18:                             <Grid MinHeight="150" MinWidth="150">

  19:                                 <Grid.RowDefinitions>

  20:                                     <RowDefinition Height="10*"/>

  21:                                     <RowDefinition Height="50*"/>

  22:                                     <RowDefinition Height="10*"/>

  23:                                 </Grid.RowDefinitions>

  24:

  25:                                 <TextBlock

  26:                                     x:Name="TitleBlock"

  27:                                     Margin="0"

  28:                                     Text="Prueba"

  29:                                     FontSize="24"

  30:                                     Padding="6,2,0,0"

  31:                                     Foreground="Black"

  32:                                     Grid.Row="0">

  33:

  34:                                 </TextBlock>

  35:

  36:                                 <Rectangle

  37:                                     Grid.Row="0"

  38:                                     Fill="{StaticResource NodeCaptionBackground}"

  39:                                     Canvas.ZIndex="-1"/>

  40:

  41:                                 <TextBlock

  42:                                     x:Name="DescriptionBlock"

  43:                                     Text="Texto descriptivo que podría ocupar perfectamente más de una línea"

  44:                                     TextWrapping="Wrap"

  45:                                     Padding="4,4,4,0"

  46:                                     Foreground="Black"

  47:                                     Grid.Row="1"/>

  48:

  49:                                 <Rectangle Grid.Row="1" Fill="White" Canvas.ZIndex="-1" />

  50:

  51:                                 <HyperlinkButton

  52:                                     x:Name="LinkMoreInfo"

  53:                                     VerticalAlignment="Bottom"

  54:                                     Grid.Row="2" HorizontalAlignment="Right">www.bing.es</HyperlinkButton>

  55:

  56:                                 <Rectangle Grid.Row="2" Fill="White" Canvas.ZIndex="-1" />

  57:                             </Grid>

  58:                         </Border>

  59:                     </Border>

  60:                     <Grid x:Name="GridShadows" Margin="-2,-2,-6,-6">

  61:                         <Rectangle Stroke="Black" Margin="5" RadiusX="7" RadiusY="7" Opacity="0.3"/>

  62:                         <Rectangle Stroke="Black" Margin="4" RadiusX="8" RadiusY="8" Opacity="0.25"/>

  63:                         <Rectangle Stroke="Black" Margin="3" RadiusX="9" RadiusY="9" Opacity="0.2"/>

  64:                         <Rectangle Stroke="Black" Margin="2" RadiusX="10" RadiusY="10" Opacity="0.15"/>

  65:                         <Rectangle Stroke="Black" Margin="1" RadiusX="11" RadiusY="11" Opacity="0.1"/>

  66:                         <Rectangle Stroke="Black" Margin="-37,0,37,0" RadiusX="12" RadiusY="12" Opacity="0.05"/>

  67:                     </Grid>

  68:                 </Grid>

  69:             </ControlTemplate>

  70:         </Setter.Value>

  71:     </Setter>

  72: </Style>

(Os recuerdo que estoy aprendiendo, así que encontraréis probablemente cosas que haya que definir de mejor manera: estoy pensando en estilos fundamentalmente…)

Dándole un poco de interactividad

El objetivo es que el usuario pueda seleccionar nodos para editar sus contenidos, arrastrarlos por la ventana para ajustar su disposición, relacionarlos entre sí…)

Voy a empezar por algo sencillo (y que sólo tiene sentido si se está utilizando un ratón). Destacar el control que se encuentre bajo el cursor cambiando simplemente el color del borde (de momento a un rojo chillón para destacar, más adelante intentaremos mejorar el aspecto visual).

Mi primera tentación fue (tirando de experiencias previas desarrollando con aplicaciones Windows puras y duras) tirar de manejadores de eventos. Sin embargo, unas pocas visitas a la red parecieron indicar que esa era una de las peores ideas que se me podrían haber ocurrido.

   1: protected override void OnPointerEntered(Windows.UI.Xaml.Input.PointerRoutedEventArgs e)

   2: {

   3:     base.OnPointerEntered(e);

   4:

   5:     // ¿Qué tal si cambio aquí el aspecto del borde de mi control?

   6: }

   7:

   8: protected override void OnPointerExited(Windows.UI.Xaml.Input.PointerRoutedEventArgs e)

   9: {

  10:     base.OnPointerExited(e);

  11:

  12:     // Y aquí me limito a volverlo como estaba. ¿No?

  13: }

Así que a seguir investigando.

Tras algunas vueltas más salieron a flote algunos conceptos. Triggers y el VisualStateManager.

Resulta que los Triggers no funcionan en el XAML de Windows 8, así que me quedé con la otra opción.

El VisualStateManager

En esencia, se trata de un componente que me permite definir estados visuales de un control, grupos de estados visuales y (opcionalmente) transiciones para cambiar de un estado a otro. En resumen, ayuda a dejar en la capa de presentación la lógica de presentación asociada al cambio del estado visual de un control. Resumiendo: “evita” que tengas que escribir código en el Code Behind (ya veremos que he tenido que meter una línea, al menos).

Dentro del grid externo que defino en mi control (el que tiene como nombre “CtrlMainLayout”) me he limitado a introducir el siguiente código.

   1: <VisualStateManager.VisualStateGroups>

   2:     <VisualStateGroup x:Name="NodeStates">

   3:         <VisualStateGroup.Transitions>

   4:             <VisualTransition To="PointerOver" GeneratedDuration="0:0:0.5" />

   5:         </VisualStateGroup.Transitions>

   6:

   7:         <VisualState x:Name="Normal" />

   8:         <VisualState x:Name="PointerOver">

   9:             <Storyboard>

  10:                 <ColorAnimation

  11:                     Storyboard.TargetName="MainBorderColor"

  12:                     Storyboard.TargetProperty="Color"

  13:                     To="Red" />

  14:                 <ColorAnimation

  15:                     Storyboard.TargetName="InnerBorderColor"

  16:                     Storyboard.TargetProperty="Color"

  17:                     To="OrangeRed" />

  18:             </Storyboard>

  19:         </VisualState>

  20:     </VisualStateGroup>

  21:     <VisualStateGroup x:Name="FocusStates"/>

  22: </VisualStateManager.VisualStateGroups>

Lo que este código quiere decir es lo siguiente.

  1. He definido un grupo de estados visuales llamado “NodeStates”
  2. Dentro de dicho grupo he definido dos estados visuales
  1. Normal
  2. PointerOver
  • El estado visual “PointerOver” tiene definidas dos animaciones de color (una para cada uno de los bordes, interior y exterior, que defino dentro de mi control). En ambos casos pasamos del color que sea a Rojo (en el caso del borde exterior) y Naranja rojizo (en el caso del interior)
  • Una transición que indica que, cuando se transicione de cualquier estado (no se define el atributo “from”) al estado “PointerOver” la duración de la animación será de cinco segundos.

Bueno, pues ya está. ¿No? La web está llena de ejemplos que aplican a la plantilla de un botón y no hace falta nada más…

Craso error: compilo, paso mi cursor por encima del control y nada de nada.

¿Cómo cambio entre estados visuales?

Otra vez a internet y a darle vueltas. Después de cierta cantidad de esfuerzo (acompañado de bizquera) descubrí por qué funcionaba para un botón y no para mi control y es que, el botón ya tiene definidos una serie de estados visuales (Default, PointerOver, Pressed, Disabled) que gestiona internamente. Pero mi control no.

Así que, aquí viene la línea de código en mi code-behind (vale, en realidad son dos).

   1: protected override void OnPointerEntered(Windows.UI.Xaml.Input.PointerRoutedEventArgs e)

   2: {

   3:     base.OnPointerEntered(e);

   4:

   5:     VisualStateManager.GoToState(this, "PointerOver", true);

   6: }

   7:

   8: protected override void OnPointerExited(Windows.UI.Xaml.Input.PointerRoutedEventArgs e)

   9: {

  10:     base.OnPointerExited(e);

  11:

  12:     VisualStateManager.GoToState(this, "Normal", true);

  13: }

Sencillamente: capturo los eventos de entrada y salida del cursor sobre y desde el control y utilizo el VisualStateManager para indicar el cambio de estado (hacia “PointerOver” cuando el cursor entra y hacia “Normal” cuando el cursor sale).

¡Y ya está, funcionando!

image

(Los controles de los extremos son controles de plantilla y el central un control de usuario)

¿Alguien conoce una mejor forma de manejar situaciones como estas?