Usando o contexto do aplicativo em qualquer lugar?

Em um aplicativo Android, há algo errado com a seguinte abordagem:

public class MyApp extends android.app.Application {

    private static MyApp instance;

    public MyApp() {
        instance = this;
    }

    public static Context getContext() {
        return instance;
    }

}

e passá-lo para todos os lugares (por exemplo, SQLiteOpenHelper) onde o contexto é necessário (e não está vazando, é claro)?

Existem alguns problemas em potencial com essa abordagem, embora em muitas circunstâncias (como no seu exemplo) funcione bem.

Em particular, você deve ter cuidado ao lidar com qualquer coisa que lide com o GUIque exige a Context. Por exemplo, se você passar o aplicativo Context para o LayoutInflaterdiretório, receberá uma exceção. De um modo geral, sua abordagem é excelente: é uma boa prática usar um Activity's Contextdentro disso Activitye Application Contextao passar um contexto além do escopo de um Activitypara evitar vazamentos de memória .

Além disso, como alternativa ao seu padrão, você pode usar o atalho para chamar getApplicationContext()um Contextobjeto (como uma Atividade) para obter o Contexto do Aplicativo.

Na minha experiência, essa abordagem não deve ser necessária. Se você precisar do contexto para qualquer coisa, normalmente é possível obtê-lo por meio de uma chamada para View.getContext () e, usando o resultado Contextobtido, pode chamar Context.getApplicationContext () para obter o Applicationcontexto. Se você estiver tentando obter o Applicationcontexto disso a partir de um, Activityvocê sempre pode chamar Activity.getApplication (), que deve ser transmitido conforme o Contextnecessário para uma chamada SQLiteOpenHelper().

No geral, não parece haver um problema com sua abordagem para essa situação, mas ao lidar com Contextapenas verifique se você não está vazando memória em nenhum lugar, conforme descrito no blog oficial do Google Android Developers .

Algumas pessoas perguntaram: como o singleton pode retornar um ponteiro nulo? Eu estou respondendo a essa pergunta. (Não consigo responder em um comentário porque preciso postar código.)

Pode retornar nulo entre dois eventos: (1) a classe é carregada e (2) o objeto dessa classe é criado. Aqui está um exemplo:

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

Vamos rodar o código:

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

A segunda linha mostra que Y.xinstance e X.yinstance são nulos ; eles são nulos porque as variáveis X.xinstance e Y.yinstance foram lidas quando eram nulas.

Isso pode ser corrigido? Sim,

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 este código não mostra nenhuma anomalia:

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

MAS isso não é uma opção para o Applicationobjeto Android : o programador não controla a hora em que é criado.

Mais uma vez: a diferença entre o primeiro exemplo e o segundo é que o segundo exemplo cria uma instância se o ponteiro estático for nulo. Mas um programador não pode criar o objeto de aplicativo Android antes que o sistema decida fazê-lo.

ATUALIZAR

Mais um exemplo intrigante, onde estão os campos estáticos inicializados 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 você obtém:

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

Observe que você não pode mover a declaração da variável estática uma linha para cima, o código não será compilado.

Classe de aplicação:

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

}

Declare o aplicativo no AndroidManifest:

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

Uso:

MyApplication.getAppContext()

Você está tentando criar um wrapper para obter o Contexto do Aplicativo e existe a possibilidade " null" de retornar o ponteiro.

De acordo com o meu entendimento, acho que é melhor abordagem para chamar qualquer um dos 2 Context.getApplicationContext() ou Activity.getApplication().

É uma boa abordagem. Eu também o uso. Eu apenas sugeriria substituir onCreatepara definir o singleton em vez de usar um construtor.

E desde que você mencionou SQLiteOpenHelper: onCreate ()você também pode abrir o banco de dados.

Pessoalmente, acho que a documentação errou ao dizer que normalmente não há necessidade de subclassificar Application . Eu acho que o oposto é verdadeiro: você deve sempre subclassificar Application.

Eu usaria o Contexto do Aplicativo para obter um Serviço do Sistema no construtor. Isso facilita os testes e os benefícios da composição

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

}

A classe de teste usaria o construtor sobrecarregado.

O Android usaria o construtor padrão.

Eu gosto, mas sugiro um 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;
    }
}

Estou usando a mesma abordagem, sugiro escrever o singleton um pouco melhor:

public static MyApp getInstance() {

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

    return instance;
}

mas não estou usando em todos os lugares, eu uso getContext()e getApplicationContext()onde posso fazer isso!