Anwendungskontext überall verwenden?

Stimmt in einer Android-App der folgende Ansatz nicht:

public class MyApp extends android.app.Application {

    private static MyApp instance;

    public MyApp() {
        instance = this;
    }

    public static Context getContext() {
        return instance;
    }

}

und überall dort übergeben (zB SQLiteOpenHelper), wo Kontext benötigt wird (und natürlich nicht leckt)?

Es gibt einige potenzielle Probleme mit diesem Ansatz, obwohl er unter vielen Umständen (wie in Ihrem Beispiel) gut funktioniert.

Insbesondere sollten Sie vorsichtig sein, wenn Sie mit etwas umgehen, das sich mit dem befasst GUI, was a erfordert Context. Wenn Sie beispielsweise den Anwendungskontext an übergeben, erhalten LayoutInflaterSie eine Ausnahme. Im Allgemeinen ist Ihr Ansatz ausgezeichnet: Es ist empfehlenswert, einen Activity's Contextinnerhalb dieses Ansatzes zu verwenden Activityund Application Contextbeim Übergeben eines Kontexts, der über den Rahmen eines hinausgeht Activity, Speicherlecks zu vermeiden .

Auch als Alternative zu Ihrem Muster können Sie die Verknüpfung von Aufrufen verwenden getApplicationContext()auf einem ContextObjekt (zB eine Aktivität) , um den Anwendungskontext zu erhalten.

Nach meiner Erfahrung sollte dieser Ansatz nicht notwendig sein. Wenn Sie den Kontext für etwas benötigen, können Sie ihn normalerweise über einen Aufruf von View.getContext () abrufen. Mit dem dort Contexterhaltenen können Sie Context.getApplicationContext () aufrufen , um den ApplicationKontext abzurufen . Wenn Sie versuchen, den ApplicationKontext von einem Activityabzurufen, können Sie jederzeit Activity.getApplication () aufrufen , das als Contextfür einen Aufruf an übergeben werden sollte SQLiteOpenHelper().

Insgesamt scheint es kein Problem mit Ihrem Ansatz für diese Situation zu geben, aber stellen Sie beim Umgang Contextdamit sicher, dass Sie nirgendwo Speicher verlieren, wie im offiziellen Blog von Google Android Developers beschrieben .

Einige Leute haben gefragt: Wie kann der Singleton einen Nullzeiger zurückgeben? Ich beantworte diese Frage. (Ich kann nicht in einem Kommentar antworten, da ich eine Postleitzahl eingeben muss.)

Zwischen zwei Ereignissen kann null zurückgegeben werden: (1) die Klasse wird geladen und (2) das Objekt dieser Klasse wird erstellt. Hier ist ein Beispiel:

class X {
    static X xinstance;
    static Y yinstance = Y.yinstance;
    X() {xinstance=this;}
}
class Y {
    static X xinstance = X.xinstance;
    static Y yinstance;
    Y() {yinstance=this;}
}

public class A {
    public static void main(String[] p) {
    X x = new X();
    Y y = new Y();
    System.out.println("x:"+X.xinstance+" y:"+Y.yinstance);
    System.out.println("x:"+Y.xinstance+" y:"+X.yinstance);
    }
}

Lassen Sie uns den Code ausführen:

$ javac A.java 
$ java A
x:X@a63599 y:Y@9036e
x:null y:null

Die zweite Zeile zeigt , daß Y.xinstance und X.yinstance ist null ; sie sind null , weil die Variablen X.xinstance ans Y.yinstance gelesen wurden , wenn sie null waren.

Kann das behoben werden? Ja,

class X {
    static Y y = Y.getInstance();
    static X theinstance;
    static X getInstance() {if(theinstance==null) {theinstance = new X();} return theinstance;}
}
class Y {
    static X x = X.getInstance();
    static Y theinstance;
    static Y getInstance() {if(theinstance==null) {theinstance = new Y();} return theinstance;}
}

public class A {
    public static void main(String[] p) {
    System.out.println("x:"+X.getInstance()+" y:"+Y.getInstance());
    System.out.println("x:"+Y.x+" y:"+X.y);
    }
}

und dieser Code zeigt keine Anomalie:

$ javac A.java 
$ java A
x:X@1c059f6 y:Y@152506e
x:X@1c059f6 y:Y@152506e

ABER dies ist keine Option für das Android- ApplicationObjekt: Der Programmierer steuert nicht die Zeit, zu der es erstellt wird.

