Mostrando entradas con la etiqueta Android. Mostrar todas las entradas
Mostrando entradas con la etiqueta Android. Mostrar todas las entradas

jueves, 30 de enero de 2014

¿Cómo migrar una aplicación de Firefox OS a Android con Netbeans?

Este es un tutorial para desarrolladores Web que han comenzado sus andares en el desarrollo de aplicaciones móviles haciendo su primera app para Firefox OS y ahora quieren dar el salto a Android, sin necesidad de programar en Java, ni utilizar Eclipse.

Atención: Esto es un borrador, de modo que aún está en proceso de organización y escritura. Por favor, deja cualquier sugerencia en la sección de comentarios. 

El proceso en resumen


  1. Instalar Node.js
  2. Instalar Cordova
  3. Instalar Git
  4. Instalar SDK de Android
  5. Configurar Netbeans
  6. Crear proyecto HTML5 con Cordova
  7. Importar código de aplicación de Firefox OS existente
  8. Ejecutar aplicación en Android

El proceso en detalle










































martes, 19 de marzo de 2013

Android vs BlackBerry: el primero rápido y el segundo lento... si de publicar se trata.

No, no voy a hablar de los sistemas operativos, o de cuán rápido se desarrolla para una plataforma o para otra. Tampoco voy a comparar dispositivos Android vs BlackBerry. No, aquí hablaremos del market y del tiempo que toma desde que envías una aplicación para su publicación hasta que te la publican.

TrafficBB
En un post anterior contaba que un grupo de amigos nos unimos en un equipo y participamos en el hackaton de BlackBerry en Madrid de diciembre del 2012. Como resultado de esta colaboración, creamos una pequeña aplicación móvil para estudiar las señales del tránsito.

Un mes más tarde, aprovechando una jornada de fin de semana, en el port-a-thon organizado por BlackBerry para publicar aplicaciones a su market, retocamos la aplicación y, el día 20 de enero, justo antes de la media noche y de que cerrara el plazo, enviamos nuestra aplicación para su publicación en el AppWorld.

Han pasado 2 meses desde entonces y, sin embargo, nuestra aplicación sigue "Under Review" en el panel de administración del portal para vendedores de aplicaciones de BlackBerry. Dos largos meses, en los que publicamos la misma aplicación en el market de Google, la retocamos, la volvimos a publicar, y repetimos el proceso otra vez.

Entonces: en 2 meses con BlackBerry solo hemos confirmado que nuestra aplicación sigue a la espera de ser aprobada... ¡o rechazada! Mientras, con Google, no solo publicamos la aplicación, sino que la actualizamos en dos ocasiones y, luego de dos meses, ha sido descargada casi 500 veces, con lo que ya tenemos algunas estadísticas y alguna que otra crítica o sugerencia de usuarios en los que podremos basarnos para seguir mejorándola.

Estadísticas de instalaciones totales de TrafficBB y distribución por versiones de Android (2013-03-18).

Entonces, está claro que en el market de Android es bastante rápido publicar una aplicación (cuestión de horas) y -al menos de momento- publicar en el market de BlackBerry es bastante lento (cuestión de días, semanas o meses).

Tanta diferencia no es gratuita: es muy probable que cuando BlackBerry apruebe una aplicación para su publicación ésta tenga mucho mejor acabado y calidad que cuando la aprueba Google. Sin embargo, a la larga, eso no importa tanto, porque el proceso de publicación en Google Play es tan ágil, que el publicador tiene la oportunidad de corregir y mejorar la aplicación mucho más rápido. (¡Incluso varias veces en el día!)

De modo que, en un mismo lapso de tiempo una aplicación publicada en Google Play podría adquirir el mismo nivel e, incluso, superar el nivel de calidad de la misma aplicación que pasa por un proceso de inspección más riguroso, pero más lento, en el AppWorld de BlackBerry.

La pregunta entonces es: ¿Le conviene a BlackBerry extenderse tanto en el control de calidad de las aplicaciones que se envían a su market?

Yo creo que no.

Comprendo las buenas intenciones de BlackBerry, cuidando la calidad de las aplicaciones publicadas, pero el proceso que aplican es lento y, como consecuencia, están provocando que se publiquen aplicaciones más "cuidadas" pero "viejas", al compararlas con las plataformas de la competencia.

