[Xamarin.Forms] Establecer el directorio de recursos en Apps UWP

Diferentes recursos por plataformas

Usando Xamarin.Forms desarrollamos (habitualmente) aplicaciones para diferentes plataformas compartiendo grandes cantidades de código. La clase Device contiene una serie de propiedades y métodos para ayudar a personalizar la UI y la funcionalidad para cada plataforma.

Por ejemplo:

<StackLayout>
     <StackLayout.Margin>
          <OnPlatform x:TypeArguments="Thickness">
               <On Platform="iOS" Value="0,12,0,0" />
               <On Platform="Android, UWP" Value="0,0,0,12" />
          </OnPlatform>
     </StackLayout.Margin>
</StackLayout>

En el ejemplo anterior estamos personalizando la interfaz de usuario usando diferentes márgenes en iOS y en Android.

Cuando lo unico diferente es la ruta…

Sin embargo, un caso bastante habitual donde acabamos usando OnPlatform es a la hora de trabajar con imágenes.

<Image>
     <Image.Source>
          <OnPlatform x:TypeArguments="ImageSource">
               <On Platform="Android, iOS" Value="icon.png"/>
               <On Platform="UWP" Value="Assets/icon.png"/>
          </OnPlatform>
     </Image.Source>
</Image>

Esto sucede porque mientras que en Android e iOS las carpetas para añadir recursos (Assets, Resources) permiten escribir directamente el nombre del archivo, en el caso de UWP, las imágenes se encuentran dentro de la carpeta Assets del proyecto UWP.

¿Y si podemos simplificar estos casos?.

Nuevo Platform Specific para cubrir estos casos

Desde la versión 4.5.0.142-pre1, a nivel de aplicación o página, podemos usar el siguiente Platform Specific para UWP:

Application.Current.On<Windows>().SetImageDirectory("Assets");

Donde pasamos en el método, el nombre del directorio que deseamos que Xamarin.Forms use para buscar recursos por nosotros.

Gracias al Platform Specific anterior, podemos pasar de:

<Image>
     <Image.Source>
          <OnPlatform x:TypeArguments="ImageSource">
               <On Platform="Android, iOS" Value="icon.png"/>
               <On Platform="UWP" Value="Assets/icon.png"/>
          </OnPlatform>
     </Image.Source>
</Image>

A lo siguiente:

<Image Source="icon.png"/>

Sencillo, ¿verdad?.

Más información

Windows Developer Day 2017 – Creators Update

El evento

En una combinación entre ver el streaming de Microsoft en directo, sumado a algunas sesiones técnicas veremos todas las novedades que llegan junto a la actualización Creators Update.

Creators Update

Creators Update

¿Te apuntas?

La fecha

El evento tendrá lugar el próximo Miércoles, 08 de Febrero desde las 18:00h.

Más información

[Tips and Tricks] Habilitar PlayReady en aplicación UWP para Xbox One

Introducción

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 común 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.

Podemos crear apps que funcionen en todo tipo de dispositivos como teléfonos, tabletas, portátiles, dispositivos IoT, Surface Hub e incluso Xbox One. Para ello tenemos las vías utilizadas hasta este momento, es decir, utilizando C# y XAML (o VB, C++, etc).

Ahora con la posibilidad no solo de desarrollar aplicaciones UWP para Xbox One sino además con la posibilidad de publicar la misma en la tienda, se convierte en una nueva vía llena de posibilidades.

Entre el conjunto de aplicaciones de interés para la plataforma, existen algunas categorías con especial peso como por ejemplo, las aplicaciones multimedia. Contenido en directo, bajo demanda o compartir contenido multimedia a nivel social son opciones habituales hoy día y con gran interés en una Xbox One conectada a una gran pantalla.

Te lanzas manos a la obra, con contenido adaptativo PlayReady utilizando un MediaElement y Microsoft Universal Smooth Streaming Client SDK, todo funciona correctamente pero a la hora de reproducir en la Xbox One…

