Conociendo Xamarin Forms (3 de N)

Los post 1 y 2 de esta serie, han sido simplemente una forma práctica de empezar con XAML y tener ganas de avanzar rapidamente.

El día de ayer publiqué un video que ha sido bastante bien recibido, que me resulta una manera genial de continuar con la serie de XAML y además verlo aplicado. Si bien se los muestro para Android y iOS en Xamarin Studio, el punto es que lo que hemos visto aquí puede ser aplicado para Windows y Windows Phone en Visual Studio, o tambien para hacer el mismo ejercicio del video usando Visual Studio 2015.

Xamarin es una compañía que existe hace ya varios años y que provee entre otras herramientas, una alternativa para construir aplicaciones nativas para iOS y Android usando C#, sin embargo tengo que decir que el enfoque nunca me emocionó demasiado aunque me parecia genial. No soy amiga del tema de construir interfaces escribiendo code behind, la idea de usar un marcado para construir más fácilmente la interfaz de su código subyacente siempre me ha parecido mucho mejor, por eso la noticia del lanzamiento de Xamarin Forms hace unos meses fue genial para mi.

Xamarin Forms es un toolkit de Xamarin que te permite construir una aplicación por una sola vez usando XAML y C#, y generar 3 aplicaciones nativas. Si, no estamos hablando de "ejecución Crossplatform o aplicaciones híbridas" estamos hablando de "construcción Crossplatform" el resultado final serán aplicaciones nativas.

En términos generales, para un desarrollador .NET esta es una gran noticia, es la posibilidad de aprovechar todo el conocimiento que ya posee para entrar al mundo móvil de las 3 plataformas más populares.

Xamarin Forms es promovido principalmente con el uso de CodeBehind, y tiene gran cantidad de documentación disponible en el sitio oficial, además de que se ha realizado el lanzamiento el día de hoy de un libro gratis (en previa) sobre el mismo.

¡Mi recomendación es sencilla y es aprender! Sin embargo, no se queden allí, Xamarin Forms trae consigo el poder de construir aplicaciones usando Xaml, las mismas estrategias y temas que ya conocemos como bindings, recursos, templates, convertidores, lo cual lo hace genial y poderoso.

Buen conocimiento sobre el patrón MVVM y seguir estrategias Crossplatform abrirán muchas oportunidades a todos los devs .NET.

Si usas Windows y Visual Studio te invito a escuchar la introducción a Xamarin Forms publicada en Ninja Tips. Si usas Mac continua con los post de esta serie.

Entendiendo XAML (2 de N)

En el post anterior vimos de donde proviene la sintaxis básica de XAML, ahora veamos un concepto más que es necesario para saber como crear cualquier elemento C# en XAML, si, C#.

Pues bien, para quienes estamos acostumbrados a .NET de tiempos anteriores, estamos acostumbrados a contar siempre con algo que conocemos como el CodeBehind

El CodeBehind es a grandes rasgos el código sobre el cual podemos manipular elementos gráficos de nuestras pantallas, este código generalmente se ubica en un archivo separado al archivo donde se encuentra la definición de los elementos gráficos que conforman las pantallas o controles. En el explorador de soluciones Visual Studio y otros IDEs se encargan de que veamos de hecho estos archivos unificados en la jeraquía como si fueran uno solo.

Lo primero que debemos entender es que estos dos archivos son una misma clase (en términos lógicos) sin embargo código está distribuido en dos archivos, es decir son "Clases Parciales", pero para el compilar son simplemente una clase completa.

Ahora bien, el XAML no es más que una Clase Parcial de nuestro CodeBehind, y se hace completa en conjunto con el archivo que lleva el mismo nombre que el XAML pero con la extensión adicional .CS.

Si estás empezando con XAML esto podría sosprenderte, XAML y C# visualmente son absolutamente diferentes, pero si lo piensas mejor, la situación es que las pantallas típicamente son solo estructuras, y XAML basado en XML como ya lo mencionamos antes, es ideal para definir estas estructuras.

Veamos un ejemplo

Como puedes observar escribir estructuras en XAML se hace mucho más sencillo, y visualmente incluso más simple de entender cuales estructuras están jerarquicamente aninadas.

