Singletons vs. Anwendungskontext in Android?

Ich erinnere mich an diesen Beitrag, in dem einige Probleme bei der Verwendung von Singletons aufgezählt wurden und einige Beispiele für Android-Anwendungen mit Singleton-Muster gesehen wurden. Ich frage mich, ob es eine gute Idee ist, Singletons anstelle einzelner Instanzen zu verwenden, die über den globalen Anwendungsstatus gemeinsam genutzt werden (Unterklasse android.os.Application und deren Erhalt) durch context.getApplication ()).

Welche Vor- und Nachteile hätten beide Mechanismen?

Um ehrlich zu sein, erwarte ich die gleiche Antwort in diesem Beitrag Singleton-Muster mit Webanwendung, keine gute Idee! aber auf Android angewendet. Hab ich recht? Was ist sonst in DalvikVM anders?

EDIT: Ich hätte gerne Meinungen zu verschiedenen Aspekten:

• Synchronisation
• Wiederverwendbarkeit
• Testen

Ich bin mit Dianne Hackborns Antwort nicht einverstanden. Wir entfernen nach und nach alle Singletons aus unserem Projekt, um leichte, aufgabenbezogene Objekte zu erhalten, die einfach neu erstellt werden können, wenn Sie sie tatsächlich benötigen.

Singletons sind ein Albtraum für Tests und führen, wenn sie träge initialisiert werden, zu einem "Zustandsindeterminismus" mit subtilen Nebenwirkungen (die plötzlich auftreten können, wenn Anrufe getInstance()von einem Bereich in einen anderen verschoben werden). Die Sichtbarkeit wurde als ein weiteres Problem erwähnt, und da Singletons einen "globalen" (= zufälligen) Zugriff auf den gemeinsam genutzten Status implizieren , können subtile Fehler auftreten, wenn sie in gleichzeitigen Anwendungen nicht ordnungsgemäß synchronisiert werden.

Ich halte es für ein Anti-Muster, es ist ein schlechter objektorientierter Stil, der im Wesentlichen der Aufrechterhaltung des globalen Zustands gleichkommt.

Um auf Ihre Frage zurückzukommen:

Obwohl der App-Kontext selbst als Singleton betrachtet werden kann, wird er vom Framework verwaltet und verfügt über einen genau definierten Lebenszyklus , Umfang und Zugriffspfad. Daher glaube ich, dass wenn Sie den App-globalen Status verwalten müssen, er hier nirgendwo anders hingehen sollte. Überlegen Sie für alles andere, ob Sie wirklich ein Singleton-Objekt benötigen oder ob es auch möglich wäre, Ihre Singleton-Klasse neu zu schreiben, um stattdessen kleine, kurzlebige Objekte zu instanziieren, die die jeweilige Aufgabe ausführen.

Ich kann Singletons nur empfehlen. Wenn Sie einen Singleton haben, der einen Kontext benötigt, haben Sie:

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

Ich bevorzuge Singletons gegenüber Application, da dies dazu beiträgt, eine App viel organisierter und modularer zu gestalten. Anstatt einen Ort zu haben, an dem Ihr gesamter globaler Status in der App beibehalten werden muss, kann sich jedes einzelne Teil um sich selbst kümmern. Auch die Tatsache, dass Singletons (auf Anfrage) träge initialisiert werden, anstatt Sie auf den Weg zu führen, alle Initialisierungen in Application.onCreate () im Voraus durchzuführen, ist gut.

Es ist an sich nichts Falsches daran, Singletons zu verwenden. Verwenden Sie sie einfach richtig, wenn es Sinn macht. Das Android-Framework verfügt tatsächlich über viele davon, damit pro Prozess Caches mit geladenen Ressourcen und anderen derartigen Dingen verwaltet werden können.

Auch für einfache Anwendungen wird Multithreading bei Singletons nicht zum Problem, da standardmäßig alle Standardrückrufe an die App im Hauptthread des Prozesses gesendet werden, sodass kein Multithreading stattfindet, es sei denn, Sie führen es explizit über Threads oder ein implizit durch Veröffentlichung eines Inhaltsanbieters oder Dienstes IBinder für andere Prozesse.

Denken Sie nur darüber nach, was Sie tun. :) :)

Von: Entwickler> Referenz - Anwendung

Normalerweise muss die Anwendung nicht in Unterklassen unterteilt werden. In den meisten Situationen können statische Singletons dieselbe Funktionalität auf modularere Weise bereitstellen. Wenn Ihr Singleton einen globalen Kontext benötigt (zum Beispiel um Registrierungsempfänger zu registrieren), kann der Funktion zum Abrufen ein Kontext zugewiesen werden, der beim erstmaligen Erstellen des Singletons intern Context.getApplicationContext () verwendet.

Die Anwendung ist nicht die gleiche wie beim Singleton. Die Gründe sind:

1. Die Methode der Anwendung (z. B. onCreate) wird im UI-Thread aufgerufen.
2. Die Singleton-Methode kann in jedem Thread aufgerufen werden.
3. In der Methode "onCreate" von Application können Sie Handler instanziieren.
4. Wenn der Singleton in einem Nicht-UI-Thread ausgeführt wird, können Sie den Handler nicht instanziieren.
5. Die Anwendung hat die Fähigkeit, den Lebenszyklus der Aktivitäten in der App zu verwalten. Sie hat die Methode "registerActivityLifecycleCallbacks". Aber die Singletons haben nicht die Fähigkeit.

