2011-11-13 24 views
5

Tengo una aplicación para Android, en la que las actividades activan operaciones de larga ejecución que se ejecutan en segundo plano. Estas operaciones interactúan con las actividades cuando terminen. Estoy desarrollando un componente que maneja el acoplamiento Activity/Long-Running-Task, cuidando que las actividades sean destruidas y recreadas.'Servicio' de Android de larga duración

Ahora que el componente está implementado como un servicio de Android. Las actividades llaman bindService y usan el IBinder resultante para iniciar y rastrear tareas. Decidí no usar StartService, porque prefiero la API más completa posible a través de una interfaz Java.

Ahora el problema. La actividad A se inicia, se une al servicio y llama a serviceApi.runTask (...). La actividad A luego se destruye (porque el usuario enciende el teléfono, por ejemplo) y se recrea como Actividad A '. A 'se une nuevamente al servicio, anuncia su existencia y todo debe funcionar correctamente.

Excepto que mi servicio se destruye. Cuando se destruye la Actividad A, se desvincula del servicio. Android ve que no hay más clientes y mata el servicio. Cuando se crea la Actividad A ', el servicio se crea nuevamente y pierdo todo lo que tenía el servicio anterior.

La única solución que puedo ver es usar un singleton para el servicio. Y luego, realmente no tiene que ser un servicio de Android, solo una instancia accesible para todos. ¿Eso está mal visto en Android? ¿Hay un mejor diseño que se adapte a este problema?


Editted: Incluso si llamo StartService y luego se unen a ella, nada garantiza que la instancia de servicio existirá siempre y cuando la aplicación se está ejecutando. Android puede matar los servicios adherentes si los recursos son bajos. La eliminación del servicio causará un mal funcionamiento de la aplicación, y no puedo tener eso.

Respuesta

7

Incluso si llamo StartService y luego se unen a ella, nada garantiza que la instancia de servicio existir mientras se ejecuta la aplicación.

Correcto.

Android puede matar los servicios fijos si los recursos son bajos.

Corrija también. Todo lo "adherente" significa que Android podría reiniciar el servicio.

La eliminación del servicio causará el mal funcionamiento de la aplicación, y no puedo tenerlo.

Es imposible crear un servicio que garantice su ejecución para siempre.Para empezar, los usuarios pueden deshacerse de su servicio cuando lo deseen, ya que los usuarios detestan a los desarrolladores que tienen servicios inútiles que se ejecutan para siempre. Escribir servicios eternos es necesario solo en muy pocos casos; de lo contrario, es solo una programación descuidada.

La única solución que puedo ver es usar un singleton para el servicio. Y luego, realmente no tiene que ser un servicio de Android, solo una instancia accesible para todos. ¿Eso está mal visto en Android?

Singleton (alias, miembros de datos estáticos) desaparecerá cuando se termina el proceso. El proceso finalizará eventualmente, particularmente si no hay servicios activos y ninguna de sus actividades está en primer plano.

+0

Gracias, Commonware. El componente (por falta de una palabra mejor) solo necesito ejecutarlo mientras el proceso de la aplicación está funcionando y el usuario lo está usando. Una vez que el usuario cierra la aplicación, el componente se puede cerrar también, ya que su único propósito es coordinar tareas relacionadas con la IU asíncronas en el proceso. Necesito un servicio que revise periódicamente las actualizaciones del servidor (aún no me decidí por C2DM). Lo implementaré como un servicio efímero que se apaga después de las encuestas. – zmbq

0

Tengo que crear un servicio persistente. Consulte this manual.

En pocas palabras: no llame al bindService, llame al startService.

Cuestiones relacionadas