Probando los Nokia Lumia en remoto

Bien... hoy era uno de esos días en que pensaba en lo mucho que quiero actualizar mi Lumia a otro, y al entrar a curiosear dispositivos a la página de Nokia entre a la zona de desarrolladores y allí como tal parece que siempre lo omití vi la opción de Acceso remoto a dispositivos.

Para quienes no conocemos el mundo específico de los Nokia Developers esto si que puede ser nuevo y la verdad que una buena herramienta, decidí explorar un poco y venir a contarles.

Lo primero a tener en cuenta es que solo me funcionó bien con Firefox. Internet Explorer 11 no funciona y como pueden ver en la lista Chrome ni siquiera está nombrado.

Al entrar puedes ver como tienes varios equipos disponibles para reservar.

Esto me pareció genial, claramente no todos tenemos para cambiar tan pronto de móvil, así que son recursos disponibles para poder probar nuestras apps.

Al entrar encontramos un emulador que claramente que ofrece la velocidad de estar trabajando por red y varios tools adicionales-

Cuando tu sesión está por finalizar te muestran una alerta

Pero puedes salir y extender tu sesión o reservar de nuevo.

Nada cambiará la experiencia de tener un equipo propio y más un Lumia, y lo digo con conocimiento siempre tuve otras marcas y ahora tengo Lumia y lo considero mucho mejor. Pero lo importante de tener herramientas como estas es que no estamos limitados como devs ante la tan cambiante evolución de estos dispositivos.

En fin, la herramienta tiene un manual de usuario, así que si tienen problemas no duden en usarla.

¿Cansado de esperar a tu operador para probar los updates para devs Windows Phone?

Como publiqué antes en el blog, desde octubre de 2013 en el programa de desarrolladores de Windows Phone, tendremos la posibilidad de tener de forma temprana las actualizaciones de nuestros telefonos, siempre que tengamos una cuenta de desarrollador activa y tengamos el GDR2 (Amber) en nuestros dispositivos. Pero, ¿Qué pasa si estamos con un operador que tarda mucho en actualizar? 

Muchos buscan vías alternas, la verdad es que después de haber dañado un móvil alguna vez, estos métodos no me quedaron gustando en absoluto, pero buscando esta vez resulta que hay una vía un poco menos "insegura"

Como advertencia recuerden que cualquier cosa que hagan a su teléfono es bajo su responsabilidad, por eso les cuento mi historia ya que no me fue muy bien pero hoy por fin tengo el GDR3 en mi móvil Lumia 820 que estaba en manos de un operador de esos que no planea actualizar nunca. No olviden además que perderán todos sus datos así que saquen backup de sus archivos.

Bien, los pasos son sencillos, muchos hablaban del Nokia Software Updater Retail, hay muchas fuentes de donde bajarlo, yo encontré la Url directamente del sitio de Nokia en un foro y por eso me arriesgue a actualizar desde allí.

Actualización Feb/2014: Este software ha sido publicado ya para ser descargado de manera legal en el sitio de Nokia http://www.nokia.com/us-en/support/software-recovery/ 

Después de descargarlo y conectar nuestro dispositivo, el identifica la versión que tenemos y la versión a la que vamos a actualizar y al finalizar la descarga simplemente procede a la instalación. Así de simple sin trucos ni nada adicional. La parte positiva de esta actualización es que no se trata de flashear la ROM, incluso al iniciar el teléfono se ve como se conserva todo lo que el tu operador pone por defecto y así no se pierde la garantía de tu teléfono. De todos modos les recomiendo leer el resto de mi historia, por que no todo es color rosa.

Hoy afortunamente por cosas de la vida repetí este procedimiento que ya habia intentado antes y funcionó, pero no fue así antes. Hace un mes quise intentar actualizar, y si bien el proceso terminaba con éxito, la actualización nunca mostraba un cambio en el número de la versión, quise pensar que no era ningún problema y realizé el proceso de actualización completo sin efecto alguno, repetí varias veces el proceso y nada pasó así que deje de intentarlo.

Para mi sorpresa pase todo este tiempo con un móvil absolutamente inestable que se bloqueaba por todo y por eso hoy decidí intentarlo nuevamente a ver si por un golpe de suerte funcionaba bien y así fue. El punto es que pueden pasarte muchas cosas por intentar procedimientos alternos, la decisión y el riesgo siempre serán tuyos, pero este parece un modo tranquilo de actualizarse a Amber, después de eso pueden liberarse de sus operadores y actualizarse al GDR3 con el programa para desarrolladores.

Muchos éxitos con la aventura.

Consumiendo servicios Json en clases portables

Para empezar veamos, lo que queremos implementar este el servicio de consumo de nuestra Api Json, como venimos usando Librerias de Clases Portables en nuestro proyecto de Congreso Visible, empezaremos por instalar lo necesario. Abrimos el Package Manager Console

Y cuando se abra la consola ejecutamos el comando "install-package microsoft.net.http –pre". No olviden seleccionar correctamente el proyecto donde se instalará el paquete.

En ese momento estamos listos para empezar. Pues bien consumir un servicio Json a través del GET como los que tenemos en el API de Congreso Visible es bastante sencillo.

Como ven, en realidad el consumo de Json es muy fácil, instanciamos el HttpClient y a través de una petición asincrónica realizamos el consumo de los datos y por ultimo serializamos la respuesta y depositamos el contenido en una clase que contiene la estructura del Json que consumimos y que habiamos creado previamente.