Nuestra pequeña y tremendamente simple aplicación es una muestra de ello: para cuando BlackBerry apruebe la publicación de nuestra primera versión, en el Google Play ya estaremos por la actualización 3 o 4 que tendrá nuevas funcionalidades y bastantes mejoras, comparada con su "equivalente" de BlackBerry.

BlackBerry me gusta, me gusta la diversidad y, ciertamente, deseo que la nueva plataforma despegue, pero necesitarán dejar atrás cualquier cosa que les lastre y les ralentice sus procesos de captación de aplicaciones. Hasta ahora lo han hecho muy bien y han logrado captar la atención de los desarrolladores: ahora tienen que mantenerla y, para ello, necesitan publicar lo que se está haciendo... y esto, cuanto antes mejor.

jueves, 20 de diciembre de 2012

Hackaton en BlackBerry Jam Session Madrid

El sábado 15 estuve en el hackathon que organizó RIM en Madrid para cerrar el tour de los BlackBerry Jam Sessions 2012 por España. Fue una jornada intensa al final de la cual nuestro equipo logró terminar la aplicación y ponerla a funcionar en un BlackBerry 10 Dev Alfa.

Nuestro equipo, en el hackathon del BlackBerry Jam Session en Madrid

El equipo


Teniendo en cuenta que el margen de tiempo para desarrollar la aplicación era de 10 horas, habría sido más simple que cada uno intentara hacer algo sencillo de forma individual o en parejas; pero decidimos ir en equipo e intentar hacer un sistema entre todos, a pesar de la complejidad añadida. De modo que nos apuntamos cinco personas: cuatro para el desarrollo y una para el diseño.

Debido a que el grupo era muy heterogéneo, con diferentes grados de experiencia en el desarrollo móvil, terminamos repartiéndonos las áreas de trabajo y entonces, dentro de estas, cada uno asumiría a su ritmo las tareas que más cómodas le resultaran.

La planificación


El martes, por la noche, dedicamos una hora a decidir qué producto haríamos, la tecnología de desarrollo, el sistema de control de código fuente, nomenclatura para los identificadores y el sistema de trabajo. Luego de analizarlo, acordamos que usaríamos Java con el Runtime de Android, como plataforma de desarrollo y SVN, como sistema de control de código fuente.

Al terminar, concertamos un experimento para el jueves en el que haríamos uso de las herramientas, creando un proyecto simple que se hospedaría en el hosting de SVN, al que cada uno debería integrarle un layout  vacío, con su respectiva activy, de modo que todos verificáramos que nuestros entornos estaban preparados para trabajar en equipo.

El jueves, entre las distintas versiones del SDK, las distintas versiones de Eclipse y las distintas formas de trabajar con el SVN, lo que parecía que iba a ser corto, terminó siendo una jornada nocturna de varias horas, porque comenzamos a descubrir varios detalles que, de no haberlos tratado ese día, nos habrían arruinado el hackathon. No obstante, al final del ensayo, terminamos todos con nuestros entornos a punto para el maratón de programación del sábado.

El hackathon


El sábado nos reunimos en las instalaciones de garAJE y a las 10, luego de una pequeña introducción de 30 minutos, ya estábamos comenzando nuestro producto.

Lo primero fue crear un proyecto nuevo de Android, con las 6 activities y los layouts que llevaría la aplicación para partir de una base común de estructura y nombres. Luego, creamos un proyecto en Google Code y subimos el proyecto de Android. Acto seguido, coordinamos con qué se pondría a trabajar cada cuál y nos pusimos con ello.

La jornada fue intensa. No paramos hasta que llegó la hora de las pizzas; no obstante, la pausa fue corta: comer, beber y volver al trabajo. Y no es que 10 horas sean mucho, pero si era mucho el estrés de saber que en esas 10 horas debías empezar y terminar un proyecto en el que debían coordinarse 5 personas que antes de esa semana no habían trabajado nunca juntas.

Durante el desarrollo utilizamos móviles con Android para depurar la aplicación, pero para las 7 PM ya había llegado la hora de reempaquetar y firmar la aplicación para probarla en el BlackBerry 10 Dev Alfa que me habían obsequiado en un evento anterior de BlackBerry. Un rato antes habían pasado por las mesas, ofreciendo RedBulls y, entre la cafeína y la tensión de saberse cerca de la hora límite, esa última hora fue la más absorbente de todas: no veía a nadie, no escuchaba a nadie, salvo al equipo apurando los últimos minutos, frenético, intercambiando orientaciones y reclamos.

