Posts Tagged ‘windows phone 8’


Windows 10 ha sido lanzado y con esto Microsoft promete un nuevo tipo de aplicaciones: “Universal” que asegura su ejecución en todas las plataformas Windows disponibles, desde teléfonos con Windows 10 Mobile, y Pcs. Lo que no nos está diciendo es que se ha redefinido el concepto de PC.

Las PC eran la primera opción para el trabajo tanto para casa como para oficina, con el tradicional monitor y teclado por un lado y el “CPU” por otro. Si nos hacía falta movilidad, no había problema de cambiar a una laptop. Sin embargo, surgieron los smartphones y las tablets y nos dimos cuenta que iban creciendo en potencia y capacidades al punto que muchas personas pueden quedarse con una tablet como computador principal.

Ahora bien, desde el punto de vista funcional, tener una tablet en lugar de una laptop no es nada del otro mundo. Todo está en función de las necesidades de cada usuario.

Para los desarrolladores el problema es desde donde comenzar.

Si vamos por el ala Apple, comenzamos haciendo programas para iPhone/iPod y luego las hacíamos escalar para soportar tablets iPad, cambiando principalmente las pantallas y las resoluciones soportadas. Si queríamos que nuestra app funcione también en Macs ya teníamos que cambiar el código e incluso las gráficas pues el modelo de programación para Mac OSX es diferente al que tiene iOS.

Para el caso de Microsoft, la separación también era clara, si querías móviles te ibas por un rumbo y si querías PC hacías el desarrollo de siempre. El problema es que siempre que hablamos que Windows Phone, o Windows 10 Mobile hasta ahora siempre hemos hablado de teléfonos que nunca llegaron a ser tablets. Cierto que salió Windows RT donde salieron unas tablets pero esa iniciativa nunca tuvo tanto peso comercial. Lo que si parece que viene con fuerza son las tablets pero con Windows 8.1/Windows 10, es decir, el mismo sistema operativo que tenemos en la PC o en la laptop a un precio incluso menor a las tablets disponibles con sistemas operativos móviles consolidados como iOS o Android.

Con el lanzamiento de Windows 10 se viene otra ola que es la “Aplicación Universal” donde se promete que una misma aplicación podrá ser ejecutada tanto en Windows 10 como en Windows 10 mobile. Hasta el momento no se incluía el soporte para teléfonos con Windows Phone 8/8.1 lo que significa que aún no podrá ser tan universal, pero la presencia en el mercado estas tablets con Windows 8/10 abren la posibilidad de una nueva generación de aplicaciones “super inteligentes” ya que no estamos hablando de apps reducidas para entrar en un equipo móvil, sino la misma app que usamos al sentarnos en la oficina. Si podemos tener la misma app empresarial movilizada con una tablet que cuesta 100 usd ¿Para qué molestarnos en hacer una aplicación en un sistema operativo móvil?

En la última versión de Visual Studio (2015), se incluye también el soporte de Apache Cordova, lo que “oficializa” el soporte de Microsoft de tecnologías abiertas para el desarrollo de aplicaciones multiplataforma. Con Cordova, es posible que nuestra app pueda ejecutarse en iOS, Android, Windows y en otros sistemas operativos móviles en forma limitada. Si bien el funcionamiento tiene aún algunos problemitas, la posibilidad de hacer un sólo código justifica la atención.

De hecho, ya en un post anterior, les he descrito mi aplicación Supercomics basada en Cordova que se ejecuta tanto en Windows Phone, iOS y Android. Aún estoy salvando unos problemitas para publicar la versión para Windows, y para ser específico debo decir que en Windows soporto Windows Phone 8 y 8.1, Windows Phone 10, Windows 8/8.1 y Windows 10. Notarán que puedo ir más allá de lo que ofrece una “Aplicación Universal”.

