Debugar por Bluetooth en Android Wear

Si bien se puede usar un emulador para testear, no hay nada como un terminal físico, así que una de las primeras cosas que hice al tener un Android Wear fue conectarlo al ordenador para poder ejecutar apps.

El LG G Watch se puede conectar al ordenador via cable utilizando la base de carga, pero lo más interesante es aprovechar la conexión Bluetooth y olvidarse de más cables por la mesa, así que aquí unas pequeñas instrucciones de cómo hacerlo.

1.- Habilitar las opciones de desarrollo en el Android Wear

Desde la pantalla Ajustes iremos a About y pulsaremos 7 veces sobre Build Number.

Una vez hecho esto nos aparecerá un mensaje que nos confirmará que ya podemos acceder a las opciones de desarrollo que nos aparecerán en la pantalla de Ajustes.

2.- Habilitar debugar por bluetooth en el móvil Android

Abriremos la app Android Wear en el móvil y accederemos a la pantalla Ajustes desde la ActionBar.

Allí habilitaremos la opción Debugging over Bluetooth:

En el momento en el que tengamos tanto el Host como el Target conectados ya estará todo listo.

3.- Habilitar ADB Debugging y Debug over Bluetooth en el Android Wear

Desde la pantalla Ajustes del Android Wear iremos a las opciones de desarrollo y habilitaremos las opciones ADB Debugging y Debug over Bluetooth:

En este momento nos aparecerá una notificación en el Android Wear que no desaparecerá hasta que inhabilitemos la opción de Debug over Bluetooth:

Si miramos la app Android Wear de nuestro móvil, ahora nos tendría que aparecer el Target como conectado.

4.- Conectar el Host

Por último nos faltará conectar el Host, y para ello tendremos que ejecutar dos comandos ADB:

adb forward tcp:4444 localabstract:/adb-hub
adb connect localhost:4444

(Podemos seleccionar el número de puerto que queramos)

En este momento en la app Android Wear ya nos tendría que aparecer conectados tanto el Host como el Target, y ya podemos ejecutar apps desde Eclipse/Android Studio

Happy coding!! 

Apps Android y golpes de remo

En primer lugar quisiera dejar claro que la intención de este post no es hacer una critica de ninguna aplicación en concreto, sino simplemente comentar algunos errores que se cometen a la hora de desarrollar una app android y su posible solución.

El icono de una aplicación es su carta de presentación. 

El icono será la primera imagen que verá cualquier usuario potencial de nuestra aplicación, ya sea en medio de una búsqueda en Google Play, navegando por la red o en el móvil de un amigo. Además, si conseguimos que el usuario se descargue nuestra aplicación, cada vez que éste quiera ejecutarla, irá a buscar el icono, por lo tanto es una de las cosas que más tenemos que mimar.

Soy consciente de que no todo el mundo se puede permitir o quiere tirar de un diseñador para el icono de una app, pero no está de más mirar las guías de diseño de las distintas plataformas, como en el caso de android http://developer.android.com/design/style/iconography.html

Una vez dejado claro que no voy a entrar en temas de diseño, lo que no se puede permitir es que el icono de nuestra app se vea pixelado. En la siguiente imagen se puede ver el icono de la app de "La Caixa" que se ve totalente pixelado en el Nexus5.

Un icono pixelado demuestra poco cariño, ya que se trata simplemente de tener presente que nuestra app se va a ejecutar en terminales con distintas densidades/tamaños de pantalla y tenemos que asegurarnos de incluir el icono en el tamaño adecuado para todos y cada uno de ellos.

Los botones sin feedback son el mal.

Esto es así, no hay más que discutir. Si el diablo fuera programador, pondría todos los botones sin feedback. 

Si queremos usar un view como botón, o queremos customizar nuestros botones para que se integren mejor con la UI de nuestra app, debemos asegurarnos de que mostramos una respuesta visual a las pulsaciones http://developer.android.com/design/style/touch-feedback.html

 Sin una respuesta visual a la pulsación, el usuario puede pensar que no ha pulsado correctamente el botón y pulsar más de una vez, o creer que está pulsando sobre un elemento cuando realmente está pulsando sobre otro.

Por mi sorpresa, el botón de “send” para los mensajes privados de la app oficial de Twitter no tiene feedback. Supongo (o me gustaría pensar) que será un fallo que se les ha pasado por alto y que lo arreglarán pronto.

Si tu app no tiene menú, no muestres el icono de menú.

Leído así suena de lógica verdad? Pues por lo visto no tiene tanta lógica… A cada actualización de la app TomTom sigo esperando que saquen el botón del menú, pero por lo visto a ellos no les molesta un botón que no hace nada, y los de TomTom no son los únicos.

¿Splash screen? No, gracias!

El splash screen es una pantalla inútil que roba tiempo a nuestro usuario, y dado que él ha sido quien ha abierto la app, realmente hace falta decirle que app ha abierto? hace falta el autobombo?

Algunas apps utilizan el splash screen para ir cargando datos (por ejemplo la app de PayPal), el problema es que en casos de conexión a internet lenta, se queda el splash screen allí inmóvil y no se da ninguna información al usuario de que se están cargando datos.

Si nuestra app necesita cargar unos datos en el momento de iniciarse, es mejor cargar la pantalla inicial y que el usuario pueda ver que se están cargando unos datos utilizando recursos que nos ofrece la plataforma http://developer.android.com/design/building-blocks/progress.html

Cómo he dicho al principio del post, la idea no es criticar ninguna app porque si, sino resaltar algunos errores que para mi son básicos y que como usuario me molestan mucho.