A última hora el plugin de BlackBerry para Eclipse no se instaló, fallando el proceso de instalación en la versión del Eclipse incluida en el ADT-bundle. No obstante, pudimos firmar y empaquetar gracias a la versión online de la herramienta; y cuando faltaban un par de minutos para nuestro turno de exposición del proyecto, hicimos el deploy del .bar con el instalador reempaquetado, gracias al plugin de Chrome PlayBook App Manager. Unos segundos después, nos llamaban al frente, para exponer nuestro proyecto.

Después de la exposición y responder a las preguntas, todo pareció volver a la normalidad: otra vez se escuchaban las voces de los demás equipos y el lugar pareció llenarse de personas.

¡Habíamos terminado el software y lo habíamos echado a andar en un dispositivo con BlackBerry 10!

Qué nos quedó


Splash screen de TrafficBB
Luego de la paliza del hackathon, nos quedó la experiencia y la satisfacción de lograr lo que fuimos buscando: trabajo en equipo capaz de generar software funcional, en muy poco tiempo.

Por supuesto, también nos quedó el software, un producto muy sencillo pero que consideramos útil y que, por tanto, publicaremos en las tiendas de aplicaciones de BlackBerry y Google, luego de testearlo en profundidad y pulir los detalles que aparezcan, por supuesto.

El producto (TrafficBB) es una aplicación para el aprendizaje de las señales de tránsito con una colección de las señales oficiales, según la Dirección General de Tráfico, y un área de auto evaluación con preguntas de selección múltiple para poner a prueba nuestros conocimientos.

De modo que, además de la experiencia nos ha quedado nuestra primera aplicación para el nuevo sistema operativo de RIM: el BlackBerry 10.

domingo, 25 de noviembre de 2012

BlackBerry 10 Jam World Tour - Enterprise Edition en Madrid

La semana pasada estuve en el evento de presentación de BlackBerry 10 en Madrid, donde presentaron el nuevo sistema operativo de RIM, se habló de oportunidades, estrategias, tecnologías de desarrollo y, como no... ¡Donde me obsequiaron un dispositivo BlackBerry 10 Dev Alpha!

BB10 Dev Alpha

La conferencia


El BlackBerry 10 Jam World Tour – Enterprise Edition de Madrid se efectuó en la planta 42 del Torre Espacios. Fue mi primera vez en un rascacielos, así que cuando me dí cuenta que hasta las azafatas eran de habla inglesa ya había sobrepasado mi umbral  de asombro y el no oficial pero omnipresente idioma de la charla no hizo más que reafirmarme que el inglés no es una opción, sino una realidad inevitable.

Una buena parte de la charla se concentró en mostrar las características que distinguen a BlackBerry y las ventajas que ofrece para construir e integrar soluciones empresariales y, por la tarde, pasamos de la palabra a la acción en una sesión práctica.

Lo más interesante en herramientas de desarrollo: HTML5 y Android para BlackBerry


La sesión práctica comenzó cuando todos en la sala nos pusimos manos a la obra para poner a punto el Cascades como entorno de desarrollo para C++ y una máquina virtual de BlackBerry 10 en VMWare. Labor que resultó algo lenta y, en mi opinión, un poco complicada; sobre todo la parte de la máquina virtual en VMWare.

Sin embargo cuando pasamos al WebWorks para las implementaciones con HTML5 y JavaScript, se hizo la luz: el proceso fue extremadamente simple y rápido. Tanto así que, luego de instalar el SDK, solo hizo falta instalarle un plugin (llamado Ripple) al Chrome... y listo: ya estaba montado el entorno de simulación y pruebas.

¿Podría se más simple? Parecería que no, pero sí: en RIM no solo están intentando captar a la ingente masa de desarrolladores que ya controlan las tecnologías Web, sino que también intentan captar a los desarrolladores de Android, de modo que han puesto muy fácil el proceso para comenzar a desarrollar para BlackBerry 10. Tan fácil, que, simplementente, no hay que hacer casi nada: quien haya hecho una aplicación para Android, podrá reempaquetar el apk con el instalador para generar un paquete válido para BlackBerry, sin necesidad de reescribir nada. De modo que BlackBerry 10 cuenta con el potencial generado por miles y miles de aplicaciones que ya existen para Android y podrían sean reempaquetadas y subidas a la tienda de aplicaciones de BB, el AppWord.

El dispositivo BlackBerry 10 dev Alpha


