Singletons vs. contesto applicativo in Android?

Ricordando questo post che elenca diversi problemi nell'uso dei singleton e dopo aver visto diversi esempi di applicazioni Android che usano il pattern singleton, mi chiedo se sia una buona idea usare Singletons invece di singole istanze condivise attraverso lo stato globale dell'applicazione (sottoclasse android.os.Application e ottenerlo tramite context.getApplication ()).

Quali vantaggi / svantaggi avrebbero entrambi i meccanismi?

Ad essere sincero, mi aspetto la stessa risposta in questo post schema Singleton con applicazione Web, non è una buona idea! ma applicato ad Android. Ho ragione? Cosa c'è di diverso in DalvikVM altrimenti?

EDIT: vorrei avere opinioni su diversi aspetti coinvolti:

• Sincronizzazione
• riutilizzabilità
• analisi

Non sono molto d'accordo con la risposta di Dianne Hackborn. A poco a poco stiamo rimuovendo tutti i singoli dal nostro progetto a favore di oggetti leggeri, con ambito di applicazione che possono essere facilmente ricreati quando ne hai realmente bisogno.

I singleton sono un incubo per i test e, se inizializzati pigramente, introdurranno "indeterminismo di stato" con sottili effetti collaterali (che possono improvvisamente emergere quando si spostano le chiamate getInstance()da un ambito all'altro). La visibilità è stata menzionata come un altro problema e poiché i singleton implicano l'accesso "globale" (= casuale) allo stato condiviso, possono insorgere bug sottili se non correttamente sincronizzati in applicazioni simultanee.

Lo considero un anti-pattern, è un cattivo stile orientato agli oggetti che equivale essenzialmente a mantenere lo stato globale.

Per tornare alla tua domanda:

Sebbene il contesto dell'app possa essere considerato un singleton stesso, è gestito dal framework e ha un ciclo di vita , un ambito e un percorso di accesso ben definiti . Quindi credo che se hai bisogno di gestire lo stato globale dell'app, dovrebbe andare qui, da nessun'altra parte. Per qualsiasi altra cosa, ripensa se hai davvero bisogno di un oggetto singleton o se sarebbe anche possibile riscrivere la tua classe singleton per creare un'istanza di piccoli oggetti di breve durata che eseguono l'attività a portata di mano.

Consiglio vivamente i single. Se hai un singleton che necessita di un contesto, disponi di:

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

Preferisco i singleton rispetto alle applicazioni perché aiutano a mantenere un'app molto più organizzata e modulare - invece di avere un posto in cui è necessario mantenere tutto il tuo stato globale in tutta l'app, ogni singolo pezzo può occuparsi di se stesso. Anche il fatto che i singleton inizializzino pigramente (su richiesta) invece di guidarti lungo il percorso di fare tutte le inizializzazioni in anticipo in Application.onCreate () è buono.

Non c'è nulla di intrinsecamente sbagliato nell'uso dei singleton. Usali correttamente, quando ha senso. Il framework Android ne ha davvero molti, per mantenere cache per processo di risorse caricate e altre cose del genere.

Anche per le applicazioni semplici il multithreading non diventa un problema con i singleton, perché in base alla progettazione tutti i callback standard per l'app vengono inviati sul thread principale del processo in modo che non si verifichi il multi-threading a meno che non venga introdotto esplicitamente tramite thread o implicitamente pubblicando un fornitore di contenuti o un servizio IBinder su altri processi.

Sii solo attento a ciò che stai facendo. :)

Da: Sviluppatore> riferimento - Applicazione

Normalmente non è necessario sottoclassare l'Applicazione. Nella maggior parte dei casi, i singoli statici possono fornire la stessa funzionalità in un modo più modulare. Se il tuo singleton necessita di un contesto globale (ad esempio per registrare i ricevitori di trasmissione), alla funzione per recuperarlo può essere assegnato un contesto che utilizza internamente Context.getApplicationContext () quando costruisce il singleton per la prima volta.

L'applicazione non è la stessa del Singleton. I motivi sono:

1. Il metodo dell'applicazione (come onCreate) viene chiamato nel thread dell'interfaccia utente;
2. il metodo singleton può essere chiamato in qualsiasi thread;
3. Nel metodo "onCreate" dell'applicazione, è possibile creare un'istanza di Handler;
4. Se il singleton viene eseguito nel thread none-ui, non è possibile creare un'istanza di Handler;
5. L'applicazione ha la capacità di gestire il ciclo di vita delle attività nell'app. Ha il metodo "registerActivityLifecycleCallbacks". Ma i singoli non hanno l'abilità.

