Singletons vs. Contexto do Aplicativo no Android?

Lembrando esta postagem enumerando vários problemas do uso de singletons e tendo visto vários exemplos de aplicativos Android usando o padrão singleton, pergunto-me se é uma boa idéia usar Singletons em vez de instâncias únicas compartilhadas pelo estado global do aplicativo (subclassificando android.os.Application e obtê-lo através de context.getApplication ()).

Que vantagens / desvantagens teriam ambos os mecanismos?

Para ser sincero, espero a mesma resposta neste post Padrão Singleton com aplicativo Web, Não é uma boa ideia! mas aplicado ao Android. Estou correcto? O que há de diferente no DalvikVM?

EDIT: Gostaria de ter opiniões sobre vários aspectos envolvidos:

• Sincronização
• Reutilização
• Teste

Discordo muito da resposta de Dianne Hackborn. Estamos removendo pouco a pouco todos os singletons do nosso projeto em favor de objetos leves e com escopo de tarefas que podem ser facilmente recriados quando você realmente precisa deles.

Os singletons são um pesadelo para os testes e, se forem inicializados com preguiça, introduzirão o "indeterminismo de estado" com efeitos colaterais sutis (que podem surgir repentinamente ao mover chamadas getInstance()de um escopo para outro). A visibilidade foi mencionada como outro problema e, como os singletons implicam o acesso "global" (= aleatório) ao estado compartilhado, erros sutis podem surgir quando não são sincronizados adequadamente em aplicativos simultâneos.

Eu considero isso um antipadrão, é um estilo orientado a objetos ruim que basicamente significa manter o estado global.

Para voltar à sua pergunta:

Embora o contexto do aplicativo possa ser considerado um único singleton, ele é gerenciado por estrutura e possui um ciclo de vida , escopo e caminho de acesso bem definidos . Por isso, acredito que, se você precisar gerenciar o estado global do aplicativo, ele deve ir aqui, em nenhum outro lugar. Para qualquer outra coisa, repense se você realmente precisa de um objeto singleton ou se também seria possível reescrever sua classe singleton para instanciar objetos pequenos e de curta duração que executam a tarefa em questão.

Eu recomendo muito singletons. Se você tem um singleton que precisa de um contexto, tenha:

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

Eu prefiro singletons do que Application, porque ajuda a manter um aplicativo muito mais organizado e modular - em vez de ter um lugar em que todo o seu estado global no aplicativo precisa ser mantido, cada peça separada pode se cuidar. Também é bom o fato de os singletons inicializarem preguiçosamente (a pedido) em vez de levá-lo no caminho de fazer toda a inicialização antecipada em Application.onCreate ().

Não há nada intrinsecamente errado em usar singletons. Apenas use-os corretamente, quando fizer sentido. A estrutura do Android, na verdade, possui muitas delas, para manter caches por processo de recursos carregados e outras coisas.

Também para aplicativos simples, o multithreading não se torna um problema para os singletons, porque, por design, todos os retornos de chamada padrão do aplicativo são despachados no encadeamento principal do processo, para que você não aconteça o multi-threading, a menos que o introduza explicitamente através de encadeamentos ou implicitamente, publicando um IBinder de provedor ou serviço de conteúdo para outros processos.

Apenas pense bem no que está fazendo. :)

De: desenvolvedor> referência - aplicativo

Normalmente, não há necessidade de subclassificar Application. Na maioria das situações, singletons estáticos podem fornecer a mesma funcionalidade de uma maneira mais modular. Se o seu singleton precisar de um contexto global (por exemplo, para registrar receptores de transmissão), a função para recuperá-lo poderá receber um Contexto que use internamente Context.getApplicationContext () ao construir o singleton pela primeira vez.

O aplicativo não é o mesmo que o Singleton. Os motivos são:

1. O método do aplicativo (como onCreate) é chamado no thread da interface do usuário;
2. o método singleton pode ser chamado em qualquer thread;
3. No método "onCreate" do aplicativo, você pode instanciar o manipulador;
4. Se o singleton for executado no thread none-ui, você não poderá instanciar Handler;
5. O aplicativo tem a capacidade de gerenciar o ciclo de vida das atividades no aplicativo.Tem o método "registerActivityLifecycleCallbacks" .Mas os singletons não têm a capacidade.

Eu tive o mesmo problema: Singleton ou criar uma subclasse android.os.Application?

Primeiro, tentei com o Singleton, mas meu aplicativo, em algum momento, chama o navegador

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

e o problema é que, se o aparelho não tiver memória suficiente, a maioria das suas aulas (até Singletons) é limpa para obter um pouco de memória; portanto, ao retornar do navegador para o meu aplicativo, ele falha sempre.

Solução: coloque os dados necessários dentro de uma subclasse da classe Application.

Considere os dois ao mesmo tempo:

• tendo objetos singleton como instâncias estáticas dentro das classes.
• ter uma classe comum (Context) que retorna as instâncias singleton para todos os objetos singelton em seu aplicativo, o que tem a vantagem de que os nomes dos métodos em Contexto serão significativos, por exemplo: context.getLoggedinUser () em vez de User.getInstance ().

Além disso, sugiro que você expanda seu Contexto para incluir não apenas o acesso a objetos singleton, mas algumas funcionalidades que precisam ser acessadas globalmente, como por exemplo: context.logOffUser (), context.readSavedData (), etc. Provavelmente renomeando o Contexto para Fachada faria sentido então.

Eles são realmente iguais. Há uma diferença que eu posso ver. Com a classe Application, você pode inicializar suas variáveis ​​em Application.onCreate () e destruí-las em Application.onTerminate (). Com o singleton, você precisa confiar na inicialização e destruição de estática da VM.

Meus 2 centavos:

Notei que alguns campos estáticos / singleton foram redefinidos quando minha atividade foi destruída. Notei isso em alguns dispositivos 2.3 low-end.

Meu caso foi muito simples: eu apenas tenho um arquivo "init_done" particular e um método estático "init" que chamei de activity.onCreate (). Percebo que o método init estava se re-executando em alguma recriação da atividade.

Embora eu não possa provar minha afirmação, ela pode estar relacionada a QUANDO o singleton / classe foi criado / usado primeiro. Quando a atividade é destruída / reciclada, parece que todas as classes que apenas essa atividade se referem também são recicladas.

Mudei minha instância de singleton para uma subclasse de aplicativo. Eu os acesso a partir da instância do aplicativo. e, desde então, não percebeu o problema novamente.

Espero que isso possa ajudar alguém.

Da boca do proverbial cavalo ...

Ao desenvolver seu aplicativo, você pode achar necessário compartilhar dados, contexto ou serviços globalmente em seu aplicativo. Por exemplo, se seu aplicativo tiver dados de sessão, como o usuário conectado no momento, é provável que você exponha essas informações. No Android, o padrão para resolver esse problema é ter sua instância android.app.Application como proprietária de todos os dados globais e, em seguida, tratar sua instância de Aplicativo como um singleton com acessadores estáticos para os vários dados e serviços.

Ao escrever um aplicativo Android, você garante apenas uma instância da classe android.app.Application e, portanto, é seguro (e recomendado pela equipe do Google Android) tratá-lo como um singleton. Ou seja, você pode adicionar com segurança um método estático getInstance () à sua implementação de Aplicativo. Igual a:

public class AndroidApplication extends Application {

    private static AndroidApplication sInstance;

    public static AndroidApplication getInstance(){
        return sInstance;
    }

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

Minha atividade chama finish () (que não faz com que termine imediatamente, mas acabará eventualmente) e chama o Google Street Viewer. Quando eu depuro no Eclipse, minha conexão com o aplicativo é interrompida quando o Street Viewer é chamado, que eu entendo como o aplicativo (inteiro) sendo fechado, supostamente para liberar memória (pois uma única atividade concluída não deve causar esse comportamento) . No entanto, sou capaz de salvar o estado em um Bundle via onSaveInstanceState () e restaurá-lo no método onCreate () da próxima atividade na pilha. Usando um Aplicativo estático de singleton ou subclasse, eu enfrento o estado de fechamento e perda do aplicativo (a menos que eu o salve em um Pacote configurável). Então, pela minha experiência, eles são os mesmos em relação à preservação do estado. Percebi que a conexão está perdida no Android 4.1.2 e 4.2.2, mas não no 4.0.7 ou 3.2.4,