Noch einmal: Der Unterschied zwischen dem ersten und dem zweiten Beispiel besteht darin, dass das zweite Beispiel eine Instanz erstellt, wenn der statische Zeiger null ist. Ein Programmierer kann das Android-Anwendungsobjekt jedoch nicht erstellen, bevor sich das System dafür entscheidet.

AKTUALISIEREN

Ein weiteres rätselhaftes Beispiel, in dem sich initialisierte statische Felder befinden null.

Main.java :

enum MyEnum {
    FIRST,SECOND;
    private static String prefix="<", suffix=">";
    String myName;
    MyEnum() {
        myName = makeMyName();
    }
    String makeMyName() {
        return prefix + name() + suffix;
    }
    String getMyName() {
        return myName;
    }
}
public class Main {
    public static void main(String args[]) {
        System.out.println("first: "+MyEnum.FIRST+" second: "+MyEnum.SECOND);
        System.out.println("first: "+MyEnum.FIRST.makeMyName()+" second: "+MyEnum.SECOND.makeMyName());
        System.out.println("first: "+MyEnum.FIRST.getMyName()+" second: "+MyEnum.SECOND.getMyName());
    }
}

Und du bekommst:

$ javac Main.java
$ java Main
first: FIRST second: SECOND
first: <FIRST> second: <SECOND>
first: nullFIRSTnull second: nullSECONDnull

Beachten Sie, dass Sie die statische Variablendeklaration nicht um eine Zeile nach oben verschieben können. Der Code wird nicht kompiliert.

Anwendungsklasse:

import android.app.Application;
import android.content.Context;

public class MyApplication extends Application {

    private static Context mContext;

    public void onCreate() {
        super.onCreate();
        mContext = getApplicationContext();
    }

    public static Context getAppContext() {
        return mContext;
    }

}

Deklarieren Sie die Anwendung im AndroidManifest:

<application android:name=".MyApplication"
    ...
/>

Verwendungszweck:

MyApplication.getAppContext()

Sie versuchen, einen Wrapper zu erstellen, um den Anwendungskontext abzurufen, und es besteht die Möglichkeit, dass er den nullZeiger " " zurückgibt.

Nach meinem Verständnis denke ich, dass es besser ist, eine der 2 Context.getApplicationContext() oder 2 anzurufen Activity.getApplication().

Es ist ein guter Ansatz. Ich benutze es auch selbst. Ich würde nur vorschlagen, zu überschreiben onCreate, um den Singleton festzulegen, anstatt einen Konstruktor zu verwenden.

Und da haben Sie schon erwähnt SQLiteOpenHelper: In können onCreate ()Sie auch die Datenbank öffnen.

Persönlich denke ich, dass die Dokumentation falsch war, als sie sagte, dass es normalerweise nicht notwendig ist, die Anwendung in eine Unterklasse zu unterteilen . Ich denke, das Gegenteil ist der Fall: Sie sollten Application immer unterordnen.

Ich würde den Anwendungskontext verwenden, um einen Systemdienst im Konstruktor abzurufen. Dies erleichtert das Testen und profitiert von der Zusammensetzung

public class MyActivity extends Activity {

    private final NotificationManager notificationManager;

    public MyActivity() {
       this(MyApp.getContext().getSystemService(NOTIFICATION_SERVICE));
    }

    public MyActivity(NotificationManager notificationManager) {
       this.notificationManager = notificationManager;
    }

    // onCreate etc

}

Die Testklasse würde dann den überladenen Konstruktor verwenden.

Android würde den Standardkonstruktor verwenden.

Ich mag es, aber ich würde stattdessen einen Singleton vorschlagen:

package com.mobidrone;

import android.app.Application;
import android.content.Context;

public class ApplicationContext extends Application
{
    private static ApplicationContext instance = null;

    private ApplicationContext()
    {
        instance = this;
    }

    public static Context getInstance()
    {
        if (null == instance)
        {
            instance = new ApplicationContext();
        }

        return instance;
    }
}

Ich benutze den gleichen Ansatz, ich schlage vor, den Singleton etwas besser zu schreiben:

public static MyApp getInstance() {

    if (instance == null) {
        synchronized (MyApp.class) {
            if (instance == null) {
                instance = new MyApp ();
            }
        }
    }

    return instance;
}

aber ich benutze nicht überall, ich benutze getContext()und getApplicationContext()wo ich es tun kann!