Ho avuto lo stesso problema: Singleton o creare una sottoclasse android.os.Application?

Per prima cosa ho provato con Singleton ma la mia app a un certo punto effettua una chiamata al browser

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

e il problema è che, se il portatile non ha memoria sufficiente, la maggior parte delle classi (anche i Singleton) vengono ripulite per ottenere un po 'di memoria, quindi, quando ritorna dal browser alla mia app, si blocca ogni volta.

Soluzione: inserire i dati necessari in una sottoclasse di classe Application.

Considera entrambi allo stesso tempo:

• avere oggetti singleton come istanze statiche all'interno delle classi.
• avere una classe comune (Context) che restituisce le istanze singleton per tutti gli oggetti singelton nell'applicazione, con il vantaggio che i nomi dei metodi in Context saranno significativi, ad esempio: context.getLoggedinUser () invece di User.getInstance ().

Inoltre, ti suggerisco di espandere il tuo contesto per includere non solo l'accesso agli oggetti singleton, ma alcune funzionalità a cui è necessario accedere a livello globale, come ad esempio context.logOffUser (), context.readSavedData (), ecc. Probabilmente rinominando il contesto in La facciata avrebbe senso allora.

In realtà sono uguali. C'è una differenza che posso vedere. Con la classe Application è possibile inizializzare le variabili in Application.onCreate () e distruggerle in Application.onTerminate (). Con singleton devi affidarti all'inizializzazione e alla distruzione della VM.

I miei 2 centesimi:

Ho notato che alcuni campi singleton / statici sono stati ripristinati quando la mia attività è stata distrutta. Ho notato questo su alcuni dispositivi di fascia bassa 2.3.

Il mio caso è stato molto semplice: ho solo un file "init_done" archiviato in privato e un metodo "init" statico che ho chiamato da activity.onCreate (). Noto che il metodo init si stava eseguendo nuovamente su una qualche ricostruzione dell'attività.

Anche se non posso dimostrare la mia affermazione, potrebbe essere correlato a QUANDO il singleton / la classe è stata creata / utilizzata per prima. Quando l'attività viene distrutta / riciclata, sembra che anche tutte le classi a cui fa riferimento solo questa attività vengano riciclate.

Ho spostato la mia istanza di singleton in una sottoclasse di Applicazione. Li accedo dall'istanza dell'applicazione. e, da allora, non si è più accorto del problema.

Spero che questo possa aiutare qualcuno.

Dalla proverbiale bocca del cavallo ...

Quando si sviluppa l'app, potrebbe essere necessario condividere dati, contesto o servizi a livello globale attraverso l'app. Ad esempio, se la tua app contiene dati di sessione, come l'utente attualmente connesso, probabilmente vorrai esporre queste informazioni. In Android, il modello per risolvere questo problema è avere l'istanza di android.app.Application proprietaria di tutti i dati globali, quindi trattare l'istanza dell'applicazione come un singleton con accessi statici ai vari dati e servizi.

Quando si scrive un'app Android, si ha la certezza di avere solo un'istanza della classe android.app.Application, quindi è sicuro (e consigliato dal team di Google Android) trattarla come un singleton. In altre parole, puoi tranquillamente aggiungere un metodo getInstance () statico all'implementazione dell'applicazione. Così:

public class AndroidApplication extends Application {

    private static AndroidApplication sInstance;

    public static AndroidApplication getInstance(){
        return sInstance;
    }

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

La mia attività chiama finish () (che non lo termina immediatamente, ma alla fine lo farà) e chiama Google Street Viewer. Quando eseguo il debug su Eclipse, la mia connessione all'app si interrompe quando viene chiamato Street Viewer, che intendo come la (intera) applicazione chiusa, presumibilmente per liberare memoria (poiché una singola attività completata non dovrebbe causare questo comportamento) . Tuttavia, sono in grado di salvare lo stato in un pacchetto tramite onSaveInstanceState () e ripristinarlo nel metodo onCreate () della prossima attività nello stack. O usando un singleton statico o un'applicazione di sottoclasse, devo affrontare lo stato di chiusura e perdita dell'applicazione (a meno che non lo salvi in ​​un pacchetto). Quindi dalla mia esperienza sono gli stessi per quanto riguarda la conservazione dello stato. Ho notato che la connessione si perde in Android 4.1.2 e 4.2.2 ma non su 4.0.7 o 3.2.4,