[Windows 10] x:Bind, bindings compilados

Introducción

Data binding es un mecanismo mediante el cual
podemos enlazar los elementos de la interfaz de usuario con los objetos
que contienen la información a mostrar. Cuando realizamos data binding,
creamos una dependencia entre el valor de una propiedad llamada target con el valor de otra propiedad llamada source. Donde normalmente, la propiedad target recibirá el valor de la propiedad source.

Es el mecanismo base que nos permite utilizar el patrón MVVM en nuestras Apps móviles logrando:

  • Nos permite dividir el trabajo de manera muy sencilla (diseñadores – desarrolladores)
  • El mantenimiento es más sencillo.
  • Permite realizar Test a nuestro código.
  • Permite una más fácil reutilización de código.

Sin embargo, además de toda la potencia mencionada teníamos ciertas
limitaciones. Los errores de Binding no se producían en tiempo de
compilación de la App además de tener diferentes mejoras relacionadas
con el rendimiento. Limitaciones existentes hasta ahora…

Con la llegada de Windows 1o tenemos la posibilidad de crear bindings compilados en lugar de los bindings clásicos.

¿Cómo se usan?, ¿que aportan?, ¿cúando usarlos?

A todas esas preguntas daremos respuesta en este artículo.

x:Bind

x:Bind es una nueva síntaxis en XAML que cubre un objetivo similar a
Binding. Permite crear un enlace a datos pero con significativas
diferencias. Mientras que con Binding se utiliza reflexión en tiempo de
ejecución para resolver el enlace a datos, con x:Bind se realiza una
validación en tiempo de ejecución ya que son fuertemente tipados y compilados. Además, ofrece potentes mejoras en el rendimiento.

Crearemos un nuevo proyecto UAP:

Nueva App UAP

Nuestro objetivo en este primer ejemplo será crear 1600 Borders
bindeados a colores utilizando Bindings clásicos y Bindings compilados.
De esta forma podremos realizar una interesante comparativa en los
tiempos necesarios por cada forma para realizar el enlace a datos así
como otros detalles interesantes como el consumo de memoria, etc.

Comenzamos creando un diccionario de recursos donde definiremos los distintos colores:

<SolidColorBrush x:Key="BackgroundA" Color="Red" />
<SolidColorBrush x:Key="BackgroundB" Color="Blue" />
<SolidColorBrush x:Key="BackgroundC" Color="Green" />
<SolidColorBrush x:Key="BackgroundD" Color="Yellow" />

A continuación crearemos dos vistas nuevas. En una de ellas crearemos cientos de Borders utilizando enlace de datos clásico:

<Border Height="30" Width="30" Background="{Binding BackgroundA}" />
<Border Height="30" Width="30" Background="{Binding BackgroundB}" />
<Border Height="30" Width="30" Background="{Binding BackgroundC}" />
<Border Height="30" Width="30" Background="{Binding BackgroundD}" />

Mientras que en la otra utilizaremos x:Bind:

<Border Height="30" Width="30" Background="{x:Bind BackgroundA}" />
<Border Height="30" Width="30" Background="{x:Bind BackgroundB}" />
<Border Height="30" Width="30" Background="{x:Bind BackgroundC}" />
<Border Height="30" Width="30" Background="{x:Bind BackgroundD}" />

Para utilizar bindings compilados reemplazaremos {Binding} por {x:Bind}.
Los bindings compilados están fuertemente tipados por lo que es
necesario indicar el tipo del contexto siendo por defecto la página o el
control personal en si.

NOTA: El modo de binding utilizado por defecto en bindings compilados es OneTime.

En la vista principal tendremos un par de botones que nos permitan
instanciar y medir el tiempo necesario para ello en cada caso:

var date = DateTime.Now;
var binding = new XBind();
string diff = string.Empty;
binding.Loaded += (s, args) =>
{
     diff = (DateTime.Now - date).ToString();
     Diff.Text = diff;
};
 
Content.Children.Add(binding);

Si ejecutamos la App y pulsamos el botón “Binding”:

Bindings clásicos

Si utilizamos x:Bind:

x:Bind

Si comparamos los tiempos vemos que… se reduce a practicamente la mitad!

Además, analizando consumo de memoria y CPU vemos la siguiente comparativa.

Uso de CPU utilizando enlace a datos clásico:

Uso de CPU en Bindings clásicos

Uso de CPU utilizando bindings compilados:

Uso de CPU en binding compilado

También se reduce el consumo de memoria en comparación con Bindings clásicos:

Comparativa de consumo de memoria entre Bindings

Podéis descargar el ejemplo realizado a continuación:

También podéis acceder al código fuente directamente en GitHub:

Ver GitHub

Utilizando x:Bind

Vista las visibles mejoras a nivel de rendimiento, vamos a crear una App “normal” donde veamos su uso.

Crearemos un nuevo proyecto UAP:

Nueva App UAP

Nueva App UAP

Añadimos las carpetas Views, ViewModels y Services además de las clases base necesarias para implementar el patrón MVVM de la misma forma que vimos en este artículo.

En esta ocasión, nuestro objetivo sera crear un listado de casas
donde utilizaremos x:Bind en la plantilla que representará cada elemento
de la lista.

Comenzamos creando la entidad casa dentro de la carpeta Models:

public class House
{
     public string Place { get; set; }
     public string Price { get; set; }
     public string Photo { get; set; }
}

Nuestra interfaz sera muy simple en esta ocasión contando con un sencillo ListView:

<ListView
     ItemsSource="{Binding Houses}" />

El control tiene la fuente de datos enlazada a una propiedad de la ViewModel:

private ObservableCollection<House> _houses;
 
public ObservableCollection<House> Houses
{
     get
     {
          if (_houses == null)
               LoadHouses();
 
          return _houses;
     }
}

