manera más ingeniosa de usar BroadcastReceiver en un producto único y más

Question

Tengo un producto único que almacena cierta información sobre el usuario prudente de mi solicitud. Por el momento, se almacena de inicio de sesión del usuario y la ubicación del usuario.

1) La ubicación se encuentra a través de un servicio. Por el momento, el servicio hace referencia a mi Singleton directamente a rellenar la longitud y latitud en ella. Me gustaría utilizar un BroadcastReceiver enviar una difusión que los oye Singleton y usos para actualizar los valores, en su lugar.

Sin embargo, para registrar el BroadcastReceiver, necesito un contexto en mi Singleton. ¿Cuál es la manera más hábil para lograr lo que estoy queriendo. BroadcastReceiver es, posiblemente, no el objeto apropiado?

2) Además, ¿qué problemas que estoy viendo con el uso de un producto único? Asumo que Android será posiblemente recuperar esa memoria en un momento dado (que, obviamente, sería malo); Entonces, ¿cómo puedo evitar eso? ¿Podría pasar en el contexto de la aplicación y almacenarlo en una variable miembro bancada esto?

La documentación de Android: "Pero, el ciclo de vida de un estático no es así bajo su control, de modo que al cumplir con el modelo de ciclo de vida, la clase de aplicación debe iniciar y derribar objetos éstos estática en el onCreate () y onTerminate () de la clase de aplicación," pero no estoy del todo seguro de cómo lograr esto.

Answer 1

However, to register the BroadcastReceiver, I need a Context in my singleton. What is the slickest way to achieve what I'm wanting. Is BroadcastReceiver possibly not the appropriate > object?

The "slickest way" is to not do what you are doing. Please only register a BroadcastReceiver from an Activity, Service, or maybe an Application. You must unregister this BroadcastReceiver when the Activity, Service, or Application is destroyed.

I assume that Android will possibly reclaim this memory at any given time (which would obviously be bad); so how can I prevent that?

You don't. Android reserves the right to terminate your process at any time (e.g., to reclaim memory). Task killers on Android 2.1 and previous will terminate your process at any time. Once all components of your application are destroyed, Android may recycle your process at any time, clearing out your heap at the same time. And so on.

Only put things in memory that you don't mind losing.

It is best to think of your "application" as a basket of loosely-coupled components, not as a monolithic entity.

Would passing in the application's Context and storing it in a member variable thwart this?

No.

The Android documentation states: "But, the life cycle of a static is not well under your control; so to abide by the life-cycle model, the application class should initiate and tear down these static objects in the onCreate() and onTerminate() methods of the Application Class," but I'm not entirely sure how to accomplish this.

Create a subclass of Application and indicate in the manifest that Android should use it, via the android:name attribute on the <application> element.