MEDIA_ERR_SRC_NOT_SUPPORTED – 0x80070005

¿Qué ocurre?.

La clave, entrada en el archivo de manifiesto

Tranquilo, no estas haciendo nada incorrecto, para reproducir contenido PlayReady DRM en una aplicación UWP en Xbox One se requiere una DeviceCapability específica en el manifiesto.

Haz clic derecho sobre el archivo Package.appxmanifiest. Selecciona la opción abrir con editor XML. Dentro del conjunto de Capabilities debes añadir:

<Capabilities>
    <DeviceCapability Name="6a7e5907-885c-4bcb-b40a-073c067bd3d5" />
</Capabilities>

Y todo listo!.

Más información

[Windows 10 Anniversary Update] Novedades en x:Bind, bindings compilados

Link - 05Introducció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 10 nos llegaba la posibilidad de crear bindings compilados en lugar de los bindings clásicos. Ya vimos previamente su uso, pros y contras en este artículo. Ahora, con la llegada del Anniversary Update nos llegan una gran cantidad de novedades relacionadas con el desarrollo que iremos desgranando poco a poco, entre las que se incluyen novedades en x:Bind.

¿En qué consisten?, ¿qué aportan?

En este artículo vamos a centrarnos en el conjunto de novedades incluidas en el sistema de enlace a datos compilados en la actualización Anniversary Update.

Enlace a métodos

Previamente, desde la versión 1607 de Windows, {x:Bind} soportaba un evento como parte del enlace a datos.

Veamos un ejemplo. Vamos a crear una interfaz mostrando un listado de casas. La colección de casas:

private ObservableCollection<House> _houses;

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

          return _houses;
     }
}

Que cargaremos con sencillos datos locales:

private void LoadHouses()
{
     _houses = new ObservableCollection<House>();

     _houses.Add(new House
     {
          Name = "Home 1"
     });
     _houses.Add(new House
     {
          Name = "Home 2"
     });
}

La interfaz de usuario, un control ListView enlazado con un enlace compilado a la colección:

<ListView
     ItemsSource="{x:Bind Houses}"
     ItemTemplate="{StaticResource HouseDataTemplate}" />

En cuanto a la plantilla que define cada elemento del listado:

<DataTemplate
     x:Key="HouseDataTemplate"
     x:DataType="model:House">
     <Grid>
          <Grid.ColumnDefinitions>
               <ColumnDefinition Width="Auto" />
               <ColumnDefinition Width="*" />
          </Grid.ColumnDefinitions>
          <TextBlock 
               Text="{x:Bind Name}"
               x:Phase="1"
               VerticalAlignment="Center" />
          <Button 
               Grid.Column="1"
               Content="Click me!"
               Click="{x:Bind Click}" />
     </Grid>
</DataTemplate

Se utiliza x:Bind para enlazar las propiedades, estableciendo el tipo de los datos a enlazar mediante la propiedad x:DataType.

NOTA: Recuerda que x:Bind está fuertemente tipado.

¿Ves algo “raro”?. El botón incluido dentro de la plantilla enlaza el evento Click a “algo” llamado Click.

Hasta ahora no habíamos visto la definición de la entidad House:

public class House
{ 
     public string Name { get; set; }

     public void Click(object sender, RoutedEventArgs e)
     {
          Debug.WriteLine(string.Format("Clicked {0}!", Name));
     }
}

Ahora probablemente has deducido que ocurre. Se pueden realizar enlace a datos directamente a eventos. Se necesita en el evento:

  • No tener parámetros. Ejemplo void Click().
  • Coincidir los parámetros con los parámetros del evento. Ejemplo: void Click(object sender, RoutedEventArgs e).
  • O coincidir con los tipos base de los parámetros del evento. Ejemplo: void Click(object sender, object e).

Al pulsar el botón de cada plantilla, se desencadena el evento Click que tenemos disponible en la entidad.

