¿Singletons vs. Contexto de aplicación en Android?

Recordando esta publicación que enumera varios problemas de uso de singletons y después de haber visto varios ejemplos de aplicaciones de Android que usan el patrón de singleton, me pregunto si es una buena idea usar Singletons en lugar de instancias individuales compartidas a través del estado global de la aplicación (subclasificar android.os.Aplicación y obtenerla a través de context.getApplication ()).

¿Qué ventajas / inconvenientes tendrían ambos mecanismos?

Para ser honesto, espero la misma respuesta en este patrón Singleton post con aplicación web, ¡no es una buena idea! pero aplicado a Android. ¿Estoy en lo correcto? ¿Qué es diferente en DalvikVM de lo contrario?

EDITAR: Me gustaría tener opiniones sobre varios aspectos involucrados:

• Sincronización
• Reusabilidad
• Pruebas

Estoy muy en desacuerdo con la respuesta de Dianne Hackborn. Estamos eliminando poco a poco todos los singletons de nuestro proyecto a favor de objetos livianos con ámbito de tarea que pueden recrearse fácilmente cuando realmente los necesita.

Los singletons son una pesadilla para las pruebas y, si se inicializan perezosamente, introducirán "indeterminismo de estado" con efectos secundarios sutiles (que pueden surgir repentinamente cuando se trasladan llamadas getInstance()de un alcance a otro). La visibilidad ha sido mencionada como otro problema, y ​​dado que los singletons implican acceso "global" (= aleatorio) al estado compartido, pueden surgir errores sutiles cuando no se sincronizan adecuadamente en aplicaciones concurrentes.

Lo considero un antipatrón, es un mal estilo orientado a objetos que esencialmente equivale a mantener el estado global.

Para volver a su pregunta:

Aunque el contexto de la aplicación puede considerarse un singleton en sí mismo, está administrado por el marco y tiene un ciclo de vida , un alcance y una ruta de acceso bien definidos . Por lo tanto, creo que si necesita administrar el estado global de la aplicación, debería ir aquí, en ningún otro lado. Para cualquier otra cosa, reconsidere si realmente necesita un objeto singleton, o si también sería posible reescribir su clase singleton para crear instancias de objetos pequeños y de corta duración que realicen la tarea en cuestión.

Recomiendo mucho los singletons. Si tiene un singleton que necesita un contexto, tenga:

MySingleton.getInstance(Context c) {
    //
    // ... needing to create ...
    sInstance = new MySingleton(c.getApplicationContext());
}

Prefiero los singletons sobre la aplicación porque ayuda a mantener una aplicación mucho más organizada y modular; en lugar de tener un lugar donde se deba mantener todo su estado global en la aplicación, cada pieza por separado puede cuidarse sola. También es bueno el hecho de que los singletons se inicializan perezosamente (a petición) en lugar de guiarlo por el camino de hacer toda la inicialización por adelantado en Application.onCreate ().

No hay nada intrínsecamente malo con el uso de singletons. Solo úselos correctamente, cuando tenga sentido. El marco de Android en realidad tiene muchos de ellos, para mantener cachés por proceso de recursos cargados y otras cosas similares.

Además, para aplicaciones simples, el subprocesamiento múltiple no se convierte en un problema con los singletons, ya que, por diseño, todas las devoluciones de llamada estándar a la aplicación se envían en el hilo principal del proceso, por lo que no tendrá lugar el subproceso múltiple a menos que lo introduzca explícitamente a través de hilos o implícitamente mediante la publicación de un proveedor de contenido o servicio de IBinder en otros procesos.

Solo sea reflexivo sobre lo que está haciendo. :)

De: Desarrollador> referencia - Solicitud

Normalmente no hay necesidad de subclase Aplicación. En la mayoría de las situaciones, los singletons estáticos pueden proporcionar la misma funcionalidad de una manera más modular. Si su singleton necesita un contexto global (por ejemplo, para registrar receptores de difusión), la función para recuperarlo puede recibir un Context que internamente usa Context.getApplicationContext () cuando construye el singleton por primera vez.

La aplicación no es la misma que Singleton. Las razones son:

1. El método de la aplicación (como onCreate) se llama en el hilo ui;
2. El método de singleton se puede llamar en cualquier hilo;
3. En el método "onCreate" de la aplicación, puede crear una instancia de Handler;
4. Si el singleton se ejecuta en un subproceso sin interfaz de usuario, no podría crear una instancia de Handler;
5. La aplicación tiene la capacidad de administrar el ciclo de vida de las actividades en la aplicación. Tiene el método "registerActivityLifecycleCallbacks". Pero los singletons no tienen la capacidad.

Tuve el mismo problema: Singleton o hacer una subclase android.os.Application?

Primero probé con Singleton pero mi aplicación en algún momento hace una llamada al navegador

Intent myIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.google.com"));

y el problema es que, si el teléfono no tiene suficiente memoria, la mayoría de sus clases (incluso Singletons) se limpian para obtener algo de memoria, por lo que, al regresar del navegador a mi aplicación, se bloquea cada vez.

Solución: coloque los datos necesarios dentro de una subclase de la clase Aplicación.

Considere ambos al mismo tiempo:

• tener objetos singleton como instancias estáticas dentro de las clases.
• tener una clase común (Context) que devuelve las instancias singleton para todos los objetos singelton en su aplicación, lo que tiene la ventaja de que los nombres de los métodos en Context serán significativos, por ejemplo: context.getLoggedinUser () en lugar de User.getInstance ().

Además, le sugiero que expanda su Contexto para incluir no solo el acceso a objetos únicos, sino también algunas funcionalidades a las que se debe acceder globalmente, como por ejemplo: context.logOffUser (), context.readSavedData (), etc. Probablemente renombrando el Contexto a La fachada tendría sentido entonces.

En realidad son lo mismo. Hay una diferencia que puedo ver. Con la clase Aplicación, puede inicializar sus variables en Application.onCreate () y destruirlas en Application.onTerminate (). Con Singleton, debe confiar en VM inicializando y destruyendo estadísticas.

Mis 2 centavos:

Noté que algunos campos únicos / estáticos se restablecieron cuando se destruyó mi actividad. Me di cuenta de esto en algunos dispositivos de gama baja 2.3.

Mi caso era muy simple: solo tengo un archivo privado "init_done" y un método estático "init" al que llamé desde activity.onCreate (). Noté que el método init se estaba volviendo a ejecutar en alguna recreación de la actividad.

Si bien no puedo probar mi afirmación, puede estar relacionada con CUANDO el singleton / clase se creó / usó primero. Cuando la actividad se destruye / recicla, parece que todas las clases a las que solo se refiere esta actividad también se reciclan.

Moví mi instancia de singleton a una subclase de Aplicación. Los accedo desde la instancia de la aplicación. y, desde entonces, no notó el problema nuevamente.

Espero que esto pueda ayudar a alguien.

De la boca del caballo proverbial ...

Al desarrollar su aplicación, es posible que necesite compartir datos, contexto o servicios a nivel mundial a través de su aplicación. Por ejemplo, si su aplicación tiene datos de sesión, como el usuario actualmente conectado, es probable que desee exponer esta información. En Android, el patrón para resolver este problema es hacer que su instancia de android.app.Application posea todos los datos globales y luego trate su instancia de Aplicación como un singleton con accesos estáticos a los diversos datos y servicios.

Al escribir una aplicación de Android, se garantiza que solo tendrá una instancia de la clase android.app.Application, por lo que es seguro (y recomendado por el equipo de Google Android) tratarlo como un singleton. Es decir, puede agregar de manera segura un método estático getInstance () a la implementación de su aplicación. Al igual que:

public class AndroidApplication extends Application {

    private static AndroidApplication sInstance;

    public static AndroidApplication getInstance(){
        return sInstance;
    }

    @Override
    public void onCreate() {
        super.onCreate();
        sInstance = this;
    }
}

Mi actividad llama a terminar () (que no hace que termine de inmediato, pero lo hará eventualmente) y llama a Google Street Viewer. Cuando lo depuro en Eclipse, mi conexión con la aplicación se interrumpe cuando se llama a Street Viewer, lo que entiendo como la aplicación (completa) que se está cerrando, supuestamente para liberar memoria (ya que una sola actividad finalizada no debería causar este comportamiento) . Sin embargo, puedo guardar el estado en un paquete a través de onSaveInstanceState () y restaurarlo en el método onCreate () de la próxima actividad en la pila. Ya sea mediante el uso de un Singleton estático o la Aplicación de subclases, enfrento el estado de cierre y pérdida de la aplicación (a menos que la guarde en un Paquete). Entonces, desde mi experiencia, son lo mismo con respecto a la preservación del estado. Noté que la conexión se pierde en Android 4.1.2 y 4.2.2 pero no en 4.0.7 o 3.2.4,