Por supuesto que una “Universal App” puede darnos opción a integrar APIS empresariales  y más funciones en la parte de desarrollo que aún estoy descubriendo. Hasta el momento he visto que las aplicaciones mientras más desconectadas estén, mejor experiencia de uso brindan, así que empezaremos a comparar las ventajas para sugerir la mejor plataforma para nuestras aplicaciones.

Veamos el siguiente cuadro:movilesCon esto vemos un poco más claramente que significa “Aplicación Universal”.

No es mala idea el Universal App, de hecho, es una gran cosa para el mundo empresarial donde las políticas internas normalmente, favorecen el uso de una misma plataforma para sus aplicaciones internas donde ya Microsoft reina. El tema está en el punto débil de Windows en este momento: la falta de aplicaciones móviles, y la inclusión de Apache Cordova significa que Microsoft ha aceptado que ir por la alternativa de HTML5 es lo más eficiente en este momento.

Como siempre, la pregunta que se hace un desarrollador es sobre la velocidad y las funciones que soportará cada opción pues es obvio que una herramienta “nativa” nos ofrecerá un código más rápido y nos permitirá acceso a los recursos de hardware en el terminal. Siempre al inicio de todo desarrollo se tiene que hacer una evaluación de los requerimientos para nuestra aplicación. Si vamos a desarrollar un juego con alto nivel de procesamiento, la opción nativa se impone, pero si queremos una app tipo red social o capturadora de datos con soporte a múltiples dispositivos entonces podremos “sacrificar” la velocidad por la facilidad de desarrollo pues tenemos que considerar que hay otros aspectos como la velocidad de la red o la cantidad de datos, o la integración a otros sistemas que impactan mas fuertemente en el rendimiento de nuestra aplicación.

Ninguna alternativa es completamente a prueba de balas, todo depende de lo que necesitemos. Es una gran opción usar la misma aplicación en todos nuestros dispositivos, pero la movilidad no está en el dispositivo, está en la forma en la que diseñemos la aplicación. Es necesario que se incluyan paradigmas como sincronización, bases de datos locales, autenticación, encriptación en la que se dejemos de lado de una vez por todas el supuesto que todos los recursos estan disponibles todo el tiempo.


Este post lo hago de urgencia pues acabo de experimentar todo lo que no se debe hacer en el tema de sincronización. Para esto les doy un resumen de mi entorno de desarrollo:

  • Servidor: Instancia en Cloudant.com
  • Cliente: PouchDB como base de datos con sincronización al iniciar el app
  • Framework: Ionic

En resumen, se inicia una sincronización entre mi base de datos local en PouchDB y la base remota en Cloudant. Y puede ser todo lindo en Producción, pero como estamos en Desarrollo, el proceso normal es parar e iniciar el app a cada rato. Ahora veamos las consecuencias en desarrollo:

  • Costo: Cloudant te cobra por transacciones y te dice que por transacciones “pesadas” te va a cobrar mas, y pone varias transacciones HTTP y las define como pesadas. Lo que no dice es que hay otras transacciones que se utilizan para la sincronización que también se califican como pesadas, principalmente OPTIONS que se manda a cada rato. Por lo tanto, cada sincronización es bastante intensiva en costo.
  • Tráfico: Para un modelo de desarrollo, no es bueno iniciar conexiones de datos muy seguido. Entonces, el modelo debe saber cuando es bueno iniciar la sincronización sin importar que sea en Desarrollo o Producción.
  • Batería: Como consecuencia de la reducción de tráfico, estaremos también bajando el consumo de energía en el móvil.

No malentiendan, CouchDB/PouchDB es muy bueno, y si existe la necesidad, podemos activar la sincronización “live”, pero como no todos tenemos servidores y ancho de banda de sobra, tenemos que pensar en servicios en demanda en la red, como Cloudant en mi caso. Tengan en cuenta que otros servicios como IrisCouch, también cobran por transacciones.