Si además observas con cuidado te darás cuenta que una instancia de un objeto en C# es igual a abrir y cerrar un nodo en XAML. ¿Recuerdas el primer post? Es importante, que por más simples que veas estos dos post entiendas que serán tu mejor arma para darte cuenta que XAML es un lenguaje bastante sencillo de aprender pues de hecho no tiene una sintaxis establecida con palabras claves como HTML si no que es simplemente la capacidad de poder usar clases que existen en C# en estructuras XML.

Alguno podría decir que ha visto más elementos complejos en XAML, pero vamos a ver una página y lentamente descubrir cuales son esas diferencias.

Analicemos esta imagen:

Lo primero que vemos es un nodo o instancia de winPhone:FormsApplicationPage, lo más raro que podemos observar en esto es que a la palabra FormsApplicationPage lo precede separado por dos puntos el prefijo winPhone. Esto es bastante simple de entender, ¿Recuerdas que sucede en C# cuando quieres usar una clase que no están el mismo namespace que la clase en la que estás trabajando? Si, simple, haces un using. Asi que esto podría ser similar a hacer un using, así

using Xamarin.Forms.Platform.WinPhone;

Sin embargo, XAML necesita algo más, necesita que le pongas un alias o apodo al using ¿Los has usado? Algo como:

using winPhone = Xamarin.Forms.Platform.WinPhone;

¿Ves? En C Sharp tambien puede hacerse. En XAML este using equivale a escribir

xmlns:winPhone="clr- namespace:Xamarin.Forms.Platform.WinPhone;assembly=Xamarin.Forms.Platform.WP8"

El parametro assembly indica en que Librería se encuentra ubicado el namespace.

La estructura de los using podría cambiar según la versión de Windows o Windows Phone, o como en este caso de ejemplo que es XAML para Xamarin, pero finalmente siempre cumplen el mismo propósito.

Otras lineas que podrían parecernos extrañas son:

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

Estas lineas que deben siempre respetarse, representan los esquemas a través de los cuales el XAML valida que la estructura está correcta. Es por eso que no siempre verás elementos con prefijos, por ejemplo

Hacen parte de las estructuras básicas que se definen en los esquemas de XAML mencionados anteriormente.

Si continuamos, hay otra línea que si bien ya no se te hace extraña, es importante explicar

x:Class="Croosy.Cross.WinPhone.MainPage"

Esta propiedad Class, que pertece al esquema x, permite que relacionemos al XAML la Clase Parcial correspondiente.

Por último podemos observar en XAML asignaciones de propiedades de este tipo:

Este tipo de asignaciones las conocemos como bindings y son un tema mucho más extenso. Siendo el propósito de este post solamente quitarte el miedo con respecto a XAML, nos quedaremos por ahora con su nombre en mente, pero como observamos no cambia la sintaxis en el punto de que "siempre son simplemente una asignación de una propiedad"

Por ahora es todo en bases prácticas, sin embargo recomiendo como es lógico, estudiar XAML más ampliamente desde la documentación oficial de MSDN.

Entendiendo XAML (1 de N)

Después de años de aprender por mí misma y tratar de enseñar temas como Windows, Windows Phone y Xamarin Forms, una vez más vuelvo a empezar la travesía de tratar de enseñarlo en mi blog.

La verdad es que después de vivirlo y tener mi propia empresa con proyectos XAML, la parte que no logro entender es como la mayoría de los desarrolladores .NET no ven XAML como una parte obvia de su presente y futuro.

Dicho eso, espero que quienes inicien esta serie da post, si lo vean así, XAML como la posibilidad de programar en cualquier ecosistema Windows Clásico, Windows Store, Windows Phone, XBox, Android, iPhone, el futuro está a un paso.

Disclaimer: Esta serie de post no pretende hacer énfasis profundo sobre temas teóricos, es más bien una guía rápida y práctica. Se asume una comprensión básica de temas de orientación a objetos y C#. Para los ejemplos voy a usar Visual Studio 2015 RC Enterprise, sin embargo pueden usar Visual Studio Community Edition 2015 con propositos educativos.

Bueno empecemos.

XAML (acrónimo pronunciado xammel del inglés eXtensible Application Markup Language, Lenguaje Extensible de Formato para Aplicaciones en español) es un lenguaje declarativo basado en XML.

