Autor: Javier Suárez Ruiz

Introducción

En el marco del //BUILD en San Francisco, Microsoft ha presentado Windows Phone 8.1, la nueva versión de su sistema operativo para móviles.

El SDK de Windows Phone 8.1

El SDK de Windows Phone 8.1 usa como base Visual Studio 2013 incluyendo un conjunto bastante completo de herramientas:

• Visual Studio 2013 junto a nuevas plantillas de
  proyectos. Nuestro IDE con editores de codigo y visuales, caja de
  herramientas además de herramientas de análisis de rendimiento o
  testing. Hablaremos detalladamente de las nuevas plantillas (entre las
  que se incluyen las aplicaciones universales) en otro artículo con
  detalle.

• Blend. Actualizado con las nuevas plantillas de
  Windows Phone 8.1. Herramienta destinada a la creación de interfaces de
  usuario en XAML.
• Nuevos emuladores. Contamos con hasta 6 nuevos emuladores:
  • WVGA 4″ 512MB: Resolución más baja en Windows Phone 8 (480 x 800px) en 4 pulgadas. Cuenta con 512MB de RAM.
  • WVGA 4″ 1GB: Es igual al anterior pero con el doble de RAM.
  • WXGA 4″ 1GB: Resolución de 1280 x 768px en 4 pulgadas y con 1GB de RAM.
  • 720P 4.7″ 1GB: Resolución de 1280 x 720px con 4.7 pulgadas con 1GB de RAM.
  • 1080P 5.5″ 1GB: Resolución nueva y la más alta de todas (1080 x 1920px) en 5.5 pulgadas con 1GB de RAM.
  • 1080P 6″ 2GB: Resolución nueva y la más alta de todas (1080 x 1920px) en 5 pulgadas con hasta 2GB de RAM.

Como podemos ver, contamos con una gran variedad de emuladores con
diferentes resoluciones, tamaños de pantalla y memoria lo que nos
permite probar una gran cantidad de la funcionalidad de nuestras
aplicaciones. Además al emulador se le han añadido nuevas
funcionalidades como simuladores de notificaciones, Power Tools o la
posibilidad de guardar el estado exacto del mismo en diferentes
CheckPoints. Hablaremos detalladamente de las novedades del emulador en
un nuevo artículo.

NOTA: Los emuladores de Windows Phone 8.1 son máquina virtuales (Hyper-V) del sistema.

• Application Deployment Tool. Herramienta que nos
  permite desplegar un paquete de aplicación tanto en los distintos
  emuladores como en un dispositivo físico.

• Windows Phone Registration Tool. Herramienta que nos permite registrar un dispositivo para desarrollo y asi poder desplegar aplicaciones en el.

NOTA: Sin cuenta de desarrollador podemos debloquear un teléfono y desplegar hasta dos aplicaciones.

• Simulation Dashboard para Windows Phone. Gracias al
  emulador podemos probar una gran cantidad de situaciones sin necesidad
  de un dispositivo físico. Sin embargo, hay situaciones inesperadas
  dependientes de las limitaciones de los dispositivos, las redes donde se
  ejecuta la aplicación o la ubicación por ejemplo, que pueden provocar
  comportamientos inesperados en nuestra aplicación que debemos controlar.
  Gracias a esta herramienta podemos probar diferentes conexiones de red,
  el comportamiento de la aplicación ante el bloqueo de la pantalla o
  ante recordatorios.
• Windows Phone Developer Power Tools. Es un conjunto
  de herramientas que nos permiten capturar errores en nuestro código,
  métricas de rendimiento y recopilar archivos con logs de nuestra
  aplicación. Esta herramienta nos permite verificar la estabilidad y el
  rendimiento de la aplicación.
• Windows Phone Store Test Kit. Esta herramienta nos
  proporciona un conjunto de pruebas automáticas y manuales que nos
  ayudaran a evaluar nuestra aplicación ayudándonos a preparar la misma
  para la certificación en la Store de Windows Phone.

NOTA: En caso de no tener instalada ninguna versión de Visual Studio se instalará una versión Express de la versión 2013.

Los prerequisitos para poder utilizar al completo todas las herramientas (emuladores incluidos) son las siguientes:

• Windows 8.1 Pro
• Procesador con soporte par SLAT
• 4GB de RAM o más

Tenéis el SDK disponible en siguiente enlace.
Corred insensatos, a probar las novedades, si tenéis comentarios, dudas
o cualquier tipo de feedback seran bienvenidos en los comentarios.

Más información

• Windows Phone Dev Center: Windows Phone SDK
• Blog de Josué Yeray: [Windows Phone 8.1] Presentado en el /Build 2014 el SDK de Windows Phone 8.1

Introducción

Volvemos a la carga en WPSUG, grupo de usuarios hispanos de Windows Phone,
con un nuevo Hangout sobre desarrollo en Windows Phone. En esta
ocasión, trataremos un punto interesante de cara al desarrollo en
nuestras aplicaciones Windows Phone. En muchas de ellas, necesitamos
sincronizar datos entre distintas aplicaciones, necesitamos realizar
copias de seguridad, acceder a información alojada en algun
almacenamiento remoto, etc. Las opciones a utilizar son muchas y
variadas desde Windows Phone. En este Hangout vamos a analizar los
principales servicios de almacenamiento que podemos utilizar en nuestros
desarrollos:

• Dropbox
• Onedrive
• Box
• Azure Storage

El evento

El próximo Miérocles 26 de Marzo, a las 19:00 (GMT+1)  tendra lugar Hangout en el que nos reuniremos Josué Yeray, Rafael Serna, Santiago Porras, Quique Martínez, Roberto Luis Bisbé y un servidor para analizar múltiples servicios de almacenamiento que podemos utilizar en nuestras apps Windows Phone.

¿Te apuntas?

Más información

• Web del grupo: http://www.wpsug.net
• Suscríbete a la lista de correo electrónico: windows-phone-spanish-user-group+subscribe@googlegroups.com
• Visita nuestro canal de YouTube: http://www.youtube.com/channel/UClQGfxqCwc0XF9uo8e9KuPQ
• Síguenos en Twitter: https://twitter.com/wpsug
• Correo electrónico: info@wpsug.net

Introducción

El SDK de Windows Phone 8 es bastante versátil y nos proporciona una
fuente bastante extensa de controles como para realizar una interfaz de
usuario rica y atractiva en nuestras aplicaciones. Sin embargo, en
determinadas ocasiones podemos echar de menos más controles. Si ese es
tu caso, en la entrada actual vamos a analizar las posibilidades que nos
brinda MyToolkit, ¿te apuntas?

¿MyToolkit?

MyToolkit ess un paquete de controles y utilidades gratuito
disponible tanto en Codeplex como utilizando Nuget. Podremos obtener
tanto los archivos binarios como el código fuente. Además también hay
documentación e incluso proyectos de ejemplo (WinRT y Windows Phone)
haciendo uso de los controles.

Como obtenerlo

El Toolkit lo tenemos disponible en NuGet por lo que podemos instalarlo usando Nuget Package Manager.

En las referencias del proyecto hacemos clic derecho y seleccionamos la opción Manage NuGet Packages …

En la ventana modal que nos aparece, en la parte superior derecha donde podemos realizar una búsqueda, buscamos por “mytoolkit”:

Seleccionamos el primero de los elementos y pulsamos el botón Install.
Tras un breve periodo donde se procede a descargar e incluir las
librerías en las referencias del proyecto, tendremos el siguiente
resultado:

¿Qué aporta?

El Toolkit aporta un conjunto de controles, converters, helpers y extensiones.

Controles

• DataGrid (WinRT): Nos permite crear un Grid de solo lectura aunque con posibilidades interesantes como las opciones de navegación.

• DatePicker (WinRT) Permite la selección de fechas.

• ExtendedListBox (WP, WinRT): Control ListBox  con eventos interesantes como scrolling o detectar si se llega al final del scroll.

• ExtendedListPicker
  (WP), Nos permite usar ObservableCollection<T> en lugar de
  exclusivamente ObservableCollection<object> como lo haría el
  ListPicker.

• HtmlTextBlock
  (WP, WinRT): Nos permite mostrar contenido HTML sin los problemas
  encontrados en el control WebBrowser (gestión de color de fondo, etc).

• ImageButton (WinRT), Facilita la creación de botones con imagen. Cuenta con propiedad Content, ContentPressed y IsTiltEnabled.

• NavigationList (WP, WinRT): ListBox con eventos de navegación (incluye el elemento seleccionado como parámetro)

• PanAndZoomImage (WP) Facilita la manipulación de imágenes mediante gestos.

• PanAndZoomViewer (WP) Facilita la manipulación de contenido mediante gestos.

• Pivot
  (WinRT): Permite ofrecer la experiencia de un Pivot típico de Windows
  Phone en una aplicación Windows Store. Muy sencillo de utilizar:

• TextButton (WinRT), muestra un icono  (obtenido utilizando un caracter de la fuente Segoe UI) y una cabecera.

• WatermarkedTextBox (SL, WP, WinRT): TextBox con watermark (marca de agua).

• YouTubeButton
  (WP, WinRT): Botón que muestra una previsualización del video a
  reproducir junto al icono Play. Una vez pulsado el botón reproduce el
  video. Es uno de los controles mas usados que aporta el Toolkit:

Introducción

La interfaz de usuario de las aplicaciones
Windows Phone y Windows Store se basa en el uso del lenguaje Modern UI
donde el correcto uso de fuentes obtiene un gran peso permitiendo
otorgar un aspecto espaciado y ordenado facilitando el uso de la
aplicación.

Segun las guías de estilo de ambas plataformas existen
una serie de recomendaciones en cuanto al uso de fuentes que afectan al
tipo de fuente, tamaño y espacio donde la fuente Segoe
tiene un peso especial. Estas guías nos facilitan en muchas ocasiones
el conseguir un aspecto adecuado con un correcto uso de las fuentes. Sin
embargo, en ocasiones tenemos la necesidad de usar alguna fuente en
concreto por diversos motivos:

• La fuente en cuestión en base
  de la identidad corporativa de la aplicación que estamos desarrollando
  por lo que necesitamos usarla.
• La fuente es ya usada en otros entornos como por ejemplo en aplicaciones para otros sistemas.
• La fuente otorga un beneficio en la interfaz de usuario que queremos crear.