La salida que encontré depende de como se necesita que fluyan los datos:

  • El recolector de datos: si nuestra app necesita solamente capturar datos y no necesito bajar información desde el servidor. En este caso, lo mejor es implementar un contador que incrementaremos cada vez que se actualice o se inserte un dato nuevo. Lo bueno es que para un entorno NoSQL, insertar o actualizar es el mismo método, así que en ese método podremos insertar el incremento del contador. Luego, al momento antes de sincronizar, verificaremos si es que el contador es mayor a 0, de lo contrario no iniciaremos la sincronización. Sincronizar solamente cuando hayan datos locales.
  • El visualizador de datos: Aquí es totalmente al revés, el app jala información del servidor. En este caso, la primera alternativa es la de fijar un tiempo de sincronización relativamente alto, agregar un visor de la última fecha de sincronización y la opción para forzar la sincronización manualmente.
  • Finalmente, como siempre, en la vida real tendremos una combinación de necesidades, así que la recomendación final es la de utilizar un proceso de sincronizacion para descargar datos y otro para subir datos.

Hay una función que no he mencionado aún: Sincronización filtrada. Esto es super útil y lo voy a desarrollar en otro Post, Básicamente es la de descargar solamente la información que me interesa. Esto es tan importante que todos deben usarlo si es que tenemos que descargar datos.

En conclusión, es muy fácil sincronizar sin límites, pero en la vida real, no hay que pedir más de lo que debemos consumir.


Después montones de pruebas, ya publiqué mi app. Por ahora está en Windows Phone Store y en Google Play. Muy pronto en iOS.

Es un catálogo de comics publicados localmente, que les permitirá resolver el problema principal que como coleccionista he tenido que sufrir, ir al puesto de revistas y no saber cual cómic comprar o si es que ya salió el siguiente.

El app es muy simple en el uso, pero detrás tiene un par de cosas interesantes: Sincronización automática de datos y un código para 3 plataformas.

El código único está hecho en Cordova como les dije en un post anterior. Ionic Framework para ser exactos. Las ventajas que trabajar con esta herramienta son innumerables, pero me concentraré en decir que el ahorro de tiempo en programación es de lujo. El punto en contra podría ser que pierdes ciertas funciones nativas, pero me he dado cuenta que el real problema es otro: Interfase de Usuario nativa. Con Ionic, la interfase de usuario es HTML5 donde no hay Panoramas ni Pivots que hay en WP8, por lo demás, hay alternativas que puedes salvar. Entonces, a fin de que sus usuarios no se quejen, aprendan algo de CSS y de SASS y si pueden contraten a un buen diseñador. Si es que no tienen esa virtud de diseñar pantallas bonitas, hagan como yo, manténganlo todo simple. Igual les prometo que contrataré un diseñador para mejorar la presentación.

La sincronización automática se logró mediante la plataforma CouchDB. Para ser exactos, los datos están en un servidor Cloudant y en el cliente utilizo PouchDB, de tal forma que todos los datos son locales para la aplicación. Si es que se publican colecciones o comics nuevos, la data se sincroniza (sólo las diferencias) y desde ese punto todo es local. Ahora bien, existe un modo de sincronización que permite que los datos sean replicados en tiempo real, como resultado de las pruebas he llegado a la conclusión que sólo tiene que ser activado en algunas situaciones limitadas, por dos razones: Costo del tráfico y batería.

CouchDB es super inteligente para sincronizar, y si le dices que quieres hacer una sync “live” se va a encargar de tener los datos en el móvil super actualizados, y con PouchDB eso significa que se mantenga una conexión abierta con el Servidor la mayor parte del tiempo. Esto consume tráfico, batería y todo lo que puedas imaginar. Además, Cloudant te cobra por HTTP Request, lo que significaba, para el caso de mi app, mandar una transacción “pesada” cada 25 segundos por cada móvil. Haciendo las matemáticas, es mucha plata considerando que las publicaciones de comics se hacen por lo general cada semana. En JavaScript hay un método maravilloso llamado SetTimeOut que permite establecer un método donde el app sincroniza todo al iniciar y luego decirle que vuelva a sincronizar a los n minutos. De esa manera puedo hacer que las apps sólo sincronizen cuando es realmente necesario. Como por ahora no se cuantos usuarios pueda tener, mi estrategia de sincronizacion es cada 10 minutos si es que no se ven cambios y cada 100 minutos si es que se obtuvieron cambios, es decir, como los cambios los publico una sola vez, si los descargas, ya no volverás a ver otro lote de cambios hasta dentro de un largo tiempo, así que 100 minutos es el largo tiempo por ahora. Esto debe soportar las nuevas funciones que pienso introducir en el siguiente release.