Ich hatte das gleiche Problem: Singleton oder eine Unterklasse android.os.Application erstellen?

Zuerst habe ich es mit dem Singleton versucht, aber meine App ruft irgendwann den Browser an

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

und das Problem ist, dass, wenn das Mobilteil nicht über genügend Speicher verfügt, die meisten Ihrer Klassen (sogar Singletons) bereinigt werden, um Speicherplatz zu erhalten. Bei der Rückkehr vom Browser zu meiner App stürzte es jedes Mal ab.

Lösung: Fügen Sie die erforderlichen Daten in eine Unterklasse der Anwendungsklasse ein.

Betrachten Sie beide gleichzeitig:

• Singleton-Objekte als statische Instanzen innerhalb der Klassen haben.
• Eine gemeinsame Klasse (Context) gibt die Singleton-Instanzen für alle Singelton-Objekte in Ihrer Anwendung zurück. Dies hat den Vorteil, dass die Methodennamen in Context beispielsweise von Bedeutung sind: context.getLoggedinUser () anstelle von User.getInstance ().

Darüber hinaus schlage ich vor, dass Sie Ihren Kontext erweitern, um nicht nur den Zugriff auf Singleton-Objekte, sondern auch einige Funktionen einzuschließen, auf die global zugegriffen werden muss, z. B. context.logOffUser (), context.readSavedData () usw. Vermutlich wird der Kontext in umbenannt Fassade würde dann Sinn machen.

Sie sind eigentlich gleich. Es gibt einen Unterschied, den ich sehen kann. Mit der Application-Klasse können Sie Ihre Variablen in Application.onCreate () initialisieren und in Application.onTerminate () zerstören. Bei Singleton müssen Sie sich darauf verlassen, dass die VM die Statik initialisiert und zerstört.

Meine 2 Cent:

Ich habe festgestellt, dass einige Singleton- / statische Felder zurückgesetzt wurden, als meine Aktivität zerstört wurde. Ich habe dies auf einigen Low-End-2.3-Geräten bemerkt.

Mein Fall war sehr einfach: Ich habe nur eine private Datei "init_done" und eine statische Methode "init", die ich von activity.onCreate () aufgerufen habe. Ich stelle fest, dass sich die Methode init bei einer Neuerstellung der Aktivität erneut selbst ausführte.

Obwohl ich meine Bestätigung nicht beweisen kann, kann dies damit zusammenhängen, WENN der Singleton / die Klasse zuerst erstellt / verwendet wurde. Wenn die Aktivität zerstört / recycelt wird, scheinen alle Klassen, auf die sich nur diese Aktivität bezieht, ebenfalls recycelt zu werden.

Ich habe meine Singleton-Instanz in eine Unterklasse von Application verschoben. Ich greife auf sie aus der Anwendungsinstanz zu. und bemerkte das Problem seitdem nicht mehr.

Ich hoffe das kann jemandem helfen.

Aus dem sprichwörtlichen Pferdemund ...

Bei der Entwicklung Ihrer App müssen Sie möglicherweise Daten, Kontext oder Dienste global für Ihre App freigeben. Wenn Ihre App beispielsweise Sitzungsdaten enthält, z. B. den aktuell angemeldeten Benutzer, möchten Sie diese Informationen wahrscheinlich verfügbar machen. In Android besteht das Muster zur Lösung dieses Problems darin, dass Ihre android.app.Application-Instanz alle globalen Daten besitzt und Ihre Anwendungsinstanz dann als Singleton mit statischen Zugriffsmethoden für die verschiedenen Daten und Dienste behandelt.

Wenn Sie eine Android-App schreiben, haben Sie garantiert nur eine Instanz der android.app.Application-Klasse. Daher ist es sicher (und vom Google Android-Team empfohlen), sie als Singleton zu behandeln. Das heißt, Sie können Ihrer Anwendungsimplementierung sicher eine statische getInstance () -Methode hinzufügen. Wie so:

public class AndroidApplication extends Application {

    private static AndroidApplication sInstance;

    public static AndroidApplication getInstance(){
        return sInstance;
    }

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

Meine Aktivität ruft finish () auf (was nicht sofort beendet wird, aber irgendwann erledigt wird) und ruft Google Street Viewer auf. Wenn ich es auf Eclipse debugge, wird meine Verbindung zur App unterbrochen, wenn Street Viewer aufgerufen wird. Ich verstehe, dass die (gesamte) Anwendung geschlossen wird, um Speicher freizugeben (da eine einzelne Aktivität, die beendet wird, dieses Verhalten nicht verursachen sollte). . Trotzdem kann ich den Status in einem Bundle über onSaveInstanceState () speichern und in der onCreate () -Methode der nächsten Aktivität im Stapel wiederherstellen. Entweder durch Verwendung eines statischen Singletons oder einer Unterklassenanwendung kann die Anwendung geschlossen werden und den Status verlieren (es sei denn, ich speichere sie in einem Bundle). Aus meiner Erfahrung sind sie in Bezug auf die Erhaltung des Staates gleich. Ich habe festgestellt, dass die Verbindung in Android 4.1.2 und 4.2.2 unterbrochen ist, jedoch nicht in 4.0.7 oder 3.2.4.