Cargaremos el listado de casas con un método creando datos falsos en local de manera aleatoria:

private void LoadHouses()
{
     _houses = new ObservableCollection<House>();
     Random random = new Random();
     for (int i = 0; i < 100; i++)
     {
          _houses.Add(new House
          {
               Place = Places[random.Next(0, Places.Count)],
               Photo = string.Format("ms-appx:///Assets/{0}.png", random.Next(1, 4)),
               Price = string.Format("${0}", random.Next(10000, 100000).ToString())
          });
     }
}

Y llegamos a la parte más importante, la definición del template de cada casa:

<DataTemplate x:Key="HouseTemplate" x:DataType="model:House">
     <Grid Width="200"
           Height="80">
          <Grid.ColumnDefinitions>
               <ColumnDefinition Width="75" />
               <ColumnDefinition Width="*" />
          </Grid.ColumnDefinitions>
          <Grid.RowDefinitions>
               <RowDefinition Height="Auto" />
               <RowDefinition Height="Auto" />
           </Grid.RowDefinitions>
           <Image Grid.RowSpan="2"
              Source="{x:Bind Photo}"
              MaxWidth="70"
              MaxHeight="70" />
           <TextBlock Text="{x:Bind Place}"    
                  Grid.Column="1"
                  FontSize="18"/>
           <TextBlock Text="{x:Bind Price}"  
                  Grid.Column="1"  
                  Grid.Row="1"
                  FontSize="12" />
     </Grid>
</DataTemplate>

Utilizamos x:Bind para enlazar cada elemento visual de la plantilla a
la propiedad deseada. Importante resaltar además de compilados, son
fuertemente tipados. Es obligatorio para no tener errores de compilación
indicar el tipo de los datos a los que accedemos por enlace a datos.
Esto lo realizamos utilizando x:DataType. En nuestro ejemplo, la entidad House.

Nuestro ListView quedara:

<ListView
     ItemsSource="{Binding Houses}"
     ItemTemplate="{StaticResource HouseTemplate}" />

Ejecutando la App:

DataTemplate utilizando x:Bind

 

Podéis descargar el ejemplo realizado a continuación:

También podéis acceder al código fuente directamente en GitHub:

Ver GitHub

¿Cuándo utilizar Bindings compilados?

Lo visto hasta ahora nos indica que:

  • Tenemos la posibilidad de tener bindings compilados obteniendo errores en tiempo de compilación.
  • Son fuertemente tipados por lo que debemos indicar el tipo de la información.
  • Obtenemos mejoras en el rendimiento tanto en consumo de CPU como de memoria.

Por lo tanto, ¿lo usamos siempre?

La respuesta corta es no. Entrando en profundidad:

  • Los bindings compilados, en ocasiones,  tienen un comportamiento
    diferente al de los bindings clásicos existiendo situaciones no válidas
    para los primeros.
  • Los bindings compilados como indicamos al nombrarlos se compilan
    permitiéndonos obtener errores en tiempo de compilación pero tambien nos
    aporta limitaciones. No podemos crear bindings compilados dinámicamente
    (añadir o quitar bindings en runtime).
  • Con los bindings clásicos podemos crear un mismo template para
    entidades diferentes siempre y cuando el nombre de las propiedades
    coincida. Con los bindings compilados como hemos visto, estan
    fuertemente tipados y no podemos realizar lo mismo.

Por lo tanto, en nuestros desarrollos entran en juego los bindings
compilados pero no sustituyen en abosluto a los bindings clásicos.
Dependiendo de la situación utilizaremos unos u otros en consecuencia.

Más información

[Windows 10] HTTP Live Streaming

Introducción

En el desarrollo de nuestras Apps hay ciertos contenidos que los
usuarios aprecian especialmente. Entre el contenido destacado contamos
con el multimedia.

HTTP Live Streaming o HLS es un protocolo de
streaming de contenido multimedia que consiste en segmentar en
diferentes archivos pequeños, cada uno de ellos en diferentes tamaños y
calidades para permitir difundir el contenido con una tasa adaptativa
dependiendo de la calidad de la conexión.

HTTP Live Streaming

Hasta ahora podíamos implementar HLS en nuestras Apps utilizando componentes de terceros como por ejemplo Windows Phone Streaming Media o Player Framework.

Con la llegada de Windows 10 contamos con lo necesario para trabajar con contenido multimedia adaptativo gracias a la clase AdaptiveMediaSource.

Crearemos un nuevo proyecto UAP:

Añadimos las carpetas Views, ViewModels y Services además de las clases base necesarias para implementar el patrón MVVM de la misma forma que vimos en este artículo.

Nuestro objetivo en este ejemplo será analizar todo lo necesario para
realizar streaming adaptativo de contenido multimedia utilizando las
nuevas APIs disponibles en Windows 10.

Comenzamos diseñando nuestra interfaz. El reproductor será un control de tipo MediaElement:

<MediaElement />

Control que soporta reproducción de audio y video ante múltiples
formatos. Añadiremos también un botón para lanzar la reproducción:

<Button
     Grid.Row="1"
     HorizontalAlignment="Center"
     Content="Play"/>

El resultado:

Al pulsar el botón lanzaremos un comando en la ViewModel:

private ICommand _playCommand;
 
public ICommand PlayCommand
{
     get { return _playCommand = _playCommand ?? new DelegateCommandAsync(PlayCommandExecute); }
}
 
private async Task PlayCommandExecute()
{
 
}

Quedando la definición del botón de la siguiente forma:

<Button
     Grid.Row="1"
     HorizontalAlignment="Center"
     Content="Play"
     Command="{Binding PlayCommand}"/>

El comando se encargará de acceder a contenido multimedia adapatativo:

var hlsUri = new Uri(HlsUrl);
var hlsSource = await AdaptiveMediaSource.CreateFromUriAsync(hlsUri);

La clase AdaptiveMediaSource nos permite trabajar con una fuente de streaming adaptativo. Utilizamos CreateFromUriAsync, método asíncrono que nos permite crear una instancia de AdaptiveMediaSource desde una Uri, es decir, trabajando directamente con una Url.

NOTA: Tenemos la posibilidad de obtener la
instancia de AdaptiveMediaSource trabajando con Streams utilizando el
método CreateFromStreamAsync.

El resultado obtenido es una instancia de la clase AdaptiveMediaSourceCreationResult que contiene información imprescindible relacionada con el estado, conexión y contenido de la fuente de streaming adaptativo:

  • HttpResponseMessage:
    Contiene la respuesta de la petición Http realizada para acceder al
    contenido multimedia. Útil para obtener información sobretodo en caso de
    errores.
  • MediaSource: Instancia de la clase AdaptiveMediaSource  que representa el contenido multimedia.
  • Status: Valor contemplado en enumeración que nos indica el estado de la creación de  MediaSource.

Crearemos una propiedad pública para enlazar contenido obtenido:

private AdaptiveMediaSource _mediaSource;  
 
public AdaptiveMediaSource MediaSource
{
     get { return _mediaSource; }
     set
     {
          _mediaSource = value;
          RaisePropertyChanged();
     }
}

Siempre antes, utilizaremos la propiedad Status para verificar que todo ha ido sin problemas:

if (hlsSource.Status == AdaptiveMediaSourceCreationStatus.Success)
{
     MediaSource = hlsSource.MediaSource;
}

Llegados a este punto, solo tenemos que asignar el contenido obtenido
de la fuente de streaming multimedia adapatativo a nuestro control MediaElement.

Creando un Behavior

A pesar de tener una propiedad Source, la asignación de AdaptiveMediaSource al MediaElement se realiza utilizando el método SetMediaStreamSource del MediaElement, ¿cómo podemos enlazarlo directamente?

Crearemos un Behavior para ello. Añadiremos la referencia a Extensions SDK:

En nuestro proyecto, dentro de la carpeta Behaviors, crearemos una nueva clase que heredará de IBehavior:

public class MediaStreamSourceBehavior : DependencyObject, IBehavior
{
     public void Attach(DependencyObject associatedObject)
     {
         var control = associatedObject as MediaElement;
         if (control == null)
             throw new ArgumentException(
                 "MediaStreamSourceBehavior can be attached only to MediaElement.");
 
         AssociatedObject = associatedObject;
     }
 
     public void Detach()
     {
         AssociatedObject = null;
     }
}

Realizamos la implementación de la interfaz IBehavior asociando el Behavior al elemento MediaElement. A continuación, crearemos una nueva propiedad de dependencia de tipo AdaptiveMediaSource a la que bindearemos la propiedad MediaSource que creamos previamente en nuestra ViewModel:

public AdaptiveMediaSource Media
{
     get { return (AdaptiveMediaSource)GetValue(MediaProperty); }
     set { SetValue(MediaProperty, value); }
}
 
public static readonly DependencyProperty MediaProperty =
            DependencyProperty.Register("Media",
            typeof(AdaptiveMediaSource),
            typeof(MediaStreamSourceBehavior),
            new PropertyMetadata(null, OnMediaChanged));
 
private static void OnMediaChanged(object sender,
DependencyPropertyChangedEventArgs e)
{
     var behavior = sender as MediaStreamSourceBehavior;
     if (behavior.AssociatedObject == null || e.NewValue == null) return;
 
     var mediaElement = behavior.AssociatedObject as MediaElement;
     if (mediaElement != null)
          mediaElement.SetMediaStreamSource((AdaptiveMediaSource)e.NewValue);
}

Al asignar el valor de la propiedad de depencia creada, utilizaremos el método SetMediaStreamSource del control MediaElement para asignar la fuente.

Solo nos queda utilizar el Behavior en nuestra interfaz de usuario. Añadimos los namespaces necesarios:

xmlns:i="using:Microsoft.Xaml.Interactivity"
xmlns:behaviors="using:HlsPlayer.Behaviors"

Utilizamos el Behavior con nuestro control MediaElement bindeando la fuente de streaming:

<MediaElement
     AutoPlay="True">
     <i:Interaction.Behaviors>
           <behaviors:MediaStreamSourceBehavior
                Media="{Binding MediaSource}"/>
     </i:Interaction.Behaviors>
</MediaElement>

Al ejecutar la Aplicación y pulsar el botón Play:

Comienza la reproducción del streaming adaptativo de contenido multimedia.

Podéis descargar el ejemplo realizado a continuación:

También podéis acceder al código fuente directamente en GitHub:

Ver GitHub

Recordar que cualquier tipo de duda o sugerencia la podéis dejar en los comentarios de la entrada.

Más información

[Windows 10] Nuevas herramientas, Visual Tree Inspector

Introducción

Cada vez que nos llega a los desarrolladores un nuevo SDK, es un
momento especial con una mezcla de altísima curiosidad y ganas de probar
novedades. Entre las novedades principales siempre hay nuevas APIs,
controles y otros elementos para poder realizar Apps que antes no eran
posibles. Sin embargo, entre el conjunto de novedades siempre suelen
venir nuevas herramientas que facilitan ciertas tareas: obtener más
analíticas, mejores medidores de rendimiento, más opciones en
emuladores, etc.

Desde versiones anteriores de Visual Studio, una de las herramientas más demandadas son herramientas de depuración de UI XAML.

Nuevas herramientas

Con Visual Studio 2015 nos llegan nuevas herramientas entre las que
se incluyen herramientas que permiten inspeccionar el árbol de elementos
XAML asi como modificar todas las propiedades de cualquier elemento.
Esta nueva herramienta se llama Visual Tree Inspector.