Si hacemos un pequeño stop y sin entrar en muchos detalles, decir que la base es XAML nos llega a que el "formato" de los elementos que se escriben en XAML, cumple con las normas con las que se escribe XML, es decir:

En XAML tenemos Nodos o Elementos, los cuales se abren con el nombre del nodo y se cierran igual. Estos nodos pueden tener o no contenido, veamos unos ejemplos:

Observa como además se pueden escribir comentarios en XML y como un nodo puede contener otros nodos formando así una jerarquia.


Cada nodo puede tener propiedades clave/valor, que siempre sin importar su tipo serán escritas como strings.

Si crean un proyecto XAML para cualquier tecnología y en cualquier herramienta, generalmente encontrarán algo como esto:

La imagen, ya no dería confundir o asustar, es XML, hay nodos y propiedades, algunos nombres de propiedades se ven un poco diferentes, y algunos simples como los que vimos antes, pero no son más que propiedades, y de la misma forms los valores de las propiedades tambien lucen algunos normales y otros raros, e incluso Visual Studio los dibuja con colores diferentes, pero siguen siendo strings.

Esas parte que vemos un poco extrañas son XAML y vamos a ir entendiendolas parte por parte, sin embargo, no debemos perder de vista que no es más que XML y que en todas partes debe seguir las normas básicas que observamos en los ejemplos, abrir y cerrar los tags, y poner los valores de las propiedades entre comillas. Si eres nuevo en esto, seguramente seguir estas dos reglas para empezar te ayudará mucho a no equivocarte.

¿Por qué complicarse usando XAML para construir interfaces? 

Por excelentes ejemplos como el HTML está probado que tener un lenguaje de marcas permite la separación entre las tareas de diseño y la programación, situación que es muy requerida hoy en día para mejorar y acelerar los tiempos de construcción, delegando tareas a equipos especializados en cada una de estas partes, ya que no es lo más común que una misma persona tenga tanto habilidades para codificar como para diseñar.

¿Significa eso que estamos aprendiendo algo para diseñadores? Quizá, pero sucede que a diferencia de HTML no existen tantos diseñadores que sepan XAML por lo tanto como programadores es seguro que nos tocará construir ambas partes y por lo tanto entenderlo de pies a cabeza, como nos corresponde con HTML.

¿Para que aprender XAML si morirá como Silverlight?

Aclaro que hago está pregunta de forma arbitraria por que es lo que mucha gente se pregunta o simplemente muchos corren el rumor sin siquiera entender la diferencia entre XAML y Silverlight.

Asegurar que XAML no morirá nunca, es algo que no puedo hacer, que no morirá pronto es seguro. WPF fue el primer producto que usó XAML como lenguaje de marcas para aplicaciones de escritorio, luego lo hizo Silverlight. Este producto era la apuesta de Microsoft para la Web robusta y con experiencia enriquecida. Lo que fue claro con el tiempo es que HTML, CSS y JS mandan en cuanto a Web se refiere y por eso es que no solo Silverlight murió como producto, si no que además lo hizo Flash quien está en desuso.

XAML sin embargo no corrió con la suerte de Silverlight por que no es un producto, es un lenguaje que puede ser usado en varias tecnologías, WPF hoy sigue existiendo, y además en los productos estrella de Microsoft como Windows Phone y Windows, XAML se usa como tecnología principal para construir aplicaciones. Hoy en día además se promueve XAML para construir aplicaciones para XBOX y también es posible construir aplicaciones para Android y iOS usando XAML con Xamarin Forms.

¿Morir? ¿En serio? No, no por ahora, aprender XAML hoy en día es una gran inversión para un desarrollador .NET y de hecho es la razón por la que vuelvo a iniciar de cero, con una visión más amplia y un paso más lento que lo que lo hice alguna vez en mi blog anterior.

Espero que lo vayan disfrutando, XAML es XAML, si aprendes todas sus reglas, trucos y demás, básicamente hoy en día serás facilmente un desarrollador nativo en cualquiera de las tecnologías que mencioné antes, y saben... esa posibilidad no la tiene ningun desarrollador de ninguna otra tecnología.

Así que espero que esta serie los ayude a empezar y a emocionarse con XAML tanto como yo.

Nos vemos en la próxima.