Usi il contesto dell'applicazione ovunque?

In un'app Android, c'è qualcosa che non va nel seguente approccio:

public class MyApp extends android.app.Application {

    private static MyApp instance;

    public MyApp() {
        instance = this;
    }

    public static Context getContext() {
        return instance;
    }

}

e passarlo ovunque (es. SQLiteOpenHelper) dove è richiesto il contesto (e ovviamente non perde)?

Ci sono un paio di potenziali problemi con questo approccio, sebbene in molte circostanze (come il tuo esempio) funzionerà bene.

In particolare dovresti stare attento quando hai a che fare con tutto ciò che ha a che fare con GUIun Context. Ad esempio, se si passa l'applicazione Contesto in LayoutInflatersi otterrà un'eccezione. In generale, il tuo approccio è eccellente: è una buona pratica usare un Activity's Contextdentro quello Activity, e Application Contextquando si passa un contesto oltre lo scopo di un Activityper evitare perdite di memoria .

Inoltre, in alternativa al modello è possibile utilizzare il collegamento di chiamata getApplicationContext()a un Contextoggetto (come un'attività) per ottenere il contesto dell'applicazione.

Nella mia esperienza questo approccio non dovrebbe essere necessario. Se hai bisogno del contesto per qualsiasi cosa, di solito puoi ottenerlo tramite una chiamata a View.getContext () e usando quello Contextottenuto puoi chiamare Context.getApplicationContext () per ottenere il Applicationcontesto. Se stai cercando di ottenere Applicationquesto contesto da un Activity, puoi sempre chiamare Activity.getApplication () che dovrebbe essere in grado di essere passato come Contextnecessario per una chiamata a SQLiteOpenHelper().

Nel complesso non sembra esserci un problema con il tuo approccio a questa situazione, ma quando Contexthai a che fare assicurati solo che non stai perdendo memoria da nessuna parte come descritto sul blog ufficiale degli sviluppatori Android di Google .

Alcune persone hanno chiesto: come può il singleton restituire un puntatore nullo? Sto rispondendo a questa domanda. (Non posso rispondere in un commento perché devo inserire il codice.)

Può restituire null tra due eventi: (1) la classe viene caricata e (2) viene creato l'oggetto di questa classe. Ecco un esempio:

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

Eseguiamo il codice:

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

La seconda riga mostra che Y.xinstance e X.yinstance sono null ; sono nulli perché le variabili X.xinstance e Y.yinstance sono state lette quando erano nulle.

Questo può essere risolto? Sì,

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

e questo codice non mostra anomalie:

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

MA questa non è un'opzione per l' Applicationoggetto Android : il programmatore non controlla l'ora in cui viene creato.

Ancora una volta: la differenza tra il primo esempio e il secondo è che il secondo esempio crea un'istanza se il puntatore statico è nullo. Ma un programmatore non può creare l' oggetto dell'applicazione Android prima che il sistema decida di farlo.

AGGIORNARE

Un altro esempio sconcertante in cui si trovano i campi statici inizializzati 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());
    }
}

E ottieni:

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

Si noti che non è possibile spostare la dichiarazione della variabile statica di una riga in alto, il codice non verrà compilato.

Classe di applicazione:

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

}

Dichiarare l'applicazione in AndroidManifest:

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

Uso:

MyApplication.getAppContext()

Stai cercando di creare un wrapper per ottenere il contesto dell'applicazione e c'è la possibilità che possa restituire il nullpuntatore " ".

Secondo la mia comprensione, immagino che sia il miglior approccio per chiamare uno dei 2 Context.getApplicationContext() o Activity.getApplication().

È un buon approccio. Lo uso anche io. Vorrei solo suggerire di eseguire l'override onCreateper impostare il singleton invece di utilizzare un costruttore.

E dal momento che hai menzionato SQLiteOpenHelper: In onCreate ()puoi anche aprire il database.

Personalmente penso che la documentazione abbia sbagliato nel dire che normalmente non è necessario sottoclassare l'Applicazione . Penso che sia vero il contrario: dovresti sempre sottoclassare l'Applicazione.

Vorrei utilizzare il contesto dell'applicazione per ottenere un servizio di sistema nel costruttore. Ciò facilita i test e beneficia della composizione

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

}

La classe di test utilizzerà quindi il costruttore sovraccarico.

Android userebbe il costruttore predefinito.

Mi piace, ma suggerirei invece un 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;
    }
}

Sto usando lo stesso approccio, suggerisco di scrivere un po 'meglio il singleton:

public static MyApp getInstance() {

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

    return instance;
}

ma non sto usando ovunque, io uso getContext()e getApplicationContext()dove posso farlo!