2010-07-01 8 views

Respuesta

12

No. No hay fundamental diferencia.

Dicho esto, la aplicación subclase de android.app.app es muy es un buen lugar para almacenar datos globales/estatales. Solo hay una instancia y todo lo que deriva de Context tiene acceso a ella.

También estoy seguro de que vincular un servicio a una aplicación dará como resultado vidas extrañas si no tiene cuidado. Lo que quiero decir es que a pesar de que su aplicación está fuera de la vista y no tiene actividades activas, su aplicación aún podría existir porque su servicio aún existe. Su servicio todavía existe porque su aplicación todavía existe. Tendría que cerrar el servicio manualmente en función de algún evento que no sea en Destroy.

+0

Gracias. Por lo tanto, no hay una forma clara de cerrar el servicio en este caso. –

+0

Tengo que preguntar, ¿por qué quiere un servicio si va a almacenar los datos en el objeto Aplicación? Todas sus actividades tienen acceso al objeto de la aplicación a través de getApplication(). –

+0

El servicio va a realizar todas las E/S. Estoy tratando de implementar algo como http://stackoverflow.com/questions/3141632/android-service-interacting-with-multiple-activities Tal vez pueda almacenar este estado/datos globales en mi servicio (?) . No sé si es un buen diseño o un mal diseño porque es la primera vez que trabajo con múltiples actividades y servicios. –

3

La respuesta de @ Jere.Jones no es 100% correcta. Tiene una instancia de clase de aplicación por proceso. Entonces, si ejecuta su servicio en un proceso separado, p. con

<service 
     android:name=".engine.NetworkService" 
     android:exported="false" 
     android:process=":xxxService" /> 

tiene dos instancias separadas de Appliaction, lo que significa que si tiene que "mantener un estado" debe asegurar su bien no en el proceso de cruce, o usted tiene que utilizar IPC para sincronizar estos sacia.

Cuestiones relacionadas