Visual Tree Inspector

El Árbol visual dinámico es la primera de dos piezas fundamentales para depurar UI XAML.

Esta herramienta nos permite ver el árbol de controles de la App en
ejecución indicando el número de elementos hijos de cada elemento ideal
para entender la estructura visual de una vista compleja y entender
problemas de rendimiento. Además, haciendo sobre un elemento podemos ver
el archivo XAML donde esta definido quedando marcado.

Conociendo la estructura de la vista es fácil navegar por los
elementos del arbol. Son embargo, ¿que ocurre si la vista es compleja y
no conocemos la estructura?

La herramienta incluye una opción para poder seleccionar elementos visuales de forma muy sencilla con un simple clic de ratón.

Seleccionando la primera opción en la herramienta habilitaremos la selección de elementos de la App en ejecución.

Una vez habilitado, podemos seleccionar elementos en la App en
ejecución quedando marcadas también en el árbol de controles y mostrando
el código XAML de la definición.

El elemento seleccionado queda bordeado de rojo. También tenemos la
opción de ver adorners de diseño de la App en tiempo de ejecución.
Podemos activar esta opción con el segundo botón del conjunto de botones
disponible en la herramienta.

Veremos distintas marcas de diseño del elemento seleccionando
dándonos información relacionada con la posición y tamaño del elemento.

Live Property Explorer

La segunda pieza relacionada con las herramientas de depuración de UI XAML es el explorador de propiedades dinámico.

Esta herramienta nos permite ver todas las propiedades del elemento
seleccionado, incluso aquellas sobreescritas. Podemos ver si las
propiedades estan establecidas con valores directos, accediendo a
recursos, etc. Además, y la parte más interesante, permite cambiar los
valores de la App en ejecución directamente viendo los cambios de manera
inmediata.

Más información

Resumen y material de la Windows 10 Game Jam en Sevilla

El evento

Windows 10 ha llegado como la culminación en el viaje hacia la convergencia en el desarrollo entre plataformas Windows. Ahora hablamos de Apps Universales
escritas una única vez con un código comun tanto para la lógica de
negocio como para la interfaz de usuario. Además, generamos un único paquete
que mantendrá una interfaz consistente y familiar para el usuario pero
adaptada a cada plataforma. Con las herramientas de desarrollo de
Windows 10 disponibles, había una oportunidad excelente para crear un
nuevo Hackathon, ¿verdad?

Este pasado fin de semana (los días 15, 16 y 17 de Abril) se ha
celebrado un Hackathon de desarrollo de Apps y Juegos para Windows 10 en
Sevilla.

Windows 10 Game Jam

El lugar

El evento tenía lugar en el Cloud Pointing de
Sevilla situado en el Parque Empresarial Nuevo Torneo. La sala en la que
nos situabamos estaba bastante bien equipada con proyectores, buena
disposición de mesas, aire acondicionado, etc. Además la zona era de
fácil acceso y con bastante aparcamiento.

Clouding Point

Ganadores

Los ganadores del Hackathon en esta ocasión han sido juegos en cada categoría:

  • Categoría Profesional. UNepic. Juego 2D de rol con sistema de inventario, combates, gestión de nivel y muchos otros detalles con una historia muy divertida.
UNepic

NOTA: Juego inspirado en UNepic, muy recomendado juego de aventuras y rol creado por el desarrollador español Francisco Téllez de Meneses.

Podéis verlo en movimiento en el siguiente video:

  • Categoría Estudiantes. Hungry Birds. Juego 2D de
    habilidad. Con distintos niveles consiste en recopilar toda la fruta del
    escenario sin morir en el intento para poder pasar al siguiente nivel.
Hungry Birds

El juego en movimiento:

Resaltar que todos los juegos fueron desarrollados con los Quick Starter de Wave Engine.

El material

Tuve el placer de participar en varias sesiones técnicas sobre
desarrollo de Apps Windows 10. Comenzamos viendo las posibilidades del
control RelativePanel, nuevo control de layout que permite posicionar a
los elementos de forma relativa con respecto al panel y ellos mismos
facilitando además la adaptación de los elementos de la interfaz ante
cambios de orientación o tamaño de pantalla. Además, vimos los Adaptive
Triggers utilizados en XAML para detectar condiciones de entorno como
distintos tamaños de pantalla permitiéndonos aplicar distintos estados
visuales para adaptar la interfaz a cada dispositivo.

Tuvimos otra sesión en la que vimos las  principales novedades en
XAML, mejoras en rendimiento, nuevas herramientas, nuevas APIs de
perspectiva 3D, etc.

Por último, alzamos la vista hacia novedades próximas como los nuevos
Bridges que permiten crear Apps Windows 10 desde código Android o iOS,
viendo como será el proceso, que se puede y que no hacer entre otras
muchas cuestiones.

En cuanto a las demos técnicas realizadas, las tenéis todas disponibles en GitHub:

Ver GitHub

Llegados a este punto solo me queda agradecer a mi compañero Josué Yeray
por su ayuda durante todo el fin de semana junto a intrépidos MSPs
(Antoni Cobos y Juan Luis Ruiz) que nos acompañaron todos los días, a los chicos de
Wave Engine por su fantástico taller y ayuda continua, a Microsoft por toda la ayuda, al Clouding Point por las instalaciones, a OnCampus por su colaboración y por supuesto a todos los asistentes por sus ganas y entrega durante todo el fin de semana.

¿Cúando repetimos?

Más información

[Evento] Seminario Xamarin en Avante

Introducción

No hay duda, los smartphones han llegado, y ya forman parte de la
vida de todos nosotros. En muchos aspectos de nuestra vida accedemos a
información, realizamos algna tarea o sencillamente nos entretenemos con
uno de ellos.

