[Windows Phone 8.1] MVVM en apps universales.

Hola a todos!

Una de las grandes novedades, como ya vimos anteriormente, en la nueva versión de Windows Phone 8.1 son las aplicaciones universales. Este nuevo tipo de proyecto nos promete ser capaces de compartir la gran mayoría de código entre una versión Windows Store y otra Windows Phone de la misma aplicación. ¿Pero realmente es así? Antes de empezar a repasar nuevas APIs, XAML y otras cosas, creo que es importante ver como podemos usar MVVM en nuestras aplicaciones universales para compartir gran parte del código.

Implementando MVVM en proyectos universales

Realmente la implementación de MVVM no cambia en absoluto, con respecto a la que podríamos hacer en Windows Phone 8.0 o Windows Store. Lo único que cambia es el proyecto donde colocamos nuestros archivos.

Mientras que anteriormente implementábamos MVVM en el propio proyecto de la aplicación o una PCL, en las apps universales usaremos el proyecto Shared para almacenar nuestros archivos. El objetivo es llegar a tener solo el XAML de las páginas en cada proyecto de plataforma y que toda la lógica de la aplicación esté centralizada en el proyecto Shared. ¿Es esto posible? Si en la mayoría de los casos. Siempre nos encontraremos con casos en que las APIs de Phone y Store no son exactamente iguales, incluso donde su valor de retorno no es el mismo. En estos casos tendremos dos opciones: Crear una ViewModel específica para cada proyecto o usar bloques condicionales de compilación. ¿Cual usar en cada caso? Pues dependerá un poco de nuestras necesidades particulares en cada momento y de lo que necesitemos hacer. Si es poco el código particular de cada plataforma y mucho el código compartido, quizás usar un bloque condicional nos ayude a compartir código y no tener que reescribirlo todo. Sin embargo, si el código particular es la mayoría de la ViewModel, quizás sea mejor crear una por cada plataforma.

Vamos a comenzar por las bases. En todo proyecto XAML con MVVM, me gusta crear dos clases base: PageBase y ViewModelBase.

PageBase

PageBase la usaré como clase base de todas mis páginas. Esto me permite varias cosas:

  • Definir comportamientos comunes a todas las páginas, como detección de internet.
  • Definición de transiciones comunes.
  • En conjunto con la ViewModelBase, “rutear” los metodos de navegación hacia las ViewModels.
  • Establecer en la ViewModelBase el Frame activo de cada página, de forma que sea más facilmente accesible.

Con esta funcionalidad, la clase PageBase tendría este aspecto:

PageBase
public class PageBase : Page
{
    private ViewModelBase vm;

    public PageBase()
    {
    }

    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);
    }

    protected override void OnNavigatingFrom(NavigatingCancelEventArgs e)
    {
        base.OnNavigatingFrom(e);
        vm.OnNavigatingFrom(e);
    }
}

Aquí podemos observar una de las ventajas de Windows Phone 8.1 y las aplicaciones universales. Ya no tenemos un objeto PhoneApplicationPage. Ahora todas las páginas, tanto de Windows Phone como Windows Store, heredan del objeto Page. Esto permite que de igual forma, nuestra página base pueda ser compartida entre las dos plataformas.

Podéis ver que el código no es nada de otro mundo, controlamos los métodos de navegación y en el método OnNavigateTo obtenemos la ViewModel asignada a la página y establecemos el Frame activo en la misma. Por último en todos los métodos de navegación invocamos un método que se llama igual en la ViewModelBase. De esta forma no necesitamos usar code behind para controlar la navegación de nuestras páginas.

ViewModelBase

Nuestra ViewModelBase actuará como la clase base de las cuales heredarán todas nuestras ViewModels, lo que nos permitirá darles una funcionalidad básica y homogénea a todas:

  • Acceso al objeto Frame de la página asociada.
  • Acceso a los eventos de navegación para sobre escribirlos.
  • Notificación de cambios.
  • Notificación de carga a la UI.

El código de la ViewModelBase, sería parecido a este:

ViewModelBase
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 OnNavigatingFrom(NavigatingCancelEventArgs 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;
    }
}

Hemos creado tres métodos abstractos: OnNavigatedFrom, OnNavigatingFrom y OnNavigatedTo que implementaremos en nuestras ViewModels para poder ejecutar código durante la navegación. Esto es muy útil cuando queremos recibir un parámetro de otra página, pero también al cargar datos. Si realizamos carga de datos en el constructor, podemos ralentizar la carga de la página. Sin embargo usando el método OnNavigatedTo, realizamos la carga una vez que la página está activa, no antes.

