En este artículo quiero analizar distintos usos de posicionamiento que pueden requerir nuestras aplicaciones y ver cómo podemos conseguirlos cuando estamos desarrollando nuestra aplicación con Apache Cordova o PhoneGap.

Como funcionalidades asociadas a la localización pueden enumerarse muchas, pero podríamos decir que todas ellas están basadas en los siguientes escenarios:

• Posicionamiento puntual: es cuando necesitamos saber las coordenadas longitud y latitud del usuario de forma puntual, por ejemplo para adjuntarlas a una foto, un formulario, consultar una API que nos devuelva datos geolocalizados, etc.
• Seguimiento del usuario en primer plano: es cuando necesitamos monitorizar la posición del usuario mientras usa la aplicación porque probablemente esté moviéndose y necesitemos actualizarla en la interfaz de nuestra aplicación, probablemente actualizando dicha posición en un mapa. Un ejemplo claro de esto sería el juego Pokemon Go o Glas aplicaciones de mapas de Apple y Google.
• Seguimiento del usuario en background: es cuando necesitamos monitorizar completamente la ubicación del usuario, esté usando o no nuestra aplicación. En este escenario sería el sistema operativo quien se encargaría de ir ejecutando periódicamente nuestra aplicación para informarle de la posición del usuario.
• Geofence: aplicaciones que únicamente necesitan saber cuando el usuario pasa por ciertas zonas más o menos amplias, donde el sistema operativo únicamente avisará a nuestra aplicación si pasa por alguna de estas zonas.

Para poder abordar estos escenarios, vamos a ver los siguientes posibilidades:

• API HTML5
• Plugin oficial de Apache Cordova de Geolocalización
• Plugin para Geolocalización en background
• Plugin para Geofence.

Posicionamiento agresivo y consumo de batería.

Antes de continuar me gustaría comentar el principal problema asociado a los sensores GPS, especialmente cuando se hace seguimiento de la posición del usuario: el incremento en el consumo de energía y por tanto la reducción de su autonomía del dispositivo.

Hay que tener en cuenta que a día de hoy no es estrictamente necesario asociar sensores GPS a la posibilidad de obtener la localización del usuario, pues es posible realizar geolocalización mediante el uso de posicionamiento Wifi o posicionamiento basado en triangulación de estaciones de repetición móviles.  Este tipo de localización no es tan exacta como la localización basada en sensores, pero su impacto en la batería es prácticamente nulo en comparación a la activación de GPS.

En este contexto, se suele hablar de posicionamiento agresivo el realizado por sensores GPS, el cual es muy exacto pero consume mucha batería, y posicionamiento no agresivo al realizado mediante triangulación wifi o repetidor, el cual puede no ser tan exacto aunque su consumo es muy reducido. En general es deseable hacer uso de posicionamiento agresivo únicamente cuando necesitemos un alto grado de exactitud en la posición del usuario.

API W3C HTML5 de Geolocalización

Con HTML5 podemos obtener la posición de un usuario desde el navegador web gracias a la API de Geolocalización definida por el W3C. Fue una de las primeras APIs incluidas en el conjunto de especificaciones de HTML5 y por tanto su disponibilidad en los navegadores actuales es bastante alta.

Es una API muy sencilla que que expone los siguientes métodos accesibles desde window.navigator.geolocation:

• getCurrentPosition: obtiene las coordenadas actuales del dispositivo sobre el que se ejecuta la aplicación.
• watchPosition: Monitorizar la posición del dispositivo, de forma que cada variación de coordenadas nos sea notificada.
• clearWatch: indicamos que ya no queremos seguir monitorizando y que cesen las llamadas de notificación de cambio de posición.

Esta API nos simplifica mucho la vida porque nos independiza de los complicados escenarios que puede haber detrás de la geolocalización, pues nos garantiza que se nos devolverá la “mejor” localización posible, en caso de poder obtener una. Si el dispositivo tiene sensores GPS, wifi o señal de radio los utilizará para obtener la posición en base a ellos, donde únicamente podremos saber la calidad o el nivel de precisión de dicha señal.

Veamos qué información podemos obtener a través de esta API. La función getCurrentPosition tiene la siguiente definición:

window.navigator.geolocation.getCurrentPosition(successCallback, errorCallback, options)

Como vemos, se trata de una función asíncrona donde le pasaremos una función a ejecutar en caso de éxito, una función a ejecutar en caso de fracaso, y un objeto con algunas opciones de configuración. En caso de éxito, a la función successCallback se le pasará un objeto con los siguientes datos:

• longitude: coordenada de longitud
• latitude: coordenada de latitud
• altitude: altitud en metros, o null si el dispositivo no es capaz de calcularla
• accuracy: nivel de exactitud de coordenadas, especificada en metros. A más metros menos exactitud
• altitudeAccuracy: exactitud en la altitud, también en metros.
• heading: dirección en la que se mueve el dispositivo, en grados centígrados. Si el dispositivo está quieto será NaN o null si el dispositivo no es capaz de obtener dicha información
• speed: velocidad en metros por segundo.

Como opciones, comentar que solo tendremos 3 a definir:

• enableHightAccuracy: booleano indicando si deseamos activar la geolocalización precisa. En la mayoría de implementaciones esto se traduce en hacer uso del GPS, es decir, si deseamos geoposicionamiento agresivo o no agresivo.
• timeout: tiempo máximo definido en milisegundos para invocar a successCallback con la información de posicionamiento. Si se supera, se invocará errorCallback.
• maximumAge: podremos indicar si admitimos valores de posicionamiento cacheados y el tiempo máximo permitido para dichos valores. Lo definimos también en milisegundos

Si aparte de conocer la posición del dispositivo deseamos hacerle un seguimiento, podremos hacer uso de la función watchPosition:

var watch_id = navigator.geolocation.watchPosition(successCallback, errorCallback, options)

Como vemos es muy parecida a getCurrentPosition, pero en vez de llamar una única vez a successCallback, se invocará cada vez que se registre un cambio de coordenadas en el dispositivo.

Por otra parte, gracias al identificador que devuelve esta función podremos cancelar la operación de seguimiento invocando a la función clearPosition(watch_id).

Como vemos, la información de posicionamiento que podemos obtener con esta API es más que suficiente para un gran número de escenarios e incluso podremos definir si deseamos posicionamiento preciso o no, lo cual como ya hemos visto nos permitirá ahorrar batería.

Plugin PhoneGap/Apache Cordova de Geolocalización

Como he comentado, la API HTML5 de geoposicionamiento se encuentra prácticamente en todos los navegadores actuales, pero no siempre fue así y es posible que todavía existan usuarios con navegadores obsoletos .

Por este motivo, cuando trabajamos bajo Apache Cordova / Phonegap es recomendable instalar el plugin de geolocalización, el cual se encarga de implementar la API definida por el W3C en aquellos dispositivos donde no esté disponible una implementación del navegador.

Si vas a usar geolocalización en tu aplicación, te recomiendo que instales este plugin ejecutando:

cordova plugin add cordova-geolocation-plugin

Geolocalización en background

Si lo que deseamos es realizar un seguimiento constante del dispositivo incluso si la aplicación pasa a ejecutarse en segundo plano, no será suficiente con el uso de las APIs comentadas. Uno de los problemas que encontramos en aplicaciones desarrolladas con Apache Cordova / PhoneGap es que no son capaces de ejecutar código en segundo plano. Una vez que la aplicación pasa a ejecutarse en segundo plano se detiene completamente la ejecución JavaScript del WebView, por lo que no podremos seguir capturando la posición del usuario.

Una primera aproximación para poder solventar este problema sería hacer uso de algún plugin que nos permitiese ejecutar código en segundo plano, como por ejemplo cordova-plugin-background-mode. Sin embargo, dicho plugin no será válido si queremos desarrollar sobre iOS y queremos publicar nuestra app en la App Store, ya que iOS tiene muy restringido qué funcionalidades pueden ejecutarse en segundo plano. Solo nos valdrá para aplicaciones que queramos off-store o empresariales.

La solución pasa por hacer uso de un plugin específico de geoposicionamiento en segundo plano:cordova-plugin-background-geolocation. Este plugin nos permitirá seguir capturando la posición del usuario incluso si la aplicación pasa a segundo plano, tanto en iOS como en Android, y está optimizado para hacer un uso eficiente del posicionamiento y evitar que nuestra aplicación consuma excesiva batería. También nos servirá para geolocalizar en primer plano de una forma más eficiente, aunque para primer plano podremos seguir usando las APIs ya comentadas.

Con este plugin podremos definir una función JavaScript que se llamará cada vez que se registre un cambio significativo en las coordenadas del dispositivo. El sistema operativo se encargará de arrancar nuestra aplicación en segundo plano y llamará a dicha función para que procese la información de posicionamiento.

El plugin no solo es capaz de llamar a la función callback definida, sino que además será capaz de enviar por POST la posición registrada a una URL que definamos. Si no es capaz de enviarla en repetidos intentos (porque el dispositivo está sin cobertura, por ejemplo), las irá guardando en un buffer local hasta un máximo configurable y volverá a intentarlo enviando todas las coordenadas de posición acumuladas.

Lo primero que tendríamos que hacer sería instalar el plugin en nuestro proyecto:

cordova plugin add cordova-plugin-mauron85-background-geolocation

Hay que comentar que el plugin ya incluye las modificaciones necesarias en los proyectos para pedir los permisos correspondientes tanto en iOS como en Android para poder realizar geoposicionamiento en segundo plano.

Vamos a ver un ejemplo básico para ver cómo podríamos usar el plugin:

//como cualquier llamada a plugins Cordova/Phonegap, 
//deben hacerse tras el evento deviceready
document.addEventListener('deviceready', onDeviceReady, false);

function onDeviceReady () {
  //Esta es la función que se invocará en cada registro de posicionamiento en segundo plano
  var callbackFn = function(location) {
    console.log('[js] Posición en background:  ' + location.latitude + ',' + location.longitude);
    // Aquí incluímos lo que queramos hacer con la información, incluso enviarla
    // a un servidor si queremos.
    // jQuery.post(url, JSON.stringify(location));

    // Debemos informar que hemos terminado para que el sistema operativo
    // cierre ordenadamente nuestra aplicación
    backgroundGeolocation.finish();
  };

  var failureFn = function(error) {
    console.log('Error');
  };

  // Configuramos el plugin, indicando nuestra función callback y algunas opciones
  backgroundGeolocation.configure(callbackFn, failureFn, {
      desiredAccuracy: 10,
      stationaryRadius: 20,
      distanceFilter: 30,
      interval: 60000
  });

  // Activamos la geolocalización en segundo plano
  backgroundGeolocation.start();

  // Si en algún momento queremos pararla, podemos indicarlo con stop()
  backgroundGeolocation.stop();
}

A la hora de configurar el plugin mediante la función configure, podremos especificar algunos parámetros que nos permitirán ajustar la precisión y la frecuencia de los registros de posicionamiento, la URL a la que queremos que se envíen los registros o el máximo número de registros que se almacenarán el buffer que hemos comentado antes. Aquí hay que tener en cuenta que cuanto más frecuencia y precisión deseemos, más penalizaremos la batería de los dispositivos que ejecuten nuestra aplicación.

Geofencing