Esto también nos afecta como desarrolladores. El desarrollo móvil se
ha convertido en una prioridad en una gran mayoria de ámbitos.

Actualmente contamos con varias plataformas dominantes:

  • iOS
  • Android
  • Windows Phone

Esto a nivel de desarrollo nos supone barreras. Contamos con
plataformas de desarrollo diferentes, lenguajes diferentes, etc.
suponiendo un nivel de aprendizaje y esfuerzo cada vez mayor de cara a
desarrolladores. Además, la experiencia nos ha demostrado que los
usuarios no aceptan aplicaciones no nativas. Buscan aplicaciones
rápidas, fluidas y con consumos moderados perfectamente adaptadas a la
plataforma, ofreciendo una experiencia completa.

¿Qué podemos hacer para mejorar este panorama?

Xamarin

Aquí es donde entran en juego las tecnologías multiplataforma. Entre
las opciones disponibles, una de las más destacadas y en auge es Xamarin.

Xamarin permite el desarrollo de aplicaciones móviles nativas multiplataforma utilizando C#.
Además, poder compartir una gran cantidad de código, outilizar Visual
Studio como IDE lo convierte en una excelente opción para muchos
desarrolladores.

El evento

En Avante junto con Bravent han preparado un seminario gratuito donde
abordaremos las posibilidades de Xamarin para desarrollar Apps móviles
multiplataforma nativas. Veremos aportes, costes, estructura de proyectos, servicios y
mucho más de la manera más práctica posible. Además, tendremos alguna
que otra sorpresa con los asistentes.

Fecha

El evento tendrá lugar el próximo Martes, 19 de Mayo de 16:00h a 16:30h. Tendremos tres sesiones de 2:30 horas de duración en total.

Lugar

Tendrá lugar en Avante situado en La Cartuja. Tenéis la información exacta del lugar a continuación:

C/ Torricelli, 26, 41092 Sevilla

Agenda

La agenda sera la siguiente:

  • 16:00h – 17:00h: Introducción a Xamarin El mercado
    móvil es hoy día un pilar importante tanto para usuarios como para
    desarrolladores. Sin embargo, tenemos un mercado amplio y diverso con
    una gran variedad de dispositivos y sistemas. Si entramos en el terrero
    de desarrolladores el problema se acentúa con diferentes entornos de
    desarrollo, lenguajes y otros elementos. En esta sesión repasaremos el
    estado actual, introduciremos Xamarin como herramienta para crear
    aplicaciones nativas multiplataforma desde Visual Studio analizando
    todas sus bondades y costes además de ver distintas opciones Xamarin
    Classic y Xamarin.Forms.
  • 17:00h – 18:00h: Arquitectura de Apps multiplataforma con Xamarin Nuestro
    objetivo como desarrolladores es crear aplicaciones útil y atractivas
    pero sobretodo perfectamente funcionales. Para poder lograr ese objetivo
    es sin duda muy importante la arquitectura aplicada a la App. En esta
    sesión repasaremos el patrón MVVM aplicándolo a una aplicación Xamarin
    en cada una de las plataformas paso a paso así como la cantidad de
    código que se puede llegar a compartir entre plataformas tanto en
    ejemplos como en Apps reales.
  • 18:00h – 18:30h: Conociendo el resto de ecosistema Xamarin
    El ecosistema Xamarin no cesa en las herramientas de desarrollo.
    Tenemos a disposición una gran variedad de servicios destinados a
    complementar el mismo, analíticas, testing, análisis de rendimiento,
    etc. En esta sesión vamos a hacer un repaso por todos los servicios
    disponibles realizando demos de cada uno de ellos.

¿Te apuntas?

Más información

[Evento WPSUG] Repasando las novedades del BUILD 2015

Introducción

Tras un BUILD 2015 intenso con una enorme cantidad
de novedades, material y alguna que otra incónita en el aire, ¿que mejor
que reunir a un grupo de desarrolladores que han asistido y otros que
han seguido y probado novedades para analizarlas?

El evento

El próximo Jueves 7 de Mayo, a las 19:00 (GMT+1) Josué Yeray, Rafa Serna, Santiago Porras, Alejandro Campos y un servidor estaremos
en un nuevo Hangout en el que se realizará un desglose en todas las
novedades presentadas relacionadas con el desarrollo en la paltaforma
Windows. Veremos novedades a nivel de desarrollo de Apps Windows 10,
trataremos los Bridges viendo sus posibilidades y limitaciones o novedades en HoloLens entre otro conjunto de novedades.

  • 19:00 en España
  • 13:00 en Colombia
  • 12:00 en México Centro
  • 13:30 en Venezuela
  • 15:00 en Chile continental

¿Te apuntas?

Más información

[Hackathon] Windows 10 Game Jam en Sevilla

Introducción

Poniéndonos algo nostálgicos, podemos recordar el verano del año
2013, donde en Twitter, surgió una iniciativa brutal por rapidez y
alcance. Jose Bonnin (Evangelism Management en Microsoft) publicó un
tweet comentando los hackathons de Windows 8 que se estaban celebrando
en Barcelona y Mallorca. A partir de ese tweet varios desarrolladores
empezaron a preguntar si era posible celebrar un hackathon en su ciudad.
Todo corrió como la pólvora hasta llegar a lo que fue el Megathon
(Hackathon Windows 8 a nivel nacional). Con éxito abrumador tuvo
repetición aun más exitosa al año siguiente.

Un fin de semana intenso donde con un trasfondo de sana competición
se consigue aprender, compartir y hacer mucho networking entre todos los
participantes.