Actualizando el BBM en el BlackBerry 10 dev Alpha
Al final del evento a un grupo de desarrolladores nos obsequiaron con un prototipo del nuevo BB 10 que será lanzado a principios del año que viene. Este estupendo "regalo" me confirmó que RIM está haciendo todo lo posible para llamar la atención de la comunidad de desarrolladores pues, como ellos mismos hicieron notar en la charla, un móvil o un tablet no tiene posibilidades de éxito si no cuenta con una buena cantidad de aplicaciones disponibles. De modo que además del aumento de opciones mediante la diversificación de las tecnologías disponibles para programar, RIM está estimulando a los programadores con la organización de Hackatons y obsequios como éste que, sin duda, nos da un empujón a los que queremos comenzar a hacer aplicaciones móviles para esta plataforma.

Luego de utilizar un poco el terminal, se le toma rápidamente aprecio a la impresionante calidad de la pantalla (lamentablemente mi amateur foto no le hace honor) y a la velocidad del sistema en general. No obstante, hay que adaptarse a unos conceptos de navegación  distintos a lo que estamos acostumbrados pues no hay ningún botón, salvo el de encendido, de modo que el tradicional botón de inicio que tienen los otros sistemas para ir a la pantalla principal, de inicio o el "home" del sistema, aquí no existe pues ha sido remplazado por un gesto.

Pero no entraré en más detalle porque la descripción del nuevo sistema operativo de BlackBerry es motivo suficiente para todo un post.

lunes, 5 de noviembre de 2012

III Cumbre de Desarrolladores de Samsung: Android, Smart Devices y Tizen

Hace unas semanas (el 16/10/2012) estuve en la III Cumbre de Desarrolladores de Samsumg, en la que, como ya es habitual, se presentaron los productos y tecnologías en las que Samsung está apostando. Android afianzó su posición como plataforma de base, quedando Bada relegado al olvido que, aunque ocupó una buena parte de la cumbre anterior, este año no recibió ni una sola mención y, en su lugar, hizo su aparición Tizen.

Aunque se tocaron más temas, aquí comentaré lo que para mí resultó más interesante de la cumbre: la presentación de la Galaxy Camera, el paso evolutivo del SmartTV hacia Smart Interaction, el stylus con su SDK y la anunciada presentación de Tizen.

Las cámaras fotográficas como nueva plataforma de desarrollo

Este año el ecosistema de multiscreen de Samsung, formado por 4 plataformas -smartphones, tablets, televisores y portátiles- creció con la inclusión de la pantalla táctil de 4.77 pulgadas de la Galaxy Camera. Una cámara de 16 megapíxeles que dejó de ser un dispositivo pasivo para convertirse en una smartcamera completamente interactiva; para lo cual la dotaron de un Android 4.1 corriendo en un procesador de cuatro núcleos a 1.4 GHz, con 1 GB de RAM y conectividad 3G y WiFi. Esto, dicho así, parece más un smartphone que una cámara; pero ya que ningún smartphone tiene un zoom óptico de 21x, ni control manual de todos los parámetros de la óptica de la cámara, esta mezcla no puede catalogarse como otra cosa que una cámara.

Pantalla, cuerpo y objetivo de la Galaxy Camera
Esta fusión abre un mundo de oportunidades para el consumidor, comenzando por la edición de fotografías y vídeos en la propia cámara, o el almacenamiento en la nube de las capturas que ya no necesitarán esperar a ser descargadas en el ordenador para liberar la memoria SD.

Por otra parte, contar con Android en la cámara la convierte en una plataforma más para desarrollar aplicaciones; en la que también Samsung ofrecerá  APIs específicas para el desarrollo de aplicaciones que saquen partido al dispositivo, como funciones para el seguimiento de objetos en movimiento o la sincronización de imágenes; pero eso..., aún está por llegar.

Del SmartTV al Smart Interaction


Este año Samsing volvió a sorprender, presentando el nuevo concepto de televisión inteligente, dotada de lo que llamaron Smart Interaction.

Demostración del uso de Smart Interaction
En una presentación muy entretenida y dinámica, ilustraron la evolución de la televisión tradicional en Samsung hasta llegar a la interacción inteligente donde ahora la tele, además de ejecutar aplicaciones, incorpora nuevas formas más naturales de interacción, al tradicional mando a distancia. Para lograrlo, Smat Interaction comienza por incorporar una cámara y un micrófono aun televisor con SmartTV, de modo que es posible controlar el televisor mediante comandos de voz; hacer gestos con la mano para señalar, seleccionar y arrastrar objetos en la pantalla; y utilizar el reconocimiento facial para desbloquear funciones o recordar configuraciones o partidas pendientes en aplicaciones y juegos.

Además de la demo que incluyó una vídeo-llamada por Skype combinando el control por voz y gestual, en la sala de exposiciones había televisores disponibles para interactuar con ellos y, cosa "rara", el que tenía una versión de Angry Birds para SmartTV no paraba de tener a alguien "evaluando" el producto.

Galaxy Note y S-Pen SDK


Junto al Smart Interaction, esta fue una de las partes más interesantes porque presentaron la nueva versión 2.2 del SDK para la interacción con el stylus en los dispositivos de la familia Note. Algunas de las aportaciones o mejoras vinculadas a los recientemente lanzados smartphone y tablet -Galaxy Note II y tablet Galaxy Note 10.1- fueron:
  1. Reconocimiento de la extracción y guardado del stylus.
  2. Mejoras en el reconocimiento de movimientos (hovering) y pulsaciones del botón del stylus sin tocar la pantalla hasta una distancia de 1 cm.
  3. Aumento de la sensibilidad del stylus, llegando al reconocimiento de 1024 niveles de presión.
  4. Aplicaciones del stylus en la identificación biométrica de una persona mediante su firma, gracias al reconocimiento de la forma, el ritmo y la presión durante el trazo.
Algo a notar es que, ciertamente, el dispositivo y las APIs han mejorado pues la experiencia de uso del Galaxy Note II supera con creces a la de su predecesor. Si en el 2011 el Galaxy Note prometía, aún tenía cierto retardo en la aparición del trazo, cuando se utilizaba para dibujar. Sin embargo, las nuevas APIs y el hardware más potente del Note II ofrecen una experiencia muy natural en la toma de notas manuscritas y en el dibujo.

Tizen: mucho ruido y pocas nueces


Después de esperar ilusionado que llegara el momento de Tizen, sufrí una decepción. Al ver que Bada ya no figuraba en el programa de la conferencia y que desde el principio se estuvo mencionando el nombre del nuevo sistema operativo móvil, esperaba escuchar una declaración de intensiones sólida respecto a esta "promesa" de sistema multiplataforma declarado abierto por partida triple: open Web, open source y open governance.

Sin embargo, al ser precisados por algunos asistentes, desde Samsung hicieron hincapié en que aún no hay fechas para una versión estable de la SDK y que no tienen un roadmap definido. De modo que por ahora no recomendaban migrar ninguna aplicación y sugirieron, de momento, solo explorar el sistema y las SDK, pero nada más.

Efecto demo en la charla de AllShare Framework


Para terminar, una nota que le da razón de ser a este blog. Resultó ser que en la presentación de la SDK para compartir contenidos y conectar los distintos dispositivos de Samsung (AllShare Framework), hubo imprecisiones que llegaron a frustrar la presentación. Cuando en la demo intentaron controlar desde el móvil una aplicación que se ejecutaba en el televisor, las continuas demoras y fallos hicieron que, luego de unos minutos que parecieron infinitos, se continuara con la presentación sin mostrar la interacción deseada.

Como comentó alguien en un tweet: hasta los grandes sufren el efecto demo.

martes, 17 de julio de 2012

Aplicación en modo kiosko para Android: lo que no se puede hacer

Generalmente solemos hablar de lo que se puede hacer y cómo se hace; pero para evitar quebraderos de cabeza a veces es bueno saber qué es lo que no se puede hacer y así no perdemos el tiempo intentándolo. Debido a que ya he pasado por eso (intentar infructuosamente hacer ciertas cosas con Android) pongo aquí algunas cosas que he verificado que no es posible hacer o que no son recomendables hacer.

Nota: Antes de comenzar debo aclarar que lo que aquí se comenta está relacionado con el desarrollo de aplicaciones usando la SDK de Android que serán ejecutadas en un dispositivo con su ROM original, sin rootear. Ninguna conclusión de las siguientes deberá aplicarse al desarrollo con otras plataformas como la NDK, Mono Droid o cualquier otro medio utilizado para desarrollar aplicaciones para Android, ni para el caso de la ejecución de aplicaciones en un entorno con privilengios de súper usuario.

Las cosas que intenté hacer y ahora describo, estaban relacionadas con el desarrollo de una aplicación en modo kiosko (ver post anterior Aplicación en modo kiosko para Android). Una aplicación en modo kiosko, por definición, debería limitar toda la interacción del usuario con el dispositivo a los elementos que se quieran y definan en la aplicación. En nuestro caso, se suponía que todos los botones del hardware estarían bloqueados, incluso el botón para bloquear o apagar el móvil. Sin embargo, aquí nos encontramos con la primera limitación en Android: 

No es posible inhabilitar o desactivar el comportamiento del botón de encendido del móvil. 

Si bien es cierto que podemos interceptar algunos eventos relacionados con dicho botón, no hay nada que hacer al respecto salvo procesamientos al margen del proceso iniciado (apagado de la pantalla, reinicio o apagado del terminal). De modo que si queremos que una aplicación en modo kiosko en Android no sea interrumpida por la pulsación del botón de encendido, tendremos que inhabilitar físicamente dicho botón, lo cual es "poco" factible en la mayoría de los casos.


No obstante, supongamos que logramos inhabilitar el botón de encendido, digamos, porque empotramos un teléfono o un tablet con Android en una carcasa que limita su utilización a la interfaz táctil. Nos encontramos entonces con la necesidad de poder reiniciar o apagar el dispositivo, ya sea mediante algún elemento en la interfaz o de manera remota, reaccionando a un SMS, un código recibido por NFC, un patrón leído a través de la cámara o la estrategia que mejor nos convenga. 


Para reiniciar y apagar el dipositivo disponemos de los métodos reboot() y goToSleep(). Sin embargo, a pesar de que parece que podemos reiniciar y apagar el dispositivo con dichos métodos, la ejecución de los mismos requiere del permiso android.permission.DEVICE_POWER que, aunque no lo dice en la documentación de la SDK, está restringido a las aplicaciones que se ejecutan con permisos del sistema y, por tanto, nuestra aplicación no podrá apagar ni reiniciar el dispositivo ejecutándose como una aplicación corriente. De modo que:

No es posible reiniciar o apagar el móvil, por programación.

Finalmente, el último problema está relacionado con la intercepción de llamadas entrantes. En nuestra aplicación, deberíamos interceptar las llamadas entrantes y colgarlas para no interrumpir el funcionamiento de la aplicación. Sin embargo, aunque hay varias aplicaciones que logran hacer esto, lo hacen accediendo a una API no oficial que, desde la versión 2.3 de Android a quedado limitada a las aplicaciones que se ejecutan con permisos del sistema. De modo que, si nuestra aplicación se ejecutará en Android 2.2 o una versión anterior, podríamos usar la estrategia que se ilustra claramente este post: Blocking Incoming call - Android. Sin embargo, deberá tenerse en cuenta que ese código no funcionará en versiones de Android posteriores a la 2.2 pues desde la 2.3 el permiso necesario para manipular una llamada (android.permission.MODIFY_PHONE_STATE) se ha limitado a las aplicaciones del sistema. En Stakoverflow este tema se ha tratado extensamente (como en este hilo) y queda claro que no es posible hacerlo, y aunque hay quien propone diferentes estrategias para paliar el problema, ninguna es la solución definitiva a éste problema que pueda aplicarse a cualquier versión del sistema y en cualquier terminal. De modo que:

No es posible colgar una llamada entrante, por programación, en Android 2.3 o superior.

Hasta aquí las limitaciones con las que me he topado en el desarrollo de aplicaciones para Android. Seguramente haya muchas más, pero de momento, estas están verificadas como problemas, hasta el momento, irresolubles. A lo mejor alguien encuentra una solución universal y la comparte; pero por ahora:

  • No es posible inhabilitar o desactivar el comportamiento del botón de encendido del móvil.
  • No es posible reiniciar o apagar el móvil, por programación.
  • No es posible colgar una llamada entrante, por programación, en Android 2.3 o superior.

lunes, 27 de febrero de 2012

Aplicación en modo kiosko para Android

Hace un tiempo tuve que migrar una aplicación de Windows Mobile a Android. En sentido general el desarrollo en Android fue más simple y más rápido; pero cuando llegué al punto de duplicar el comportamiento del "modo kiosko", Android se tornó casi tan arisco como Windows Mobile. Aquí publico hoy la solución que apliqué para que sirva de base a otros desarrollos.

No es que hacer una aplicación que se ejecute en modo kiosko en Windows Mobile sea simple. De hecho lograr que la aplicación se mantuviera siempre en primer plano bloqueando los botones de hardware del teléfono fue toda una odisea que necesitó alguna chapucilla código particularizado para cubrir limitaciones (como que en los teléfonos Samsung se nos estaba vetado deshabilitar el botón de la cámara -según nos confirmaron desde Samsung- y, por tanto, cada vez que se pulsaba el botón de la cámara la aplicación perdía el foco).

Los teléfonos con Android, por suerte, tienen unas APIs más uniformes, pero no por esto el modo kiosko deja de ser un reto. Para comenzar, no encontré ningún lugar donde pusieran en claro qué hacer para que una interfaz se mantuviera en primer plano y a pantalla completa, independientemente de la interacción que tuviera el usuario con el dispositivo. Debido a que la información que encontré era incompleta y estaba dispersa, hoy pongo aquí el resumen de lo necesario para crear una aplicación que se ejecute en modo kiosko, acompañado del código fuente de un proyecto sobre el que se puede partir para hacer una aplicación que ya satisface estos requisitos.

Para comenzar, una aplicación en modo kiosko en Android debe:
  1. Mostrarse a pantalla completa, de modo que el usuario no se salga de la aplicación accediendo a otras opciones que aparezcan en la zona de notificaciones, en la barra de título.
  2. Bloquear los soft buttons y botones de hardware, de modo que el usuario no pueda salirse de la aplicacion presionando el botón back ni se interrumpa la aplicación por la presión de otros botones como el control del volumen.
  3. Remplazar el home del dispositivo por la pantalla inicial de la aplicación, de modo que, al presionar el botón "home" (que lamentablemente no puede ser interceptado, como el resto de botones) en lugar de salir de la aplicación para mostrar la pantalla de inicio del teléfono, se muestre la aplicación y se pueda restablecer la interfaz al punto donde se estaba.
Debo puntualizar que esta solución no es La Solución para todas las aplicaciones que requieran ejecutarse en modo kiosko pues cada una puede requerir un mayor o menor grado de control. Sin embargo, la esencia de dicho control puede obtenerse haciendo que las actividades de nuestra aplicación extiendan la clase KioskModeActivity cuyo código es el siguiente:

package org.carlosbello.android.kioskmode;

import android.app.Activity;
import android.os.Bundle;
import android.view.KeyEvent;
import android.view.Window;
import android.view.WindowManager;

/**
 * Actividad de base para crear interfaces en modo kiosko.
 * @author Carlos Bello
 */
public class KioskModeActivity extends Activity {
    /** Indica si deberá desactivarse el uso del botón de retroceso. */
    protected boolean blockBackButton = false;
    
    /**
     * Establece la visualización a pantalla completa para evitar una salida 
     * accidental a través de la barra de título o cualquier otro elemento 
     * interactivo que no sea nuestra propia interfaz.
     */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        requestWindowFeature(Window.FEATURE_NO_TITLE);
        getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
                WindowManager.LayoutParams.FLAG_FULLSCREEN);
    }
    
    /**
     * Intercepta los eventos del teclado para evitar la interacción con 
     * cualquier elemento que no forme parte de nuestra interfaz, salvo la 
     * funcionalidad del botón de retroceso, si estuviera habilitado.
     */    
    @Override
    public boolean onKeyDown(int keyCode, KeyEvent event)  {
        return !blockBackButton && keyCode == KeyEvent.KEYCODE_BACK
            ? super.onKeyDown(keyCode, event)
            : true;
    }
}

Ahora, para evitar salirse de la aplicación, la actividad inicial deberá establecer blockBackButton a true y registrarse en el manifiesto del proyecto con la categoría HOME; de modo que si reiniciamos el terminal se abrirá nuestra aplicación primero que cualquier otra y al pulsar el botón home se mostrará siempre nuestra aplicación.

Claro que convertir nuestra aplicación en el home del sistema trae como consecuencia que si queremos salir de la aplicación, terminaremos entrando en ella nuevamente pues el home del sistema es nuestra propia aplicación. De hecho, ese es parte del objetivo: que si nos salimos por accidente de la aplicación, ésta se abra automáticamente. Este "inconveniente" puede sortearse buscando otra aplicación que pueda funcionar como home y abriéndola explícitamente.

Como el código para hacer esta búsqueda es algo más extenso, dejo en el siguiente enlace un proyecto de ejemplo de una aplicación que puede ejecutarse en en modo kiosko:
http://ejectodemo.googlecode.com/files/20120227_AndroidKioskMode.zip

Update: desde agosto de 2014 el código está disponible en GitHub:
https://github.com/carlosbello/efectodemo/tree/master/AndroidKioskMode

Atención: Debe tenerse en cuenta que si durante la ejecución de la aplicación se presiona el botón home y se marca la casilla de "Usar por defecto" se reescribirá la pantalla home del sistema y se necesitará eliminar los valores por defecto, almacenados para la aplicación AndroidKioskMode o desinstalarla para restablecer el home original.

Bueno, esto es todo. Agradeceré cualquier colaboración que mejore esta solución o plantee una solución diferente.

domingo, 27 de noviembre de 2011

II Cumbre de Desarrolladores de Samsung: Bada y software para televisores

El pasado miércoles (23/11/2011) estuve en la II Cumbre de Desarrolladores de Samsung, donde se presentaron las últimas novedades en materia de aplicaciones para dispositivos móviles de esta compañía. Lo más sorprendente: los televisores entran en la competencia de las tiendas de aplicaciones. Fui al evento en busca de lo relacionado con el desarrollo para teléfonos móviles y, sobre todo, en Android; pero me encontré con un foro enfocado en Bada y Smart TV.

Bada


Durante la sección de la mañana casi todo rondó sobre el desarrollo de aplicaciones móviles pero, sobre todo, basándose en Bada. Resulta que, por lo que podía verse en la sala da exposiciones, Samsung parece estar decidido a impulsar con fuerza este sistema operativo haciendo la interfaz de sus teléfonos con Bada tan parecida a los de Android que cuesta notar la diferencia.


Quien haya manejado un teléfono con Android podrá desenvolverse con un Bada sin ningún problema: el sistema de menús es casi idéntico y la apariencia en general es tan parecida que cuando tomé el Samsung Wave III tuve que mirar en el menú los datos del software del teléfono para convencerme que no se trataba de un móvil con Android. De modo que, de cara al usuario, Samsung está intentando allanarles -y si es posible hacerles transparente- el caminio del cambio a los usuarios.

Wave y Galaxy, Bada y Android


En cuanto a los programadores, las conferencias fueron también la demostración de la intención de Samsung de hacer de Bada su principal plataforma. Si bien es cierto que desarrollar en C++ no ayuda a que los desarrolladores de Android se adapten con facilidad, los desarrolladores para iPhone podrían recibir con agrado esta plataforma pues la charla sobre migración de aplicaciones de iOS a Bada daba la impresión de que el modelo de desarrollo y la SDK habían sido concebidos con la intención de atraer a estos desarrolladores facilitándoles el cambio como a nadie.

Para finalizar y abrirle las puertas a todos, presentaron también la posibilidad de desarrollar con HTML5 + JavaScript con acceso a funcionalidades nativas del móvil.

Smart TV

Esta fue, para mí, la gran sorpresa: hacer de los televisores un dispositivo más para el despliegue de aplicaciones. Toda la sección vespertina se dedicó al tema del desarrollo de aplicaciones para Smart TV que no solo estará presente en los televisores de Samsung, sino también en sus reproductores de Blue-ray.

Smart Hub: el punto de acceso a las aplicaciones de Smart TV en Samsung
Ya no se trata de que los televisores tengan menús para navegar por ciertos contenidos multimedia locales y fuentes de entrada de vídeo, ni de las ofertas de televisión a la carta que ofrece cada proveedor de televisón; sino de un dispositivo más, conectado a Internet y con la posibilidad de instalar software de cualquier fabricante. Samsung ha llevado el concepto su de tienda de aplicaciones para teléfonos móviles a los televisores y reproductores de Blue-ray. Así que en breve estaremos viendo un número creciente de productos que los consumidores tendrán a su libre disposición. Para el usuario es una pantalla más: además del móvil, el tablet y el portátil, ahora podrán disfrutarse de las aplicaciones preferidas en el televisor, relajados en el sofá e interactuando a distancia con el propio mando del televisor, o con un móvil o un tablet conectados por Wifi.

Para el final de la jornada presentaron la SDK de Smart TV y los procesos del desarrollo, empaquetado y distribución de aplicaciones, que estarán implementadas en HTML5 + JavaScript. De modo que, poco a poco, ésta se irá abriendo camino como una plataforma más para la cuál habrá que desarrollar aplicaciones.