Sea por el motivo que sea, en ocasiones, nuestra aplicación tiene la necesidad de usar alguna fuente en concreto.

¿Cómo lo conseguimos?

Fuentes personalizadas

Tanto
en el desarrollo de aplicaciones Windows Phone como en aplicaciones
Windows Store tenemos acceso a una gran variedad de fuentes a las que
podemos acceder utilizando la propiedad FontFamily en elementos de texto. Por defecto tenemos acceso a una gran variedad de fuentes:

• Arial
• Arial Black
• Arial Unicode MS
• Calibri
• Cambria
• Cambria Math
• Comic Sans MS
• Candara
• Consolas
• Constantia
• Corbel
• Courier New
• Georgia
• Lucida Sans Unicode
• Segoe UI
• Symbol
• Tahoma
• Times New Roman
• Trebuchet MS
• Verdana
• Wingdings
• Wingdings 2
• Wingdings 3

Como
podemos ver la variedad es alta pero… ¿y si la fuente que necesitamos
utilizar no esta entre las fuentes disponibles?, ¿y si nuestra fuente
(TTF) no se encuentra en el sistema?

¿Cómo usar fuentes personalizadas?

El
trabajo con fuentes personalizadas en aplicaciones Windows Phone y
Windows Store es sumamente sencillo. Comenzamos con el archivo o
archivos de fuente en extesión .ttf. Para poder trabajar con las fuentes
debemos tenerlas disponibles en nuestro proyecto.

NOTA: En este ejemplo vamos a utilizar la fuente Cheddar Jack disponible en el siguiente enlace.

Añadir la fuente a la solución

Incluimos el archivo TTF en una carpeta llamada Fonts dentro de los Assets de nuestra aplicación:

Tras añadir la fuente, en sus propiedades, estableceremos la propiedad Build Action a Content y la propiedad Copy to Output Directory a Copy if newer:

Para poder utilizar la fuente necesitamos además de saber la ruta y
nombre del fichero, el nombre de la fuente (no es igual al nombre del
fichero).

Obtener el nombre de la fuente

Para obtener el nombre de la fuente bastará con realizar doble clic sobre el fichero TTF:

En nuestro caso el nombre de la fuente es Cheddar Jack.

Utilizando la fuente

Añadimos un TextBlock en el contenido del Grid principal de nuestra aplicación y le añadimos en la propiedad FontFamily:

¿Qué significado tiene el texto que hemos indicado?

NOTA: Podemos renombrar el archivo TTF a por
ejemplo CheddarJack.ttf y todo seguira funcionando correctamente. Sin
embargo, la última parte, el nombre de la fuente, debe reflejar
exactamente el nombre de la fuente incluidos espacios.

NOTA:
Hay fuentes con problemas de compatibilidad. En estos casos si la
fuente se llama Gothan Medium por ejemplo y tenemos problemas a la hora
de acceder a la misma debemos quedarnos solo con la primera palabra, es
decir, Gothan. Solo necesitamos realizar esta acción ante determinadas
fuentes con problemas de compatibilidad.

Podéis descargar el ejemplo a continuación:

Extra

Ya
hemos visto lo realmente sencillo que es trabajar con fuentes
personalizadas en aplicaciones Windows Phone y Windows Store pero hay
algunos detalles interesantes a comentar.

Acceso a la fuente en runtime

Podemos utilizar una fuente personalizada en runtime utilizando la propiedad FontFamily de un control de texto:

Trabajo organizado

Cuando toda nuestra aplicación accederá a
fuentes personalizadas no debemos colocar la propiedad FontFamily
continuamente con la ruta, nombre del fichero y nombre de la fuente.
Debemos hacer un uso adecuado de la potencia disponible en XAML
utilizando recursos y estilos.

Podemos crearnos un diccionario de
recursos llamado Fonts. Dentro del archivo de recursos podremos
organizar las fuentes de la siguiente forma:

Incluimos el diccionario de recursos entre los recursos de la aplicación:

Y desde cualquier control de texto bastara con:

Fácil y muy cómodo, ¿cierto?.

Más información

• Dev Center: Text and fonts for Windows Phone
  
• Dev Center: Quickstart: Text for Windows Phone
  
• Super Dev Resources: How to use custom fonts in Windows Phone and Windows Store apps

Introducción. La importancia de las métricas

Una vez publicada una aplicación en la Store recibir feedback sobre
la misma es sumamente útil. El Dev Center nos facilita información como
el número de descargas totales, descargas por países, fallos de la
aplicación, etc. Esta información es muly útil para saber en que
mercados esta teniendo más éxito nuestra aplicación y donde debemos
aplicar más esfuerzo con traducciones o que partes de la aplicación
fallan y debemos corregir. Pero… ¿es suficiente?. Como casi todo en la
vida, depende. A algunos les sobra con dicha información y para otros es
muy escasa. Sería interesante saber información como cuanto tiempo
estan los usuarios con nuestra aplicación, por que páginas navega, por
donde nunca pasa el usuario, desde que dispositivos accede, etc. Con
esta información podemos sacar muchas conclusiones como detectar
problemas de UX, añadir un mayor esfuerzo en zonas de la aplicación
donde el usuario pasa la mayor parte del tiempo, esforzarnos por
facilitar y promover el acceso a zonas apenas accedidas, corrección de
bugs, etc.