Windows 10 ha llegado como la culminación en el viaje hacia la convergencia en el desarrollo entre plataformas Windows. Ahora hablamos de Apps Universales
escritas una única vez con un código comun tanto para la lógica de
negocio como para la interfaz de usuario. Además, generamos un único paquete
que mantendrá una interfaz consistente y familiar para el usuario pero
adaptada a cada plataforma. Con las herramientas de desarrollo de
Windows 10 disponibles, había una oportunidad excelente para crear un
nuevo Hackathon, ¿verdad?

Windows 10 Game Jam

Desde el 15 al 17 de Mayo tendremos la Windows 10 Game Jam, Hackathon de desarrollo de Apps y juegos para Windows 10.

Windows 10 Game Jam

El Viernes 15 tendremos múltiples sesiones técnicas relacionadas con
el desarrollo de Apps Windows 10, mientras que Sábado 16 y Domingo 17
tendra lugar la competición en si realizando la entrega de premios el
Domingo, de 17:00h a 19:00h.

Las sesiones técnicas

El Viernes tendremos múltiples sesiones técnicas
donde se iran analizando todas las novedades principales a nivel de
desarrollo a la hora de crear Apps Windows 10. La agenda sera la
siguiente:

  • 10:00-11:00: Introducción a las Apps UAP Conoceremos
    la plataforma de Apps Universales (UAP) y como nos permite la creación
    de una App con un mismo paquete funcionando en todos los dispositivos
    Windows 10. Crearemos nuestra primera App UAP conociendo la estructura
    del proyecto aplicando buenas prácticas e implementando el patrón MVVM.
    Además, exploraremos los SDKs de extensión viendo cómo utilizar APIs
    específicas por plataforma o como crear vistas por familia de
    dispositivos.
  • 11:00-12:00: Interfaces adaptativas en Windows 10 Comenzaremos
    viendo las posibilidades del control RelativePanel, nuevo control de
    Layout que permite posicionar a los elementos de forma relativa con
    respecto al panel y ellos mismos facilitando además la adaptación de los
    elementos de la interfaz ante cambios de orientación o tamaño de
    pantalla. Además, daremos un vistazo a los Adaptive Triggers utilizados
    en XAML para detectar condiciones de entorno como distintos tamaños de
    pantalla permitiéndonos aplicar distintos estados visuales para adaptar
    la interfaz a cada dispositivo.
  • 12:30-13:30: Nuevos controles en Windows 10 Exploraremos
    los nuevos controles XAML disponibles en Windows 10 realizando especial
    hincapié en el control SplitView que nos permite crear una barra de
    navegación flexible ante distintas opciones de layout.
  • 15:00-16:00: Nuevas APIs disponibles en Windows 10 Ante
    tal cantidad de nuevas posibilidades disponibles en nuevas APIs no
    podíamos dejar atrás un repaso ante las novedades principales. Nuevas
    posibilidades de comunicación entre Apps UAP, el Action Center ahora
    disponible en teléfonos, tabletas y PCs, la captura de escritura con
    pens entre otras novedades.
  • 16:00-17:00 Migración de Windows 8.1 a Windows 10 Explicaremos
    el proceso de migración de una App Windows Store o Windows Phone 8.1 a
    UAP. Las Apps para Windows 8.1 funcionan en Windows 10, pero con la
    llegada de la nueva plataforma tenemos una gran cantidad de
    características de las que tomar ventaja o sencillamente extender a
    otras familias de dispositivos.

 NOTA: Del 29 de Abril al 1 de Mayo tendra lugar el //BUILD 2015 en San Francisco donde se esperan novedades a nivel de desarrollo en Windows 10. La agenda actual es provisional.

El Hackathon

El Sábado de 10:30h a 19:00h y el Domingo de 10:30h a 17:00h
los participantes tendran tiempo para desarrollar aplicaciones o juegos
para Windows 10. Es necesario traer equipo de desarrollo propio pero no
os preocupéis por otros aspectos, siempre habra coordinadores
encantados de ayudar resolviendo dudas, aportando ideas en todo lo
necesario, tendremos catering, conexión a internet y todas las
condiciones para focalizar toda la atención en aprender, compartir y
desarrollar.

Podréis participar en equipos de hasta cuatro miembros. Si no tenéis
los equipos ya formados el propio Viernes se coordinara y ayudara a
formar equipos lo más compensados posibles dependiendo de las
habilidades de cada miembro.

Edificio VilamarTendrá lugar en el Cloud Pointing de Sevilla situado en el Parque Empresarial Nuevo Torneo. Tenéis la información exacta del lugar a continuación:

c Biología, 12, Edificio Vilamar 2, 3ª Planta
Parque Empresarial Nuevo Torneo
41015 Sevilla

Premios

Habra detalles para todos los participantes y
por supuesto, premios para los ganadores. Esta orientado tanto a
profesionales como a estudiantes, contando con dos categorias y premios
para cada una de ellas. Los ganadores en cada categoría recibiran
teléfono Lumia 635.

¿Te parece poco?

Si te parece poco, Microsoft esta organizando el evento en muchas otras ciudades alrededor del mundo:

  • Marousi, Greece (May 14)
  • Zagreb, Croatia (May 14)
  • Bucharest, Romania (May 15)
  • Kyiv, Ukraine (May 15)
  • Seville, Spain (May 15)
  • Budapest, Hungary (May 15)
  • Lima, Peru (May 15)
  • Santiago, Chile (May 15)
  • Danang, Vietnam (May 16)
  • Colombo, Sri Lanka (May 16)
  • Tallinn, Estonia (May 16)
  • Bratislava, Slovakia (May 16)
  • brno, Czech Republic (May 16)
  • Prague, Czech Republic (May 16)
  • Madgeburg, Germany (May 16)
  • Lisbon, Portugal (May 17)
  • Turku, Finland (May 20)
  • Milan, Italy (May 20)
  • Rzeszów , Poland (May 22)
  • Bordeaux, France (May 22)
  • Paris, France (May 22)
  • Toulouse, France (May 22)
  • Mexico City, Mexico (May 22)
  • Munchen, Germany (May 23)
  • San Juan, Puerto Rico (May 29)
  • Beijing, China (Jun 5)
  • Bangkok, Thailand (Jun 6)
  • Yorkshire, UK (Jun 11)
  • Vienna, Austria (Jun 12)
  • Gurgaon, India (Jun 16)
  • Trichy, India (Jun 18) R
  • Bogota, Colombia (Jun 18)
  • Jabalpur, India (Jun 21)
  • Visakhapatnam, India (Jun 23)

