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.

Apps para seguir las ventas/descargas de tus apps

A todos nos gusta hacer un seguimiento de las ventas/descargas de nuestras apps, aunque en ocasiones, las páginas oficiales no ofrecen todos los datos que nos gustaría tener, o simplemente, nos parece "engorroso" tener que acceder a sus webs cada día para mirar esos datos.

A lo largo del tiempo, he ido descubriendo algunas apps muy útiles para tal fin, que me dispongo a compartir.

Appmonger (Google Play - 2,99€):

Appmonger es una aplicación Android que obtiene los datos de ventas de apps de nuestra cuenta de Google Checkout y nos muestra estos datos utilizando distintos tipos de gráficos, y con los filtros que nosotros le queramos aplicar, bien sean filtros por apps, por intervalos de fecha, etc. La app también nos permite añadir widgets al escritorio de nuestro móvil para poder ver los datos que queramos sin tener que abrir la aplicación, e incluye notificaciones.

La única "pega" de esta app es que al hacer ella misma el cambio de divisas, a final de mes puede que nos varíe un poco el importe total de ventas, pero nada exagerado.

Sin duda alguna, una app muy recomendable, y más por su reducido precio.

Andlytics (Google Play - Gratis):

Andlytics es una aplicación Android que nos extrae los datos de nuestra cuenta de desarrollador android, y nos permite ver todos los datos de nuestras apps, comentarios, descargas totales, descargas activas, puntaciones... Un detalle a destacar de esta app es que si usamos AdMob para monetizar alguna de nuestras apps, lo podemos especificar y podemos ver también el revenue que tenemos para esa app.

La aplicación también nos permite recibir una notificación en cuanto detecta un cambio en los datos de alguna de las apps, así como exportar e importar los datos.

Otra aplicación más que recomendable para los desarrolladores Android.

  

AppViz2 (MacOs - $49):

AppViz2 es una aplicación para MacOs que obtiene los datos de nuestra cuenta de desarrollador iOS, y nos las muestra con unos gráficos que nos permiten ver cómo evolucionan las descargas/ventas de nuestras apps de una manera muy rápida y visual. AppViz2 no tan sólo nos muestra las descargas/ventas de nuestras apps, sino que también nos muestra la posición que ocupan nuestras apps en los distingos ránquings de la AppStore. 

Desde la aplicación también podremos ver todos los comentarios que dejan en la AppStore los usuarios.

Pese a su precio, si tienes aplicaciones subidas al AppStore, la facilidad de uso y toda la información que nos muestra hacen que esta sea una aplicación más que recomendable.

App Annie (Web - Gratis/Pago):

App Annie es una web que engloba distintos servicios para desarrolladores, y entre ellos están el poder hacer un seguimiento de las descargas/ventas diarias en los distintos markets de las distintas plataformas, así como de su posición dentro de estos markets. Además ofrecen servicios de análisis de estos datos/estadísticas.

Sin duda alguna vale la pena registrarse en esta web, ya que además de poder recibir un mail diario con los datos de nuestras apps, tienen un seguimiento del posicionamiento de las apps en los distintos markets que vale mucho la pena.

Mi propia classe "Log"

La mayoría de programadores Android utilizamos la classe Log. Para el que no la conozca, esta classe nos permite mandar "mensajes" que podemos ver con el LogCat, y esto resulta útil para poder ver el valor de una variable en un punto determinado, o si se ha llamado a un método en concreto, para verificar el ciclo de vida de un Activity, y así un largo etc.

El "problema" es que si no quitamos (o comentamos) estos "menajes", también serán visibles para los usuarios de nuestras apps si consultan el Log en su terminal, o si miran el LogCat conectando su terminal a un PC, y esto no siempre queremos que ocurra.

Para evitar esto, en su tiempo cree una classe propia que permite mostrar/ocultar todos estos Logs cambiando sólo un parámetro, y la comparto con vosotros por si os resulta útil...

La classe en cuestión es esta:

public class MyLog {

 private static final Boolean LOGS_ON = true;

 // Send a DEBUG log message.
 public static void d(String tag, String msg) {
  if (LOGS_ON) {
   Log.d(tag, msg);
  }
 }

 // Send a DEBUG log message and log the exception.
 public static void d(String tag, String msg, Throwable tr) {
  if (LOGS_ON) {
   Log.d(tag, msg, tr);
  }
 }

 // Send an INFO log message.
 public static void i(String tag, String msg) {
  if (LOGS_ON) {
   Log.i(tag, msg);
  }
 }

 // Send a INFO log message and log the exception.
 public static void i(String tag, String msg, Throwable tr) {
  if (LOGS_ON) {
   Log.i(tag, msg, tr);
  }
 }

 // Send an ERROR log message.
 public static void e(String tag, String msg) {
  if (LOGS_ON) {
   Log.e(tag, msg);
  }
 }

 // Send a ERROR log message and log the exception.
 public static void e(String tag, String msg, Throwable tr) {
  if (LOGS_ON) {
   Log.e(tag, msg, tr);
  }
 }

 // Handy function to get a loggable stack trace from a Throwable
 public static void getStackTraceString(Throwable tr) {
  if (LOGS_ON) {
   Log.getStackTraceString(tr);
  }
 }

 // Send a VERBOSE log message.
 public static void v(String tag, String msg) {
  if (LOGS_ON) {
   Log.v(tag, msg);
  }
 }

 // Send a VERBOSE log message and log the exception.
 public static void v(String tag, String msg, Throwable tr) {
  if (LOGS_ON) {
   Log.v(tag, msg, tr);
  }
 }

 // Send a WARN log message.
 public static void w(String tag, String msg) {
  if (LOGS_ON) {
   Log.w(tag, msg);
  }
 }
}

Y para usarla tan sólo tendremos que utilizar "MyLog.i(tag, msg)" en lugar de "Log.i(tag, msg)". Si queremos ocultar todos los logs, simplemente cambiamos el valor de la constante LOGS_ON a "false" y ya no se mostrará ningún Log.

Primer post...

A pesar de que nunca he sido muy bloguero, llevo tiempo con ganas de tener un sitio en el que poder compartir todo tipo de cosas relacionadas con el mundo de la programación Android, así que me he decidido a crear este blogger, a ver cómo va la cosa...