Entre los principales problemas que tuve es el hecho de trabajar en un código único es posible mientras no tengamos que ver cosas muy pegadas al móvil. Por ejemplo, hay plugins para manejar beeps o para el manejo de estadísticas que sólo funcionan en el móvil haciendo las tareas de debug  bastante tediosas. Así que lo ideal es empezar el proyecto sabiendo que plugins se van a utilizar, para lo cual hay que certificarlos antes y probar que funcionan tal como deben. Por ejemplo, yo les comenté en un Post anterior que utilizaría Angulartics para el manejo de estadísticas, pues resulta que no trabaja tan fácil como lo pensé, y no es que el código sea complicado, simplemente tiene sus lios y listo. Gastar tiempo en investigar esos errores dentro del proyecto es una pesadilla, así que hagan su propio catálogo de plugins que ustedes hayan certificado y tendrán la ventaja.

Por el lado de los datos, PouchDB (o CouchDB como quieran) es un estándar que lo único que tiene fuerte es la sincronización y el manejo de los formatos de base de datos. Quiere decir que consultar los datos puede llegar a ser algo especial. Felizmente PouchDB es manejado por un tipo muy buena onda que se llama Nolan Lawson que está creando librerias y herramientas muy potentes que ayudan a bajar la complejidad, pero lo que si es un hecho es que NO ES SQL, así que hay que meterle algo de cabeza al inicio, como por ejemplo, crear llaves primarias con fecha y datos de la clase padre (plop!) y demás trucos que están todos documentados que en sistemas SQL ni te imaginas. Igual todo vale la pena porque funciona como un reloj suizo.

Un punto importante es el tema de los formatos de base de datos. Hasta ahora, SQLite ha sido la opción única para manejar datos en el móvil y resulta que es un estándar que ya fue. WebSQL definía el uso de archivos sql en aplicaciones HTML5 y actualmente ha sido reemplazado por IndexedDB que es como un super diccionario. El problema aquí es que SQLite sigue siendo muy veloz, y algunas plataformas ya han dejado de lado SQLite, como por ejemplo FirefoxOS y parece que Windows Phone 8.1 también. En fin, para evitar tener que recodificar ese soporte, PouchDB nos facilita la vida haciendo esa gestión por nosotros, si el sistema soporta WebSQL, lo usa y si sólo soporta IndexedDB, cambia todo tras bambalinas, genial. Tiene otros soportes, pero con estos dos es suficiente. Para los curiosos, PouchDB también trabaja en la PC para lo cual utiliza LevelDB que es otro rollo en base de datos para aplicaciones Web.

En conclusión, ya pueden probar mi App que principalmente les permitirá ver que un app puede tener datos actualizados de forma transparente y que comparte un código para todas sus plataformas, así no sean coleccionistas de comics.

Google Play Store:

Get it on Google Play

Windows Phone Store:

154x40_WP_Store_blk

 

Muy pronto para iOS:

 

NOTA FINAL: Disculpen los banners, pero también son parte del experimento

 


Cuando se dice Windows 8, ahora debemos especificar de cual de todas las plataformas estamos hablando, porque ahora hay Desktop, Tablet y hasta telefonos, todos con las mismas pantallas y con aplicaciones similares, algo que ni Google ni Apple pueden hacer aún.