Donde tendremos también otras ciudades en España como Cádiz, con quien se realizaran conexiones en directo entre otras sorpresas.

¿Te apuntas?

Más información

[Windows 10] MVVM en Apps Windows

Introducción

Con la llegada de las herramientas de desarrollo de Windows 10 Technical Preview tenemos la culminación en el viaje hacia la convergencia en el desarrollo entre plataformas Windows.

Ahora hablamos de Apps Universales escritas una
única vez con un código comun tanto para la lógica de negocio como para
la interfaz de usuario. Además, generamos un único paquete que mantendrá una interfaz consistente y familiar para el usuario pero adaptada a cada plataforma.

Además de lanzarnos de pleno a analizar nuevos controles, APIs y
herramientas, debemos abordar como implementar el patrón MVVM en Apps
UAP para conseguir una buena arquitectura y compartir código.

El patrón MVVM

Model-View-ViewModel (MVVM) es un patrón de diseño de aplicaciones que permite desacoplar el código de interfaz de usuario del código que no sea de interfaz de usuario.

El patrón MVVM consta de 3 partes:

  • La vista (View) contiene la interfaz de usuario y su lógica.
  • El vista-modelo (ViewModel) contiene la lógica de presentación.
  • El modelo (Model) contiene la lógica de negocio junto a los datos.

La vista interactúa con el vista-modelo mediante enlace a datos (Data Binding) y mediante comandos:

Las ventajas conseguidas utilizando el patrón son significativas:

  • Nos permite dividir el trabajo de manera muy sencilla (diseñadores – desarrolladores)
  • El mantenimiento es más sencillo.
  • Permite realizar Test a nuestro código.
  • Permite una más fácil reutilización de código.

MVVM en escena!

Realmente podemos mantener una implementación MVVM muy similar a como hacíamos hasta ahora en Apps Universales Windows y Windows Phone 8,1.

Crearemos un nuevo proyecto UAP:

Comenzamos por la base. Contamos con dos ficheros clave en nuestro proyecto Universal para implementar el patrón MVVM:

  • PageBase
  • ViewModelBase

PageBase

Como revelamos con su nombre, será una clase de la que heredaran
todas las páginas de nuestra aplicación. Y si, comentamos que serán
todas las páginas de la aplicación (ya sean del proyecto Windows o del
proyecto Windows Phone). Las páginas en ambas plataformas es exactamente
igual, un objeto de tipo Page. Esta clase cuenta con varios objetivos:

  • Establecer el Frame activo en todo momento para que el acceso al mismo sea sencillo.
  • Permitir el acceso de los eventos de navegación desde nuestras viewmodels.

Además podría interesarnos además:

  • Gestionar las transiciones entre páginas.
  • Gestionar estados (Loading, etc.)
  • Gestionar el estado segun la conexión de red.

Con la funcionalidad básica (facilitarnos el acceso a Frame y eventos de navegación) quedaría:

public class PageBase : Page
{
        private ViewModelBase _vm;
 
        protected override void OnNavigatedTo(NavigationEventArgs e)
        {
            base.OnNavigatedTo(e);
 
            _vm = (ViewModelBase)this.DataContext;
            _vm.SetAppFrame(this.Frame);
            _vm.OnNavigatedTo(e);
        }
 
        protected override void OnNavigatedFrom(NavigationEventArgs e)
        {
            base.OnNavigatedFrom(e);
            _vm.OnNavigatedFrom(e);
        }
}

Gestionamos los eventos básicos de navegación (al entrar y al salir de la página) de modo que, en el método OnNavigateTo obtenemos la viewmodel de la página y asignamos el Frame.

ViewModelBase

Continuamos con la segunda de nuestras clases base. En esta ocasión
trataremos la clase base de la que heredarán todos los viewmodels. Los
objetivos básicos de la clase son:

  • Notificar cambios (implementar INotifyPropertyChanged).
  • Acceso al objeto Frame que nos permitirá realizar la navegación.
  • Permitir el acceso a los eventos de navegación.
public abstract class ViewModelBase : INotifyPropertyChanged
{
        private Frame appFrame;
        private bool isBusy;
 
        public ViewModelBase()
        {
        }
 
        public Frame AppFrame
        {
            get { return appFrame; }
        }
 
        public bool IsBusy
        {
            get { return isBusy; }
            set
            {
                isBusy = value;
                RaisePropertyChanged();
            }
        }
 
        public event PropertyChangedEventHandler PropertyChanged;
 
        public abstract Task OnNavigatedFrom(NavigationEventArgs args);
 
        public abstract Task OnNavigatedTo(NavigationEventArgs args);
 
        public void RaisePropertyChanged([CallerMemberName]string propertyName = "")
        {
            var Handler = PropertyChanged;
            if (Handler != null)
                Handler(this, new PropertyChangedEventArgs(propertyName));
        }
 
        internal void SetAppFrame(Frame viewFrame)
        {
            appFrame = viewFrame;
        }
}

El acceso a los eventos de navegación lo lograremos implementando en la viewmodel los métodos abstractos OnNavigatedFrom y OnNavigatedTo. Esto no permite guardar y recuperar parámetros o estados.