Ahora ya podemos empezar a crear nuestras páginas y ViewModels, usando las clases base que hemos definido.

Páginas

En cada página, tendremos que incluir el namespace de nuestra página base y cambiar su tipo, tanto en XAML como en C#:

 

MainPage.xaml
<base:PageBase
    x:Class=“Wp81MVVM.MainPage”
    xmlns:base=“using:Wp81MVVM.Base”
    xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”
    xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml”
    xmlns:local=“using:Wp81MVVM”
    xmlns:d=“http://schemas.microsoft.com/expression/blend/2008”
    xmlns:mc=“http://schemas.openxmlformats.org/markup-compatibility/2006”
    mc:Ignorable=“d”>

    <Grid Background=”{ThemeResource ApplicationPageBackgroundThemeBrush}>

    </Grid>
</base:PageBase>

 

 

MainPage.xaml.cs
namespace Wp81MVVM
{
    using Wp81MVVM.Base;

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

 

Ahora solo tenemos que definir una ViewModel para esta página, implementando la ViewModelBase y sus métodos abstractos de navegación:

ViewModel
public class MainViewModel : ViewModelBase
{
    public MainViewModel()
    {

    }

    public override Task OnNavigatedTo(Windows.UI.Xaml.Navigation.NavigationEventArgs args)
    {
        return null;
    }

    public override Task OnNavigatedFrom(Windows.UI.Xaml.Navigation.NavigationEventArgs args)
    {
        return null;
    }

    public override Task OnNavigatingFrom(Windows.UI.Xaml.Navigation.NavigatingCancelEventArgs args)
    {
        return null;
    }
}

Ya solo nos queda unir nuestra página y nuestra ViewModel, de la forma que más nos guste: usando IoC, asignándola directamente en el constructor de la página… En este caso voy a usar Unity para resolver nuestra ViewModel y servicios. Para ello, lo primero que necesitaremos es añadir una referencia en nuestro proyecto universal a Unity. En este tipo de proyectos esto significa añadir la referencia a cada proyecto de plataforma (Phone y Store). Vamos a comenzar por el proyecto Store. Solo tenemos que hacer click derecho sobre el nodo “References” del proyecto y seleccionar la opción “Manage NuGet packages”, buscar “Unity” y presionar el botón instalar:

image

Ahora deberíamos repetir lo mismo con el proyecto Phone, pero el resultado será el siguiente:

image

El problema aquí es que, en la mayoría de los casos, todavía no se han actualizado los paquetes de NuGet para soportar los tipos de proyecto “WindowsPhoneApp, version=8.1”. ¿Quiere decir esto que no podemos usar Unity? Ni mucho menos. Lo unico que quiere decir es que no podemos instalarlo desde NuGet. Como Windows Phone 8.1 y Windows Store comparten ahora todo el core de desarrollo, “en teoría” podríamos usar el mismo ensamblado que en Windows Store. Solo tenemos que hacer click con el botón derecho sobre “References” en el proyecto Windows Phone y seleccionar “Add Reference”, presionar el botón “Browse” e ir a la carpeta de packages donde se ha descargado Unity para Windows Store previamente, seleccionando la carpeta NetCore45, que es la usada en Windows Store, seleccionamos la dll dentro de esa carpeta y presionamos “add” y “ok” y listo, ya tendremos Unity funcionando en nuestra aplicación Windows Phone 8.1.

Ahora en nuestro proyecto Shared, en la carpeta Base de ViewModels, vamos a añadir una nueva clase llamada ViewModelLocator, que haga uso de Unity para registrar y resolver nuestras ViewModels, exponiéndolas mediante propiedades públicas:

ViewModelLocator
public class ViewModelLocator
{
    IUnityContainer container;

    public ViewModelLocator()
    {
        container = new UnityContainer();

        container.RegisterType<MainViewModel>();
    }