Microsoft promete una sola estrategia para todos los dispositivos, pero eso no significa que sea como tener piezas de Lego que encajan unas con otras. La verdadera real ventaja de Microsoft es que esta  planteando lo que era mas que lógico: una sola manera de interactuar con todos nuestros dispositivos, ahora, lo que viene detrás puede ser algo diferente, pero como veremos , eso no importa.

Para los que somos de preguntar demasiado, quisiéramos tener un programa que se ejecute igual en mi pc, en mi tablet y en mi teléfono, y quizá es la idea de muchos cuando se empezó a hablar de Windows 8, pero no es así, pues cada plataforma aun requiere un binario diferente. El mérito de todo esto es que esto ya no es mas un problema para los usuarios comunes y corrientes, que son la mayoría. A partir de ahora, ese problema es de los programadores.

Para los usuarios finales, esto es lo que estaban esperando por mucho tiempo, con un pequeño detalle: van a tener que aprender algunas cosas nuevas. El costo de hacer una interfase de usuario única es que hay cosas nuevas que hay que integrar a las viejas plataformas, así que hay que acostumbrarse ahora a tener la pantalla toda llena de marcas de dedos incluso en la que se tiene en la casa, o en el tablet o en el teléfono.

Otra gran noticia es que por fin se reconoce que habemos usuarios que no solo quieren jugar con tus tablets, por lo que las tablets vienen con teclados y con Office de saque (al menos en la version RT) lo que significa que el tablet ya no es mas un juguete diseñado para la sala de la casa, ahora si puede ser  una herramienta corporativa en la que podremos modificar presentaciones y enviarlas por correo juntamente con instrucciones detalladas, todo gracias a los dos sabores de teclado disponibles, y seguramente saldrán mas aparatos de este tipo. Pensemos de esta manera, un trabajador móvil podría tener su teléfono para recibir y ver correos, así como para navegación urgente y su tablet para cuando hace falta  contestar o preparar algún documento, que ahora si se puede.

Las alternativas actuales son casi nulas: tenemos Blackberries con teclado, pero solo sirve para contestar correos nada que ver con office, y todos los demás dispositivos son forzados a trabajar con teclados pero sus aplicaciones no están preparadas para el trabajo, además que hay que comprarlas aparte en la mayoría de los casos.

Entonces, el nuevo paradigma móvil es:

– Smartphone para cosas urgentes y rápidas

– Tablets para cuando realmente hay que trabajar.

Es decir, cargar dos dispositivos que es totalmente factible pues ya el día de hoy mucha gente tiene que hacer eso. Además, el tablet del que estamos hablando es un aparato de una pantalla de 10 pulgadas, por lo que  es algo mas grande que las 7 pulgadas que hasta ahora eran el tamaño ideal para el trabajo móvil. Puedo asumir el mayor tamaño si es que estamos hablando de tener Office completo en la tablet, y con el teclado. Ciertamente, hay Androids y iPads con teclado, pero no hay nada mejor cuando el dispositivo ha sido pensado para trabajar así desde el  principio.

Es cierto que se trata de una plataforma nueva y que seguramente aun quedan algunas cosas que mejorar, quizá Windows 8.1 mejore esas cosas, pero al menos ya hay un esquema que permite hacer las cosas de una sola manera sin importar el tipo de usuarios que seamos.

Sobre el hardware disponible al día de hoy, pues tal vez deberíamos esperar. Microsoft Surface RT suena grandioso, pero todavía no está claro como va a ser el tema de las actualizaciones del sistema operativo en ese modelo, serán tan ágiles como en la version PC? De todas maneras, no me quejo si tengo que trabajar con uno de esos, obviamente con el cover Type (El cover Touch tiene un teclado que parece mas light).

Microsoft llegó tarde a la fiesta de móviles pero se trajo consigo una fiesta mas grande y novedosa basada en la simplicidad y en la experiencia única. Algo que Apple recién comenzó hace poquito y que Google nunca podrá (Fragmentación!!!).





%d bloggers like this: