Activación de las opciones de desarrollo

Depurar una aplicación de Android en W10 (1)

En los terminales que usan Android como sistema operativo hay dos operaciones que requieren el uso del ordenador. La primera es el Hard Reset y consiste en reinstalar la versión de Android que viene de serie con el terminal restaurando los archivos que se hayan eliminado o modificado. La segunda operación es el modo de depuración (ADB) que permite depurar las aplicaciones que se programan con el PC y acceder a contenido del teléfono que no está accesible directamente. Por ejemplo, con ADB se pueden usar herramientas de copia de seguridad y guardar la información del teléfono (aplicaciones y sus datos) en el PC por si se perdiera el teléfono. Para usar ADB hace falta instalar los drivers en el PC y configurar el teléfono para que acepte la conexión en las versiones de Android a partir de Kit Kat. Se puede dar el caso que en las instrucciones para hacer el Hard Reset se diga que es necesario instalar los drivers de ADB en los terminales que llevan un SOC de Qualcomm. No es necesario instalarlos si configuramos el teléfono para que se inicie en Fastboot Mode.

Este artículo actualiza uno previo que podéis encontrar en InnerZaurus (https://www.innerzaurus.com/android/programacion-android/depurar-una-aplicacion-en-android-4-4-con-windows.html) en varios aspectos para tener en cuenta Windows 10 como sistema operativo y los terminales que llevan Lollipop. Aunque se centra en el tema de los drivers en los terminales de bq, los pasos son aplicables a cualquier terminal que lleve como SOC Mediatek o Qualcomm. Para que sea más cómodo de leer el artículo lo he dividido en dos partes. La primera tratará sobre los terminales que llevan SOC de Qualcomm y la siguiente sobre los terminales que lleven Mediatek.

Partimos de una instalación limpia de Windows 10. A lo largo del artículo parto de que la versión de Windows 10 está completa y no es una versión modificada. Se pueden encontrar versiones de Windows (no oficiales) que no tienen algunos componentes importantes de Windows. En esos casos es posible que no podáis completar algunos pasos del artículo.

Para que funcione ADB es necesario cumplir varios requisitos:

  • Configurar ADB en el teléfono.

  • Instalar el driver.

  • Aceptar la petición de conexión desde el ordenador en el teléfono (a partir de Kit Kat).

Configurar ADB en el teléfono

Terminales con Lollipop

Se puede dar el caso que salga durante el instalador “Driver instalation failed”. Arreglaremos el problema más adelante. Conectamos el teléfono al ordenador con ADB activado. Para activarlo:

  • Ajustes, Información del teléfono.

  • Pulsamos sobre el número de compilación hasta que salga un aviso indicando que se han activado las opciones de programación.

  • Entramos en Opciones de desarrollo y activamos Depuración USB.

Aparecerá una nueva opción en la pantalla de Ajustes

Opciones de desarrollo 

Activamos la Depuración USB.

Activación de ADB 

La parte del teléfono ya estaría configurado. El siguiente paso es instalar los drivers de ADB en Windows para que aparezca la ventana de confirmación de la conexión.

Instalación del driver para SOC Qualcomm

En el caso de ADB, el driver es el mismo para todos los terminales que llevan Qualcomm. El M5.5 tiene otra página de descargas pero se aplica al Hard Reset. Se puede configurar ADB con el driver “genérico”.

Descomprimimos el archivo Drivers qualcomm + adb, entramos en la carpeta y ejecutamos el instalador.

Selección del idioma del instalador 

Primer pasos del asistente

 Ruta de instalacion de los drivers

 

Resumen del instalador

 

Hay que fijarse si durante la instalación ha aparecido un mensaje indicando que hay un error al instalar el driver. Abrimos el Administrador de dispositivos de Windows y comprobamos si detecta bien el teléfono.

Administrador de dispositivos de Windows 

El problema se puede solucionar. Es un poco laborioso pero al final ADB funcionará. Los drivers de Windows pueden venir firmados. Un driver firmado incluye, junto a los archivos necesarios, una firma digital que permite detectar modificaciones en los archivos. Windows no permite a partir de Windows 8.x instalar de serie drivers que no estén firmados y es necesario deshabilitar la comprobación para que permita instalarlos. Podéis desactivar los drivers firmados siguiendo los pasos de este enlace de la Web de Acer.

 En el siguiente inicio abrimos la carpeta que contiene los drivers (C: Program Files (x86)BQ Handset USB Driver). Entramos en la carpeta de nuestra arquitectura y pulsamos con el botón derecho sobre el archivo android_ winusb.inf. Seleccionamos Instalar. Tiene que aparecer la siguiente pantalla:

Instalación de android winusb

 

Abrimos el Administrador de dispositivos de Windows y pulsamos con el botón derecho sobre el dispositivo. Actualizar controlador

Actualizar controlador 

Buscar software de controlador en el equipo.

Busqueda del controlador

 

Elegir una lista de controladores de dispositivo en el equipo.

Ruta de los drivers 

Seleccionamos AndroidUsbDeviceClass.

Dispositivo AndroidUSBDeviceClass

 

Elegimos el primer dispositivo:

Seleccion del driver 

Aparecerá una ventana advirtiendo que Windows no puede comprobar que el driver vaya a funcionar con el terminal. La aceptamos y el driver estará instalado. En el Administrador de dispositivos de Windows aparecerá el terminal con una señal de interrogación porque hemos forzado la instalación.

 Driver instalado

 

Para probar la conexión necesitamos el ejecutable de ADB. Lo podéis encontrar en el SDK de Android y en los recoverys que hay por el foro (para Qualcomm). Abrimos una consola de Windows y pasamos a esa carpeta:

  • cd C: UsersUSUARIO AppDataLocalAndroidsdk platform-tools

  • adb devices

Comando ADB devices

 

Si llegamos a este punto Windows ha detectado el teléfono pero no tiene permisos para acceder. Activamos la pantalla del teléfono y aparecerá el aviso de conexión.

Confirmación de la conexión en el teléfono 

Aceptamos la conexión y ejecutamos de nuevo el comando

  • adb devices

Comando ADB devices correcto

 

Los pasos son los mismos en los terminales Aquaris E5 4G (junto con su equivalente de la Fnac), Aquaris M5 y Aquaris M5.5.

Prueba del funcionamiento de ADB

En la misma carpeta que tenemos ADB ejecutamos los comandos para tomar una captura de pantalla:

  • adb shell screencap -p /sdcard/captura.png

  • adb shell screencap -p /sdcard/captura.png

  • adb shell rm /sdcard/captura.png

 La captura de pantalla aparecerá en el escritorio.

Captura de pantalla con ADB

Depurar una aplicación en Android 4.4 con Windows

revans2 Chalkboard

Ya hemos visto en un artículo anterior la forma de configurar Ubuntu para que detecte un terminal con Android 4.4. En este artículo veremos algo parecido para el caso de Windows. A diferencia de GNU/Linux existen más casos en los que se usan los drivers de depuración (aparte de la programación). Como ejemplo tenemos la aplicación Helium. Esta aplicación nos permite crear una copia de seguridad del terminal sin necesitar permisos de root.  Para hacer la copia utiliza ADB por debajo. Por esta razón es necesario que Windows tenga bien instalados los drivers y que el terminal permita la conexión del PC.

Hay tres detalles importantes al usar ADB en Windows. El primero es que el terminal tenga la depuración activada. El segundo es que los drivers estén bien instalados. Al conectar el terminal tiene que aparecer en el Administrador de dispositivos de Windows un dispositivo asociado con ADB que no muestre ninguna señal de advertencia. En este punto ya tenemos configurado el terminal y los drivers de Windows. ADB utiliza un identificador (dependiente del fabricante) para conectarse al terminal. El último detalle importante es que el identificador del fabricante esté definido en el archivo correspondiente para que todo funcione de forma adecuada.

Activación de las opciones de depuración

Las opciones de depuración se encuentran al final del menú Ajustes. Por defecto están ocultas y es necesario activarlas de forma manual. Para hacerlo entramos en Información del teléfono y pulsamos varias veces sobre el número de compilación. Cuando salga un aviso de Android volvemos al nivel superior y entramos en las opciones de depuración. Sólo tenemos que activar las opciones de desarrollo y la Depuración USB.

Instalar los drivers de Windows

La instalación de los drivers no es complicada aunque si que es un poco laboriosa. Antes de instalar los drivers os recomiendo hacer una copia de seguridad con la aplicación de Windows DriverBackup. No es necesario pero nos permite recuperar el driver de un dispositivo si algo sale mal. Mi equipo usa Windows 8.1 (x64). Por alguna razón el driver del MTP dejó de funcionar un tiempo después de instalar los drivers de depuración. El problema se puede arreglar sin reinstalar Windows.

Copia de seguridad de los drivers de MTP

DriverBackup es una aplicación de código abierto que permite guardar una copia de seguridad de los drivers que usa el equipo. Posteriormente se podrá restaurar esa copia de seguridad y usar el dispositivo aunque no tengamos los drivers originales. El terminal por defecto usa los drivers del protocolo MTP. Este protocolo se usa para intercambiar información entre el PC y los dispositivos multimedia.

Listado de dispositivosListado de dispositivos

En la categoría Dispositivos portátiles seleccionamos el dispositivo para el que queremos hacer la copia de seguridad.

Información de la copia de seguridadInformación de la copia de seguridad

Esperamos a que acabe el asistente.

Progreso del asistenteProgreso del asistente

Al final tendremos en una carpeta los archivos asociados al driver.

04 Archivos del backupArchivos del backup

Instalador de los drivers

Los siguientes pasos se aplican en los terminales de bq. Si tenemos un terminal de otra marca es necesario seguir las instrucciones de su página Web. Descargamos los drivers desde el siguiente enlace. Al ejecutar el instalador nos aparecerá una ventana de consola con información del proceso. Si usamos una versión de Windows anterior a Windows 8 no debería aparecer ningún error.

En el caso de usar Windows 8.x la cosa cambia un poco y nos obliga a modificar algunos archivos.

Error al hacer la instalación en Windows 8.xError al hacer la instalación en Windows 8.x

El mensaje que se ve en la captura dice básicamente que no se puede ejecutar el instalador. Para arreglarlo hay que ir a la carpeta C:USB_Driver y editar el archivo  Install.bat. Os recomiendo que hagáis la edición del archivo usando la aplicación de Windows Notepad++ aunque se puede usar el Bloc de notas de Windows. La línea que hay que añadir es la 17. La primera parte del comando de la línea 17 busca la versión de Windows que usa el equipo mientras que la segunda (la parte del do echo) define una serie de variables auxiliares.

Modificación que hay que hacer en el archivo Install.batModificación que hay que hacer en el archivo Install.bat

Guardamos los cambios y lo ejecutamos pulsando con el botón derecho sobre el archivo Install.bat. Es necesario ejecutarlo como Administrador para que la instalación se haga de forma correcta. En las versiones antiguas de Windows el usuario trabajaba por defecto como Administrador por lo que será suficiente con ejecutar el archivo bat.

Driver instalado correctamenteDriver instalado correctamente

Hay un par de detalles que quiero remarcar. El primero de ellos es la creación del archivo adb_usb.ini en la carpeta .android. Dentro de ese archivo tendremos una cadena de texto que tiene el ID del fabricante. Este ID es el que usará ADB posteriormente y si no está definido ADB no detectará el teléfono. El segundo detalle es que se importa una clave en el registro de Windows. A efectos prácticos hace que el driver que hemos instalado se pueda usar desde las herramientas del SDK de Android sin tener que hacer modificaciones.

Se puede dar el caso que, después de instalar los drivers, nos aparezca en el Administrador de dispositivos de Windows el terminal con una señal de exclamación. Al ver las propiedades del dispositivo veremos una pantalla similar a la siguiente.

El driver está instalado pero no se puede usarEl driver está instalado pero no se puede usar

Cuando se da este caso hay que forzar a Windows para que use el driver correcto. En Windows 7 se pueden instalar drivers que no estén firmados. A partir de Windows 8, esta opción está desactivada por defecto y tenemos que activarla para poder instalar los drivers. Podéis ver los pasos en el siguiente enlace. La opción que permite instalar drivers que no estén firmados se desactiva al reiniciar. Una vez hemos instalado los drivers abrimos las propiedades del dispositivo y pulsamos en Actualizar controlador.

Actualización del driverActualización del driver

Pulsamos en el botón Usar disco y ponemos como ruta la carpeta C:USB_Drivers.

Ruta de los driversRuta de los drivers

Seleccionamos el archivo android_winusb.inf y dejamos que Windows trabaje. Nos saldrá un aviso indicando que es un driver que no está firmado. Si no aparece el aviso y da directamente un error hay que repetir el proceso que permite instalar drivers no firmados.

Aviso que sale al instalar drivers no firmadosAviso que sale al instalar drivers no firmados

Cuando finalice el proceso tendremos el driver instalado en Windows.

Driver instaladoDriver instalado

En el momento que esté el driver instalado ya podremos usar ADB. Abrimos una consola de Windows, vamos a la carpeta que contiene ADB (viene de serie con el SDK de Android). Ejecutamos el comando adb devices. Si todo es correcto aparecerá un aviso en el terminal pidiendo permisos para aceptar la conexión del escritorio.

02 RSAFirma RSA

El archivo adb_usb.ini

Este archivo se encuentra oculto en la carpeta .android que se encuentra en la carpeta del usuario. Tiene que tener una línea con el identificador. En el caso de bq, la línea es:

0x2A47

Si adb devices no encuentra el terminal seguramente será porque no está definida la línea. Después de hacer añadir el identificador reiniciamos ADB con el comando adb kill-server y buscamos de nuevo el terminal con adb devices.

Corrección del problema del MTP

En mi equipo me ha aparecido después de un tiempo de instalar los drivers de depuración un problema relacionado con el MTP. El dispositivo aparece en Mi PC / Equipo pero al acceder Windows nos dice que no tenemos permisos. El mensaje aparece en cualquier dispositivo que use este protocolo.

Error MTPError MTP

La forma de arreglarlo es sencilla si hemos guardado antes de empezar el driver que se usa en el MTP. Si no habéis hecho la copia será necesario que busquéis otro equipo con la misma versión de Windows.  Los pasos son:

  • Abrimos la ruta C:WindowsInf.
  • Renombramos el archivo wpdmtp.inf
  • Copiamos el archivo el mismo archivo del otro equipo con Windows en la misma ruta.
  • Desconectamos el cable USB y lo conectamos de nuevo.

Guardo una copia del archivo wpdmtp.inf que usa Windows 8.1 (x64). Podéis pedirme el archivo en los comentarios y os lo mando por correo electrónico.

Conclusiones

El proceso de instalación de los drivers de depuración es bastante entrenido. En el caso de bq hay que hacer una modificación en el archivo bat que instala los drivers. Si usamos Windows 8.x es necesario permitir la instalación de controladores que no estén firmados. Para hacerlo podéis seguir el enlace que he puesto en el artículo. Recordad que el terminal tiene que tener activada las opciones de depuración. Una vez lo hemos hecho Windows usará el driver asociado. Por último ADB usará el driver y la información contenida en el archivo adb_usb.ini para comunicarse con el terminal.

En Android 4.4 es necesario confirmar la conexión del PC. Este paso no hay que hacerlo si el terminal usa una versión anterior de Android. El proceso es en cierta manera similar al que seguimos en Ubuntu. En Ubuntu los drivers venían de serie y lo único que hacíamos era sociar el identificador del fabricante con un driver y modificar el archivo adb_usb.ini.

Para cualquier duda podéis usar los comentarios o mandarme un correo electrónico.

Logo Ubuntu

Depurar una aplicación en Android 4.4 con Ubuntu

Cuando empezamos a programar con Android trabajamos con un entorno que lleva todo integrado (IDE). Estos entornos como Eclipse o Netbeans facilitan la codificación de la aplicación y su depuración tanto en un dispositivo emulado como en uno real. Si trabajamos con un dispositivo emulado podemos probar cualquier combinación de hardware, desde pantallas pequeñas de 4 pulgadas hasta las pantallas que usan las tabletas de 10 pulgadas sin necesidad de comprar el dispositivo real. Aunque el código funciona en el emulador, es importante probarlo en un dispositivo real ya que el comportamiento del emulador no es ideal y la ejecución es varios ordenes de magnitud más lenta (dependiendo del PC que tengamos).

Para depurar la aplicación en un terminal real el primer paso es que el sistema operativo lo reconozca. Con las versiones anteriores a Kit Kat este paso era sencillo. A partir de Kit Kat es necesario realizar un par de operaciones antes de que el sistema lo reconozca. Entre estas operaciones está instalar los drivers y dar permisos al PC para que se conecte al terminal. Los siguientes pasos se aplican a Ubuntu 14.04 y a los terminales que llevan Android 4.4. El terminal elegido es el Aquaris E5 FHD aunque se pueden aplicar a otros terminales (ya sean o no de bq).

Actualización: parece que tanto los terminales de la serie E como la Edison 3 comparten el mismo idProduct. En ese caso es suficiente con configurar el sistema una única vez para trabajar con cualquiera de los terminales que llevan Kit Kat.

Condiciones iniciales

  • Ubuntu 14.04 de 64 bits. Tiene que funcionar también en otras distribuciones de GNU/Linux que sean modernas.

  • Aquaris E5 FHD. Por cuestión de tiempo sólo pondré los pasos para este modelo pero indicaré como obtener los valores para otros terminales.

  • Cable USB para conectar el teléfono al PC.

Preparando el sistema

Aunque podemos usar la versión de ADB que viene en el SDK de Android con ADT o Android Studio he optado por usar la versión que viene con los repositorios de Ubuntu. Una vez hemos configurado los archivos del sistema no deberíamos tener problemas en usar una u otra herramienta.

Instalamos ADB con el siguiente comando:

sudo apt-get install android-tools-adb

El comando lsusb nos muestra los dispositivos USB que están conectados al bus del sistema. Por alguna razón el Aquaris E5 FHD no aparece directamente sino que está un poco oculto. Necesitamos dos valores para hacer que ADB detecte a los terminales con Android 4.4. El primero de ellos es el idVendor mientras que el segundo es idProduct. Para conocerlos ejecutamos el siguiente comando:

lsusb -v > dispositivos.txt

 Abrimos el archivo con nano dispositivos.txt y buscamos la cadena de texto bq (o el nombre del fabricante que tengamos). En mi caso este es el contenido del archivo:

Información del comando lsusb para un Aquaris E5 FHDInformación del comando lsusb para un Aquaris E5 FHD

Trabajando con el sistema

El idVendor debe de ser el mismo para todos los modelos de bq. El idProduct es el elemento que cambiará según el terminal que tengamos. Vamos a añadir esta información a las reglas de udev. Cuando conectamos un dispositivo USB al PC el subsistema que se encarga de gestionarlo se llama udev. Los terminales de la serie Aquaris E y la Edison 3 comparten el mismo idProduct.

sudo nano /etc/udev/rules.d/51-android.rules

Añadimos las siguientes líneas:

# ADB para la gama Aquaris E y la Edison 3 SUBSYSTEM=="usb", ATTR{idVendor}=="2a47", ATTR{idProduct}=="0c02", MODE="0600", OWNER="mimecar"

Los campos que están remarcados son los que tenemos que modificar. Fijaros que el identificador no lleva la cadena inicial que indica que es un valor en hexadecimal. Para los terminales de bq el primer campo será fijo y cambiarán el segundo y el tercero. El segundo es el idProduct y lo tenemos que sustituir por el valor que hemos obtenido antes. En OWNER ponemos el nombre de nuestro usuario en GNU/Linux.

Si trabajamos con varios terminales podemos añadir una línea por terminal al archivo 51-android.rules respetando la estructura anterior. El último paso es crear el archivo adb_usb.ini y poner el idVendor.

nano ~/.android/adb_usb.ini

Pegamos el siguiente contenido (para terminales de bq):

# ANDROID 3RD PARTY USB VENDOR ID LIST -- DO NOT EDIT. # USE 'android update adb' TO GENERATE. # 1 USB VENDOR ID PER LINE. # ie0x2207 0x2a47

 

Últimos pasos

Desconectamos el teléfono del PC y reiniciamos el servidor de ADB con los siguientes comandos:

adb kill-server  adb start-server  * daemon not running. starting it now on port 5037 *  * daemon started successfully * 

Comprobamos si ADB detecta el teléfono.

adb devices  List of devices attached  CB000000 offline 

Si hemos hecho los pasos de forma correcta nos aparecerá el número de serie y el texto offline. A partir de Kit Kat se ha introducido una capa extra de seguridad. Esta capa obliga a que el usuario acepte la conexión de ADB con el teléfono desbloqueado. En caso de no hacerlo la conexión se corta. Aceptamos la conexión en el teléfono.

Petición de la conexión de ADB
 

adb devices  List of devices attached  CB000000 device 

Al ejecutar de nuevo adb devices veremos el texto device, que indica que todo está funcionando de forma correcta. Para asegurarnos podemos usar los siguientes comandos de ADB que hacen una captura de la pantalla.

adb shell /system/bin/screencap -p /sdcard/screenshot.png adb pull /sdcard/screenshot.png screenshot.png

Abrimos el archivo para ver una captura de pantalla realizada con ADB.

Conclusiones

 Antes de publicar una aplicación en Google Play conviene depurarla en un dispositivo real. Para hacerlo es necesario en primer lugar que el sistema operativo reconozca el teléfono o la tableta. En las versiones anteriores a Kit Kat era suficiente con conectar el terminal y conectarnos con ADB para empezar la depuración. A partir de Android 4.4 es necesario realizar algunos pasos extras para lograr lo mismo. Los pasos no son complicados aunque requieren usar un poco la consola. Si bien me he centrado en un modelo concreto de bq, el artículo se puede aplicar a cualquier teléfono o tableta que usen Kit Kat. Sólo deberemos modificar los valores idVendor / idProduct para adaptarlo a nuestras necesidades. Recordad que hay que modificar dos archivos, el correspondiente a udev y el que controla ADB.

Referencias

Logo SDK

Cursos de programación para dispositivos móviles

En un artículo anterior os comenté algunos cursos relacionados con las programación de aplicaciones móviles en las plataformas Coursera y edX. Ambas plataformas tienen cursos en inglés y esto puede ser un problema para algunos usuarios. Por esta razón os comento hoy el inicio de varios cursos de programación en castellano. El primero de ellos es un mini curso de varias lecciones que dan en la Web de El androide libre mientras que el resto son cursos que aparecen en las plataformas UPV[X] y MiriadaX. Los tres cursos son gratuitos y se pueden seguir con un ordenador y una conexión a Internet. El curso de UPV[X] empieza el próximo Martes y se centra en el sistema operativo Android. Por otra parte, el curso de MiriadaX tiene un planteamiento más generalista al tratar el desarrollo de aplicaciones usando HTML5 y Firefox OS. En el artículo completo podéis encontrar los temarios de los tres cursos.

Curso de El androide libre

Su autor es Jose Angel Zamora. El temario del curso es el siguiente (copiado de la Web del curso):

  • 0. Empezando
  • 1. Fundamentos de una aplicación
  • 2. Recursos de una app
  • 3. La clase Activity
  • 4. La clase Fragment
  • 5. View personalizada
  • 6. Adaptadores (Adapter)
  • 7. La clase Intent
  • 8. Receptores de mensajes broadcast (Broadcast Receiver)
  • 9. Prefencias de una app (Shared Preferences)
  • 10. Bases de datos SQLite
  • 11. Servicios (La clase Service)
  • 12. Tareas asíncronas (La clase AsyncTask)
  • 13. Gestores de contenidos (Content Provider)
  • 14. La barra de acciones ActionBar
  • 15. Notificaciones
  • 16. Orientación del dispositivo
  • 17. Animaciones
  • 18. Widgets
  • 19. Otros conceptos
  • 20. Información adicional

Curso UPV[X]

Su autor es Jesús Tomás Gironés. El temario del curso es el siguiente (copiado de la Web del curso):

  • Unidad 1: Repaso de Java
  • Unidad 2: Introducción a Android y entorno de desarrollo
  • Unidad 3: Diseño del interfaz del usuario – Vistas y Layouts
  • Unidad 4: Actividades, Barra de Acciones y Preferencias
  • Unidad 5: ListView e Intenciones
  • Unidad 6: Ciclo de vida de una Actividad y Seguridad
  • Unidad 7: Posicionamiento y Mapas
  • Unidad 8: Bases de datos en Android

Programación de Aplicaciones móviles unsado HTML5 y Firefox OS (el título lo he reducido)

El temario del curso es el siguiente (copiado de la Web del curso):

  • Módulo 0. Introducción al curso y al programa “Diseño de servicios en la nube para acceso movil con HTML5”       
  • Modulo 1: Introducción a Internet, la nube, la arquitectura de la Web, HTML5 y CSS       
  • Modulo 2: Introducción a JavaScript y a las aplicaciones Web en HTML5, así como la publicación en la nube       
  • Modulo 3. Estructuración y visualización de páginas Web en HTML y CSS adaptadas a un entorno multipantalla con PCs, móviles y tabletas       
  • Módulo 4: Tipos string y boolean de JavaScript, sentencias if/else y for, y caracteristicas avanzadas de objetos, incluyendo acceso al navegador mediante el arbol DOM       
  • Módulo 5: Interacción con el usuario, funciones, eventos, manejadores de eventos, formularios, jQuery y Zepto       
  • Módulo 6: Ejemplo de un cronómetro, eventos tactiles y localStorage, así como su utilización en aplicaciones Web       
  • Modulo 7. Gráficos, multimedia y animación en HTML5: SVG, CANVAS y elementos video y audio       
  • Modulo 8. Arrays, JSON, geolocalización y Mash-ups con otros servicios y aplicaciones, tales como Google Maps
Logo SDK

Cursos de programación en Android (Coursera y edx)

Un curso online masivo es un curso gratuito que se puede realizar desde cualquier lugar del mundo. Existen 3 plataformas principales que ofrecen estos cursos, dos en inglés (Courseray edx) y una en español (MiriadaX). Detrás de estas plataformas se encuentran universidades importantes que ofrecen la posibilidad de certificar los conocimientos obtenidos en el curso con un certificado. El certificado se tiene que pagar pero no es obligatorio hacerlo para seguir el curso. Los cursos se apoyan en vídeos, presentaciones y las redes sociales. Podemos preguntar las dudas en los foros correspondientes y recibiremos respuestas de profesoras y alumnos. El idioma de los cursos es principalmente el inglés en Coursera y edx y el español en MiriadaX.

Dentro de Coursera podemos encontrar los cursos normales y los de especialización. Se diferencian en que un curso de especialización está compuesto de varios cursos normales que se centran en un tema concreto. Para aprender a programar aplicaciones en Android podemos seguir un curso de especialización que empezó la semana pasada y consta de 3 cursos normales. En el primero, que está accesible en estos momentos, estudiaremos el funcionamiento de la plataforma Android así como las estructuras que podemos usar para programar aplicaciones. No es necesario tener conocimientos previos de Android para poder seguir este curso. Una vez tenemos una base podremos pasar al segundo de los cursos que se centra en la creación de servicios para las aplicaciones en Android. Por último el tercer curso también explica la forma de crear servicios en la nube. Cada curso es independiente y se puede realizar aunque no hayamos hecho los anteriores.

edx tiene también un curso orientado al desarrollo de aplicaciones móviles pero de forma más genérica. Se puede seguir tanto si tenemos Android como iOS. El curso empezará el próximo 4 de Febrero.

MiriadaX no tiene de momento cursos abiertos. Parece que está pendiente una segunda edición del curso de Firefox OS. Cuando se abra la inscripción del curso pondré una indicación en InnerZaurus.

Hay un detalle importante que quiero comentaros. Aunque los cursos propios de las plataformas no coinciden en el tiempo, es posible que se realicen de forma simultánea cursos similares en Coursera, edx o MiriadaX. Se pueden seguir varios cursos de forma simultánea si tenemos en cuenta que cada curso tiene unas horas de trabajo estimadas. Por ejemplo, en el curso de edx las horas estimadas de trabajo están en el rango de 10 a 12 h por lección. Es importante reservar ese tiempo en nuestro horario semanal para poder trabajar y aprovechar el curso. Cada curso tiene tareas semanales que es necesario realizar en un plazo acotado de tiempo.

Logo Android

Mejorar la calidad de una aplicación desarrollada en Android

A la hora de probar y verificar una aplicación que hemos desarrollado en Android tenemos varias fases intermedias que, si bien no son obligatorias, ayudan a mejorar la calidad de la aplicación. Podemos distinguir dos tipos de errores. Por una parte tenemos los errores de funcionamiento por otra parte los errores de diseño. Un error de funcionamiento sería que el usuario pierda los datos por un bloqueo de la aplicación mientras que un error de diseño podría ser que el interfaz de la aplicación no se adaptara a la pantalla. Los dos tipos de errores se pueden detectar en la fase de  testeo  que realiza el programador pero en algunas ocasiones quedan enmascarados por el propio programador. Supongamos que un error aparece en unas condiciones concretas que no probamos. Al trabajar siempre de la misma forma no activamos el error pero cuando otro usuario utiliza la aplicación siguiendo otro orden lo encuentra. 

¿De qué forma podemos detectar estos problemas antes de que publiquemos la aplicación en Google Play? Recordad que los usuarios son nuestros clientes aunque la aplicación sea gratuita. Si al usarla encuentran errores es posible que escriban comentarios negativos que se traducirá al final en menos descargas de usuarios nuevos. Cuando la aplicación es de pago los resultados pueden ser peores. La solución de este problema es relativamente sencilla y consiste en verificar de forma adecuada la aplicación antes de su lanzamiento.

Errores de funcionalidad

Los errores de funcionamiento se pueden detectar de forma manual o de forma automatizada (con ciertos límites) si usamos pruebas unitarias. Una prueba unitaria se puede considerar como una función de verificación que llama a la función real de nuestra aplicación, le introduce los datos y comprueba el resultado de la operación. Los datos que introduce los decide el programador y pueden ser datos válidos o erróneos.  La función que esté bajo prueba debe responder de forma adecuada aunque la introducción sera errónea sin que se produzca el cierre de la aplicación. Supongamos que la función original espera un texto de 100 caracteres y le pasamos una cadena que tiene 1000 caracteres. De forma transparente al usuario debemos procesar la información y si es necesario informar al usuario de que el texto tiene que ser más pequeño.

Las pruebas unitarias tienen otra ventaja respecto a las pruebas manuales. Al añadir una función nueva es fácil que afecte a otras partes de la aplicación si comparten datos o se ha cambiado la estructura de los datos. Antes de probar la aplicación en un terminal real pasamos toda la batería de pruebas. Si se produce un error tendremos localizada la función en la que se encuentra y el tipo de datos que se le ha introducido. Un ejemplo de esto puede ser una función que trata con una base de datos. Si la función 1 espera los datos de una forma (de una sentencia SQL) y la función 2 los necesita de otra (con la misma sentencia SQL) podemos romper la función 1 con la función 2.

Errores de diseño

Los errores de diseño muchas veces son evidentes como el ejemplo de la aplicación que se sale de la pantalla pero en ocasiones son más sutiles. El diseño de la aplicación puede ser correcto para una pantalla de 4,5 pulgadas pero ser incomodo si usamos una pantalla más pequeña. Para estos casos es posible aplicar un diseño personalizado para pantallas pequeñas para que la experiencia del usuario sea adecuada. Estos detalles no los podemos ver si hacemos las pruebas siempre en el mismo tipo de dispositivos y de la misma forma. Necesitaremos por tanto que otros usuarios prueben nuestra aplicación y nos ofrezcan realimentación. Según el alcance de la prueba podemos distinguir dos casos:

  • La prueba se realiza en un ámbito local con pocos usuarios.

  • La prueba se realiza en un ámbito global con muchos usuarios.

En el primer caso los usuarios que prueban la aplicación pueden ser conocidos, amigos e incluso familiares. La ventaja de esta forma de trabajar es que controlamos a los usuarios que hacen la prueba pero tiene como inconveniente que la mayoría de los usuarios no serán “clientes” de la aplicación. Con esto me refiero a que si realizamos un contador de viajes para el transporte público los usuarios que prueban la aplicación deberían ser aquellos que la usarían a diario. El resto de usuarios puede probar la aplicación pero no nos dará tanta información útil. En el extremo opuesto está el segundo caso: tenemos usuarios interesados en la aplicación pero no controlamos quien la instala. La elección entre ambos casos no es excluyente sino que podemos realizar una primera etapa con el primer caso y después pasar al segundo.

Acceder a una versión beta (como usuario)

Para realizar la prueba usaremos Google Play y una comunidad de Google+. El funcionamiento es sencillo. Al unirnos a la comunidad de la aplicación que realiza la prueba activaremos una opción “especial” en Google Play. A partir de ese momento cuando instalemos la versión oficial de la aplicación estaremos instalando realmente la versión beta. El proceso es reversible y podemos volver a la versión estable en cualquier momento. Antes de pasar a una versión beta hay que comentar que si bien la versión es suficientemente estable, pueden aparecer errores de diferentes tipos.>Si usamos el terminal con >Android> y una aplicación crítica para el trabajo no hay que pasar a una versión beta de esa aplicación.

Explicaré los pasos para entrar en el programa de beta de la aplicación Todoist. Hay muchas aplicaciones que están siguiendo este tipo de desarrollo, sólo tenéis que investigar un poco por Google Play. Iniciamos la sesión en la cuenta de Gmail y entramos en la comunidad de Todoist.

Comunidad de TodoistComunidad de Todoist

Los pasos para activar el programa de verificación están en la columna derecha de cada página. Tenemos que pulsar en el enlace que nos dan y nos saldrá una pantalla similar a la siguiente:

Programa de beta Programa de beta

Es suficiente con pulsar en el botón y a continuación pulsar en el enlace inferior: Descargar Todoist: Lista de tareas de Play Store. Con esta función podemos como usuarios acceder a versiones en desarrollo y sugerir funciones a las aplicaciones que más usamos en el terminal con Android.

Conclusiones

El desarrollo de una aplicación exige varias habilidades en todas las fases. Durante la creación tenemos que aplicar técnicas de diseño (respetar las guías de estilo de Android), programación (lógica de la aplicación) o marketing (para publicar la aplicación en Google Play).  En cada una de las fases podemos usar diferentes herramientas que facilitan la creación de la aplicación. En el diseño podemos diseñar el interfaz de usuario con Fluid UI en el PC o con la aplicación POP usando bolígrafo y papel en un terminal con Android. Para la programación tenemos Eclipse y la documentación de Android mientras que para el marketing podemos realizar pruebas de la aplicación en grupos reducidos limitados o en grupos amplios perdiendo parte del control de la prueba.

Logo

Crear mockups interactivos en Android con boligrafo y papel

Hemos visto dos formas de hacer mockups (bocetos) de las aplicaciones de Android. La primera consiste en usar un programa de edición fotográfica para crear las pantallas usando la paleta de controles de Android. Su limitación aparece en que las pantallas no son interactivas. El siguiente paso es usar alguna de las aplicaciones Web que permiten crear las pantallas con elementos interactivos como Fluid UI. Estos servicios son útiles pero tienen un coste mensual que es necesario tener en cuenta para diseños complejos. A estas dos formas de trabajar se le suma una tercera con la aplicación POP – Prototyping on Paper. El funcionamiento es similar a Fluid UI con una diferencia importante: el origen de las pantallas no es un diseño en el ordenador sino un diseño en papel. Primero dibujamos las pantallas con bolígrafo y papel y después les hacemos una fotográfica. En la imagen resultante definiremos zonas de acción en los botones y otros componentes y los enlazaremos con las pantallas de destino.

La aplicación es gratuita y está disponible para Android / iOs. Podéis ver la demostración del proyecto en el siguiente enlace. Si pulsáis en una parte de la pantalla en la que no está definida un acción aparecerán en color verde las posiciones que tienen la acción mapeada.

Introducción

Lo normal es que una aplicación tenga varias pantallas. Por comodidad es posible hacer una plantilla en un programa de dibujo que contenga el rectángulo de la pantalla y los elementos estáticos como la barra superior o la barra de controles de manera que sólo tengamos que dibujar los controles. Instalamos la aplicación desde Google Play la ejecutamos. Podemos crear un máximo de dos proyectos en la aplicación. Si creamos una cuenta desde la propia aplicación el número máximo de proyectos es cinco.

Para crear un proyecto pulsamos en el icono +.

Listado de proyectosListado de proyectos

Dentro de cada proyecto tendremos varias fotografías que representan el interfaz de usuario de la aplicación. Antes de escribir el artículo he dibujado en un papel las cuatro pantallas que componen la aplicación del Sudoku (no tengo parado el proyecto). Las pantallas las he dibujado a mano y cada una tiene un tamaño diferente. Por esta razón os comentaba la posibilidad de usar una plantilla para que los tamaños sean similares. Si queremos añadir una pantalla nueva tenemos que usar el icono de la cámara que hay en la barra inferior. El segundo icono nos permite añadir como pantalla una imagen que tengamos guardada en el teléfono. El resto de iconos nos permiten borrar pantallas, entrar en modo interactivo o compartir el proyecto.

Listado de fotografíasListado de fotografías

Pulsamos sobre una de las pantallas para entrar al modo de edición. La idea es simple: dibujamos un rectángulo y después le asociamos una pantalla. El segundo botón de la barra nos permite elegir una animación entre las pantallas mientras que el último se usa para elegir la pantalla de destino.

Selección de las zonasSelección de las zonas

La pantalla actual queda difuminada y sólo tenemos que seleccionar la que queremos de destino.

Pantalla de destinoPantalla de destino

Hemos visto prácticamente todas las opciones de la aplicación. El funcionamiento es sencillo e intuitivo. Si volvemos a la pantalla inicial en la que se ven todas las fotografías del proyecto podemos pulsar el botón Play y probar el diseño.

Demo 01Demo 01
Demo 02Demo 02
Demo 03Demo 03
Demo 04Demo 04

Conclusiones

En este artículo hemos visto otra herramienta que podemos usar para diseñar mockups interactivos. Para compartir un proyecto hace falta crear una cuenta desde la propia aplicación. De momento parece que no funciona esta opción (en el momento de escribir el artículo). Probaré más adelante y haré las correcciones necesarias. POP nos permite trabajar sin un ordenador utilizando sólo el terminal con Android. Si en un proyecto trabajan varias personas es mejor usar otras alternativas como Fluid UI.

Logo Android

Las versiones de Android y su distribución

Cada cierto tiempo Google publica una nueva versión de Android con nuevas funciones y prestaciones. La última versión liberada es Android 4.4 (KitKat). Es importante matizar los términos versión liberada y versión disponible. Podemos pensar que si el fabricante acaba de liberar Android 4.4, la mayoría de los dispositivos debería tener Android 4.3 al ser la versión anterior. Para poder usar una versión de Android concreta en un terminal se tienen que cumplir dos cosas. La primera es que el fabricante la adapte a sus terminales y la segunda que existan drivers para los diferentes chips. Aunque esté disponible el código de Android, sin los drivers correspondientes a los chips de la CPU o la tarjeta gráfica no se puede hacer nada. No importa la marca del terminal que tengamos. Sólo es cuestión de tiempo que el terminal deje de tener soporte y se quede estancado en una versión determinada de Android. A partir de este punto las opciones que tenemos como usuarios son: quedarnos con la última versión disponible del fabricante o esperar a que la comunidad de cocineros haga una adaptación.

Para ver de forma numérica la distribución de cada versión de Android podemos usar la información que proporciona Google. Los datos corresponden a un periodo de 7 días medidos a finales de este mes. Están actualizados en la fecha de publicación de este artículo. Las versiones de Android 2.x aún tienen su uso pero se concentran en un porcentaje que está en torno al 30 %. Estos valores corresponden a terminales antiguos que no tienen actualizaciones y que ya tienen un tiempo en el mercado. Android 3.x era una versión específica para tabletas y por el porcentaje se puede decir que su uso es marginal. Los valores interesantes vienen a continuación.

Versión Nombre API Distribución
2.2 Froyo 8 2.2%
2.3.3 –
2.3.7
Gingerbread 10 28.5%
3.2 Honeycomb 13 0.1%
4.0.3 –
4.0.4
Ice Cream Sandwich 15 20.6%
4.1.x Jelly Bean 16 36.5%
4.2.x 17 10.6%
4.3 18 1.5%

Android 4.0.x (Ice Cream Sandwich) supuso un cambio importante en la forma de trabajar con Android y unificó los interfaces de teléfono y tableta. Entre las versiones 4.0.x y 4.1.x tenemos aproximadamente el 56 % de todos los dispositivos del mercado. Conforme subimos de versión el porcentaje baja de forma drástica. Android 4.2.x está en el 10 % de los dispositivos mientras que la penúltima versión de Android sólo tiene un 1,5 %. En la Wikipedia podemos encontrar un gráfica generada por Fjmustak con la distribución de las versiones. Está actualizada a Septiembre de este año e incluye hasta Android 4.2.

Android historical version distribution sep 2013 (Fjmustak)Android historical version distribution sep 2013 (Fjmustak)

Como usuarios tenemos algunas opciones y se centran básicamente en usar ROMs cocinadas cuando el terminal tiene un tiempo en el mercado. A modo de ejemplo pongo mi HTC Desire que lleva Android 4.2.2. La versión oficial que puedo usar es Android 2.3 con ciertas limitaciones. En la actualidad esa versión tiene una cuota de mercado del 28,5 %. Al principio puede dar respeto rootear un terminal o instalarle un sistema operativo que no es “oficial”, pero los beneficios superan a los riesgos y la comunidad de cocineros crea ROMs muy buenas que pueden ampliar la vida útil de un terminal. No es obligatorio como antes pasaba por ejemplo con los Nokia comprar un terminal nuevo si querías usar una versión más moderna de Symbian.

Conclusiones

En este pequeño resumen con datos podemos ver que aunque un dispositivo que tenemos, ya sea un teléfono o una tableta, no tenga la última versión de Android no quiere decir que estemos desfasados. Android Jelly Bean está en torno al 48 % del mercado. Cualquier terminal moderno debería tenerlo. Si vamos a comprar un terminal y no lo lleva es mala idea hacerlo. Ya ha pasado el tiempo en el que los terminales salían con Android 2.x y con suerte se actualizaban a Android 4.x.

Las aplicaciones de Android pueden trabajar a partir de una versión mínima del SDK. Si usamos Android 4.x podremos usar prácticamente todas las aplicaciones disponibles en Google Play. En el caso de tener una versión anterior (2.x) conviene revisar si existen ROMs de terceros y actualizar. Al usar una ROM de terceros eliminamos todas las aplicaciones que incluyen las operadoras de telefonía y que acaban gastando recursos del terminal o penalizando el rendimiento.

Logo Android

Recursos de programación para Android

Cuando queremos realizar una aplicación en Android tenemos muchos recursos disponibles para trabajar y aprender. Algunos de ellos son los típicos como la documentación que proporciona Google mientras que otros se enfocan en el uso de comunidades. Si tenemos una cuenta de Gmail, al mismo tiempo tenemos una cuenta en la red de Google llamada Google+ (queramos o no). El alta es automática y no requiere registrarse como ocurre en otras redes sociales. Dentro de Google+ tenemos las Comunidades que actúan como una especie de foro simplificado. Cada usuario pregunta y los miembros de la comunidad le responden.

Cada comunidad tiene unas reglas concretas aunque suelen seguir el sentido común: no hacer SPAM, mantener un ambiente cómodo, etc. Algunas de las comunidades relacionadas con la programación son:

Este artículo no es estático sino que lo iré ampliando a medida que encuentre recursos de diferentes tipos. Por ejemplo, en un futuro puedo añadir también foros enfocados a la programación con Android para resolver dudas en castellano.

Logo Android

Crear mockups interactivos en Android con Fluid UI

La programación es un arte que suele dar bastantes dolores de cabeza. Inicialmente puede parecer que lo importante es ponerse a picar (escribir) código lo más rápido posible para cumplir los requisitos del cliente. Una vez funciona se prepara un interfaz de usuario más o menos usable, se prueba la aplicación y se entrega al cliente. La aplicación tiene que cumplir los requisitos del cliente tanto en el funcionamiento interno como en la apariencia. Normalmente se da más prioridad al funcionamiento interno y se le da menos importancia a la apariencia. Para evitar este problema y que el cliente devuelva una aplicación que no cumple sus necesidades podemos hacer mockups antes de empezar la programación. Un mockup es un esbozo o un boceto de una aplicación. En el caso de una aplicación para Android tendríamos una vista más o menos fiable de la pantalla en la que se mostraran las opciones antes de implementarlas. La ventaja de usarlos es clara ya que permite que el cliente conozca la apariencia de su aplicación y la modifique en las fases iniciales del proyecto.

Para realizar un mockup podemos usar papel y bolígrafo o el ordenador. La forma más rápida es obviamente con papel y bolígrafo porque permite hacer bocetos y si no cumplen los requisitos tirarlos y empezar de nuevo. Una vez tenemos un diseño candidato para la aplicación es necesario enseñárselo al cliente. Si en lugar de presentarle el diseño en bolígrafo lo hacemos mediante el ordenador el resultado será más profesional. Tenemos dos opciones en este punto del diseño. La primera es usar un software de edición fotográfica como Gimp para dibujar las pantallas. Podéis encontrar una plantilla con los controles de Android 4.3 en esta dirección. La segunda opción es similar pero funciona de forma diferente y consiste en hacer pantallas interactivas usando aplicaciones Web. Para esta tarea podemos usar LucidChart o Fluid UI

Introducción

Supongamos dos escenarios. En el primero el cliente ve las pantallas de la aplicación. Mediante las explicaciones que le demos conocerá el funcionamiento de la aplicación y las relaciones entre las pantallas. En el segundo escenario en lugar de decirle las relaciones damos el prototipo al cliente. El propio cliente prueba la aplicación pulsando en los controles y viendo el resultado de la acción usando un navegador. Cuando pulsa en un elemento de una lista puede acceder a la pantalla de propiedades. Después vuelve a la pantalla inicial al pulsar el botón “atrás” que tenemos en la aplicación. Se comporta como si la aplicación estuviera programada pero sin la necesidad de haber escrito una línea de código. Aunque da un poco más de trabajo preparar este segundo escenario conseguiremos que el prototipo sea más profesional y que el cliente nos aporte las modificaciones que crea oportunas sobre el diseño.

El funcionamiento de estas aplicaciones Web es sencillo. Básicamente se comporta como una imagen segmentada en la que cada parte de la imagen tiene enlazada otra imagen. En la red hay varias aplicaciones de este tipo pero las dos más útiles son LucidChart y Fluid UI. Ambas permiten hacer mockups de Android (o de productos de Apple entre otras plataformas), facilitan la creación de mockups interactivos y tienen una versión gratuita limitada. Las capturas corresponden a un diseño que estoy haciendo de una aplicación para Android. La aplicación tiene tres pantallas. Una principal, una que permite editar la información de un bono y una tercera que corresponde al primer paso de un asistente. 

Si pulsamos en el primer elemento de la lista (el bono 1) podemos acceder a la pantalla de edición. Al pulsar en el botón Atrás se vuelve a la pantalla inicial. En el caso de pulsar el icono de Añadir pasaréis al primer paso del asistente. Desde esta pantalla se puede volver a la pantalla inicial o pasar a la pantalla de edición pulsando en el botón. Tengo una demo (en fase de diseño) en el siguiente enlace. La parte interactiva funciona a partir de las relaciones que definamos. Si un elemento no tiene ninguna relación no hará nada. La demo sólo responde a los elementos que he comentado.

01 Pantalla principal01 Pantalla principal      

02 Propiedades del bono02 Propiedades del bono    

03 Asistente para crear un bono nuevo03 Asistente para crear un bono nuevo

Conclusiones

Este artículo es una introducción a la forma de diseñar una aplicación para Android que se pueda mostrar al cliente. Si bien es cierto que no tenemos la respuesta de una aplicación real que esté programada, también hay que tener en cuenta que no hemos escrito ninguna línea de código. El número de pantallas depende de los estados que queramos mostrar. Por ejemplo si pulsamos sobre un botón y queremos que se muestre un menú tendremos que clonar la pantalla inicial y añadir a la pantalla creada el menú. Es un proceso un poco artesanal pero que puede ahorrar tiempo en las fases del diseño de la aplicación. Una vez que el cliente acepta el diseño ya podemos empezar a codificar el programa.

Tanto LucidChart como Fluid UI tienen una versión gratuita y varios planes de pago. Con Fluid UI es posible crear en la versión gratuita un proyecto que tenga 10 pantallas como máximo. No se pueden exportar los resultados pero siempre podemos hacer una captura de pantalla del navegador. Los planes de pago son un servicio de suscripción y hay que tenerlo en cuenta en los gastos que tengamos. Podemos hacer cosas parecidas con un software como Gimp en local, pero las pantallas serán estáticas. Todo depende del uso que demos a cada herramienta y de la relación coste / tiempo ahorrado en el desarrollo.