Definiendo Vistas. Utilizando PageBase

En la carpeta Views añadiremos nuestras vistas. Cada página será un objeto de tipo PageBase, tanto en XAML:

<base:PageBase
    x:Class="Navigation.Views.MainView"
    xmlns:local="using:Navigation"
    xmlns:base="using:Navigation.Views.Base"
    mc:Ignorable="d"
    DataContext="{Binding FirstViewModel, Source={StaticResource Locator}}">
    <Grid>
    </Grid>
</base:PageBase>

Como en el code-behind:

public sealed partial class MainView : PageBase
{
     public MainView()
     {
         this.InitializeComponent();
     }
}

La VistaModelo

Creamos una clase derivada de ViewModelBase:

public class FirstViewModel : ViewModelBase
{
 
}

Implementamos los métodos de navegación definidos en ViewModelBase:

public class FirstViewModel : ViewModelBase
{
    public override Task OnNavigatedFrom(NavigationEventArgs args)
    {
        return null;
    }
 
    public override Task OnNavigatedTo(NavigationEventArgs args)
    {
        return null;
    }
}

Asociando la Vista con la VistaModelo

Ahora, necesitamos conectar nuestra vista con nuestro viewmodel.
Podemos hacerlo de múltiples formas, desde el constructor de la vista,
instanciandola en App, usando Ioc. En nuestro caso, utilizaremos Ioc.
Usaremos Unity.

Una vez añadida la referencia correspondiente en cada proyecto (Windows y Windows Phone) creamos una nueva clase en la carpeta Base dentro de la carpeta ViewModels llamada ViewModelLocator:

public class ViewModelLocator
{
     readonly IUnityContainer _container;
 
     public ViewModelLocator()
     {
            _container = new UnityContainer();
 
            _container.RegisterType<MainViewModel>();
     }
 
     public MainViewModel MainViewModel
     {
            get { return _container.Resolve<MainViewModel>(); }
     }
}

Sencillamente registramos nuestras viewmodels y creamos un par de
propiedades públicas por cada viewmodel para poder resolverlas y acceder
a ellas desde las vistas. A continuación, registramos nuestro locator en App.xaml:

<locator:ViewModelLocator x:Key="Locator" />

Asignamos la viewmodel como DataContext de nuestra viewmodel:

DataContext="{Binding MainViewModel, Source={StaticResource Locator}}"

Y todo preparado!.

Hel10 World!

Vamos a añadir un botón a nuestra interfaz que al ser pulsado muestre un mensaje en pantalla.

Añadimos el botón en nuestra vista (MainView.xaml):

<Button            
     Content="Hel10 World"            
     Command="{Binding HelloCommand}"
     HorizontalAlignment="Center" />

Nuestro botón cuenta con un comando definido en la ViewModel:

private ICommand _helloCommand;
 
public ICommand HelloCommand
{
     get { return _helloCommand = _helloCommand ?? new DelegateCommand(HelloCommandExecute); }
}
 
private void HelloCommandExecute()
{
     // TODO:    
}

Al ejecutar el comando debemos mostrar el mensaje. De momento, no hemos añadido lógica. Utilizaremos para mostrar el mensaje un servicio.

Servicios

Introducimos el concepto de servicio. Básicamente serán clases que cubrirán un escenario muy específico. Por ejemplo:

  • Gestionar Tiles
  • Enviar un email
  • Llamar por teléfono
  • Mostrar un mensaje

En lugar de escribir el código específico para esas acciones directamente en la ViewModel, lo haremos en clases separadas, nuestros servicios. Las ViewModels interactuarán con estos servicios para poder realizar y gestionar las acciones necesarias.

Primero definiremos nuestro servicio de diálogo mediante una sencilla interfaz:

public interface IDialogService
{
     void Show(string message);
}

Realizamos la implementación de nuestro servicio:

public class DialogService : IDialogService
{
     public void Show(string message)
     {
    var messageDialog = new MessageDialog(message);
    var result = messageDialog.ShowAsync();
     }
}

Muy simple. Utilizamos el MessageDialog para mostrar el mensaje recibido como parámetro en nuestro servicio.

En el ViewModelLocator registramos el servicio:

_container.RegisterType<IDialogService, DialogService>(new ContainerControlledLifetimeManager());

Visto como crear el servicio y como registrarlo queda la duda de como se resuelve y utiliza en la ViewModel.
Bastará con declarar la interfaz de la clase como parámetro del
constructor público de la ViewModel. Registramos el servicio y la
ViewModel en nuestro contenedor de Unity, Unity lo resolverá
automáticamente. Cada servicio necesario en la ViewModel es “inyectado” con la implementación declarada en nuestro contenedor.

De esta forma conseguimos:

  • No tener que crear nuevas instancias de nuestro servicio cada vez que sea necesario.
  • Tener el código para una acción concreta en una única clase, sin repeticiones similares en múltiples ViewModels.
  • Tenemos la capacidad de modificar la implementación a “inyectar” en la ViewModel de un servicio con suma facilidad.
public MainViewModel(IDialogService dialogService)
{
     _dialogService = dialogService;
}

Modificamos la ejecución del comando utilizando nuestro servicio de diálogo:

private void HelloCommandExecute()
{
     _dialogService.Show("Hello World!");
}

Si ejecutamos la App veremos algo como lo siguiente:

Al pulsar el botón, se ejecutará el comando definido en la ViewModel
asignada como DataContext de la vista, que utilizará el servicio de
dialogo inyectado en el constructor para mostrar el dialogo:

Podéis descargar el ejemplo realizado a continuación:

También podéis acceder al código fuente directamente en GitHub:

Ver GitHub

Recordar que cualquier tipo de duda o sugerencia la podéis dejar en los comentarios de la entrada.

Más información