Ir al contenido principal

Dos herramientas muy útiles generando para Android

La versión Evolution 2 de Genexus incluye generadores para iOS (iPad, iPhone e iPod), Android (Galaxy, etc) y Blackberry (RIM).

Cuando se trabaja con nuevas tecnologías es importante contar con algunas herramientas que faciliten la tarea.

En este sentido hay dos que para mi han resultado muy útiles:



Capturar pantallas de la aplicación

El desarrollo lo hago con mi Galaxy conectado al USB de mi computadora, con eso el F5 (RUN) de Genexus copia y ejecuta el APK (la aplicación) directamente en el Galaxy.

Esto me ha resultado mucho más práctico que el emulador de Android: más ágil, más real, puedo usar más recursos del device que en el emulador no están disponibles, etc.

La ventaja que tenía el emulador es que al tener en la misma pantalla del PC la información, capturar una pantalla era muy sencillo (simplemente un print screen o el snipping de W7).

Eso hasta que encontré el "ddms" que es una tool que viene con el SDK de Android (bajo el directorio de android\tools).

Levanta una "consola" del device bastante interesante:



Entre las posibilidades está la de capturar la pantalla del Android y salvarla como un archivo.

Nota: Para el iPad uso la combinación de teclas de "print screen" y eso me lo envío por mail.

Debugging

Otra tool que me ha servido es el CatLog que es una aplicación para Android que permite leer el log del mismo, buscar, etc.

En el caso de aplicaciones Genexus, las mismas envian mensajes a ese log, por lo cual si ejecuto una aplicación registrará, entre otras cosas, un "getdata". Por lo cual busco ese "string" con esta herramienta, ahí obtengo el "process id" y luego puedo ver todos los mensajes de ese proceso (los mensajes que envió la aplicación Genexus).

Ese "tramo" de log lo puedo salvar, enviar por mail, etc.

¿Para qué lo he usado?

Por ejemplo: para ver qué servicios REST se están consumiendo, con qué parámetros, etc. Un ejemplo de un tramo de log:

URI='http://labs.genexus.com:8080/Vdir/rest/WorkWithDevicesCompany_Company_Section_General?CompanyId=13820&fmt=json'>
11-09 22:22:22.375 D/EntityService(566): Task DEQUEUE:
11-09 22:22:22.375 I/GeneXusApplication(566): GetData from http://labs.genexus.com:8080/Vdir/rest/WorkWithDevicesCompany_Company_Detail?CompanyId=13820&fmt=json


Entonces copiando esa misma URL (http://labs.genexus.com:8080/Vdir/rest/WorkWithDevicesCompany_Company_Detail?CompanyId=13820&fmt=json) en un Browser puedo ver qué está devolviendo el server.

Update 20/Abril

El logcat también se puede ejecutar con el emulador de Android.

Para hacerlo:

1. En un command prompt ejecutar:c:\directorio_donde_esta_SDK\platform-tools\adb logcat > log.txt
2. Ejecutar la aplicación (F5 en Genexus)
3. Cuando se quiera para el "log" se da Ctrl+C en el command prompt y "corta" el log

En el archivo log.txt queda toda la información.

Update 19/Junio (Si bien no tiene que ver con las herramientas dejo el Tip acá.)

Quería probar con Android 4.0, para eso instalé el SDK R18 y luego segui las instrucciones de este link:

http://software.intel.com/en-us/articles/intel-atom-x86-image-for-android-ice-cream-sandwich-installation-instructions-recommended/

Tip: Genexus levanta el emulador con MygxAvd pero si ya hay un device conectado usa el device y si antes se levanta una imagen (AVDManager) usa ese. De este modo si se quiere probar con diferentes versiones o AVDs simplemente se crean las mismas y antes de dar F5 en la KB se levanta la que se quiera usar.

Update 10/Abril/2014

El DDMS ha mejorado mucho en las nuevas versiones del SDK (22.3 en mi caso).

Hay otro tip que puede servir: para filtrar los mensajes de una aplicación Genexus lo que me ha dado mejor resultado es primero filtrar por "Genexus" (flecha roja) porque seguro algun mensaje incluye esa palabra, ahí identificar el Process Id (PID) (flecha azul):



Luego filtro por el proceso:



De este modo veo todos los mensajes de la aplicación (incluyan o no la palabra Genexus)

Update 28/Abril/2014

A partir del build 80088 de la Evolution 3 si se tiene un comando "msg("mi mensaje", status)", el mismo es enviado al output con lo cual queda en el logcat/ddms.

Nota: si la app es offline toda la lógica ejecuta en el device, si es online entonces esto funciona para los "user" y "control" events, para los "system" (load, refresh, etc) que se ejecutan en el server no quedan los msg en el log.

Update 08/06/2016 

Mucha agua ha corrido bajo el puente y en las nuevas versiones del SDK de Android (25) no existe más el DDMS así que uso el monitor.bat que ya venía en las anteriores y es bastante similar:

Tip: para ejecutarlo, al menos en W10, solo lo logré ejecutando un command prompt como administrador (run as administrator del cmd) y ahi ejecutarlo: C:\android-sdk-windows\tools>monitor

Comentarios

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en