Este documento describe varios ejemplos de implementación de servicios en Android. El primer ejemplo muestra un servicio vinculado que se ejecuta en el hilo principal y utiliza Messengers para comunicarse con los clientes. Los ejemplos 2 y 3 muestran un servicio remoto que implementa AIDL para comunicarse con clientes en el mismo APK o en uno diferente.

1. Máster Universitario en Ingeniería Informática
– Arquitecturas y Plataformas Móviles –
Práctica 3: Servicios en Android
Para el Ejemplo 1 Messenger-Service-Example:
1. A partir de la documentación disponible en:
 http://developer.android.com/guide/components/services.htm
l
 http://developer.android.com/guide/components/bound-
services.html
identificar correctamente el tipo de servicio que se está
implementando (¿Bounded o Started?). Estudiar también el
mecanismo de comunicación con los clientes.
Es tipo Bounded y la comunicación con los clientes se realiza
mediante Messengers (Handlers, messengers y binders).
2. El servicio del ejemplo ¿dónde se ejecuta? ¿en el main thread?
¿en un thread
aparte? ¿en un proceso aparte?
Se ejecuta en el Main Thread, dado que no se indica proceso
independiente ni se llama a un thread aparte para ejecutar dicho
código.
3. Modificar la implementación del servicio para que se ejecute
siempre en un
proceso aparte. Con el servicio en ejecución, ¿qué sucede si el
proceso
donde se ejecuta el servicio se mata desde el DDMS?
Se vuelve a crear y bindear a la activity, puesto que se bindea en el
oncreate de la actividad con el flag BIND_AUTO_CREATE, lo que
implica que se creará automáticamente el servicio mientras exista el
binding.
4. Extender la implementación del servicio de forma que se
responda a las
peticiones de los clientes con un mensaje informando de la hora,
minuto y
segundo en la que se procesa la petición en vez del mensaje de tipo
Toast
que se incluye en el servicio de ejemplo.
5. ¿Qué sucedería si múltiples clientes realizasen peticiones en
paralelo al
servicio? ¿Se atienden en serie o de forma simultánea? Razonar la
respuesta.

2. Se atienden en serie (secuencialmente), dado que el servicio utiliza
internamente Binders, que son interfaces con bloqueo.
6. ¿Qué tipo de acoplamiento existe entre la implementación del
cliente y del
servicio? Dicho de otra forma, si se modifica la implementación del
servicio,
¿cómo puede afectar a la implementación del cliente?
El cliente necesita saber qué mensajes están disponibles (ints) para
enviarlos y que el handler los maneje. Si cambia la implementación,
el cliente no sirve.
7. En caso de ser posible, ¿qué cambios habría que realizar en el
proyecto para
separar el servicio y el cliente en apks diferentes? ¿Cuál sería la mejor
estrategia a adoptar para realizar la comunicación entre los clientes y
el
servidor?
Habría que separar cliente y servicios en proyectos diferentes, saber
el nombre completo de la clase del servicio y comprobar en el cliente
que el servicio está ejecutándose antes de usarlo (tal y como se hace
actualmente).
8. En la documentación de Android Developers
(http://developer.android.com/guide/components/services.html) se
indica lo
siguiente: “To ensure your app is secure, always use an explicit intent
when
starting or binding your Service and do not declare intent filters for
the
service.” Explica por qué puede ser inseguro declarar intent filters
para el
servicio.
En la documentación se dice: “Using an implicit intent to start a
service is a security hazard because you cannot be certain what
service will respond to the intent, and the user cannot see which
service starts. Beginning with Android 5.0 (API level 21), the system
throws an exception if you call bindService() with an implicit intent.”
Propón un mecanismo alternativo para que un cliente pueda iniciar
(o hacer bind) para el caso de un servicio remoto sin que el cliente
tenga que
conocer, en tiempo de compilación, la clase que implementa el
servicio.

4. Para los Ejemplos 2 (RemoteServiceExample) y 3
(RemoteServiceClientExample):
1. Estudiar el ciclo de vida del Ejemplo 2 utilizando el cliente
incluido en el
mismo apk. ¿Dónde se ejecuta el servicio (main thread, thread aparte,
proceso aparte …?
Se ejecuta en el Main Thread, dado que no se indica proceso
independiente ni se llama a un thread aparte para ejecutar dicho
código.
2. Se trata de un servicio que, simultáneamente, es de tipo started
y bounded.
¿Sería posible convertirlo en un servicio exclusivamente de tipo
bounded?
¿Qué ventajas/inconvenientes presentaría con respecto a la
implementación
del ejemplo?
Sí, simplemente no se utiliza el onStart para invocar al servicio. Las
ventajas e inconvenientes dependen del objetivo de la aplicación.
(Véase ocumentación).
Binding to a Started Service
As discussed in the Services document, you can create a service that is both started and
bound. That is, the service can be started by calling startService(), which allows the
service to run indefinitely, and also allow a client to bind to the service by
calling bindService().
If you do allow your service to be started and bound, then when the service has been started,
the system does not destroy the service when all clients unbind. Instead, you must explicitly
stop the service, by calling stopSelf() or stopService().
Although you should usually implement either onBind() or onStartCommand(), it's
sometimes necessary to implement both. For example, a music player might find it useful to
allow its service to run indefinitely and also provide binding. This way, an activity can start the
service to play some music and the music continues to play even if the user leaves the
application. Then, when the user returns to the application, the activity can bind to the service
to regain control of playback.
Be sure to read the section about Managing the Lifecycle of a Bound Service, for more
information about the service lifecycle when adding binding to a started service.
3. Extender la implementación del servicio para incluir un método
void setCounter(int newCounter);
de forma que los clientes puedan modificar el valor del contador
interno
del servicio. ¡Atención a los posibles accesos concurrentes!

5. 4. El cliente incluido en el Ejemplo 2 (y también el del Ejemplo 3,
que es
idéntico al del Ejemplo 2 excepto por su ID) guarda internamente
información sobre el estado del servicio. Más concretamente, se
almacena
la condición de started/stopped del servicio. ¿Qué posibles problemas
tiene
esta solución?
Si hay varios clientes utilizando el servicio, o si por algún motivo el
servicio se para inesperadamente el estado no estaría actualizado.
¿Sería posible extender la implementación del servicio de forma que
se pueda preguntar al propio servicio si está iniciado o no?
¿Sería la implementación dependiente de si el servicio es de tipo
bounded o
started?
5. Probar el cliente externo incluido en el Ejemplo 3. ¿Qué
diferencias hay en
su comportamiento con respecto al cliente incluido en el Ejemplo 2?
Modificar la implementación del servicio para que se ejecute en un
proceso
independiente, ¿qué consecuencias supone para el cliente del
Ejemplo 2?
¿y para el cliente del Ejemplo 3?
6. Razonar las ventajas e inconvenientes que supone la
implementación de un
servicio remoto basado en AIDL con respecto a la utilización de
Messengers.