Por último, veremos un caso especial de geoposicionamiento en segundo plano, llamado Geofencing. Consiste en generar notificaciones de usuario cada vez que éste entre o salga (según queramos) de una determinada area circular, definida por unas coordenadas y un radio de amplitud en metros.

Personalizando y adaptando el plugin anterior podríamos implementar sin problemas un esquema de geofencing, pero si únicamente queremos hacer tracking de dispositivos para esta finalidad, probablemente nos interese conocer un plugin específico para esto: cordova-plugin-geofence

Este plugin nos permitirá definir tantas zonas a monitorizar como queramos, indicando la longitud, latitud y radio de acción en metros de cada una de ellas. Indicaremos los datos de la notificación que queremos que se genere así como cuando queremos que se genere, si al entrar, al salir o en ambos casos.

Para probarlo, añadimos el plugin a nuestro proyecto

cordova add plugin cordova-plugin-geofence

Posteriormente lo primero que haremos será inicializar el plugin:

document.addEventListener('deviceready', function () {
  // window.geofence is now available
  window.geofence.initialize().then(function () {
    console.log("Successful initialization");
  }, function (error) {
    console.log("Error", error);
  });
}, false);

Una vez hecho esto, podremos ir añadiendo areas a monitorizar con la función addOrUpdate:

window.geofence.addOrUpdate({
  id: 'area1', //Identificador único que se asignará al área
  latitude: 37.663354, //Coordenada de latitud del centro del área
  longitude: -1.7042037, //Coordenada de longitud del centro del área
  radius: 300, //Radio del área en metros
  transitionType: TransitionType.ENTER, //Tipo de transición que deseamos: 1 - Entrada, 2 - Salida, 3 - Ambas
  notification: {
    id: 1, //id numérico de la notificación, opcional
    title: 'Entrando en Area', //Título de la notificación
    text: 'Has entrado en el área', //Texto de la notificación
  }
}).then(function () {
  console.log('Área añadida');
}, function (reason) {
  console.log('Fallo al añadir área', reason);
});

El plugin ofrece otras funciones para poder consultar las áreas de monitorización que tenemos definidas así como poder eliminarlas. Hay que tener en cuenta que una vez establecida un área, se dispararán las notificaciones mientras que ésta esté definida y no la borremos. Incluso si reiniciamos el dispositivo.

Conclusión

Hemos visto distintas herramientas que tenemos a nuestra disposición para poder implementar distintas funcionalidades asociadas al geoposicionamiento en nuestros proyectos Cordova /PhoneGap, y según lo que queramos hacer nos vendrán mejor unas u otras.

Creo que el principal factor a tener en cuenta es encontrar el equilibrio entre la precisión necesaria para cumplir con el cometido de nuestra aplicación y el consumo de energía que ello requerirá. Si hacemos un uso excesivo o muy agresivo del posicionamiento penalizaremos considerablemente la vida útil de la batería en los dispositivos donde ejecutemos nuestra aplicación, lo cual no suele gustar mucho a los usuarios y por tanto

La entrada Geolocalización con Apache Cordova / Phonegap: posicionamiento, seguimiento en background y geofence se publicó primero en alfonsomarin.

Si a tí te pasa algo parecido y no puedes contar con los servicios de un diseñador profesional, quiero compartir contigo algunos trucos y recursos que yo utilizo y que me ayudan a coger ideas a la hora de definir el aspecto visual de una aplicación móvil.

Cuestiones a tener en cuenta

A la hora de diseñar una aplicación desde cero tendremos que centrarnos en dos aspectos principales:

• El aspecto visual: cómo se visualizarán los componentes, gama de colores principales, aspecto de los botones, menús, tipografía, etc.
• Arquitectura y navegación: cómo vamos a distribuir las secciones de nuestra aplicación, cómo será el menú de navegación, y en general todo lo que tenga que ver con la experiencia de usuario (UX).

Los recursos que voy a comentar en este post están más orientados al primer punto, es decir a la definición del aspecto visual. Sin embargo algunos nos darán ideas sobre elementos de interfaz de usuario que podamos utilizar para definir la arquitectura de la aplicación y mejorar la experiencia de usuario.

En general buscaremos un estilo y un aspecto visual que nos sea útil en cualquier plataforma sobre la que desarrollemos, pues somos multiplataforma y queremos que nuestra aplicación se vea igual de  bien en cualquier dispositivo. Sin embargo, debemos intentar que nuestra aplicación haga uso en la medida de lo posible de los patrones de diseño recomendados en cada plataforma. Un ejemplo típico es el uso de botones explícitos para ir atrás en iOS que no deberíamos usar en Android, o el típico botón de “más acciones” representado por un icono de tres puntos verticales en Android, o que en iOS los paneles tabulados suelen incluir los iconos en la parte inferior de la pantalla y Android en la parte superior.

1. Galerías de patrones de diseño

Existen varias páginas web que recopilan distintos patrones de diseño agrupándolos por categorías y mostrando ejemplos encontrados en aplicaciones reales. Son una fuente de inspiración fenomenal pues nos permiten analizar las soluciones que han dado distintos diseñadores a distintas secciones típicas que podamos encontrar en una aplicación, como son los menús de navegación, las páginas de perfil, los listados o calendarios.

• iOS patterns: disponemos de más de 500 patrones encontrados en las versiones de iOS de numerosas aplicaciones. Están centrados en las versiones para smartphone, no encontrando ideas para aplicaciones de tablet.
• Android Niceties: parecida a la anterior pero centrada en Android. Es un tumblr que van actualizando con capturas de distintas aplicaciones. Se echa en falta un poco de categorización como hacen otras páginas similares pero podremos usar el sistema de etiquetas para ver ejemplos más segmentados.
• pttrns.com: Esta página me encanta. No solo podremos filtrar por elementos específicos de interfaz de usuario sino que podremos seleccionar la plataforma que nos interesa. Además, no solo se incluyen capturas de aplicaciones para smartphone sino que además podremos ver aplicaciones para tablets o incluso smartwatch (principalmente Apple Watch). Tremendamente recomendable.
• Mobile patterns: Aunque podemos seleccionar iOS y Android, básicamente encontraremos ejemplos de iOS, y una vez más solo contempla aplicaciones para smartphone.
• capptivate.co: como novedad esta página web ofrece algunas de las capturas con animación incluída, donde no solo podremos coger ideas sobre aspecto visual sino que además podremos cogerlas sobre animaciones y transiciones entre elementos.
• Pinterest: Si de coger ideas se trata, no podía faltar la red social “visual” más popular. En ella buscando con términos como “Mobile UI”, “iOS UI” o “Android UI” encontraremos muchos más ejemplos que nos puedan servir de inspiración.

2. Kits de diseño

Otra opción que podemos utilizar es buscar algún Kit UI destinado para móviles que nos den una solución completa a los elementos de interfaz más comunes de una aplicación móvil. Suelen ser diseños que vienen en en formato PSD (Photoshop) o para Sketch (SketchApp). Muestran pantallas completas a modo de capturas donde podremos ver cómo se muestran los elementos que componen el diseño y usarlos en nuestras propias aplicaciones. Muchos de estos kits ofrecen una versión gratuita donde limitan el número de elementos o un número reducido de pantallas, ampliándolas en las versiones de pago.

El problema de estos kits es que, al poder ser adquiridos ya sea gratuitamente o pagando por ellos, no se nos garantiza la exclusividad de los mismos, pudiendo darse el caso en el que nos encontrásemos otras aplicaciones haciendo uso de los mismos.

Por otra parte, hay que tener en cuenta que únicamente nos ofrecen las capturas y como mucho los elementos separados por capas para poderlos “trocear” y usar en nuestra aplicación, pero seremos nosotros quien finalmente los tengamos que “traducir” al lenguaje de maquetación de la plataforma de desarrollo que estemos utilizando. Si por ejemplo estamos haciendo una aplicación web o híbrida, tendremos que traducir todos esos elementos gráficos a HTML5 y CSS.

En las siguientes webs podremos encontrar Kits orientados a aplicaciones móviles:

• freebiesbug.com: en esta web encontraremos numerosos recursos de diseño gratuítos, donde cuentan con una sección específica de kits para aplicaciones móviles. La mayoría de estos kits ofrecen versiones ampliadas de pago y estan disponibles en PSD y/o Sketch.
• ui8.net: un buen repositorio donde no solo encontraremos Kits UI sino que disponen de fuentes, iconos y otros recursos de diseño. Son de pago pero muchos a un precio muy económico.
• sketchappsources.com: si trabajas con la aplicación de diseño SketchApp, encontrarás numerosos kits y recursos compatibles con esta aplicación.
• Recopilaciones realizadas en blogs: muchos blogs especializados en temas de diseño ofrecen recopilaciones de Kits UI gratuitos o de pago como son el caso de them, themefurnace.com, Envato,  o speckyboy.com.

Por último, aquí tienes un video donde se puede ver algunas recomendaciones a la hora de utilizar los kits de diseño, en este caso con Photoshop.

3. Icono principal de la aplicación

El icono principal de la aplicación, aquel que la identifica y el cual aparecerá en la pantalla de aplicaciones de nuestro dispositivo, es de las partes más delicadas de toda la aplicación, al menos a nivel de diseño. Junto al nombre que le demos a nuestra aplicación jugará un papel crucial a la hora de realizar el marketing y la promoción. Sin embargo, una vez más existen sitios donde podemos recoger algo de inspiración, incluso comprar iconos ya hechos:

• iOS icon gallery: iconos de aplicaciones iOS, Mac y Apple Watch. Podemos buscar por categorías y por colores.
• iconsfeed.com: aunque también podemos buscar por categorías, la interfaz es mas cuidada que la anterior donde destaca el sistema de iconos relacionados que podemos ver según elegimos uno.
• iOSpirations: Otra página centrada en iconos de apps de iOS y Mac.

También tenemos algunas utilidades online que nos permitirán generar juegos de iconos para disponer de todos los tamaños necesarios para la publicación de la app.

• makeappicon.com
• appicon.build

4. Juego de Iconos de aplicación

Aparte del icono principal de la aplicación, normalmente necesitaremos juegos de iconos para usar dentro de la aplicación, aquellos que utilizaremos dentro de botones, pestañas, elementos de menú, etc. En algunas ocasiones si partimos de algún Kit UI, éste ya incorporará algunos que podremos reutilizar.

Yo recomiendo buscar juegos completos de iconos para asegurarnos de tener disponible una gama amplia donde elegir y poder cubrir todas las funcionalidades de nuestra aplicación, y así asegurarnos que siguen una línea de diseño homogénea.

Una vez más encontraremos catálogos de iconos gratuitos o de pago. A continuación indico unos cuantos ejemplos:

• Font Awesome: ampliamente conocida por cualquier desarrollador web, se trata de una fuente open source donde podremos encontrar un catálogo tremendamente completo de iconos para utilizar en nuestras aplicaciones.
• Recopilatorio de 30 packs de iconos gratis: esta recopilación de packs me parece muy completa. Échale un vistazo porque encontrarás packs realmente buenos
• flaticon.com: otra famosa web donde podremos descargar iconos por separado o por packs.
• icons8.com: buscador de con más de 30000 iconos. Podremos descargarlos gratuitamente en tamaño 100×100, tamaño normalmente suficiente para aplicaciones móviles si los utilizamos como complementos de elementos de interfaz (botones, menús, …)

