vida una studio programacion libros libro ejemplo desarrollar ciclo aprende aplicaciones aplicacion android service lifecycle

android - una - Ciclo de vida de la clase de aplicación mientras se ejecuta el servicio



manual de programacion android pdf (2)

Estoy desarrollando una aplicación con clase de aplicación personalizada que inicializa un par de singleton para que vivan durante el tiempo de trabajo de todas las aplicaciones. También tengo un par de servicios en mi aplicación que funcionan con estos singletons. ¿Es posible que la clase de aplicación sea destruida por Android con instancias de singleton antes de los servicios para que los servicios no puedan usarlos? ¿O la aplicación vive siempre incluso para los servicios de su contexto? ¿Cuál es la mejor manera de encontrar una salida a esta situación?

Gracias.


Desde mi comprensión, el servicio no puede vivir sin el context aplicación, el servicio está vinculado a la aplicación con la referencia de Context así que creo que si la aplicación se destruye también se mata el Context y eso lleva a que todos los componentes hayan sido eliminados,

puedes leer aquí para más información

http://developer.android.com/guide/components/fundamentals.html#proclife


  • En cuanto al objeto de la aplicación:

El objeto de la aplicación es el principal punto de partida absoluto en cualquier aplicación de Android. Siempre existirá antes de cualquiera de los elementos declarados Manifiesto, como actividad, servicio y BroadcastReceiver. Así que relájate que los singletons estarán ahí para ti.

  • En cuanto al paradigma singleton:

Ese es un gran tema de debate, puedes buscar en Google más sobre él, así que lo que sigue es mi opinión personal sobre él. Cualquiera que sea el motivo de sus singletons (una base de datos, un almacenamiento en caché de mapas de bits, un FileUtils), creo que está bien y es correcto inicializarlos en el primer punto de entrada de su aplicación, que es la Aplicación. Pero la aplicación en sí misma no es un objeto destinado a transportar o mantener esos objetos, de esa manera mi enfoque de diseño sugerido es:

=> en tu objeto / clase singleton tendrás que:

private static MySingletonClass instance; // reference to the single object private MySingletonClass(Context c){ // private constructor to avoid construction from anywhere else // let''s say it needs the context for construction because it''s a database singleton } public static MySingletonClass get(){ // if(instance == null) throw new RuntimeException("This singleton must be initialised before anything else"); return instance; } public static void init(Context c){ // call the initialisation from the Application instance = new MySingletonClass(c); }

=> y luego en su objeto Aplicación simplemente inicia el singleton

onCreate(){ MySingletonClass.init(getApplicationContext()); }

de esa manera mantendrá la inicialización necesaria, aplicará el patrón de singleton, pero para acceder al objeto que llama a esa clase de objeto, no a la aplicación. Sé que es solo una diferencia organizativa, pero creo que eso es lo que separa el código bueno y el malo.

Entonces, por ejemplo, en su servicio, la llamada es: MySingletonClass.get() y nunca debe ser MyApplication.mySingle .

Espero eso ayude.