¿Cómo podemos obtener toda esa información?

Flurry Analytics

El agende de Flurry Analytics para Windows Phone permite de manera
gratuita conseguir analíticas de uso y comportamiento de nuestras
aplicaciones.

Para comenzar a utilizar Flurry Analytics comenzaremos realizando el registro en: flurry.com.

Tras registrarnos y validar nuestras credenciales creamos una
aplicación para obtener un application key válido que nos permita
integrar Flurry en nuestra aplicación.

Elegimos de que tipo de aplicación deseamos obtenemos analíticas:

Tras elegir plataforma, rellenamos la información básica de la aplicación, nombre y categoría:

Por último, tendremos nuestra aplicación creada y todo listo para
comenzar a integrar Flurry en nuestra aplicación Windows Phone:

Descargamos el archivo comprimido con todo lo necesario:

• Documentación
• La librería a utilizar en nuestra aplicación Windows Phone
• El Application Key

Flurry SDK

Descomprimimos el contenido del archivo comprimido:

Integración en nuestra App

Vamos a realizar un ejemplo práctico donde integrar Flurry Analytics. Creamos un nuevo proyecto.

Añadimos la referencia a la librería FlurryWP8SDK.dll que teníamos disponible en el archivo descomprimido previamente.

En el archivo de manifiesto, WMAppManifiest.xml, para que todo funcione correctamente añadimos las siguientes capacidades:

• ID_CAP_NETWORKING
• ID_CAP_IDENTITY_DEVICE

NOTA: En todo proyecto Windows Phone la primera
de las capabilities viene macada por defecto. Sin embargo, la segunda
capability debemos marcarla para que las analíticas de Flurry funcionen
correctamente.

En el evento Application_Launching añadimos:

Y en el evento Application_Activated:

Y listo!

¿Ya?, ¿de verdad?. Pues si, con tan solo los pasos anteriores
conseguimos una gran cantidad de información relacionada con nuestra
aplicación. Información como:

• Dispositivos usados
• Número de usuarios
• Idiomas usados
• Versiones
• Zonas geográficas
• Frecuencia de uso
• Tiempo que cada usuario permanece en la aplicación
• Etc

Tracking Avanzado

Una parte importante a tener en cuenta cuando publicamos una
aplicación en la Store, es su correcto funcionamiento bajo cualquier
entorno y circunstancia. Por lo tanto, tener constancia de cuantos
errores tenemos en nuestra aplicación y de que tipo nos da una gran
ventaja a la hora de resolver los errores y garantizar la calidad
exigida e nuestra aplicación.

¿Cómo podemos sacar beneficio de las analíticas de nuestra aplicación para ello?

Con las analíticas de errores. Podemos registrar las excepciones de nuestra aplicación utilizando el método LogError:

NOTA: Flurry capturara los 10 últimos errores registrados por sesión con un máximo de 256 carácteres  en el mensaje por error.

De esta forma podemos controlar excepciones de una manera muy
sencilla. Ante casos no esperados, la aplicación se cerrará entrando en
última instancia en el método Application_UnhandledException de App.xaml.cs.

Por lo tanto, podemos capturar toda expceción no controlada facilmente:

Otro factor de interés del que tener analíticas más exactas es de los eventos que suceden en nuestra aplicación. Usaremos el método LogEvent
para añadir analíticas de eventos pudiendo registrar no solo un evento
sino los parámetros que recibe. Gracias a este tipo de analíticas
podemos saber por ejemplo que secuencias de acciones suele realizar la
mayoría de usuarios o cuales apenas se realizan por ejemplo.

FlurryWP8SDK.Api.LogEvent(string eventId, bool timed, List<Parameter> parameters)

NOTA: Tenemos una limitación de 10 parámetros por
evento. Además nuestra aplicación no puede superar los 300 eventos
registrados. Aun asi, en la mayoría de ocasiones, son valores muy altos
que nos permiten tener unas trazas muy exactas de lo que sucede en
nuestra aplicación.

Otras analíticas

Dentro del SDK de Flurry Analytics tenemos otros métodos que nos permiten registrar analíticas de más tipos como por ejemplo:

• Registrar vistas utilizando el método LogPageView:

FlurryWP8SDK.Api.LogPageView()

• Edad de los usuarios utilizando el método SetAge:

FlurryWP8SDK.Api.SetAge(int age)

• Género de los usuarios utilizando el método SetGender:

FlurryWP8SDK.Api.SetGender(Gender gender)

• Localización exacta del usuario con información del GPS utilizando el método SetLocation:

FlurryWP8SDK.Api.SetLocation(double latitude, double longitude, float accuracy)

• Etc.

Además tenemos la posibilidad de controlar cuando se registra la información desde que sucede.

Podéis descargar un ejemplo utilizando Flurry Analytics a continuación:

NOTA: Debéis introducir vuestro Flurry API Key propio para poder probar el ejemplo.

Como hemos podido ver, añadir Flurry Analytics es un proceso rápido y
sencillo que nos aporta una gran cantidad de analíticas sobre el uso de
nuestra aplicación que podemos debemos utilizar para gestionar las actualizaciones de nuestra aplicación acorde a las necesidades y usos de la misma.