    public MainViewModel MainViewModel
    {
        get { return container.Resolve<MainViewModel>(); }
    }
}

Como podemos ver, desde nuestro proyecto Shared podemos acceder a cualquier ensamblado referenciado en nuestros proyectos de plataforma, haciendo muy sencillo escribir código compartido. Ya solo nos queda añadir nuestro ViewModelLocator como una referencia en el archivo App.xaml, que también se encuentra compartido en el proyecto Shared:

Shared App.xaml
<Application
    x:Class=“Wp81MVVM.App”
    xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”
    xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml”
    xmlns:local=“using:Wp81MVVM”
    xmlns:VMBase=“using:Wp81MVVM.Base”>

    <Application.Resources>
        <VMBase:ViewModelLocator x:Key=“Locator”/>
    </Application.Resources>
</Application>

Y ya lo podemos usar en las páginas de ambas plataformas. De la misma forma que haríamos en un proyecto de Phone o Store tradicional:

 

MainPage.xaml Windows Store
<base:PageBase
    x:Class=“Wp81MVVM.MainPage”
    xmlns:base=“using:Wp81MVVM.Base”
    xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”
    xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml”
    xmlns:local=“using:Wp81MVVM”
    xmlns:d=“http://schemas.microsoft.com/expression/blend/2008”
    xmlns:mc=“http://schemas.openxmlformats.org/markup-compatibility/2006”
    mc:Ignorable=“d”
    DataContext=”{Binding MainViewModel, Source={StaticResource Locator}}>

    <Grid Background=”{ThemeResource ApplicationPageBackgroundThemeBrush}>

    </Grid>
</base:PageBase>

 

 

 

Mainpage.xaml Windows Phone
<base:PageBase
    x:Class=“Wp81MVVM.MainPage”
    xmlns:base=“using:Wp81MVVM.Base”
    xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”
    xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml”
    xmlns:local=“using:Wp81MVVM”
    xmlns:d=“http://schemas.microsoft.com/expression/blend/2008”
    xmlns:mc=“http://schemas.openxmlformats.org/markup-compatibility/2006”
    mc:Ignorable=“d”
    Background=”{ThemeResource ApplicationPageBackgroundThemeBrush}
    DataContext=”{Binding MainViewModel, Source={StaticResource Locator}}>

    <Grid>

    </Grid>
</base:PageBase>

 

En este punto, puede parecer que tener una sola página es mejor y compartirla en el proyecto Shared. Si, podríamos hacerlo sin ninguna dificultad. Pero en la mayoría de los casos, haría que en Phone o Store, la UX fuese horrible. En mi caso soy un firme defensor de hacer una interface de usuario para cada plataforma, aprovechándonos de sus puntos fuertes. Sin embargo, si que es posible que nos encontremos compartiendo pequeños trozos de interface en forma de controles de usuario y en muchos casos usando las diferentes páginas solo para modificar la distribución de la información en pantalla para aprovechar mejor el área de trabajo de cada plataforma. Esto da para un próximo artículo.

Conclusión

Esto es todo por hoy, como hemos podido ver es muy fácil compartir código con los proyectos universales, sin necesidad de hacks ni cosas extrañas (seguro que en algún momento nos hacen falta jeje) y nos permite construir apps para la plataforma Windows en conjunto. Como siempre, podéis descargar todo el código de ejemplo aquí para jugar con él y usarlo como punto de partida para vuestras apps.

Sería un buen arranque para una app que queráis presentar en el Hackathon //Publish del 16 de Mayo en Madrid, Barcelona o Palma de Mayorca. Premios, asistencia para el diseño de tu app, y mentores para ayudarte a crear el próximo hit!

Un saludo y Happy Coding!

 

[Eventos] Después del //Build/ llega //Learn/ y //Publish/

Hola a todos!

Solo hace unos días que termino el //Build/ 2014. Este año los seguidores de Windows Phone tuvimos grandes novedades y anuncios con la presentación de Windows Phone 8.1. Desde Microsoft Corp. y la comunidad de MVPs de Windows Phone, queremos ayudarte a seguir el ritmo de las novedades y crear grandes aplicaciones usando las nuevas ventajas que ofrece la plataforma Windows con esta última revisión.

Para ello, se han creado dos eventos que tendrán lugar en Abril y Mayo: //Learn/ y //Publish/

//Learn/

Este evento online está organizado directamente por los MVPs de Windows Phone. Durante 6 horas, tendremos webcast sobre diferentes temáticas de Windows Phone 8.1: aplicaciones universales, diseño, nuevas APIs, notificaciones… Lo mejor de todo, es que no solo será en Inglés. Dispondremos de una track principal en inglés y tracks paralelas en Chino, Ruso, Portugués, Frances y Español!!

En la Track en Español, Sorey García, Roberto Alvarado, Jose Luis Latorre, Ivan Toledo y un servidor estaremos dando todo el contenido. Las sesiones que tendremos serán las siguientes (Puede variar alguna todavía):

