- Creamos con el wizard un nuevo proyecto Android;
- Definimos el nombre del proyecto (Watch), el cual identifica al mismo solamente en el espacio de trabajo (Eclipse).
- Definimos la versión a utilizarse para compilar el proyecto (Android 2.1-update1), la cual define todas las características propias de las clases utilizadas en el proyecto, para la plataforma definida.
- Definimos el nombre de la aplicación (Watcher), visible en los administradores de aplicaciones instaladas del dispositivo.
Definimos el nombre del paquete (cHackAll.Watch), usado para referenciar a las clases y elementos del proyecto desde el mismo y desde otros proyectos. También es utilizado para definir el nombre del archivo compilado (/data/app/cHackAll.Watch.apk).
- Marcamos la casilla para la creación de una actividad básica y definimos su nombre (MainActivity), lo que genera un archivo fuente y esqueleto de la clase con el mismo nombre.
- Definimos la versión mínima de SDK[API] del proyecto (7), usado para verificar si el paquete puede o no ser instalado y ejecutado en el dispositivo (usado también en los markets).
[img width=275 height=400]http://chackall.delphiaccess.com/android/s001.png[/img]
- Hasta éste punto hemos repasado lo básico y tenemos una plantilla por defecto;
[img width=400 height=300]http://chackall.delphiaccess.com/android/s002.png[/img]
Ahora, vamos configurando ciertas características del proyecto;
- Eliminamos la 'carpeta' layout, la cual contiene una interfaz (formulario, forma, vista, UI, etc.), pues para los fines de éste ejemplo no habrá interacción con el usuario. Es importante recalcar que ésta o estas interfaces contenidas en ésta carpeta son definidas en tiempo de diseño y como en otros lenguajes es posible definirlos en tiempo de ejecución mediante código en forma dinámica.
- Eliminamos la carpeta values, la cual contiene y puede de contener varias constantes del proyecto accesibles desde cualquier parte del mismo. Inicialmente contiene el nombre visible en los accesos del dispositivo.
Se pueden crear carpetas con diversos nombres que contengan archivos XML con mensajes en idiomas específicos par ala internacionalización del proyecto, también pueden contener archivos de imágenes, librerías, archivos binarios y otros.
- Habiendo eliminado las carpetas values y layout, provocamos errores en el proyecto que hace referencia a la configuración por defecto. Corregimos el nombre de la aplicación (Application Attributes > Label) con una constante (Watcher), dicho valor es visible en el acceso a la aplicación, listado de aplicaciones y otros. Eliminamos el nombre (Label) de la clase MainActivity pues nuestra actividad va a intentar iniciar nuestro servicio y ha de finalizar inmediatamente.
- Finalmente definimos el tema (máscara, plantilla, estilo, etc.) de MainActiviry para que al ser ejecutado el dispositivo defina las características visuales del mismo. Para éste ejemplo y al no haber interacción alguna con el usuario lo definimos como "@android:style/Theme.NoDisplay" lo cual utiliza una plantilla propia de la SDK sin interfaz, entonces al momento de correr la aplicación no se verá el parpadeo de una ventana que aparece y se oculta o cierra.
[img width=400 height=300]http://chackall.delphiaccess.com/android/s003.png[/img]
- Finalmente corregimos el último error de MainActivity el cual hace referencia a la ya citada interfaz de usuario de la plantilla inicial;
[img width=400 height=300]http://chackall.delphiaccess.com/android/s004.png[/img]
- Bien, ahora vamos un poco contra la corriente; las directrices Programación Orientada a Objetos nos enseñan a escribir cada clase en un archivo clase separado. Por varios motivos ajenos a éste ejemplo es siempre lo mejor, pero en éste ejemplo escribiremos dentro de la clase de la actividad inicial la clase de nuestro servicio.
- Finalmente escribimos el código que ha de iniciar el servicio en la actividad inicial;
[img width=400 height=300]http://chackall.delphiaccess.com/android/s005.png[/img]
- Ejecutamos;
[img width=214 height=400]http://chackall.delphiaccess.com/android/s006.png[/img]
- Guardamos;
[img width=400 height=123]http://chackall.delphiaccess.com/android/s007.png[/img]
- Eclipse compilará, ejecutará “adb install” para instalar el paquete en el dispositivo (o emulador) y “adb shell ‘am start…” para ejecutar al paquete recién instalado;
- Hasta éste punto tenemos nuestra aplicación que debiese correr un servicio (lo cual podría traducirse en algo así como un proceso residente), sin embargo todavía nos falta configurar nuestro paquete para que la plataforma reconozca al servicio que está dentro de otra clase. Para ello debemos cambiamos la clase del servicio a pública para que sea visible desde fuera de la actividad, y a estática pues la instancia de dicha clase será única.
- Habiendo hecho este cambio menor, cambiamos la configuración de nuestro proyecto añadiendo un nuevo servicio a la aplicación (paquete);
[img width=400 height=300]http://chackall.delphiaccess.com/android/s009.png[/img]
[img width=400 height=359]http://chackall.delphiaccess.com/android/s010.png[/img]
[img width=400 height=300]http://chackall.delphiaccess.com/android/s011.png[/img]
- Hacemos la referencia al Servicio;
[img width=400 height=333]http://chackall.delphiaccess.com/android/s012.png[/img]
- Modificamos la actividad y servicio con un mensaje (Toast), en la creación de la clase estática de nuestro servicio (MainService) para saber que todo va bien;
[img width=400 height=300]http://chackall.delphiaccess.com/android/s013.png[/img]
- Guardamos los cambios, instalamos y comprobamos el mensaje proveniente desde el servicio;
- Listo, nuestro “proceso residente” funciona! ahora démosle un posible uso tomando el segundo ejemplo de éste post escrito en C (ó GCC [NDK]). Al igual que el escrito en C vamos a realizar una suave vibración para notificar al usuario que se ha realizado la copia y para saber que debemos realizar la copia vamos a escribir el código dentro de un hilo que esté verificando cada segundo la presencia de una nueva foto o video (en mi caso localizado en “/sdcard/DCIM/100MSDCF”).
- Finalmente corregiremos un BUG del ejemplo inicial causado al extraer la memoria externa del dispositivo.
A diferencia del ejemplo escrito en C, que es ejecutado en un entorno de super usuario, nuestra aplicación requiere un par de privilegios explicitos otorgados por el usuario al momento de instalar el paquete en el dispositivo, éstos serán para realizar la vibración y poder escribir en la memoria externa (microSD) del dispositivo pues es allí donde normalmente se almacenan las fotografías y videos capturados con el mismo;
[img width=400 height=300]http://chackall.delphiaccess.com/android/s015.png[/img]
[img width=400 height=300]http://chackall.delphiaccess.com/android/s016.png[/img]
En el anterior ejemplo (adjunto), no se ha realizado una explicación del onBind//bindService//ServiceBinder//ServiceConnection por ser un servicio que no se comunica con otros servicios o actividades, tampoco se ha realizado una explicación de los Receivers que podían haber sido utilizados para la notificación de extracción de la memoria externa o hasta la ejecución automática del servicio;
[img width=400 height=242]http://chackall.delphiaccess.com/android/s017.png[/img]
Salud!