El resultado:

Event Bindings

Event Bindings

Ahora, tras la actualización Anniversary Update, se da un paso más permitiendo enlazar con cualquier método sin necesidad de un converter. Las únicas condiciones que debe complir el método es que sea público y en caso de tener parámetros, facilitarlos. Una forma de:

  • Obtener conversión de valores avanzada.
  • Tener un enlace a datos que dependa de más de un parámetro.

Veamos un ejemplo. En algunos formularios donde hay contraseñas involucradas se ofrece feedback visual de la seguridad de la contraseña introducida. Vamos a mostrar una barra de color rojo, naranja o rojo dependiendo de la seguridad.

Tendremos una propiedad donde se enlazará la contraseña:

public string UserPassword { get; set; }

En la UI:

<ProgressBar 
     Background="Transparent"
     Foreground="{x:Bind PasswordStrengthBrush(Password.Password), Mode=OneWay}"
     Value="{x:Bind PasswordStrengthValue(Password.Password), Mode=OneWay}"
     Height="3"/>
<PasswordBox 
     x:Name="Password"
     PlaceholderText="Insert Password"      
     Password="{x:Bind UserPassword, Mode=TwoWay}" />

Un control PasswordBox encargado de capturar la contraseña (utilizando x:Bind), y en la parte superior un ProgressBar que mostrará más o menos recorrido y distintos colores dependiendo de la seguridad de la contraseña introducida.

Fíjate en el enlace a datos de Foreground y Value del PasswordBox. ¿Qué está pasando?.

Para modificar el color se enlaza a un método público llamado PasswordStrengthBrush que recibe como parámetro la contraseña (directamente accediendo a la propiedad Password del PasswordBox!).

En cuanto al valor, de nuevo, se hace un enlace a un método público llamado PasswordStrengthValue recibiendo como parámetro de nuevo la contraseña.

El primero de los métodos:

public SolidColorBrush PasswordStrengthBrush(string password)
{
     if (string.IsNullOrEmpty(password))
          return new SolidColorBrush(Colors.Transparent);

     int length = password.Length;

     if (length >= 3 && length < 6)
          return new SolidColorBrush(Colors.Orange);
     if (length >= 6)
          return new SolidColorBrush(Colors.Green);

     return new SolidColorBrush(Colors.Red);
}

Si la longitud de la contraseña es inferior a tres carácteres, se devuelve color rojo, si es ingerior a seis carácteres, color naranja, devolviendo color verde en caso de que la longitud de la contraseña sea superior a seis carácteres.

El segundo de los métodos:

public double PasswordStrengthValue(string password)
{
     if (string.IsNullOrEmpty(password))
          return 0;

     int length = password.Length;

     if (length >= 3 && length < 6)
          return 66;
     if (length >= 6)
          return 100;

     return 33;
}

Aumentará el progreso de la barra de progreso en base a la longitud de la contraseña.

El resultado:

Function Bindings

Function Bindings

En un escenario donde se necesite un enlace a datos en modo two-way, se debe tener un segundo método encargado de hacer la operación inversa. Esto se consigue utilizando la propiedad BindBack.

Conversiones implícitas

x:Bind añade soporte a conversiones implícitas de algunos tipos.

¿Cuántas veces has creado un BoolToVisibilityConverter o similar (inverso, con opacidad, etc.)?.

Ya no sería necesario!. Podemos tener propiedades de tipo bool:

public bool IsVisible { get; set; }
public bool IsNotVisible { get; set; }

Donde una es cierta y otra falsa:

IsVisible = true;
IsNotVisible = false;

Al enlazar desde la UI:

<TextBlock 
     Text="Visible"
     Visibility="{x:Bind IsVisible}"/>
<TextBlock 
     Text="No Visible"
     Visibility="{x:Bind IsNotVisible}"/>

Podemos enlazar la propiedad Visibility directamente con bindings compilados a las propiedades de tipo bool.

