Korzystasz z kontekstu aplikacji wszędzie?

Czy w aplikacji na Androida jest coś nie tak z następującym podejściem:

public class MyApp extends android.app.Application {

    private static MyApp instance;

    public MyApp() {
        instance = this;
    }

    public static Context getContext() {
        return instance;
    }

}

i przekazać go wszędzie (np. SQLiteOpenHelper) tam, gdzie wymagany jest kontekst (i oczywiście nie przecieka)?

Istnieje kilka potencjalnych problemów z tym podejściem, chociaż w wielu okolicznościach (takich jak twój przykład) będzie działać dobrze.

W szczególności powinieneś zachować ostrożność, mając do czynienia ze wszystkim, co dotyczy tego, GUIco wymaga Context. Na przykład, jeśli przekażesz kontekst aplikacji do niego LayoutInflater, otrzymasz wyjątek. Ogólnie rzecz biorąc, twoje podejście jest doskonałe: dobrą praktyką jest użycie Activity's Contextwewnątrz tego Activity, a Application Contextkiedy przekazujesz kontekst poza zakresActivity aby uniknąć wycieków pamięci .

Ponadto, jako alternatywa dla Państwa wzoru można użyć skrótu dzwoniąc getApplicationContext()na Contextobiekt (taki jak aktywny), aby uzyskać kontekstu aplikacji.

Z mojego doświadczenia wynika, że ​​takie podejście nie powinno być konieczne. Jeśli potrzebujesz kontekstu do czegokolwiek, zwykle możesz go uzyskać przez wywołanie View.getContext () i używając Contextuzyskanego tam możesz wywołać Context.getApplicationContext (), aby uzyskać Applicationkontekst. Jeśli próbujesz uzyskać Applicationkontekst z tego Activity, zawsze możesz wywołać Activity.getApplication (), które powinno być możliwe do przekazania jako Contextpotrzebne do wywołania SQLiteOpenHelper().

Ogólnie rzecz biorąc, wydaje się, że nie ma problemu z twoim podejściem do tej sytuacji, ale radząc sobie z Contexttym, upewnij się, że nigdzie nie tracisz pamięci, jak opisano na oficjalnym blogu Google Android Developers .

Niektórzy pytają: jak singleton może zwrócić wskaźnik zerowy? Odpowiadam na to pytanie. (Nie mogę odpowiedzieć w komentarzu, ponieważ muszę wysłać kod).

Może zwracać wartość null pomiędzy dwoma zdarzeniami: (1) klasa jest ładowana i (2) tworzony jest obiekt tej klasy. Oto przykład:

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);
    }
}

Uruchommy kod:

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

Drugi wiersz pokazuje, że instancja Y.xinstance i X.yinstance ma wartość NULL ; są one puste, ponieważ zmienne X.xinstance i Y.yinstance zostały odczytane, gdy były puste.

Czy można to naprawić? Tak,

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);
    }
}

a ten kod nie wykazuje anomalii:

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

ALE nie jest to opcja dla Applicationobiektu z Androidem : programista nie kontroluje czasu jego utworzenia.

Jeszcze raz: różnica między pierwszym przykładem a drugim polega na tym, że drugi przykład tworzy instancję, jeśli wskaźnik statyczny ma wartość NULL. Ale programista nie może tworzyć z Androidem obiektu aplikacji zanim system zdecyduje się to zrobić.

AKTUALIZACJA

Jeszcze jeden zagadkowy przykład, w którym znajdują się zainicjowane pola statyczne 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());
    }
}

I dostajesz:

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

Pamiętaj, że nie można przenieść deklaracji zmiennej statycznej o jeden wiersz wyżej, kod nie zostanie skompilowany.

Klasa zastosowania:

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;
    }

}

Zadeklaruj aplikację w AndroidManifest:

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

Stosowanie:

MyApplication.getAppContext()

Próbujesz utworzyć opakowanie, aby uzyskać kontekst aplikacji, ale istnieje możliwość, że zwróci on nullwskaźnik.

Zgodnie z moim rozumieniem, wydaje mi się, że jest to lepsze podejście do call-any z 2 Context.getApplicationContext() lub Activity.getApplication().

To dobre podejście. Ja też go używam. Sugerowałbym jedynie przesłonięcie, onCreateaby ustawić singleton zamiast używania konstruktora.

A skoro wspomniałeś SQLiteOpenHelper: WonCreate () możesz również otworzyć bazę danych.

Osobiście uważam, że dokumentacja niesłusznie mówi, że zwykle nie ma potrzeby podklasy aplikacji . Myślę, że jest odwrotnie: zawsze należy podklasować aplikację.

Chciałbym użyć kontekstu aplikacji, aby uzyskać konstruktor usługi systemowej. Ułatwia to testowanie i zapewnia korzyści ze składu

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

}

Klasa testowa użyłaby wtedy przeciążonego konstruktora.

Android użyłby domyślnego konstruktora.

Podoba mi się, ale zamiast tego zaproponowałbym singleton:

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;
    }
}

Używam tego samego podejścia, proponuję napisać singleton nieco lepiej:

public static MyApp getInstance() {

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

    return instance;
}

ale nie używam wszędzie, używam getContext()i getApplicationContext()gdzie mogę to zrobić!