5. Tipografías

Por último, y no por ello menos importante, debemos seleccionar la tipografía adecuada a utilizar en nuestra aplicación.

Un problema que solemos encontrar si utilizamos Kits UI es que éstos no suelen incorporar las tipografías, de forma que si realmente queremos trasladar esos diseños a componentes de aplicación funcionales (ya sean HTML5 o nativos) tendremos que buscar fuentes similares o directamente descargar las originales, ya sean fuentes libres o de pago.

A continuación muestro algunos repositorios de fuentes, algunas completamente libres y gratuitas y algunas de pago, donde podremos buscar aquella que más se ajuste al diseño que buscamos:

• 1001freefonts.com
• fontspace.com
• fonts.google.com
• fontbundles.net
• fontsquirrel.com

Conclusión

Como hemos visto, existen multitud de recursos para encontrar inspiración o directamente conseguir buenos diseños a bajo coste. Esta estrategia es ideal para aquellos proyectos propios o aplicaciones para terceros donde queramos reducir presupuesto. Sin embargo, siempre que puedas te recomiendo que uses los servicios de algún profesional que te permita dotar a tu aplicación de ese extra de calidad que aporta un diseño equilibrado y cuidado.

La entrada Recursos para diseño de aplicaciones móviles se publicó primero en alfonsomarin.

El problema es el de siempre: sistemas operativos diferentes con lenguajes de programación diferentes y SDKs diferentes que nos obligan a desarrollar una versión distinta para cada plataforma y que implican una curva de aprendizaje bastante empinada. En estos casos es inevitable hacerse la pregunta de oro: ¿No podría desarrollar una única app que pudiese ejecutarse en cualquier sistema operativo? o al menos en las plataformas principales.

En este post veremos las estrategias que actualmente se usan para el desarrollo multiplataforma: Web App (HTML5), aplicaciones híbridas y aplicaciones pseudo-nativas o compiladas. Veremos cada una de ellas explicando las ventajas e inconvenientes que nos podemos encontrar en cada estrategia. También veremos qué frameworks o librerías podremos usar en cada aproximación.

Aplicaciones HTML5

Gracias a los avances y APIs introducidas con HTML5 existe un gran número de aplicaciones que pueden implementarse haciendo uso únicamente de las APIs HTML5, JavaScript y CSS. Es la tecnología multiplataforma por excelencia ya que todo sistema operativo móvil cuenta con un navegador web, normalmente basado en WebKit lo que asegura una implementación rezonablemente estándar de las APIs HTML5. Incluso Microsoft en sus últimas versiones de Internet Explorer está mejorando el soporte a estas plataformas.

Aunque podríamos incluir en esta estrategia a cualquier web tradicional que haga uso una plantilla adaptativa (responsive), para aplicaciones móviles es recomendable hacer uso de frameworks que ofrezcan componentes de interfaz de usuario especializados para móviles y que se asemejen a los componentes que normalmente ofrecen los SDK nativos para componer las vistas de nuestra aplicación: Vistas, transiciones entre vistas, vistas de navegación, listados de selección, barras de herramientas, componentes de formulario, carruseles de fotos, botones, etc.

Para trabajar con este tipo de framework utilizaremos JavaScript o alguna de sus variantes compiladas como CoffeScript o TypeScript. Suelen estar basados en algún patrón como el de Modelo Vista controlador (MVC) o el Modelo Vista VistaModelo (MVVM) y la idea que persiguen es que toda la arquitectura de la aplicación se monte en el lado del cliente y únicamente se utilice el servidor para la recuperación de datos, normalmente usando JSON.

Ventajas

• Únicamente necesitamos saber HTML, JavaScript y CSS para abordar cualquier plataforma
• Máxima reutilización de código, ya que es la misma app para todos los dispositivos
• Mayor número de plataformas soportadas

Desventajas

• No podremos acceder a APIs nativas de cada plataforma o cualquier funcionalidad a la que no pueda acceder el navegador, como por ejemplo las notificaciones Push.
• El rendimiento es menor que en las aplicaciones nativas, pues es el navegador web quien realmente está ejecutando la aplicación
• Limitaciones de almacenamiento típicos de HTML5, donde normalmente tendremos acceso a 5MB que en muchas aplicaciones no será suficiente.
• Capacidad de funcionamiento offline limitada

Para desarrollarlas podríamos dos opciones:

1. Usar cualquier framework JavaScript de frontend, como Backbone.js, Angular, React, Ember.js, … junto a algún framework CSS como Ratchet o TopCoat.
2. Usar un frameworks que dispongan de un catálogo de componentes especializados en interfaces móviles, como podrían ser Ionic Framework, Onsen UI, Framework7 o Sencha Touch.

La primera opción suele estar más enfocada a aplicaciones web adaptativas que deban funcionar en sobremesa y en dispositivo móvil. La segunda opción suele usarse más en aplicaciones únicamente enfocadas a dispositivos móviles y probablemente candidatas a ser encapsuladas como aplicaciones híbridas.

Aplicaciones Híbridas

Son aplicaciones HTML5 que encapsulamos en una aplicación nativa. Siguen la misma filosofía que las aplicaciones HTML5 vistas anteriormente pero en vez de ejecutarse en el navegador del dispositivo lo hacen en un componente nativo WebView.

Estas tecnologías no solo se encargan de montar el componente WebView y cargar dentro nuestra aplicación, sino que nos ofrecerá mecanismos para comunicar nuestra aplicación JavaScript con la parte nativa, y así poder ofrecer funcionalidades que dentro de un navegador no podríamos ofrecer, ya que potencialmente podremos acceder cualquier API nativa que nos ofrezca cada SDK. Funcionalidades como las notificaciones Push, las compras dentro de la aplicación o el acceso a los contactos harán uso de este mecanismo para que podamos integrarlas dentro de nuestra aplicación JavaScript.

Ventajas

• Al ser una aplicación instalable, podremos publicarla en las tiendas de aplicaciones de cada plataforma
• Podremos acceder a las APIs nativas desde nuestra aplicación JavaScript, ya sea porque estén soportadas por la plataforma o porque podamos desarrollar un plugin para acceder a ellas
• Existen plugins ya desarrollados para acceder a las APIs más importantes, ya sean plugins oficiales o desarrollados por la comunidad

Desventajas

• Si necesitamos una funcionalidad nativa y no existe un plugin para ello, tendremos que aprender a desarrollar la parte nativa de cada plataforma
• El rendimiento sigue siendo menor que las aplicaciones nativas, pues aunque nuestra aplicación se ejecuta dentro de un WebView, éste no deja de ser un tipo de navegador más
• Es difícil hacer uso de funcionalidades nativas que impliquen componentes visuales. Por ejemplo, si deseamos acceder a las librerías de mapas nativas, estas se ejecutarán en una vista distinta al WebView y por tanto no estará integrada en el sistema de transiciones de nuestra aplicación. Hacer convivir estos componentes con el WebView algunas veces es complicado.

En esta categoría el framework por excelencia es Apache Cordova. La mayoría de frameworks HTML5 ofrecen opciones de integración con Cordova y la cantidad de plugins disponible es muy grande, tanto oficiales como desarrollados por la comunidad. A día de hoy se puede decir que es un estándar de facto y grandes empresas como Adobe, Intel o Microsoft están ayudando a su desarrollo, pues todos ellos disponen de productos que orbitan sobre Apache Cordova (Adobe con PhoneGap, Intel con su IDE de desarrollo XDK y Microsoft con su cliente de línea de comandos TACO).

Aplicaciones pseudo-nativas

Por último, tendríamos frameworks que generan código nativo a partir de código escrito en otro lenguaje como JavaScript, C#, Python, etc. A las aplicaciones que podamos desarrollar con estos frameworks las llamo pseudo-nativas porque realmente estaremos trabajando con componentes nativos y a todos los efectos nuestra aplicación parecerá nativa, pero la desarrollaremos bajo una única capa de abstracción y lenguaje de programación comunes.

Estos frameworks nos sitúan a un nivel más cercano a la plataforma base y realmente no tendremos limitaciones teóricas a la hora de acceder a cualquier librería o componente nativo ofrecido por cada plataforma soportada. Incluso en algunos casos podremos acceder a las APIs nativas de cada plataforma sin necesidad de escribir plugins o similares, directamente desde nuestro código JavaScript o C#.

Ventajas

• Podremos generar aplicaciones con componentes visuales nativos, sin las restricciones de las aplicaciones híbridas
• Estos frameworks son los que más nos pueden acercar al rendimiento nativo

Desventajas

• Suelen enfocarse principalmente a iOS y Android, dejando de lado a otras plataformas como Windows Phone o Blackberry donde se ofrece un soporte muy residual en el mejor de los casos
• Aunque su rendimiento sea similar a las aplicaciones nativas, siempre estarán un paso por detrás ya que siempre existirá la capa intermedia de traducción de código común a código nativo
• La cantidad de código común es menor que en las aplicaciones híbridas, especialmente la parte correspondiente a la interfaz de usuario que es donde más diferencias nos podemos encontrar en cada plataforma
• Si queremos sacar el máximo rendimiento nuestras aplicaciones, necesitaremos conocer más a fondo las APIs nativas de cada plataforma, lo cual puede incrementar la curva de aprendizaje.

Los principales frameworks que podemos situar en esta categoría son los siguientes:

• Xamarin (C#): adquirido por Microsoft tiene soporte para iOS, Android y Windows Phone. Aunque originalmente fue de pago, tras la compra por parte de Microsoft es posible realizar publicar nuestras aplicaciones sin adquirir licencias de pago.
• Appcelerator (JavaScript): de los primeros frameworks en esta categoría, a día de hoy es necesario adquirir licencias para poder publicar aplicaciones. Soporta iOS, Android y Blackberry.
• NativeScript (JavaScript): uno de los frameworks más prometedores pues permite acceso a APIs nativas directamente desde JavaScript. Actualmente soporta iOS y Android aunque están trabajando para poder añadir Windows Phone. Además, podemos hacer uso de Angular 2 para estructurar nuestra aplicación. Completamente Open Source.
• Kivy (Python): su fuerte son las interfaces gráficas, mas orientado a juegos que a aplicaciones tradicionales. Completamente Open Source
• Qt (C++): un clásico en el mundo multiplataforma, también soporta iOS, Android, Windows Phone y Blackberry. Salvo que nuestro proyecto sea Open Source, tendremos que adquirir una licencia para poder publicar nuestras aplicaciones.
• Unity (C# y JavaScript): motor de videojuegos que nos permitirá

Recomendaciones finales

Desde mi punto de vista las aplicaciones HTML5 son las más rápidas de desarrollar, y si ya disponemos de conocimientos en desarrollo web nos será muy fácil hacernos con alguno los frameworks comentados especializados en interfaces móviles. Por otra parte probaría Apache Cordova y al menos ojearía el funcionamiento de los plugins oficiales para poder hacer aplicaciones híbridas que puedan publicarse. Solo con esto tendríamos la posibilidad de abordar un gran número de aplicaciones móviles con resultados altamente competitivos.

Después elegiría un framework del último grupo para poder abordar aquellos proyectos que deban ser nativos, ya sea por rendimiento, por requisitos o por limitaciones que encontremos en las aplicaciones híbridas.

Una vez llegados a ese punto, podremos aventurarnos a profundizar en las APIs y SDK nativos de cada plataforma, pues un mejor conocimiento de ellos nos permitirá mejorar nuestros desarrollos pseudo-nativos o el desarrollo de plugins para las aplicaciones híbridas que realicemos.

La entrada Alternativas para desarrollar aplicaciones móviles multiplataforma se publicó primero en alfonsomarin.

Existen situaciones en las que únicamente necesitamos los elementos de interfaz de usuario, ya sea porque la aplicación sea extremadamente sencilla, tal vez porque únicamente necesitamos un prototipo o porque ya tengamos desarrollada gran parte de la aplicación haciendo uso de un determinado framework JS que implemente su propio esquema MVC o MVVC.

Para esos casos conviene conocer algunos frameworks CSS que básicamente nos proporcionan eso, conjuntos de componentes para definir el aspecto visual de nuestra aplicación que podamos acoplara a cualquier stack de tecnologías que estemos utilizando. Algo similar a Bootstrap pero especializados en componentes para aplicaciones móviles.

Ratchet

Desarrollada por algunos de los creadores de Bootstrap y también nacida desde las entrañas de Twitter, Ratchet nos ofrece un conjunto de componentes especializados en interfaces móviles basados en HTML, CSS y JavaScript. Es muy fácil de aprender y permite tanto a diseñadores como a desarrolladores realizar prototipos de una forma muy rápida. Puedes acoplarlo a cualquier tecnología frontend que estés utilizando pues el código que incluye solo afecta a los componentes que proporciona, al estilo de su primo-hermano Bootstrap.

Está en la versión 2 y ofrecen personalizaciones para iOS y para Android, aunque la versión de android no la han actualizado a las nuevas interfaces basadas en material design y esto puede ser un punto en contra. Sin embargo, la versión iOS está muy lograda.

TopCoat

Librería CSS pura que no contiene ningún módulo de script. La principal ventaja de este framework es la optimización del mismo, donde destacan que se trata de uno de los frameworks más rápidos del momento. Dado que las aplicaciones móviles HTML5 pecan en ciertas plataformas de un bajo rendimiento, es interesante plantearnos el uso para la capa visual de un framework CSS bien optimizado para atenuar esos problemas.

Sobre él se han montado otros frameworks HTML5 como onsen.io, con una filosofía similar a Ionic donde usaríamos AngularJS para la arquitectura de la aplicación, aunque recientemente también han incluido el soporte para jQuery.

Tal vez se hecha en falta alguna funcionalidad adicional al estilo de bootstrap donde te da algunos componentes interactivos, pero va como anillo al dedo si lo único que necesitamos es el aspecto visual.

Tiene una versión para aplicaciones web de escritorio y otra versión para aplicaciones móviles, donde para cada una encontraremos dos variantes, una en tonos oscuros y otra en tonos claros. Sin embargo, no encontraremos personalizaciones para plataformas como iOS o Android.

ChocolateChip-UI

Inicialmente puede funcionar con jQuery, pero ellos ofrecen también una «versión especializada» de manejador DOM llamadado ChocolateChipJS y que está optimizado para navegadores móviles. No es una librería CSS pura como podría ser TopCoat pues ofrece widgets funcionales implementados en JavaScript, donde también han creado las versiones en TypeScript.

Sus principales plataformas objetivo son iOS, Android y Windows Phone, para los cuales disponemos de temas especializados para cada una de ellas.

Actualmente el proyecto está un poco parado pues lleva unos meses sin actualizarse, pero

Framework7

Sin duda uno de los frameworks más potentes y el que personalmente más me gusta. No solo proporciona un completo set de componentes UI que imitan a la perfección los componentes nativos de cada plataforma, sino podremos gestionar transiciones entre pantallas, menús contextuales, control de scroll nativo, etc. Dispone de temas para iOS y para Android (Material Design), y como he comentado el nivel de similitud conseguido respecto a los controles originales de cada plataforma es espectacular.

No se trata de una librería CSS pura ya que al menos tendremos que incorporar código JavaScript de inicialización para arrancar las vistas y que pueda funcionar el sistema de transiciones. Sin embargo, este JavaScript es muy limpio y sencillo que podremos acoplar perfectamente a cualquier framework MVC tipo AngularJS, ember, backbone.js, etc. Además, no se apoya en ninguna librería de terceros ya que implementa su propio manipulador DOM optimizado para móviles que han llamado Dom7.

En cuanto pueda escribiré un tutorial sobre este framework porque realmente merece la pena.

La entrada Frameworks CSS3 específicos para aplicaciones móviles HTML5 se publicó primero en alfonsomarin.

De momento analizaremos cómo montar nuestro stack de desarrollo para trabajar con PhoneGap, destacando qué elementos debemos instalar y qué posibilidades tenemos para compilar y ejecutar nuestros proyectos en dispositivos o simuladores. No veremos nada de su API interna para poder hacer uso de capacidades nativas no disponibles en HTML5, eso lo dejaré para un segundo artículo. Sin embargo, con lo que veremos en esta introducción podremos encapsular cualquier aplicación HTML5 estándar dentro de una aplicación móvil.

¿Qué es PhoneGap?

PhoneGap es un framework que nos permitirá encapsular una aplicación web desarrollada en HTML5, JavaScript y CSS3 en una versión nativa que podremos instalar y/o publicar en distintas plataformas móviles y plataformas de escritorio.

La estrategia que persigue consiste en sustituir el navegador por una vista web (WebView) embebida en una aplicación nativa, haciendo transparente al usuario que realmente es una aplicación web. Además, gracias a librerías puente adicionales (plugins) podremos acceder a ciertas funcionalidades nativas no disponibles en un navegador web estándar a través de APIs JavaScript .

Mira sobre qué cantidad de plataformas podrás crear versiones nativas de tu aplicación:

•    Android
•    Amazon FireOS
•    Windows Phone (7 y 8)
•    BlackBerry 10
•    Firefox OS
•    iOS
•    Ubuntu
•    Windows 8
•    Tizen

Hay que admitir que pocos frameworks multiplataforma te permiten a día de hoy alcanzar a tantas plataformas. Una pasada.

Aclaración sobre aplicaciones web

El término «aplicación web» es muy amplio, y conviene aclarar qué tipo de aplicaciones podremos encapsular con PhoneGap. El framework está orientado a aplicaciones web que hagan uso de tecnologías de frontend, es decir, HTML5, CSS3 y JavaScript. No podremos usar tecnologías de servidor como PHP, Ruby o similares dentro de nuestra aplicación PhoneGap ya éste pone a nuestra disposición un mini-navegador (el WebView), no un mini-servidor. Obviamente podremos comunicarnos con servidores externos para obtener datos o incluso vistas HTML5, pero toda la lógica de la aplicación debe estar contenida en el cliente.

Es cierto que también podríamos cargar en el WebView interno de PhoneGap una dirección web cualquiera y así obtendríamos una «versión instalable» de dicha web, pero no es la filosofía de la plataforma ya que el efecto sería el mismo que crear un acceso directo a dicha web, con la salvedad que podríamos publicarlo en tiendas.

Aplicaciones de tipo SPA basadas en tecnologías frontend como por ejemplo Angular.js, backbone.js o ember.js, encajarían muy bien dentro de una aplicación que pudiera encapsularse con PhoneGap. Sin embargo, lo más común es hacer uso de frameworks HTML5 específicos para móvil como son Ionic, Framework 7 o Sencha Touch, pues además nos proporcionarán componentes visuales típicos en interfaces móviles.

Arquitectura de PhoneGap

La arquitectura de PhoneGap podemos dividirla  en dos partes: el kernel y los plugins.

El kernel se encarga básicamente de arrancar la aplicación nativa, crear un WebView y cargar dentro de él nuestra aplicación web. También se encargará de establecer la arquitectura básica de comunicación entre dicho WebView y la parte nativa de la aplicación, para que pueda ser utilizada por parte de los plugins.

Por otra parte, los plugins son componentes que podremos añadir para hacer uso de funcionalidades, servicios y APIs nativas que no son accesibles de forma estándar por un navegador web, expuestas ante nuestra aplicación como funciones JavaScript que podremos usar desde nuestra aplicación web.

Entre los plugins oficiales (mantenidos por los desarrolladores de PhoneGap) podemos encontrar los siguientes:

•    Battery Status: Monitorización y consulta de estado de la batería
•    Camera: acceso a la cámara y álbum de fotos del dispositivo
•    Contacts: acceso, creación y modificación de contactos existentes en el dispositivo
•    Device: Información referente al dispositivo (plataforma, versión de S.O., etc.)
•    Device Motion: acceso al acelerómetro del dispositivo
•    Device Orientation: acceso a la brújula del dispositivo
•    Dialogs: mostrar notificaciones en forma de diálogos
•    FileSystem: acceso al sistema de ficheros del dispositivo modelado a través del API File de HTML5
•    File Transfer: soporte para descargas y subidas de ficheros
•    Geolocation: consulta de posición GPS
•    Globalization: soporte para representar distintos objetos según su localización
•    InAppBrowser: abrir URLs dentro de la propia aplicación sin salir al navegador principal del dispositivo.
•    Media: Grabación y reproducción de archivos de audio
•    Media Capture: captura de ficheros multimedia mediante las aplicaciones de captura del dispositivo
•    Network Information: información sobre el estado de la conexión del dispositivo, si está online u offline o si está mediante Wifi, 3G, etc.
•    Splashscreen: control fino sobre el comportamiento de la pantalla de inicio SplashScreen.
•    Vibration: hacer que el dispositivo vibre.

También existen numerosos plugins creados por la comunidad que podremos buscar desde https://plugins.cordova.io, y en última instancia siempre tendremos la posibilidad de crearnos los nuestros propios, aunque en ese caso sí necesitaremos  disponer de conocimientos sobre desarrollo nativo en cada plataforma.

PhoneGap vs Apache Cordova

Antes de empezar a juguetear con el framework quiero aclarar la relación entre PhoneGap y Apache Cordova, pues mucha gente no tiene claro si son lo mismo o no. Para entenderlo mejor haremos un poco de historia.

PhoneGap fue desarrollado por la empresa Nitobi como software libre, pero en 2011 Adobe la adquirió pasando así PhoneGap al control del gigante de software. Por aquel entonces la comunidad alrededor de PhoneGap ya era considerable y tanto Adobe como Nitobi sabían que debían mantenerla para que la plataforma siguiese creciendo, así que decidieron mantener libre el desarrollo bajo el paraguas de la fundación Apache y rebautizaron el proyecto como Apache Córdova.

Como ellos mismos dicen, Apache Cordova es a PhoneGap lo que WebKit es a Chrome o Safari. Por una parte estaría la tecnología en sí y por otra un producto comercial basado en ella. Apache Cordova es y siempre será libre, y los avances que se produzcan sobre la plataforma (nuevas versiones, funcionalidades, etc.) se harán sobre Apache Cordova. Sin embargo, Adobe construirá su propia versión que seguirá llamando PhoneGap y sobre la que ofrecerá servicios complementarios de valor añadido.

Instalando PhoneGap

Para la creación y gestión de nuestro proyecto PhoneGap necesitaremos el cliente de comandos que podremos instalar a través de NMP, el sistema de paquetería de NodeJS que imagino que ya tendrás instalado en tu sistema como buen desarrollador web que eres. Si no es así, visita ambas páginas para informarte de los pasos a seguir para instalarlos en tu plataforma de desarrollo.

Realmente podemos instalar dos versiones de comandos: phonegap o cordova. Personalmente prefiero instalar phonegap porque a día de hoy (no siempre fue así) con el cliente phonegap podremos hacer lo mismo que con el cliente cordova, pero además podremos acceder a los servicios y aplicaciones creadas por Adobe, pues algunos de ellos son gratuitos y siempre puede venir bien.

Para instalarlo ejecutamos en nuestra línea de comandos lo siguiente

$ npm install -g phonegap@latest

Si optásemos por usar el cliente cordova haríamos algo similar

$ npm install -g cordova

Creación de un proyecto ejemplo

Vamos a crear un proyecto PhoneGap haciendo uso de nuestro cliente de comandos que acabamos de instalar y echaremos un vistazo a su estructura interna. Escribimos esto en la línea de comandos

$ phonegap create miApp

Esto creará un directorio miApp con el siguiente contenido:

• config.xml: fichero de configuración donde podremos tunear cositas
• hooks: scripts para realizar operaciones de integración, construcción, etc. Uso avanzado que no veremos aquí.
• plugins: aquí se alojarán los plugins que vayamos instalando (lo haremos más adelante).
• www: aquí es donde está la mandanga, nuestra app web. Este será el contenido que se cargue en el WebView.

Si ojeamos el contenido del directorio www veremos que ya hay una pequeña “app” de ejemplo a modo de aplicación HelloWorld. Esta app es muy básica y no hace uso de ningún plugin externo, pero los chicos de PhoneGap son muy listos y saben que lo que deseas realmente es ejecutar cuanto antes algo en un teléfono o simulador. Así que eso mismo es lo que vamos a hacer ahora, ejecutar esa pequeña aplicación en algún dispositivo.

Ejecutando la aplicación de ejemplo

Opción 1: PhoneGap App

La opción más rápida para ver corriendo nuestra aplicación en un dispositivo móvil es haciendo uso de PhoneGap App, uno de los servicios ofrecidos por Adobe para desarrolladores y que podremos usar gratuitamente siempre que estemos haciendo uso del cliente phonegap, no el cliente cordova.

Esta aplicación está disponible en Google Play, App Store y Windows App Store, así que la instalaremos en el dispositivo donde deseemos hacer las pruebas y tras conectarla con nuestro proyecto a través de nuestra red local podremos ver en vivo el funcionamiento de nuestra app, así como ver reflejado automáticamente cualquier cambio que realicemos en el código.

Instalamos y ejecutamos la aplicación en nuestro dispositivo y veremos nos solicitará que especifiquemos una dirección a la que conectarse

Para saber qué dirección es esa debemos ejecutar lo siguiente en nuestro equipo, dentro del directorio miApp:

$phonegap serve
[phonegap] starting app server...
[phonegap] listening on 192.168.10.12:3000
[phonegap]
[phonegap] ctrl-c to stop the server


Introducimos la dirección que se nos indica y voilà, app ejecutándose en el dispositivo. Lo chulo de esto es que mientras tengamos activo esta conexión, cualquier cambio que hagamos en el código hará que recargue la aplicación en el cliente y podamos ver los cambios de forma instantánea.

La única limitación de este esquema es que no podremos probar plugins no oficiales, ya sean plugins de la comunidad o desarrollados por nosotros, pero es un fenomenal punto de partida.

Opción 2: build local

La segunda opción que tenemos es construir localmente los binarios para instalarlos en el dispositivo o ejecutarlos en un simulador. En este caso necesitaremos tener instalados y configurados los SDK de cada plataforma con la que queramos trabajar. En este apartado explicaré los stack básicos para trabajar con Android y con iOS, al ser las plataformas más populares

Stack Android

Necesitaremos los siguientes elementos

• Instalar el SDK de Android: Personalmente recomiendo instalar Android Studio y que éste se encargue de instalar lo necesario. Toda la información en su página de documentación.
• Un dispositivo o emulador donde probar nuestra aplicación, donde tenemos 3 opciones:
  • Usar Android Virtual Device: si no tienes aprecio por tu vida y tu tiempo, puedes configurar un dispositivo virtual sobre el que ejecutar tu aplicación. Es tremendamente lento pero podremos configurar cualquier tipo de dispositivo. Si has instalado Android Studio podrás crear y arrancar emuladores desde Tools -> Android -> AVD Manager.
  • Instalar el fantabuloso Genymotion: esta plataforma de máquinas virtuales Android es realmente rápida. Podremos ejecutar cualquier máquina virtual de las que ofrecen y ser detectada por el SDK como si fuese un dispositivo físico conectado a nuestro equipo. Más información en su página web.
  • Usar un dispositivo físico: si disponemos de un móvil o tablet Android, podremos activar el modo desarrollador en él y conectarlo por USB a nuestro equipo.

Una vez configurado el SDK de Android debemos indicar que deseamos soportar dicha plataforma. Para eso ejecutamos el siguiente comando dentro de miApp:

$phonegap platform add android

Ya solo tendremos que ejecutar la aplicación en el dispositivo que deseemos. Si vamos a hacerlo sobre un AVD que hayamos creado, lo arrancamos previamente desde el AVD Manager y una vez arrancado el dispositivo virtual (después de 2 o 3 cafés) ejecutamos:

$phonegap emulate android

Si en vez de usar una instancia de AVD deseamos cargar la aplicación en una máquina virtual Genymotion previamente arrancada, o en un dispositivo android que tengamos conectado por USB, ejecutaremos esto:

$phonegap run android

Cada vez que lanzamos un ‘emulate’ o un ‘run’, internamente se realiza un ‘build’ que generará la última versión de nuestra app para la plataforma indicada, cuyo proyecto almacenará en el directorio platform/android. Siempre podremos abrir dicho proyecto desde Android Studio si algo no termina de funcionar o necesitamos depurar alguna parte nativa

Stack iOS

El SDK de iOS solo está disponible para MacX, así que necesitarás un equipo de Apple para poder hacer builds locales. Para poder crear la versión iOS de nuestra aplicación tendremos que instalar XCode desde la Mac App Store para que se instale el SDK y los simuladores.

Para que el cliente phonegap sea capaz de arrancar el simulador, es necesario que instales el paquete ios-sim vía npm:

$npm install -g ios-sim

Una vez instalado todo debemos añadir el soporte ios a nuestro proyecto:

$phonegap platform add ios

Ahora sí, podremos ejecutar la app en un simulador usando:

$phonegap run ios

Ejecutando ios-sim showdevicetypes podremos ver un listado de simuladores disponibles (iPhone5, 6, iPad, …), así que podremos indicar cual queremos

Si queremos ejecutarlo en un dispositivo físico, tendremos que poner

$phonegap run ios --device

Para esto último tendremos que habernos dado de alta en el programa de desarrolladores de Apple (99 eureles/año) y haber generado todos los certificados Apple para nuestra aplicación, pero este tema excede el alcance de este tutorial.

Opción 3: generar binario usando PhoneGap Build

PhoneGap Build es otro servicio freemium ofrecido por Adobe donde podremos compilar en la nube nuestro proyecto. Esto tiene la ventaja de no necesitar instalar ningún SDK de ninguna plataforma en nuestro equipo de desarrollo. También es una forma interesante de poder trabajar sobre iOS sin disponer de un Mac, ya que el binario realmente se generará en la nube. Ojo, seguirás necesitando darte de alta en el programa de desarrolladores de Apple, pero al menos te ahorrarás la compra del Mac.

Para usarla hay que darse de alta con un Adobe ID en https://build.phonegap.com/, donde disponen de un plan gratuito que podremos usar para empezar a probarla.

Una vez creada la cuenta, para compilar nuestro binario solo tendremos que indicar la plataforma que deseamos con el siguiente comando:

$phonegap remote build android

Cómo continuar a partir de aquí.

En este momento deberías ser capaz de encapsular cualquier aplicación web que únicamente haga uso de estándares HTML5, CSS3 y JavaScript, incluso podrás verlas funcionando sin muchas complicaciones en la aplicación PhoneGap App olvidándote de la instalación de SDKs nativos.

No hemos entrado en ningún detalle sobre la API interna de PhoneGap y cómo podríamos instalar y hacer uso de los distintos plugins que nos permitirán ir un paso más allá y hacer cosas que HTML5 y un navegador estándar no pueden hacer, como acceder a los contactos, la cámara, notificaciones push,  etc…

En breve haré una segunda parte donde explicaré todo eso pero de momento podrás continuar ampliando tu información en los siguientes enlaces:

• Hello World Explained: explicación detallada de la aplicación ejemplo que se incluye al crear el proyecto y con la que hemos estado jugando.
• Eventos: eventos propios de kernel que no dependen de ningún plugin.
• Añadir plugins: las opciones del interfaz de comandos para la gestión de plugins
• APIs de Plugins: acceso a las APIs de cada uno de los plugins oficiales con ejemplos

La entrada Introducción a PhoneGap / Apache Cordova se publicó primero en alfonsomarin.

Requisitos

Las notificaciones push no funcionan en el simulador iOS incorporado en Xcode, y por tanto necesitaremos una cuenta de desarrollador iOS para poder generar los certificados apropiados y poder probar nuestra aplicación en un terminal. Además, al tratarse de una aplicación iOS necesitaremos trabajar con un equipo Mac.

Resultado

Al final de este artículo tendremos una aplicación iOS basada en Cordova/PhoneGap capaz de recibir mensajes push y una pequeña aplicación de servidor realizada en PHP capaz de mandarlos. Ambas aplicaciones están exentas de florituras y serán extremadamente sencillas, con el código estrictamente necesario para realizar su cometido, que es enviar y recibir mensajes push.

Preparativos previos

Antes de empezar, vamos a crear una carpeta en nuestro equipo donde almacenaremos todos los elementos de este proyecto. La carpeta la llamaremos testpush y crearemos 3 directorios: certs, app y server.

En certs meteremos los certificados de Apple (ya veremos qué son y cómo se crean), en app meteremos el proyecto Cordova/PhoneGap y en server el código PHP de nuestro servidor capaz de enviar push.

Introducción a las notificaciones push en iOS

Con mucha probabilidad ya sabrás lo que son las notificaciones push, que son básicamente mensajes generados desde un servidor y que llegan a nuestro terminal sin necesidad de que el terminal esté consultando constantemente al servidor.

El primero que introdujo este concepto fue Blackberry, pero actualmente está presente en todas las plataformas y cada una aborda el problema de forma ligeramente diferente. La estrategia que sigue Apple es la siguiente:

1. La aplicación deberá indicar al sistema operativo que desea recibir notificaciones, y el sistema operativo le pedirá permiso al usuario (típica pantalla de “La aplicación X desea enviarle notificaciones”)
2. Si el usuario ha aceptado, la aplicación se registrará en los servidores de Apple APNS (Apple Push Notification Service) y obtendrá un token, el cual podemos ver como una dirección a la que se enviarán los mensajes y que identifica a la aplicación y al dispositivo sobre el que se ha instalado.
3. Nuestra aplicación le hará llegar el token al servidor (normalmente nuestro) que realizará las notificaciones push. En terminología Apple a estos servidores los llaman Providers.
4. Cada vez que el servidor desee comunicarse con ese dispositivo, hará una petición al APNS indicándole el mensaje push y el token asociado del dispositivo al que queremos enviarlo.

Fácil, ¿verdad?

Particularidades a las notificaciones push en iOS

También es conveniente saber ciertas peculiaridades de las notificaciones push en iOS:

• No son confiables: es decir, no hay ninguna garantía de que una notificación push llegue al destino, aunque el APNS haya aceptado el mensaje. El dispositivo podría estar apagado o fuera de cobertura, y el APNS lo reintentará varias veces, pero si no lo consigue lo desechará.
• Los mensajes no pueden contener más de 256 caracteres
• Aparte del mensaje, una notificación push podría indicar estas opciones:
  • sound: con qué sonido debe sonar la notificación (en caso de que el usuario haya permitido los sonidos). Si no se indica sonará con el sonido por defecto.
  • badge: el numerito que debe aparecer en el globo del icono (en caso de que el usuario haya permitido globos en los iconos)

Alta de aplicación en Apple y generación de certificados

Antes de empezar a crear la aplicación es conveniente crear todos los elementos que posteriormente se necesitarán para que funcionen las notificaciones push. Así que de momento nos toca “hacer papeleo”.

Concretamente necesitaremos que crear los siguientes elementos:

• App ID: deberemos dar de alta un ID de aplicación para que podamos asociarle el resto de elementos, además de activarle explícitamente el soporte a Push Notifications.
• Certificado Push: debemos generar un certificado específics para el servicio Push que será utilizado por nuestro servidor para comunicarse con el APNS. Este certificado irá asociados al App ID, así que únicamente servirá para mandar mensajes a esa aplicación.
• Perfil de aprovisionamiento (provisioning profile): es necesario crear un perfil asociado al App ID para que podamos configurarlo en Xcode y así poder instalar la aplicación en un dispositivo real.

Para crear todos estos elementos, entraremos en nuestra cuenta de desarrollador iOS, en la sección Certificates, Identifiers & Profiles.

Paso 1: Creación del App ID

Nos vamos a Identifiers y luego a App IDs, donde pulsando en el botón + podremos crear uno nuevo.

En el formulario de creación debemos especificar estos valores:

• App ID Description: el nombre de nuestra app. En este caso Test Push.
• Explicit App ID: el identificador único de nuestra app, normalmente especificado como dominio inverso. Yo he puesto com.alfonsomarin.testpush (tú tendrás que poner otro diferente)
• App Services: qué servicios queremos tener disponibles en nuetra app. Debemos marcar al menos Push Notifications, que es para lo que queremos la app.

Confirmamos y se generará el App ID, al cual iremos asociando los certificados y profiles

Paso 2: Generación de certificado Push

Ahora toca crear el certificado, que es uno de los pasos más pesados. Antes de continuar comentar que Apple identifica dos entornos diferenciados: desarrollo (development) y producción (production). El entorno de desarrollo nos permitirá instalar nuestra aplicación en dispositivos de pruebas mientras estemos desarrollándola, y el entorno de producción nos permitirá generar las versiones destinadas a publicación, ya sea para la App Store o instalaciones Ad Hoc.

En este tutorial vamos a generar el certificado y el perfil de desarrollo, siendo idénticos los pasos a seguir para generar los de producción.

Para crear el certificado necesitaremos generar un fichero llamado Certificate Signing Request (CSR), el cual nos pedirá Apple para poder generar los certificados. A grosso modo y sin entrar en detalles de funcionamiento, los certificados Apple están basados en clave pública y clave privada, y el CSR realmente contiene la clave privada con la que Apple generará el certificado público, por eso debemos proporcionarlo nosotros.

Para crear el CRS debemos hacer lo siguiente:

1. Abrir el programa Acceso a llaveros
2. En el menú superior, seleccionamos Acceso a llaveros → Asistente para Certificados → Solicitar un certificado de una autoridad de certificación…
3. Indicamos los siguientes valores:
   1. Dirección de correo del usuario: ponemos cualquier dirección de correo
   2. Common Name: ponemos Test Push. Podemos poner cualqueir cosa pero poner el nombre de la app nos ayudará a localizar posteriormente la clave privada.
   3. Seleccionamos “Se guarda en el disco”, y pulsamos Continuar

Nos pedirá que guardemos la clave en algún sitio de nuestro disco duro. La guardaremos como TestPush.certSigningRequest en el directorio certs de nuestro proyecto.

Antes de salir del programa Acceso a llaveros, exportaremos la clave que acabamos de generar a un fichero .p12 que posteriormente también necesitaremos. Para ello nos vamos a la sección “Claves” y al final aparecerán el par de claves (pública y privada) que acabamos de crear. Pinchamos en la clave privada con el botón derecho y seleccionamos Exportar “Test Push”. Lo guardaremos como TestPush.p12 también en el directorio certs de nuestro proyecto, y nos pedirá un password con el que cifrar el fichero. Es importante recordar ese password pues posteriormente lo necesitaremos.

Ahora sí que podemos crear el certificado Push. En el panel de desarrollador de Apple nos vamos a Certificates y en All pulsamos el botón + para empezar con la creación:

1. Seleccionamos Apple Push Notification service SSL (Sandbox), de la sección Development. Si quisiésemos generar los de producción tendríamos que seleccionar Apple Push Notification service SSL (Production) de la sección Production.
2. En el siguiente paso seleccionamos el App ID que acabamos de crear
3. Ahora nos pide que subamos el CSR, el cual encontraremos en el directorio certs de nuestro proyecto
4. Una vez subido el CSR se generará el certificado, que debemos descargar y guardar en el directorio certs. Lo guardaremos como testpush_aps_development.cer

Al llegar a este punto deberías tener 3 ficheros en el directorio certs:

• El fichero CSR
• La clave privada en formato .p12
• El certificado SSL generado por Apple en formato .cer

De momento el fichero CSR ya no lo necesitaremos más, pero es conveniente que lo guardemos para poder utilizarlo de nuevo cuando tengamos que renovar el certificado SSL (expiran cada año), ya que así no tendremos que generar una nueva clave y podremos reutilizar el mismo fichero .p12 ya generado. Además, también podremos utilizarlo para solicitar el certificado de producción.

A la hora de trabajar con certificados en PHP es más cómodo trabajar con un único fichero en formato PEM que contenga tanto la clave privada como el certificado. Vamos a crear ese fichero .pem con los siguientes comandos (ejecutados desde el directorio certs de nuestro proyecto):

$ openssl x509 -in testpush_aps_development.cer -inform der -out TestPushCert.pem
$ openssl pkcs12 -nocerts -out TestPushKey.pem -in TestPush.p12

(introducir la contraseña que pusimos cuando creamos el fichero .p12, y pedirá una nueva para el fichero .pem. Yo he utilizado otra vez testpush)

$ cat TestPushKey.pem TestPushCert.pem > TestPushCK.pem

Y por fin hemos terminado con los certificados. Esto nos generará el fichero combinado TestPushCK.pem, que junto a la contraseña que hemos usado es lo que tendrá que utilizar nuestro servidor para enviar notificacioens push.

Paso 3: Creación de Provisioning Profile

Ya solo queda crear el perfil de aprovisionamiento para poder firmar nuestra app en Xcode. En el panel de desarrollador de Apple nos vamos a Provisioning Profiles y en All pulsamos el botón + para empezar con la creación:

• Seleccionamos iOS App Development: recordemos que estamos en desarrollo. También podríamos seleccionar para distribución en AppStore o AdHoc.
• Seleccionamos el App ID generado en el paso 1.
• Seleccionamos el certificado de desarrollador que incorporará el perfil
• Seleccionamos los dispositivos sobre los que podremos instalar la aplicación. Aquí ya deberías tener los tuyos dados de alta, pero si no es así tendrás que hacerlo previamente desde Devices → All.
• Por último, indicamos un nombre descriptivo para el profile. Le ponemos TestPushDev (a mi me gusta poner sufijos Dev, AdHoc o AppStore según sea el tipo de perfil que estoy creando).

Una vez generado podremos descargarlo y a través del Finder arrastrarlo al icono de Xcode para instalarlo, pero si tenemos configurada nuestra cuenta de desarrollador en Xcode podremos sincronizarla con el portal y el perfil se descargará automáticamente. Podemos sincronizar desde el menú Xcode → Preferences → Accounts → View Details (pulsar icono de sincronización).

Creación de la aplicación Cordova/PhoneGap para iOS

Ha llegado el momento de crear nuestra aplicación. El cometido de la misma será únicamente obtener el token proporcionado por el APNS tras el registro y mostrarlo por pantalla. En una aplicación real lo que debería hacer es enviarlo al servidor y que este lo almacenase de alguna forma (en base de datos, por ejemplo), pero por simplificar símplemente lo mostrará por pantalla para que podamos copiarlo y meterlo manualmente en una variable del servidor. Así simplificaremos el código de ambas aplicaciones evitando tener que implementar funcionalidades complementarias que no están directamente relacionadas con el proceso de notificaciones push.

Paso 1: creacion del proyeto

Para crear el proyecto Cordova/PhoneGap haremos uso del cliente cordova, que ya deberías tener instalado. Para ello abrimos un terminal, nos situamos dentro del directorio app de nuestro proyecto y escribimos:

$ cordova create . com.alfonsomarin.testpush TestPush

Añadimos la plataforma ios al proyecto

$ cordova platform add ios

Paso 2: Instalación del plugin de notificaciones Push

Cordova no ofrece un plugin oficial para soporte de notificaciones push, así que tendremos que hacer uso de algún plugin de terceros. El que voy a utilizar es PushPlugin debido a su popularidad y por ser uno de los más completos, estables y mejor mantenidos por el momento. De hecho, aparte de iOS y Android ofrece soporte a Windows Phone 8, Windows8 y Amazon Fire OS, lo cual es muy interesante en vistas a futuras adaptaciones de nuestra aplicación a dichas plataformas.

Por tanto, el siguiente paso es instalar dicho plugin:

$ cordova plugin add https://github.com/phonegap-build/PushPlugin.git

Paso 3: Inclusión del código de registro de nuestra aplicación

Como ya sabemos lo primero que debe hacer nuestra aplicación es indicar al sistema operativo que deseamos recibir notificaciones, para que este le pida permiso al usuario y así poder obtener nuestro token.

El plugin ofrece esta funcionalidad a través de la llamada register(tokenHandler, errorHandler, options), cuyos parámetros tienen el siguiente significado:

• tokenHandler: función que recibirá el token. Esta función sería la encargada de registralo en el servidor, pero como hemos comentado, por simplicidad únicamente mostrará el token por pantalla.
• errorHandler: si ha habido algún error, el plugin invocará esta función
• options: un hash donde indicaremos los siguientes valores:
  • badge: para indicarle al APNS si nuestra aplicación hará uso de globos en los iconos
  • sound: para indicarle al APNS si nuestra aplicación especificará el sonido a emitir en las notificaciones
  • alert: para indicarle al APNS si los mensajes contendrán algo de texto o no.
  • ecb: función callback que será invocada por el plugin cada vez que se reciba una notificación.

Sabiendo esto podremos entender mejor el código que vamos a meter a continuación. Este código lo meteremos en el propio fichero www/js/index.js generado en el proyecto base de Cordova/PhoneGap, el cual ya se encarga de gestionar la recepción del evento inicial ondeviceready, que es el que nos indica que podemos hacer uso de los plugins.

Así que editamos este fichero y al final de la función onDeviceReady incluímos este código

window.plugins.pushNotification.register(
    function(token){
        alert(token);
    },
    function(){alert(‘Error al registrarse en el servidor APNS’);},
    {
        "badge":"true",
        "sound": "true",
        "alert": "true",
        "ecb": "onNotificationAPN"
    });

Vemos que hemos definido tokenHandler y errorHandler como funciones inline, hemos especificado que queremos activar todas las opciones y por último hemos indicado que nuestra función para recibir las notificaciones push será onNotificationAPN.

Ahora solo nos queda incluir la función onNotificationAPN, que la incluiremos fuera del objeto app en el propio index.js:

function onNotificationAPN (event) {
    if (event.alert) {
       alert(event.alert);
    }

    if (event.sound) {
        var snd = new Media(event.sound);
        snd.play();
    }

    if (event.badge) {
        window.plugins.pushNotification.setApplicationIconBadgeNumber(function(){}, function(){}, event.badge);
    }
}

La implementación es bastante sencilla. Si la notificación push incluye un mensaje, lo mostramos en una pantalla de alerta. Si incluye un sonido, lo reproducimos con un objeto Media (necesitaríamos instalar el plugin org.apache.cordova.media). Y por último, si incluye un número a establecer como globo en el icono, lo hacemos con setApplicationIconBadgeNumber, otra función ofrecida por el plugin.

Paso 4: Compilación y ejecución

Ahora debemos compilar la aplicación para generar el proyecto Xcode

$ cordova build ios
$ open platforms/ios/TestPush.xcodeproj

Una vez dentro de Xcode, debemos hacer unos ajustes antes de poder ejecutar la aplicación en nuestro dispositivo iOS. Tendremos que ajustar en el proyecto el perfil de aprovisionamiento (provisioning profile) que creamos anteriormente. Este ya deberías tenerlo instalado en xcode si lo descargaste y arrastraste el fichero al icono de Xcode, o si sincronizaste tu cuenta a través de las preferencias como te comenté.

En el panel Project Navigator seleccionamos nuestro proyecto y nos vamos a la pestaña Build Settings, donde buscaremos la sección Code Signing. En dicha sección buscaremos la opción Provisioning Profile, donde seleccionaremos el perfil TestPushDev.

Ahora ya podremos enchufar el dispositivo iOS a nuestro Mac y ejecutar la aplicación. Veremos que al arrancar lo primero que hace es pedirnos permiso para enviarnos notificaciones, que es lo que esperábamos. Si aceptamos, a los segundos nos aparecerá la alerta mostrándonos nuestro token.

En sucesivas ejecuciones de la aplicación nos aparecerá el token directamente, pues el permiso solo la primera vez.

Desarrollo de la aplicación servidor (provider)

Ahora vamos a hacer un pequeño script en PHP que será capaz de enviar mensajes Push a nuestra aplicación. Este script representaría al servidor, y es un poco “tosco” pues como veremos le meteremos el token a mano, pero como ya hemos comentado lo haremos así por simplicidad y para centrarnos en el proceso de mensajería push.

Dentro del directorio server de nuestro proyecto, crearemos un script llamado server.php con el siguiente contenido:

// Nuestro token
$deviceToken = '4a9988acca4d63f7434279de17290eab37fd4006d57d66879d4c743937db958c';

// El password del fichero .pem
$passphrase = 'testpush';

// El mensaje push
$message = '¡Mi primer mensaje Push!';

$ctx = stream_context_create();
//Especificamos la ruta al certificado .pem que hemos creado
stream_context_set_option($ctx, 'ssl', 'local_cert', '../certs/TestPushCK.pem');
stream_context_set_option($ctx, 'ssl', 'passphrase', $passphrase);

// Abrimos conexión con APNS
$fp = stream_socket_client(
	'ssl://gateway.sandbox.push.apple.com:2195', $err,
	$errstr, 60, STREAM_CLIENT_CONNECT|STREAM_CLIENT_PERSISTENT, $ctx);

if (!$fp) {
	exit("Error de conexión: $err $errstr" . PHP_EOL);
}

echo 'Conectado al APNS' . PHP_EOL;

// Creamos el payload
$body['aps'] = array(
	'alert' => $message,
	'sound' => 'bingbong.aiff',
	'badge' => 35
	);

// Lo codificamos a json
$payload = json_encode($body);

// Construimos el mensaje binario
$msg = chr(0) . pack('n', 32) . pack('H*', $deviceToken) . pack('n', strlen($payload)) . $payload;

// Lo enviamos
$result = fwrite($fp, $msg, strlen($msg));

if (!$result) {
	echo 'Mensaje no enviado' . PHP_EOL;
} else { 
	echo 'Mensaje enviado correctamente' . PHP_EOL;
}

// cerramos la conexión
fclose($fp);

Tendrás que cambiar el token por el que te haya dado a tí el APNS (una forma rápida de copiarlo es abriendo en el Mac en navegador Safari mientras se ejecuta la aplicación y abrir la consola de desarrollo remota a través del menú Desarrollo → <nombre de tu iDispositivo> → index.html, y poniendo window.testPush abajo).

También te podrás fijar que hemos puesto como badge un número alto (35), para comprobar que efectivamente se establece como globo en el icono.

Ahora ya solo tenemos que ejecutar el script y ver cómo llega nuestro mensaje. En el terminal, dentro del directorio server, escribimos:

$ php server.php

Si hemos seguido todos los pasos indicados en este tutorial deberías ver el mensaje en tu terminal:

Referencias y enlaces de interés

• Código fuente del proyecto
• Apple Push Notification Services in iOS 6
• PushPlugin

La entrada Notificaciones Push en iOS con PhoneGap / Cordova se publicó primero en alfonsomarin.

Este estándar fue adoptado por la mayoría de navegadores prácticamente desde el mismo momento en que se hizo público el documento de especificación del W3C allá por 2009, así que lo encontraremos en prácticamente cualquier navegador, y con seguridad en cualquier navegador moderno de escritorio o móvil.

El acceso a este almacenamiento se realiza a través del objeto localStorage, así que una forma de saber si disponemos de él sería haciendo lo siguiente:

function supports_html5_storage() {
  try {
    return 'localStorage' in window && window['localStorage'] !== null;
  } catch (e) {
    return false;
  }
}

Sin embargo, como digo es difícil encontrar a día de hoy un navegador que no lo soporte.

Uso de localStorage

Como he comentado, se trata de un almacenamiento de tipo llave/valor, pudiendo asociar a un string (llave) un determinado valor. Este valor puede ser de cualquier tipo básico soportado por javascript, a saber: string, integer, boolean y float.

A continuación se muestra cómo podemos guardar y recuperar un valor a través del objeto localStorage:

//Guardar un valor
localStorage.setItem('hola', 'Mundo');
//Recuperar un valor
var v = localStorage.getItem('hola');
//Borramos el valor
localStorage.removeItem('hola’);

También podemos trabajar con el objeto localStorage como si un objeto stándard de javascript se tratase:

localStorage.hola = 'Mundo';
var v = localStorage['hola’];
delete localStorage.hola;

localStorage también proporciona la variable length por la que podremos saber el número de objetos guardados hasta el momento. Sabiendo el número total de objetos también podremos acceder a las llaves definidas hasta el momento con la función key(), a la que tendremos que pasar un valor numérico entre 0 y length-1. Ejemplo:

localStorage.hola = 'Mundo';
console.log(localStorage.length); // salida: 1
console.log(localStorage.key(0)); // salida: “hola”

Por último, si necesitamos limpiar completamente toda la información almacenada podremos hacer uso de la función localStorage.clear().

Formato de almacenamiento

Aunque podemos guardar cualquier valor de tipo básico de javascript como string, boolean, integer o float, el estándar determina que la información siempre se almacenará como string, así que habrá que tenerlo en cuenta a la hora de recuperar información utilizando parseInt() o parseFloat() según sea el tipo original del valor.

localStorage.numero = 45;
console.log(localStorage.numero); //salida: “45”
localStorage.real = 3.1416;
console.log(localStorage.real); //salida: “3.1416”

Esta peculiaridad es especialmente frustrante con los booleanos. Por ejemplo:

localStorage.falso = false;
if (localStorage.falso){
console.log(‘pues no es falso, es verdadero’);
}

Hay que tener cuidado con eso.

Limitación de espacio y chequeo

La especificación del W3C respecto a este estándar recomienda un máximo de 5MB para este tipo de almacenamiento por origen (por dominio), cantidad que ha sido bastante respetada por las implementaciones llevadas a cabo por los navegadores. Una vez que se alcance dicha cuota se emitirá una excepción de tipo “QUOTA_EXCEEDED_ERR”.

Aunque no hay un método estándar para saber el tamaño actual ocupado por localStorage, dado que sabemos que todos los datos se almacenan como strings podemos hacer la siguiente aproximación:

var localStorageSpace = function(){
  var allStrings = '';
  for(var key in window.localStorage){
    if(window.localStorage.hasOwnProperty(key)){
      allStrings += window.localStorage[key];
    }
  }
  return allStrings ? ((allStrings.length*16)/(8*1024)) + ' KB' : 'Empty (0 KB)';
};

Su hermano sessionStorage

Similar al objeto localStorage, podremos encontrar otro objeto llamado sessionStorage, cuya persistencia únicamente se garantiza mientras la página esté activa, es decir, mientras no cerremos la pestaña de navegación o el navegador. Ideal para hacer uso de caches

Uso actual de localStorage

localStorage se ha convertido en una herramienta esencial en numerosas aplicaciones web, si bien su uso se convierte en esencial en aplicaciones web móviles encapsuladas con Apache Córdova (PhoneGap), donde muchas de ellas no necesitan grandes necesidades de almecenamiento pero sí hacer persistentes ciertas preferencias de usuario, o cachear alguna información para uso en modo offline. Gracias a localStorage no es necesario recurrir a plugins extras cuando las necesidades de almacenamiento no son excesivas.

Eventos

También podemos detectar modificaciones en localStorage ya que cada vez que ejecutamos funciones como setItem, removeItem o clear, se dispara el evento ‘storage’, pudiendo establecer un listener sobre este:

window.addEventListener(“storage”, function(e){
// Internet Exprorer
if (!e) { e = window.event; }
}, false);

La función que asociemos al evento recibirá un parámetro de tipo StorageEvent donde se nos indicará la key modificada, el valor antiguo, el nuevo y la url que propició el cambio.

Depuración

Según el navegador que utilicemos podremos consultar visualmente el contenido almacenado en localStorage. Algunos navegadores incorporan estos visualizadores en sus herramientas para desarrolladores, como es el caso de Chrome y Safari (Recursos -> Almacenamiento local). Otros como firefox de momento necesitan hacerlo a través de una extensión.

La entrada APIs HTML5: localStorage se publicó primero en alfonsomarin.

El curso sigue centrado en las tecnologías Sencha Touch, PhoneGap (ahora Apache Cordova) y Appcelerator Titanium. He actualizado los contenidos a las últimas versiones de cada librería incluyendo algunas novedades que incorporan éstas, y voy a incluir una aplicación completa desarrollada con cada framework, contenido que venía siendo demandado por los alumnos en otras ediciones del curso.

Te recuerdo que el curso es 100% online y cualquiera puede matricularse, seas alumno de la Universidad de Murcia o no, aunque si eres alumno tendrás la ventaja de la convalidación de créditos.

A continuación os pongo la información que suelo distribuir a través de las listas de correo de la universidad, aunque podéis ampliar información en la página web específica que tengo montada para el curso: Curso de desarrollo de aplicaciones móviles multiplataforma con tecnologías web.

¿De qué trata el curso?

Gracias a las tecnologías web modernas y a su alto grado de adopción en plataformas como iOS y Android, es posible crear aplicaciones nativas haciendo uso de nuestros conocimientos en desarrollo web, sin necesidad de aprender los lenguajes de programación nativos de cada una de estas plataformas. En el curso veremos distintas tecnologías y frameworks que nos permitirán crear aplicaciones haciendo uso de HTML5, CSS3 y JavaScript.

¿A quien va destinado?

Este curso va destinado a todo aquel que tenga unos conocimientos mínimos en programación web y que conozca a nivel básico el lenguaje de programación JavaScript. La idea es reutilizar esos conocimientos para poder aplicarlos al desarrollo de aplicaciones móviles.

¿Qué plataformas se verán en el curso?

En el curso prestaremos especial atención a las plataformas Android e iOS, aunque las tecnologías utilizadas soportan otras plataformas como BlackBerry o Windows Phone.

Contenidos del curso

• TEMA 1 – Introducción a la programación móvil multiplataforma. Análisis del contexto actual en el mundo del desarrollo móvil y repaso de las mejoras aportadas por los estándares HTML5 y CSS3
• TEMA 2 – Entorno de desarrollo para iPhone y Android. Primeros pasos. Preparación del entorno de desarrollo e instalación del software necesario.
• TEMA 3 – Interfaces de usuario HTML y JavaScript. Análisis en profundidad del framework Sencha Touch 2. Veremos cómo podemos crear aplicaciones móviles destinadas a ser ejecutadas en un navegador móvil o encapsuladas en una aplicación nativa.
• TEMA 4 – Acceso a funcionalidades nativas con PhoneGap. Explicación del funcionamiento de la librería PhoneGap, la cual nos permite encapsular nuestras aplicaciones web y así poder acceder a funcionalidades nativas del dispositivo que no están disponibles en los navegadores móviles.
• TEMA 5 – Aplicaciones nativas con Appcelerator Titanium ( 1.00 ects). Explicación del funcionamiento del framework Appcelerator Titanium, mediante el cual podremos crear aplicaciones 100% nativas mediante el uso de JavaScript.
• TEMA 6 – Actividad final con PhoneGap. Desarrollo de una aplicación móvil elegida por el alumno haciendo uso de Sencha Touch y PhoneGap. La aplicación se utilizará para evaluar la superación del curso por parte del alumno
• TEMA 7 – Actividad final con Titanium. Desarrollo de una aplicación móvil elegida por el alumno haciendo uso de Appcelerator Titanium. La aplicación se utilizará para evaluar la superación del curso por parte del alumno

Metodología

El curso se desarrollará de forma ONLINE donde se proporcionará todo el material didáctico necesario. Además, existirá una máquina virtual alojada en el servicio EVA con todo el software necesario lista para ser utilizada en el curso (solo disponible si cuentas con un correo @um.es).

Percio

– 100€ (para UM y no UM).

Fechas

– Plazo de Matrícula: del 1 de Septiembre al 27 de Octubre de 2014
– Plazo de solicitud de beca: del 1 de Septiembre al 27 de Octubre de 2014
– Plazo de realización: del 3 de Noviembre al 22 de Diciembre de 2014

La entrada V Curso de desarrollo de aplicaciones móviles multiplataforma con Tecnologías Web en Universidad de Murcia se publicó primero en alfonsomarin.

Ya que el proyecto va a estar encapsulado con Cordova, se me ocurrió que esos JSON podrían ir a disco y guardarlos en el sistema de ficheros nativo del dispositivo donde no encontraríamos limitaciones de espacio gracias a la APIs fileSystem de HTML5 implementada por el plugin File de Cordova. Aunque parece ser que las APIs de acceso a fileSystem no van a seguir desarrollándose, es previsible que Cordova mantenga su implementación debido al gran valor aportado como método estándar de acceso al sistema de ficheros nativo.

Se trataría pues de implementar una interfaz similiar a localStorage para gestionar valores de tipo clave: valor,  donde valor sería de tipo texto y lo almacenaríamos en un fichero haciendo uso de clave para nombrarlo. Sin embargo, no podrá ser 100% similar debido a que los procesos de gestión de ficheros son asíncronos, así que necesitaremos incluir funciones callback, una para cuando la operación se realice con éxito, y otra para ejecutar en caso de error.

Ya puestos, como el desarrollo lo suelo realizar bajo Chrome, se incluyen las operaciones necesarias para que funcione también en este navegador. La principal diferencia radica en que mientras el plugin de Cordova no imponen ninguna cuota, Chrome sí la tiene. En Chrome podremos ver qué ficheros se han creado anteponiendo filesystem:// a la URL donde estemos ejecutando nuestra aplicación (ej: filesystem://http://localhost)

Aquí os dejo un guist con el cóidigo que he utilizado.

[gist id=»c3929e79dcf22bb41efa» file=»fileStorage.js»]

[gist id=»c3929e79dcf22bb41efa» file=»ejemplos_de_uso.js»]

La entrada Uso de API HTML5 fileSystem para cachear datos en Cordova/Phonegap o Chrome se publicó primero en alfonsomarin.

• Desarrollo de aplicaciones móviles (I): así está el mercado: destripan algunos informes sobre estadísticas en torno a las distintas plataformas móviles.
• Desarrollo de aplicaciones móviles (II): ¿Para qué plataformas móviles desarrollar y para cuál primero?: Recolección de opiniones de varios expertos sobre el estado de cada plataforma y recomendaciones sobre desarrollo y monetización de aplicaciones.

Me han parecido tremendamente interesantes y recomiendo su lectura, donde personalmente destaco los siguientes puntos:

Primera parte:

• La industria generó 68000 millones de dólares en 2013 y se estiman unos 146000 millones en 2016
• Android e iOS se reparten el 94% de las ventas siendo claramente las dos principales plataformas, y se espera que sea así durante los próximos 3 años
• Un 71% de desarrolladores móviles lo hacen para Android, y un 55% para iOS, con que parte de los desarrolladores lo hacen en ambas plataformas.
• En sudamérica es donde más apuestan por el desarrollo HTML5, donde el 64% lo hace en esta plataforma.
• La principal vía de monetización es el desarrollo por encargo, de donde provienen el 56% de los ingresos en el sector
• La segunda vía de monteización sigue siendo la publicidad con un 26% provocado por plataformas en la que la demanda por compras directas es dévil, como Windows Phone o Android
• para la mayoría de desarrolladores la pregunta clave no es qué es cuál de las dos plataformas tener como prioritaria
• Windows Phone está cogiendo fuerza poco a poco, donde un 26% de desarrolladores tienen a esta plataforma como objetivo
• El 72% de desarrolladores tiene a los smartphones como principal plataforma, y solo el 12% tiene como prioridad el desarrollo para tablet

Segunda Parte:

Expertos consultados:

• Jose María Carceles:
• Jorge del Casar: @JorgeCasar
• Julio Rivas: @juliorimo
• Marcos Trujillo: @Aracem
• Jorge Barroso: @flipper83

@Aracem: Ahora mismo no compensa trabajar para otras plataformas que no sean éstas dos [iOS y Android] porque no hay mercado suficiente para rentar los desarrollos. Luego cada plataforma tiene sus ventajas e inconvenientes pero al final el esfuerzo es más o menos el mismo.

@juliorimo: En la parte de iOS consideramos que no merece la pena hacer proyectos nuevos para una versión de iOS inferior a la 7.0 ya que con esto alcanzamos más de un 80% del mercado. En el caso de las librerías publicitarias si es algo distinto ya abarcamos desde iOS 5.0 para tener casi el 100% del mercado soportado.

@flipper83: si tu app es muy bonita, pero se rompe cada 2 por 3 o va lenta al final es también parte de la experiencia de usuario. Personalmente para mi todo es igual de importante, tanto que funcione perfectamente como que sea usable.

@Aracem: La fase de diseño de la aplicación es una de las más importantes en el ciclo de vida del proyecto. En mi opinión entre el diseño de la aplicación y la suerte se llevan un 70% del porcenjate de éxito. El resto se reparten entre las funcionalidades de la aplicación y el marketing

@JorgeCasar: Creemos que son 2 valores muy importantes para el éxito de una app o juego. En nuestros juegos creamos niveles de aprendizaje para evitar grandes cantidades de texto y que la experiencia de usuario sea la mejor desde el segundo cero. Además pasamos por diversas auditorías para conseguir certificaciones de marcas importantes.

Jose María Cárceles: Desarrollar apps para tablets android es difícil por la segmentación tan brutal que tiene en cuanto a diferentes dispositivos con diferentes tamaños de pantalla, ya que a veces no sabemos si un dispositivo es un teléfono, es un tablet, o es un híbrido entre ambos. En el caso de Apple, está muy claro, en el market sabes muy intuitivamente qué aplicaciones son para teléfono, y que aplicaciones son para tablets

 @flipper83: es especialmente molesto no poder compartir código entre esas plataformas y terminas programando varias veces el core de tu aplicación

@Aracem: Las aplicaciones hechas con HTML5 pueden ser el futuro aunque aún tiene sus peros. La ventaja de “desarrolla una vez y funciona en todos los sitios” es tremendamente atractiva aunque la tecnología, en mi opinión, aún no está lista

@Aracem: La moda ahora son los pagos in-app. Aplicaciones gratuitas que se pueden mejorar o expandir mediante micropagos. Es un sistema que funciona muy bien puesto que es más fácil convencer a los usuarios para que paguen por algún contenido adicional cuando ya conocen tu app, la usan e incluso puede que la consideren imprescindible que simplemente viéndola en la tienda de aplicaciones. En ese momento es difícil convencer que esa app que tienen ahí les va a ser lo suficientemente útil como para pagar 1 euro.

@flipper83: El modelo in-app purchase es un modelo de negocio válido, que en algún momento explotará pero no para desaparecer sino para coexistir con los ya existentes. Creo que el problema va a ser el coste por usuario, para que la gente entre en tu juego tienes que dejarte una pasta en publicidad que luego tienes que recuperar, cuanta mayor competencia exista, este coste por usuario crecerá y habrá un momento que sea insostenible para las medianas y pequeñas empresas de desarrollo.

Jose María Cáceres: Creo que ahora mismo hay una gran componente de suerte, a la hora de tener éxito, ya que existen cientos de miles de aplicaciones, y probablemente exista algo similar a lo que tu estás haciendo. La clave es mejorar lo que ya hay, que aporte valor a los usuarios, que tenga un gran diseño, que permita crear comunidad, y que hagas un esfuerzo importante en la promoción y marketing.

La entrada Estado del desarrollo móvil en 2014 se publicó primero en alfonsomarin.