¿El resultado?

Conversiones implícitas

Conversiones implícitas

El esperado, se muestra el elemento visual enlazada la propiedad verdadera. Se realiza la conversión implícita de un tipo a otro.

Castings de valor explícito soportados

Al contrario que el sistema de enlace a datos clásico que hace uso de duck typing, validación semántica, para validar el enlace, los bindings compilados verifican en tiempo de compilación que los tipos de los datos proporcionados coinciden. O lo que es lo mismo, si el valor que se estan tratando de enlazar no tiene un casting implícito al tipo de la propiedad, no se puede realizar el enlace sin un converter.

Eso era hasta ahora. Al más puro estilo C#, podemos declarar casting explícitos en un binding compilado.

Si tenemos una propiedad de tipo object:

public object Element { get; set; }

Si al crear la instancia, se crea utilizando un tipo específico (en nuestro ejemplo se utilizan tipos básicos para simplificar el ejemplo, object y TextBlock):

Element = new TextBlock
{
     Text = "Cool"
};

En la UI:

<TextBlock 
     Text="{x:Bind ((TextBlock)Element).Text}"/>

El resultado:

Casting explícito

Casting explícito

Se hace el casting al tipo TextBlock y podemos acceder a sus propiedades, enlazamos al texto.

Tenéis el código fuente del ejemplo utilizado disponible en GitHub:

Ver GitHub

Interesantes novedades, algunas de ellas muy solicitadas. También se han añadido otro tipo de actualizaciones menores como el soporte a más tipos de datos, por ejemplo, acceder a un índice específico de un diccionario clave-valor. Sin embargo, nos hemos concentrado en las que mayor impacto directo pueden tener en el desarrollo del día a día.

Y a ti, ¿qué te parecen?, ¿cúal es tu novedad favorita?, ¿qué te gustaría que se añadiese?.

Más información

[Material XDev Madrid] WinObjc: De iOS a Windows y extendiendo Xamarin.Forms

El evento

El pasado 09 de Agosto, desde el grupo XDev en Madrid, se organizaba un evento veraniego centrado en desarrollo móvil multiplataforma, con temas como convertir aplicaciones de iOS a UWP o extender Xamarin.Forms, además de tener momentos para el networking y algun que otro detalle con los asistentes.

El material

Pude participar en el evento con dos sesiones.

En la primera de ellos, nos centramos en el Windows Bridge para iOS, WinObjC. Convertimos algunas aplicaciones iOS a UWP e incluso vimos como añadir características específicas de la plataforma Windows como el uso de Live Tiles.

En la segunda sesión, nos centramos en como extender Xamarin.Forms para poder acceder a características específicas de cada plataforma, crear nuevos controles o efectos con el objetivo de ofrecer la mejor experiencia posible en cada plataforma, aun compartiendo gran parte de la interfaz de usuario.

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

Ver GitHub

Quisiera terminar añadiendo algunos agradecimientos. Gracias a todos los asistentes por asistir además de la constante participación con preguntas, en estas fechas y con tan poca antelación en el anuncio del evento es destacable; gracias a Dachi Gogotchuri por toda la ayuda en la organización y gracias a Liferay por sus increíbles instalaciones cediéndonos una sala. Nos vemos en la próxima!

Más información

Desktop App Converter, de Win32 a UWP

BridgeIntroducción

Llegar a Windows es mucho más sencillo que nunca. Si tienes una web, si tienes una App en iOS e incluso si partes de una App Win32, existen nuevas opciones destinadas a facilitar la llegada de esas Apps a Windows de la forma más sencilla posible. Si, hablamos de los Bridges presentados en el //BUILD del año 2015.

Un año después, en el marco del //BUILD 2016 se ha profundizado, conocido e incluso tenemos acceso a Project Centennial renombrado como Desktop App Converter, destinado a convertir Apps basadas en .NET y Win32 como Apps UWP. Además, permite el acceso a servicios o APIs UWP.