Más información

• Flurry: Página oficial
• Flurry Documentation: Getting Started, Windows Phone

Introducción

Al desarrollar aplicaciones tarde o temprano
tendremos la necesidad de actualizarlas ya sea bien por necesidad, para
corregir bugs, o bien para añadir nueva funcionalidad. En ambos casos,
nuestro mayor interés es que la mayor cantidad de usuariosse actualice a
la última versión. Sin embargo, esto no siempre sucede.

¿Por que?

Podemos arrojar varias posibles causas:

• El usuario utiliza el móvil con internet de manera muy puntual.
• No tiene la Store anclada al inicio y no se da cuenta de las actualizaciones.
• No se preocupa de revisar las actualizaciones.
• Directamente el usuario desconoce como realizar la acción.

Sin
abrir la aplicación de la Store y sin tenerla anclada al inicio puede
provocar que los usuarios tengan aplicaciones sin actualizar a la última
versión, no disfrutando de mejoras y lo que es peor sufriendo bugs que
incluso pueden estar resueltos en versiones posteriores.

Para
mejorar esta situación podemos indicarle al usuario de la disponibilidad
de una actualización disponible. Pero… ¿cómo detectamos desde nuestra
aplicación de la existencia de una actualización?

Cimbalino al rescate

Cimbalino
Windows Phone Toolkit es un completo conjunto de herramientas
destinadas a ahorrarnos tiempo y esfuerzo al desarrollar aplicaciones
para Windows Phone del que ya hablamos previamente. Entre el conjunto de
posibilidades que nos brinda, nos ofrece un servicio llamado IMarketplaceInformationService que
nos permite verificar la existencia de actualizaciones de la aplicación
dentro de la misma. Vamos a crear una Aplicación de ejemplo para
utilizar el Toolkit y poder verificar la existencia de actualizaciones.

Tras crear el proyecto, comenzamos añadiendo el Toolkit. Tenemos
disponible Cimbalino en NuGet por lo que podemos instalarlo usando Nuget Package Manager.

En las referencias del proyecto hacemos clic derecho y seleccionamos la opción Manage NuGet Packages …

En la ventana modal que nos aparece, en la parte superior derecha donde podemos realizar una búsqueda, buscamos por “cimbalino”:

Seleccionamos el primero de los elementos y pulsamos el botón Install.
Tras un breve periodo donde se procede a descargar e incluir las
librerías en las referencias del proyecto, tendremos el siguiente
resultado:

Ya con la librería instalada podemos continuar con nuestro objetivo.
Comenzamos definiendo la interfaz del ejemplo. En nuestro caso
colocaremos un botón en la interfaz para verificar la existencia de
actualizaciones. Sin embargo, la verificamos se puede realizar
perfectamente en el arranque de la aplicación.

Le añadimos un comando a ejecutar al ser pulsado:

En el ViewModel correspondiente a la interfaz contaremos con el comando:

Para utilizar el servicio IMarketplaceInformationService
en la acción de nuestro comando necesitamos inyectar el servicio. Los
servicios asi como la propia ViewModel no se creará manualmente sino que
se resolverá automáticamente en tiempo de ejecución por el contenedor
de dependencia. En el contenedor utilizaremos Unity (proyecto Open
Source de Microsoft) para soportar la inyección de dependencias:

En el punto de entrada de la ViewModel (el contructor) inyectaremos los
servicios necesarios previamente registrados en el contenedor:

Con el servicio disponible, verificaremos la versión de la aplicación (por reflection):

Y la compararemos con la versión disponible en la Store:

Para obtener la versión de la Store utilizaremos el método GetAppInformation del cual también tenemos versión asíncrona del servicio MarketPlaceInformationService.

En el resultado obtenido por la petición podemos obtener una enorme
cantidad de la información relacionada con la apliación publicada en la
Store:

• Título
• Versión
• Publicador
• Icono
• Fotos
• Fecha de publicación
• Puntuaciones

Por lo que el servicio puede ser utilizado para una enorme variedad
de situaciones con información relevante del estado de la apliación en
la Store.

Comparamos versiones, si la actual es superior a la de la Store,
tenemos actualización disponible. Utilizamos el servicio
MessageBoxService de Cimbalino para notificar al usuario:

Por último, si el usuario desea abriremos la Store directamente con la
apliación para que solo tenga que pulsar un botón para actualizar. Para
ello usaremos otro servicio de Cimbalino, MarketPlaceReviewService:

_marketplaceDetailService.Show(ProductId);

NOTA: Dado que la aplicación de ejemplo no esta
en la Store, para este ejemplo hemos utilizado una aplicación ya
publicada en la Store en concreto Dev Center que va por su
versión 1.4.1312.4.

Fácil, ¿verdad?. Tenemos disponible el ejemplo realizado a continuación:

Más información

• Blog de Pedro Lamas: Checking for updates from inside a Windows Phone app
• GitHub: Cimbalino
• Twitter: @CimbalinoWP
• Pedro Lamas Blog (Autor del Toolkit)
• Channel 9: Speed your Phone App Dev with the Cimbalino Windows Phone Toolkit
• Blog de Josué Yeray: [Windows Phone 8] Cimbalino Toolkit: Trabajando con XAML , [Windows Phone 8] Cimbalino Toolkit: ApplicationBar y Servicios

Introducción

Por encima de cuidar detalles como la
funcionalidad o la estética de nuestra aplicación, tenemos que lograr un
objetivo que parece simple pero que a veces se escapa, nuestra
aplicación debe funcionar correctamente bajo todas las condiciones en
todos los dispositivos para la que sea lanzada. Un fallo comun suele ser
que se escape la gestión de memoria de la aplicación pudiendo obtener una excepción de tipo OutOfMemoryException. Ya vimos como el control MemoryCounter del Coding4Fun Toolkit nos ayuda a saber el uso de memoria en todo momento. También tenemos disponible la herramienta Windows Phone Performance Analysis
para poder analizar el uso de memoria de nuestra aplicación entre otras
opciones. Sin embargo, el propio SDK nos incluye la posibilidad de
saber el uso de memoria de nuestra aplicación e incluso el límite máximo
de uso de memoria o la memoria disponible del dispositivo. Vamos a
aprender como realizar esta tarea en este artículo.

Monitorear la memoria

Tenemos disponible en el SDK de Windows Phone la API DeviceStatus
que nos permite obtener información del hardware del dispositivo como
la cantidad de memoria o la versión del sistema por ejemplo. Además,
tenemos disponible una serie de eventos a los que podemos suscribirnos
para recibir una notificación cuando un parámetro del sistema cambia.

Vamos a realizar un ejemplo práctico donde utilizar la API DeviceStatus. Creamos un nuevo proyecto:

La plantilla seleccionada será “Windows Phone Application”
para simplificar al máximo el ejemplo. Comenzamos creando la base de
nuestra interfaz. Añadiremos dos botones, uno para aumentar el consumo
de memoria y otro para liberarla:

<Button Content="Aumenta consumo memoria"/>
<Button Content="Libera consumo memoria"/>

Añadimos sus eventos clic:

<Button Content="Aumenta consumo memoria" Click="AumentaMemoria_Click" />
<Button Content="Libera consumo memoria" Click="LiberaMemoria_Click"/>

Y en el code-behind:

private void AumentaMemoria_Click(object sender, RoutedEventArgs e)
{

}

private void LiberaMemoria_Click(object sender, RoutedEventArgs e)
{

}

Creamos una colección de Bytes para cargar en memoria:

List<Byte[]> _memoria;

En el primer botón añadimos 10MB al uso de memoria cada vez que sea
pulsado. En el segundo, limpiamos la colección y llamamos el recolector
de basura:

private void AumentaMemoria_Click(object sender, RoutedEventArgs e)
{
     _memoria.Add(new Byte[1024 * 1024 * 10]);
}

private void LiberaMemoria_Click(object sender, RoutedEventArgs e)
{
     _memoria.Clear();
     GC.Collect();
}

Hasta aqui todo lo necesario para poder probar la memoria, podemos
aumentarla y liberarla. Sin embargo, no tenemos ahora mismo posibilidad
de saber que consumo esta realizando la aplicación. Vamos a añadir en
nuestra interfaz un TextBlock donde mostrar la información relacionada
con el uso de memoria:

Vamos a crear un método que actualice el texto del TextBlock anterior
con la información relacionada con la memoria. Dentro del método
usaremos la API DeviceStatus para acceder a ciertas propiedades
relacionadas con la memoria. Las propiedades son:

• ApplicationCurrentMemoryUsage: Propiedad de tipo long que nos devolverá en bytes el uso de memoria de la aplicación.
• ApplicationPeakMemoryUsage: Propiedad de tipo long que nos devolverá en bytes el uso máximo que ha llegado a utilizar la aplicación.
• ApplicationMemoryUsageLimit:  Devuelve la cantidad máxima de memoria que puede utilizar la aplicación.
• DeviceTotalMemory: Memoria disponible en el dispositivo.

private void ActualizarDatos()
{
     Data.Text = String.Format(@"
     Actual: {0}MB
     Pico máximo: {1}MB
     Límite de uso: {2}MB
     Total dispositivo: {3}MB",
     (DeviceStatus.ApplicationCurrentMemoryUsage / 1000000).ToString(CultureInfo.InvariantCulture),
     (DeviceStatus.ApplicationPeakMemoryUsage / 1000000).ToString(CultureInfo.InvariantCulture),
     (DeviceStatus.ApplicationMemoryUsageLimit / 1000000).ToString(CultureInfo.InvariantCulture),
     (DeviceStatus.DeviceTotalMemory / 1000000).ToString(CultureInfo.InvariantCulture));
}

Para finalizar llamaremos al método en los clic de los botones para
actualizar los valores en pantalla cada vez que pulsemos uno de ellos:

ActualizarDatos();

Sin duda una forma sencilla para poder consultar el uso de memoria. Sin
embargo, no es práctico en nuestras aplicaciones mostrar la información
en pantalla. Para solventar esa situación, podemos realizar un sencillo
Helper, llamado MemoryHelper, que contenga un método
que obtendrá la misma información cada X segundos y las mostrará en la
ventana de Output de Visual Studio:

public static void GetMemoryData(int seconds)
{
     _timer = new Timer(state =>
     {
          string result = string.Empty;
          result += String.Format(@"
          Fecha: {0}
          Actual: {1}MB
          Pico máximo: {2}MB
          Límite de uso: {3}MB
          Total dispositivo: {4}MB",
          DateTime.Now.ToLongTimeString(),
          (DeviceStatus.ApplicationCurrentMemoryUsage / 1000000).ToString(CultureInfo.InvariantCulture),
          (DeviceStatus.ApplicationPeakMemoryUsage / 1000000).ToString(CultureInfo.InvariantCulture),
          (DeviceStatus.ApplicationMemoryUsageLimit / 1000000).ToString(CultureInfo.InvariantCulture),
          (DeviceStatus.DeviceTotalMemory / 1000000).ToString(CultureInfo.InvariantCulture));

     Deployment.Current.Dispatcher.BeginInvoke(() => Debug.WriteLine(result));
     },
     null,
     TimeSpan.FromSeconds(seconds),
     TimeSpan.FromSeconds(seconds));
}

Podéis descargar el ejemplo a continuación:

Más información

• Dev Center: Device status for Windows Phone
  
• Dev Center: Developing apps for lower-memory phones

Uso de memoria en Windows Phone 8

Con la maduración del
mercado con respecto a Windows Phone, contamos con una variedad de
dispositivos con distintas características. Una de las características
que de forma comun varía entre diferentes dispositivos es la memoria
RAM. Contamos con dispositivos con 512MB, 1GB o 2GB de RAM. Para llegar a
la mayor cantidad de usuarios posibles tenemos que adaptar nuestra
aplicación para que funcione correctamente bajo cualquier circunstancia.

Límites de memoria

Los límites de uso de memoria son los siguientes:

El límite de memoria viene marcado por la memoria total del
dispositivo. Contamos con tres categorías, teléfonos con memoria baja
con 512MB como por ejemplo el Nokia Lumia 520, teléfonos con 1GB como
por ejemplo el Nokia Lumia 925 y teléfonos con 2GB como el Nokia Lumia
1520.

En aplicaciones utilizando XAML los límites son 150MB en dispositivos de baja memoria, 300MB en dispositivos de 1GB y 2GB.

Sin
embargo, si nuestra aplicación lo requiere podría llegar a aumentar el
límite de consumo de memoria en 30MB en dispositivos de baja memoria,
80MB en dispositivos de 1GB y en 270MB en dispositivos de 2GB (por ahora
el Nokia Lumia 1520, pensando en el uso de recursos de alta definición
con pantallas de gran tamaño).

Aumentar la cantidad disponible

Por lo tanto, si nuestra aplicación requiere un mayor consumo de memoria podemos aumentar los límites. Bien, pero… ¿como?

Lo
podemos hacer con facilidad modificando el archivo de manifiesto.
Podemos definir una Capability que indique que nuestra aplicación
requiere un mayor consumo de memoria.

Bastará con añadir:

<App>
     <FunctionalCapabilities>
          <FunctionalCapability Name="ID_FUNCCAP_EXTEND_MEM"/>
     </FunctionalCapabilities>
</App>

La entrada anterior permite establecer los límites en 180MB en
dispositivos de baja memoria, 380MB en dispositivos de 1GB y 570MB en
dispositivos de 2G.

Si por la naturaleza de nuestra aplicación es
inviable su funcionamiento en dispositivos de baja memoria, podemos
añadir otra Capability en el archivo de manifiesto para evitar que se
pueda instalar en estos dispositivos (no aparecería en la Store la
aplicación bajo un dispositivo de estas características). Debemos
añadir:

<App>
     <Requirements>
          <Requirements Name="ID_REQ_MEMORY_300"/>
     </Requirements>
</App>

Más información

Dev Center: App memory limits for Windows Phone 8

Introducción

Al publicar aplicaciones en la Store podemos
hacerlo hasta en 191 países diferentes. Esto nos ofrece unas
posibilidades increíbles a la hora de llegar a un público variado y
tener un gran alcance. Sin embargo, el publicar la aplicación en
múltiples países requiere tener en cuenta ciertos aspectos. Aspectos
como si la aplicación tiene sentido o no en un pais concreto, además de
tener en cuenta aspectos que debemos adaptar en nuestra aplicación.
Probablemente aunque tu aplicación sea una gran aplicación, destacada en
la Store, si la lanzas en español en China no tendra un gran impacto.

En
la medida de lo posible, debemos localizar la aplicación a los idiomas
donde la aplicación vaya a ser lanzada. En el artículo actual vamos a
aprender a utilizar un toolkit que nos facilitará la vida a la hora de
localizar nuestras aplicaciones, Multilingual App Toolkit.

Multilingual App Toolkit

El toolkit se instala como un plugin en Visual Studio. Podemos descargar el plugin desde el siguiente enlace.

Una
vez accedido al enlace podemos descargar el toolkit en múltiples
idiomas, seleccionamos el deseado y descargamos. Tras descargar pasamos a
instalar el Toolkit. La instalación es bastante simple.

Manos a la obra!

Vamos a crear una Aplicación de ejemplo donde utilizar y aprender las posibilidades del Multilingual App Toolkit:

Creamos un proyecto desde la plantilla más básica para concentrar
nuestra atención en el componente que nos ocupa en esta entrada.

Vamos a realizar una aplicación muy simple, con un único botón que al ser pulsado muestra un saludo.

Los textos de nuestra aplicación deben estar en una archivo de
recursos para poder utilizar el Toolkit. En todo proyecto Windows Phone
se crea por defecto un archivo de recursos que será el utilizado.

Añadimos recursos a mostrar en el contenido del botón y en el mensaje que mostramos.

Añadimos el botón en nuestra interfaz:

Y en el code-behind:

Trabajando con el Toolkit

Para comenzar a utilizar el Multilingual App Toolkit lo primero que
debemos hacer es habilitarlo. Desde Visual Studio, seleccionamos la
opción del menu Tools, y hacemos clic sobre Enable Multilingual App Toolkit.

Tras habilitar el Toolkit lo que nos interesa es realizar el objetivo
por el cual lo utilizamos, añadir soporte a más idiomas en nuestra
aplicación. Para ello, hacemos clic derecha sobre el proyecto bajo el
Explorador de soluciones y seleccionamos la opción Add translation languages…

Al seleccionar la opción nos aparecerá un ventana modal como la siguiente:

Podremos marcar los idiomas que queramos utilizar en nuestra
aplicación. Por cada idioma seleccionado se creará un fichero llamado AppResources.[cultura].xf en la carpeta Resources. Se creará un fichero XLIFF que puede ser exportado e importado en nuestor proyecto.

NOTA: Los ficheros .xlf son convertidos al formato .resx durante el proceso de compilación.

Una vez creado el fichero .xlf contamos el Multilingual Editor Tool. Es un editor sencillo que nos permite acceder a cada valor del recurso utilizado para traducirlo.

Cada valor traducible lleva asociado un icono que nos indica su
estado. Podemos marcar cada texto como traducido, pendiente de revisión,
etc. Estos estados son muy útiles cuando la traducción se realiza por
múltiples personas.

Si dominamos el idioma al que se realiza la traducción podemos
realizarla nosotros mismos. Tan solo basta con seleccionar el valor a
traducir y en el campo “Conversión” escribir el valor traducido.

Sin embargo, en la mayoría de ocasiones no dominaremos todos los idiomas en los que deseamos publicar la aplicación.

¿Qué hacemos en estos casos?

Tenemos varias opciones. Por un lado podemos utilizar el servicio de
Microsoft Translator. En la herramienta Multilungual Editor Tool podemos
pulsar el botón “Traducir” con la opción “Traducir todo” y se realizará
una traducción automática. También podemos hacer clic derecho
directamente sobre el fichero .xlf y seleccionar la opción Generate machine translations:

Una opción válida pero no ideal. Una traducción literal a veces pierde sentido o no significa lo mismo en distintos idiomas.

¿Qué hacer?

Que lo traduzca una persona en lugar de un proceso automática.
Podemos exportar el fichero, enviarlo a un traductor, recibir el fichero
traducido e importarlo en nuestro proyecto. Lo que haremos será
compartir un fichero en formato XLIFF soportado por multitud de
herramientas.

Una vez que recibimos el fichero traducimos podremos utilizarlo con facilidad, solo bastará importarlo.

Ya solo quedaría probar la traducción. Para ello bastará con modificar
el lenguaje utilizado en un dispositivo o en el emulador. Tenemos
información al respecto aqui.

Podéis descargar el ejemplo a continuación:

Más información

• Channel 9: Introduction to the Multilingual App Toolkit
  
• Channel 9: Localize Multi-Language apps using the Multilingual App Toolkit
  
• Blog Josué Yeray: [Windows Phone 8] Multilingual App Toolkit

Introducción

A finales del año pasado nacio WPSUG, grupo de usuarios hispanos de Windows Phone
con el objetivo de ayudar en lo posible a la comunidad de
desarrolladores Windows Phone con entre otras acciones, webcasts
periódicos en castellano y con contenido pedido los propios usuarios
utilizando Google Hangouts.

Un parte importante en una gran cantidad de aplicaciones móviles se basa en el uso de música
o de información relacionada con la misma. Aplicaciones con letras,
información de artistas o conciertos entre una multitud inmensa de
posibilidades.

¿Cómo podemos obtener información relacionada con un álbum o un
artista en concreto?,  ¿puedo tener la información exacta de una canción
en concreto?, ¿que posibilidades tengo?. Si te resulta interesante el
siguiente Hangout de WPSUG te resultara muy útil.

El evento

El próximo Jueves 30 de Enero, a las 19:00 (GMT+1)  tendra lugar el segundo Hangout del gupo en el que nos reuniremos Josué Yeray, Rafael Serna, Santiago Porras y un servidor para tratar todas las posibilidades de integración de las nuevas APIs de música, Nokia Music y Xbox Music en nuestras apps Windows Phone.

¿Te apuntas?

Más información

• Web del grupo: http://www.wpsug.net
• Suscríbete a la lista de correo electrónico: windows-phone-spanish-user-group+subscribe@googlegroups.com
• Visita nuestro canal de YouTube: http://www.youtube.com/channel/UClQGfxqCwc0XF9uo8e9KuPQ
• Síguenos en Twitter: https://twitter.com/wpsug
• Correo electrónico: info@wpsug.net