Debemos recordar que los servicios tienen que tener la interfaz correcta, sin embargo quiero que observen algo en ella.

Esta interfaz es la misma que en post pasados implementamos a cada una de las interfaces de las Vistas Modelo. Si se preguntan por qué la respuesta es simple, no es correcto que la url del API este quemada en nuestro código por lo tanto tenemos que usar Settings Service para recuperar el dato de la configuración.

Y para completar la implementación, así como tenemos un BindableBase para las Vista Modelo, tendremos un ServiceBase en Infraestructura para soportar el GetService y poder recuperar del contexto nuestro servicio de Settings, así:

Recuerden que para que el llamado a los settings funcione, deben inicializar el servicio en el Locator, al que por cierto renombré.

Ahora bien, después de que nos llega el resultado a la Vista Modelo, necesitamos transformar el Modelo a una VistaModelo en el comando

De esta manera nuestro codigo queda más limpio. El ViewModelHelper lo ubiqué en el proyecto de Vistas Modelo y su implementación para el ejemplo es la siguiente:

Tengan en cuenta que lo que efectivamente hace el Binding es la ultima línea, debido que al asignar la variable Parties en el contexto se ejecutará el INotifyPropertyChanged, diciendo a la vista que hay datos disponibles.

Este ejemplo se finaliza el consumo de datos y ya pueden verlo en el código que se encuentra publicado, si se preguntan como se inicializa la carga en el inicio de la aplicación decidi hacerlo de la siguiente forma:

Esto permite que el inicio de la aplicación sea fluido y que la carga de datos solo inicie cuando la carga de la página haya finalizado y así se ven los partidos cargados :)

Controlando el estado de la red usando MVVM

Bueno, continuamos con nuestras labores de infraestructura, que bien podrían parecer muchas pero que a la vez nos dan la seguridad de construir sobre bases firmes. Recuerden que este post hace parte de la serie CongresoVisible.

El nuevo reto al que nos enfrentamos es un requerimiento típico de usuarios y clientes que piden aplicaciones, controlar que no se hagan solicitudes cuando el internet no esté disponible. Pues bien, si ya lo han intentado, se habrán dado cuenta que comprobar que el internet este habilitado antes de cada petición es bastante costoso, y bueno vamos a intentar una forma más elegante de hacerlo y además de incluirlo en nuestro proyecto.

Lo primero con lo que nos encontramos es que, el comprobar el estado de la red es particular a cada plataforma como lo fue la navegación que vimos en el post anterior. Así que, aunque tenemos la interfaz de nuestro servicio en el proyecto de contratos. El contrato hasta el momento se ve así:

Su proposito va a ser exponer una propiedad que nos diga el estado de la red y además exponer un método que nos comunique el estado de la red en el momento que esta cambie.

Bien, luego de eso y aprovechando que tenemos una interfaz compartirda en las view model que cumple con un proposito similar, agregamos una propiedad nueva, el NetworkMonitor, a través del cual accederemos al Internet Services a verificar el estado de la conexión desde cualquiera de las vistas modelo.

Cómo es de esperarse este NetworkMonitor será implementado por la clase que comparten todas nuestras view models, es decir BindableBase.

Ahora bien, como ya lo había mencionado, al tener que enfrentar este problema como algo puntual de cada plataforma, ubicaremos la implementación del servicio en nuestra carpeta local de infraestructura.

La implementación será la siguiente:

Esta es la clase que debemos implementar en cada plataforma. Si observan bien, lo que en realidad sucede es que al interior del servicio estamos suscritos a la clase de Windows Phone que nos comunica los cambios en el estado de la conexión. Cuando esto ocurre hacemos dos cosas, verificamos el estado de la red y cambiamos la variable de control, pero además si alguien está escuchando el evento que expuso nuestra interfaz entonces le comunicaremos que el estado de la red cambió.

Algo más que debemos tener en cuenta es que para que nuestras vistas modelo que necesiten conexión a internet tengan el NetworkMonitor disponible, debemos asígnarlo en el constructor del Locator quien ya sabemos al estar como recurso de la aplicación estará vivo desde el inicio.

Actualización: En post siguientes al intentar ensamblar la aplicación se identificó un faltante en este punto y es la inicialización la primera vez que se inicia el localor. La clase quedó así.

En la inicialización simplemente se llama el método que establece los valores de las variables.

Este lo hacemos a modo de ejemplo, puesto que como estamos haciendo TDD aprovecharemos este post para hacer los Test de conectividad de nuestra aplicación. Primero preparamos la Vista Modelo que vamos a probar con un método que solo va a usar el servicio de consumo de datos si la red está disponible. Algo sencillo como pueden ver:

El GetFilters del FakeJsonService recuerden no es más que un llamado al Callback

Luego de eso construimos los Test de conectividad

Si hacen debug a estos test notarán como en el primero de ellos, jamás se pasa por el Breakpoint, lo que es lógico, debido a que al no haber conexión a internet no se usa el servicio de consumo de datos que es lo que queriamos. Mientras que en el segundo test claramente el debug entrará al Callback por que la red está disponible.

No olviden, todo este código es un tanto confuso pero está disponible en mi Github para que lo vean con calma y por que no, me envíen sus sugerencias y correcciones.