  • Introducción a Windows Phone 8.1
  • Empezando a construir apps Windows XAML
  • Controles de layout y transiciones de páginas
  • Adaptando tu UI a diferentes pantallas
  • Ciclo de vida de apps WinRT XAML
  • Tiles, badges, notificaciones y el Action center
  • Tareas en background
  • Windows XAML para desarrolladores Silverlight

El evento se celebrará el 24 de Abril, se pueden registrar aquí. Al ser un evento internacional los horarios han tenido que ser consensuados y España no sale demasiado bien parada. El evento en España empezará alrededor de la 1 de la mañana del día 25… pero no os preocupéis, el material será grabado y al día siguiente, o tan pronto tenga los enlaces, los pondré aquí.

//Publish/

Cerca de un mes después del evento //Learn/ tendremos un nuevo evento, esta vez presencial. Se trata de un hackathon organizado entre Microsoft y la comunidad MVP. En él ayudaremos a los asistentes a crear apps para Windows 8.1 y Windows Phone 8.1, tendremos mentores, premios, dispositivos para probar vuestras apps y os invitaremos a comer.

En España tenemos la suerte de tener tres sedes: Barcelona, organizada por Microsoft y Madrid y Palma de Mallorca, organizadas por la comunidad MVP. En mi caso estaré en Madrid, junto con Javier Suarez y Santiago Porras para ayudaros a crear apps increíbles y publicarlas. El evento en Madrid se llevará a cabo en las oficinas de Microsoft el día 16 de mayo.

En breve tendremos más información, según vayamos avanzando con la organización y actualizaré este post con todas las novedades. Por ahora podéis registraros en cualquiera de las tres sedes aquí.

Estos eventos son grandes oportunidades para actualizar vuestros conocimientos o introduciros en la plataforma Windows, así que no perdáis esta oportunidad. Nos vemos en breve.

Un saludo y Happy Coding!

[Windows Phone 8.1] Opciones para desarrollar

Hola a todos!

En el artículo anterior, hablamos sobre las novedades de Windows Phone 8.1 en cuanto a las herramientas que tenemos disponibles. Hoy vamos a hablar sobre las nuevas opciones y frameworks que tenemos disponibles para crear nuestras aplicaciones.

Bien, esta es una de las cosas que mas enrolladas están. Windows Phone 8.1 trae consigo nuevas formas de hacer las cosas, pero Microsoft no ha querido dejar a nadie en la cuneta, con lo que es totalmente compatible con el código que ya teníamos para Windows Phone 8.0.

En primer lugar tenemos que tener en cuenta que el motor de ejecución de apps ha cambiado en Windows Phone 8.1. Se ha abandonado el motor basado en Silverlight y se ha creado todo un nuevo motor de ejecución basado en WinRT y Windows Store. Pero sobre este motor, se ha trabajado para poder ejecutar las aplicaciones de Windows phone 8.0 sin necesidad de realizar ningún cambio ni adaptarlas. Automáticamente todas son compatibles. Con esto, podemos desarrollar de las siguientes formas:

  • Silverlight para Windows Phone 8.0: Podemos crear una app de Windows Phone 8.0 y se ejecutará perfectamente en terminales 8.0 y 8.1. Pero no tendremos acceso a las nuevas APIs de Windows Phone 8.1.
  • Silverlight para Windows Phone 8.1: Esta nueva versión nos permite migrar una app Windows Phone 8.0 de forma muy rápida (con una opción de menú) y además acceder a las nuevas APIs de Windows Phone 8.1.
  • Windows XAML: Es la gran novedad de Windows Phone 8.1, básicamente es el mismo sistema usado en las apps Windows Store XAML. 100% WinRT y mismo XAML para la interface de usuario. Es el que más cambia con respecto a la anterior versión del sistema. Con Windows XAML podremos crear proyectos universales, de los que hablaremos más adelante, que nos permitirán desarrollar para Windows Phone y Windows Store de forma muy sencilla.
  • WinJS: Para todos los aficionados a HTML5, JS y CSS… ahora podréis desarrollar apps Windows Phone nativas de la misma forma que ya se hacía en Windows Store usando HTML5 y JS. Con WinJS también podréis realizar proyectos universales. Cabe mencionar que, aunque usemos la denominación WinJS, en realidad estamos hablando de HTML5 y JS nativo, con lo que podrás usar librerías como JQuery, Angular, Knockout… WinJS es solo necesario para acceder a funcionalidades del sistema.

El nuevo camino planteado por Microsoft es Windows XAML / WinJS. Silverlight para Windows Phone 8.1 ha sido pensado para escenarios muy concretos. En particular la mayor fortaleza de Silverlight es permitirte migrar tus desarrollos de Windows Phone 8.0 a 8.1 y conseguir acceso a las nuevas APIs sin tener que reescribir toda la aplicación o gran parte de ella.

De echo, las aplicaciones de correo, alarmas, calendario, etc… que vienen en el sistema están escritas con este mismo framework Windows XAML. Con lo que nos podemos hacer una idea de su potencia dandole un vistazo a las mismas. Se ha reescrito el motor de ejecución de aplicaciones para Windows XAML y se ha creado una superficie compatible con Silverlight que permite la ejecución de las nuevas aplicaciones de Silverlight 8.1 en el motor de Windows XAML. De esta forma es como las apps  de Silverlight 8.1 pueden acceder a las nuevas APIs de Windows XAML.

image

Como podemos ver, nuestras apps de Windows Phone 8 se seguirán ejecutando sobre el mismo motor, por lo que no tendremos problemas de compatibilidad. Las apps Silverlight 8.1 se ejecutarán sobre una superficie de compatibilidad sobre el motor de ejecución Windows XAML, por eso tienen acceso a todas las nuevas APIs (nuestras apps wp8 no podrán acceder a las nuevas APIs ni usando reflection siquiera). Las nuevas aplicaciones Windows XAML se ejecutan directamente sobre su nuevo motor.

Pero cada sistema tiene sus pros y sus contras. Windows XAML es una nueva manera de desarrollar traída directamente de las aplicaciones Windows Store e introduce muchos cambios. Así, echaremos en falta los ya tan típicos Launchers y Choosers de Windows Phone, que no existen en Windows XAML y algunas cosas más. ¿Como decidimos entre uno u otro para nuestros desarrollos? Aquí intento dejaros una lista de cosas a valorar. La más importante no obstante es recordar que Silverlight para Windows Phone 8.1 existe como ayuda en la transición a la nueva versión del sistema. La opción de continuidad en el futuro es Windows XAML. No incluimos Silverlight para Windows Phone 8 en este apartado, porque no tienes que hacer nada, por defecto tu aplicación funcionará en Windows Phone 8.1.

  • Silverlight para Windows Phone 8.1:
    • Parto de una aplicación para Windows Phone 8.0.
    • No estoy interesado en hacer una versión para Windows Store.
    • Quiero poder tener acceso a las nuevas APIs de Windows Phone 8.1.
    • Necesito hacer uso de Launchers y Choosers en mi aplicación.
    • Mi aplicación usa como característica importante el acceso a la pantalla de bloqueo.
  • Windows XAML:
    • Parto de una aplicación Windows Store.
    • No parto de una aplicación Windows Store o Windows Phone, empiezo desde 0.
    • Tengo una aplicación para Windows Phone 8.0 pero no hago uso de Launchers y Choosers o la pantalla de bloqueo.
    • Quiero poder tener un proyecto único para mi aplicación Phone y Store, de forma que sea muy sencillo mantener ambas aplicaciones.
  • WinJS:
    • Tengo una aplicación WinJS para Windows Store.

Como podemos ver, para cada uno la situación puede ser distinta y el camino a escoger también. Me gusta que Microsoft haya tenido en cuenta el ofrecer una vía rápida de migración de Windows Phone 8.0 a 8.1, mediante Silverlight. Pero debemos tener en cuenta que se trata de eso, una vía de migración. En mi opinión, si vamos a desarrollar una aplicación nueva deberíamos decantarnos por Windows Xaml / WinJS (según nuestra preferencia de lenguaje) y plantearnos seriamente usar los nuevos tipos de proyectos “Universales” que nos permiten desarrollar para Store y Phone al mismo tiempo. Pero, como ya mencionamos antes, Windows XAML trae consigo muchas APIs nuevas y otras muchas que han desaparecido. ¿Qué APIs vamos a perder en comparación con Silverlight y que alternativas tenemos? Vamos a intentar ponerlas en común:

API Silverlight API Windows XAML Notas
PhotoChooserTask y CameraCaptureTask FileOpenPicker Cuando al FileOpenPicker le añadimos un filtro de archivo de imágenes, muestra un botón para acceder a la cámara, además de permitirnos seleccionar una o varias imágenes del teléfono.
Maps/Call/Mail/Marketplace LaunchUri Muchos Launchers y Choosers se pueden cambiar por Uris estandard.
IconicTile / CycleTile, FlipTile Windows 8.1 tiles Ahora los tiles en Windows Phone 8.1 son los mismos que en Windows Store, por lo que los tres tipos de 8.0 desaparecen, podemos elegir entre cerca de 60 plantillas.
Scheduled Background agent Background Task Las tareas en background pasan a ser las usadas en Windows Store.
MPNS WNS Las notificaciones push dejan de usar el sistema Microsoft Push Notification Service para acoger el Windows Notification Service, de Windows Store.
Share Tasks Share Contract En Windows Phone 8.1 tenemos el mismo contrato de compartir que ya teníamos en Windows Store.
Panorama control Hub control El control panorama desaparece y es sustituido por el control Hub de Windows Store, se mantiene el control Pivot.
LongListSelector GridView/ListView/SemanticZoom Se cambia el control LongListSelector por los Grid/ListView con SemanticZoom.

También hay APIs que desaparecen sin alternativa:

  • Lockscreen, en Windows XAML no tendremos acceso a las APIs para establecer nuestra aplicación como proveedor de la imagen de la pantalla de bloqueo.
  • FMRadio, en Windows XAML no tendremos acceso al API de radio FM.
  • Globalization, se usará el sistema de globalización de Windows Store, por lo que este namespace entero desaparece.
  • Voip, no existe en Windows XAML.
  • Alarm/PeriodicTask/ScheduledAction, no existe en Windows XAML.
  • RadialGradientBrush, no existe en Windows XAML.

Tendremos que tener estas listas en cuenta. Si nuestra aplicación necesita alguna de estas APIs, deberemos usar Silverlight para Windows Phone 8.1.

Pero no todo son pérdidas. También tendremos muchas nuevas APIs que nos brindarán mucha más potencia para nuestros desarrollos:

  • Acceso a la galería de imágenes/videos/documentos y música. Mediante el uso de FileOpenPicker podremos acceder a todos los documentos y archivos multimedia de nuestro dispositivo sin restricciones!
  • APIs criptográficas, para poder leer y trabajar con PKIs, certificados  X509 y soporte de métodos criptográficos estandard.
  • Nueva ApplicationBar, extraida directamente de Windows 8.1, enlazable a datos y con muchas nuevas funcionalidades.
  • Nuevos controles: FlipView, GridView, ListView, SemanticZoom, Menu flyouts, RichTextBox, Hub…
  • Nuevo API MediaPlayer para reproducción en background de audio.
  • Namespace Windows.Media.Editing para ayudarnos a editar video directamente en nuestra aplicación.
  • Nuevas funcionalidades de captura de la pantalla de nuestra aplicación para poder grabar videos de la misma usando el namespace Windows.Media.Capture.
  • Transferencias en background mejoradas.
  • Nuevos tiles.
  • Capacidades de Geofencing, que nos permitirán disparar ejecución de código en segundo plano basado en posicionamiento.
  • NFC: mejor soporte de TAGS, TAGS de solo lectura, escribir TAGS sin formato.
  • Control WebView mejorado (el mismo que en Windows Store).
  • Se suprime el IsolatedStorage completamente para dar paso a la api de Storage de Windows Store.
  • Roaming de settings.
  • Contrato de compartir.
  • Soporte de lectura/escritura en tarjetas SD.
  • Nuevas APIs de notificaciones y Action Center.
  • Integración de DirectX y XAML.
  • WebAuthenticationBroker.

Como podemos ver, muchas y variadas novedades. No obstante una de las novedades, en cuanto a desarrollo, que más resonará es la convergencia de la plataforma. Ya lo hemos mencionado en este artículo varias veces. Con Windows XAML tendremos a nuestra disposición nuevos proyectos que nos permitirán crear aplicaciones para Windows Store y Windows Phone. Lo veremos en el siguiente artículo.

Un saludo y Happy coding!