//BUILD 2016

//BUILD 2016

¿Quieres saber más el respecto?

En este artículo vamos a convertir una App Win32 a UWP utilizando Desktop App Converter paso a paso, desde la instalación de la herramienta hasta tener el paquete preparado, firmado y listo para distribución.

¿Qué es Desktop App Converter?

Herramienta disponible (pre-release) que nos permite llevar las aplicaciones de escritorio NET 4.6.1 o Win32 a la plataforma universal Windows (UWP). Basado en una línea de comandos, que se puede ejecutar de forma desatendida o silenciosa, crea un paquete appx que puede ser instalado mediante el comando Add-AppxPackage de PowerShell.

Desktop App Converter

Desktop App Converter

El convertidor utiliza una imagen limpia del sistema (disponible junto al convertidor) para utilizar una versión totalmente limpia del mismo y capturar cualquier entrada de registro, rutas de archivos, etc. y empaquetarlo todo en un paquete appx con su archivo de manifiesto correspondiente.

Las principales características son:

  • Permite convertir Apps Win32 a UWP.
  • Mantener y reutilizar la investigación y desarrollo invertida en la aplicación Win32.
  • Poder añadir y utilizar APIs UWP (Tiles, etc).
  • Utilizar la Windows Store y también poder monetizar la aplicación utilizando esta vía.

Preparación del entorno

Comenzamos descargando y preparando la herramienta pero antes incluso de descarga, repasemos los prerequisitos de hardware y software. Necesitamos una máquina de desarrollo con:

  • Procesador de 64 bits
  • Hardware-assisted virtualization
  • Second Level Address Translation (SLAT)

Mientras que a nivel de software debemos tener la versión 10.0.14316.0 o superior de Windows 10 Preview.

NOTA: Debemos tener la versión Enterprise de Windows para poder utilizar la herramienta. De momento, la versión pre-release disponible no funciona en la versión Pro.

Una vez revisados (y cumplidos) los requisitos necesarios realizamos la descarga de la herramienta. Podemos descargar Desktop App Converter desde el siguiente enlace.

Descargar Desktop App Converter

Descargar Desktop App Converter

Será necesario descargar:

  • DesktopAppConverter.zip
  • BaseImage-14316.wim

Tras extraer el archivo zip, estamos preparados para comenzar a preparar el entorno.

Comenzamos abriendo una ventana de PowerShell con privilegios de administrador.

Comenzamos modificando las preferencias de las políticas de ejecución de PowerShell evitando bloqueos o mensajes de alerta.

Set-ExecutionPolicy bypass
Set-ExecutionPolicy bypass

Set-ExecutionPolicy bypass

A continuación realizamos el setup de la herramienta con la siguiente línea:

.\DesktopAppConverter.ps1 -Setup -BaseImage .\BaseImage-14316.wim

NOTA: Debemos asegurarnos de navegar a la carpeta correspondiente donde hemos descomprimido la herramienta. Dependiendo de la elegida, la línea anterior puede cambiar ligeramente.

Llegados a este punto tenemos todo lo necesario para comenzar a utilizar la herramienta, es decir, para convertir Apps Win32 a UWP.

De Win32 a UWP!

El uso de la herramienta, como hemos comentado previamente, se realiza vía línea de comandos contando con gran cantidad de opciones:

DesktopAppConverter.ps1
-ExpandedBaseImage <String>
-Installer <String> [-InstallerArguments <String>] [-InstallerValidExitCodes <Int32>]
-Destination <String>
-PackageName <String>
-Publisher <String>
-Version <Version>
[-AppExecutable <String>]
[-AppFileTypes <String>]
[-AppId <String>]
[-AppDisplayName <String>]
[-AppDescription <String>]
[-PackageDisplayName <String>]
[-PackagePublisherDisplayName <String>]
[-MakeAppx]
[-NatSubnetPrefix <String>]
[-LogFile <String>]
[<CommonParameters>]

Tendremos parámetros obligatorios:

  • -ExpandedBaseImage: Ruta absoluta a la imagen base.
  • -Installer: Ruta a la aplicación Win32.
  • -InstallerArguments: Lista de parámetros separados por comas. Este parámetro es opcional si usamos un msi. Nos permite configurar sistema de logs, instalación silenciosa, etc.
  • -Destination: Ruta del paquete appx resultante.
  • -PackageName: El nombre que identifica el paquete.
  • -Publisher: Nombre del publicador incluido en el paquete.
  • -Version: Versión del paquete.

y otros opciones que pueden sernos de utilidad según el caso (por ejemplo, modo verboso). Podemos acceder vía línea de comandos a la ayuda de la herramienta en todo momento:

get-help .\DesktopAppConverter.ps1 -detailed

De modo que, convertir una aplicación Win32 llamada App.exe a una App UWP llamada “App” con versión 0.0.0.1 y publicador jsuarez serían tan sencillo como:

.\DesktopAppConverter.ps1 -Expanded C:\ProgramData\Microsoft\Windows\Images\BaseImage-14316 
–Installer C:\DesktopAppConverter\App.exe -InstallerArguments "/S" -Destination "C:\DesktopAppConverter\Output" 
-PackageName "App" -Publisher "CN=jsuarez" -Version 0.0.0.1 -MakeAppx -Verbose

Ejecutando el script en modo verboso en todo momento tenemos feedback del proceso (repaso de requisitos, conversión de rutas, registro,  preparación del manifiesto, etc):

Proceso de conversión

Proceso de conversión

Una vez terminado el proceso, en la carpeta de salida:

El resultado

El resultado

NOTA: Los paquetes generados por ahora sólo se pueden desplegar en sistemas x64.

Firmar el paquete

Para distribuir el paquete utilizaremos el comando Add-AppxPackage disponible en PowerShell. Para poder distribuirlo, el paquete debe estar firmado.

Para firmar el paquete, comenzaremos creando un certificado temporal utilizando la herramienta MakeCert. Abrimos una nueva ventana del símbolo del sistema de VS:

Símbolo del sistema de VS

Símbolo del sistema de VS

Bastará con escribir:

MakeCert.exe -r -h 0 -n "CN=jsuarez" -eku 1.3.6.1.5.5.7.3.3 -pe -sv myCert.pvk myCert.cer

Nos pedirá una contraseña:

Creando certificado

Creando certificado

A continuación, utilizamos Pvk2Pfx para generar el archivo pfx a utilizar para firmar el paquete:

pvk2pfx.exe -pvk myCert.pvk -spc myCert.cer -pfx myCert.pfx

Por último, utilizando Signtool para firmar el paquete:

signtool.exe sign -f myCert.pfx -fd SHA256 -v "C:\DesktopAppConverter\Output\App.appx"

Todo listo!. Ahora tenemos nuestra App Win32 conertida a UWP y lista para su distribución.

Despliegue

Utilizaremos la línea de comandos Add-AppxPackage para instalar la App. Sin embargo, obtendremos un error si en la máquina no tenemos importado el certificado con el que se firmó la App.

Para importar el certificado:

  1. Clic derecho sobre el paquete de la App, Propiedades -> Firmas digitales.
  2. Seleccionamos la firma, ver detalles y a continuación, ver certificado.
  3. Instalar certificado.
  4. Elegimos la opción equipo local y el contenedor de personas de confianza.
  5. Completamos.
Instalando certificado

Instalando certificado

Todo listo!. Ahora si, podemos ejecutar la línea:

Add-AppxPackages "C:\DesktopAppConverter\Output\App.appx"

La App se instalará!

Otros detalles

Desktop App Converter por defecto captura información relacionada con su uso y se la envía a Microsoft con el objetivo de mejora continua. Si deseamos modificar el comportamiento podemos añadir el siguiente valor del registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DesktopAppConverter

Añadiremos el valor DisableTelemetry con DWORD establecido a 1 para deshabilitar el envío de información. Para volver a habilitar bastará con establecer el valor a 0 o bien, eliminar la entrada del registro.

¿Y ahora qué?

Llegados a este punto conocemos la herramienta, sus posibilidades y podemos comenzar a sacarle partido. Sin embargo, aún podemos llegar mucho más lejos. Podemos hacer uso desde la aplicación de de APIs UWP como:

  • Live Tiles
  • Cortana
  • Notificaciones
  • Etc

Podemos migrar código, utilizar AppServices y mucho más!. En próximos artículos continuaremos profundizando en la herramienta viendo coo realizar alguna de estas acciones. Os espero en el próximo!

Mientras tanto, ¿cuáles son vuestras experiencias?, ¿qué os parece Desktop App Converter?. Recordar que cualquier tipo de duda, sugerencia o comentario la podéis dejar en los comentarios de la entrada.

Más información

[Xamarin.Forms] Soporte a UWP

Windows 8Universal Windows Platform

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 común 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.

Windows 10

Windows 10

Podemos crear apps que funcionen en todo tipo de dispositivos como teléfonos, tabletas, portátiles, dispositivos IoT, Surface Hub e incluso HoloLens. Para ello tenemos las vías utilizadas hasta este momento, es decir, utilizando C# y XAML (o VB, C++, etc).

Xamarin.Forms 2.0

Con la llegada de Xamarin 4 han aterrizado una gran cantidad de diversas novedades entre las que destaca la versión 2.0 de Xamarin Forms. Entre las novedades principales contamos con:

  • Soporte a UWP.
  • Compilación de XAML (XAMLC).
  • Optimización en Layouts.
  • Optimización de listados. Incluidas nuevas estrategias de cacheo.
  • Corrección de bugs.

Añadiendo UWP a App Xamarin.Forms

Vamos a crear un proyecto Xamarin.Forms y le añadiremos soporte a UWP. Necesitaremos:

  • Visual Studio 2015
  • Windows 10
  • Xamarin.Forms 2.0

Creamos un nuevo proyecto Xamarin.Forms:

Nueva App Xamarin.Forms

Nueva App Xamarin.Forms

Sobre la solución hacemos clic derecho y seleccionamos la opción añadir nuevo proyecto. Dentro de la categoría Universal elegimos la plantilla en blanco.

Nueva Aplicación Universal

Nueva Aplicación Universal

Tras añadir el nuevo proyecto, continuaremos añadiéndolo el paquete NuGet de Xamarin.Forms 2.0 necesario.

Añadimos la referencia a la PCL.

Tenemos las referencias a la PCL y a Xamarin.Forms, ahora debemos realizar pequeñas modificaciones en código para inicializar Xamarin Forms y la aplicación. En el método OnLaunched de App.xaml.cs utilizaremos el método Init para inicializar Xamarin.Forms:

Xamarin.Forms.Forms.Init (e);

En las vista principal, MainPage.xaml modificamos el tipo de la página de Page a WindowsPage utilizando el namespace Xamarin.Forms.Platform.UWP.

xmlns:forms="using:Xamarin.Forms.Platform.UWP"

Por último, añadimos una llamada al método LoadApplication en el contructor de la vista principal, MainPage.xaml.cs para inicializar la aplicación.

LoadApplication(new UWP.App());

Tenéis el código fuente disponible e GitHub:

Ver GitHub

Recordad que podéis dejar cualquier comentario, sugerencia o duda en los comentarios.

Limitaciones

El soporte es bastante elevado pero no es aún completo. Existen una serie de limitaciones conocidas:

  • El aspecto de algunas páginas o elementos no esta cerrado.
  • Existe algún posible error en navegación.
  • No hay soporte aún a mapas.

Más información