Una Application
classe estesa può dichiarare variabili globali. Ci sono altri motivi?
Una Application
classe estesa può dichiarare variabili globali. Ci sono altri motivi?
Risposte:
A parte, non riesco a pensare a uno scenario reale in cui l'estensione dell'applicazione sia preferibile a un altro approccio o necessaria per realizzare qualcosa. Se si dispone di un oggetto costoso e di uso frequente, è possibile inizializzarlo in IntentService quando si rileva che l'oggetto non è attualmente presente. L'applicazione stessa viene eseguita sul thread dell'interfaccia utente, mentre IntentService viene eseguito sul proprio thread.
Preferisco passare i dati da attività a attività con intenti espliciti o utilizzare SharedPreferences. Esistono anche modi per passare i dati da un frammento all'attività principale usando le interfacce.
"prefer to pass data from Activity to Activity with explicit Intents, or use SharedPreferences"
. Dovremmo sempre eliminare lo stato globale il più possibile e utilizzare gli strumenti Android standard per la gestione dello stato globale invece di var /
apk
file nel nostro cellulare, è composto da più blocchi utili come, Activity
s,Service
altri.Application
indipendentemente Activity
dall'utente che sta utilizzando,Application
,Cursor
e chiuderlo ancora e ancora non è buono per le prestazioni,Intent
s per passare i dati ma è goffo e l'attività stessa potrebbe non esistere in un determinato scenario a seconda della disponibilità della memoria.Application
,Application
per avviare determinate cose come l'analisi, ecc. Poiché la classe di applicazione viene avviata prima dell'esecuzione di Activity
s o
Services
s,La classe di applicazione è l'oggetto che ha l'intero ciclo di vita dell'applicazione. È il tuo livello più alto come applicazione. esempi di possibili utilizzi:
Puoi aggiungere ciò di cui hai bisogno all'avvio dell'applicazione sovrascrivendo onCreate nella classe Application.
memorizzare variabili globali che passano da un'attività all'altra. Come Asynctask.
eccetera
A volte si desidera archiviare dati, ad esempio variabili globali a cui è necessario accedere da più attività, a volte ovunque all'interno dell'applicazione. In questo caso, l'oggetto Applicazione ti aiuterà.
Ad esempio, se si desidera ottenere i dati di autenticazione di base per ogni http richiesta , è possibile implementare i metodi per i dati di autenticazione nell'oggetto applicazione.
Successivamente, è possibile ottenere il nome utente e la password in una qualsiasi delle attività come questa:
MyApplication mApplication = (MyApplication)getApplicationContext();
String username = mApplication.getUsername();
String password = mApplication.getPassword();
E infine, ricorda di usare l'oggetto Application come oggetto singleton:
public class MyApplication extends Application {
private static MyApplication singleton;
public MyApplication getInstance(){
return singleton;
}
@Override
public void onCreate() {
super.onCreate();
singleton = this;
}
}
Per ulteriori informazioni, fare clic su Classe applicazione
La classe Application è un singleton a cui puoi accedere da qualsiasi attività o ovunque tu abbia un oggetto Context.
Ottieni anche un po 'di ciclo di vita.
È possibile utilizzare il metodo onCreate dell'applicazione per creare un'istanza di oggetti costosi ma utilizzati di frequente come un supporto di analisi. Quindi è possibile accedere e utilizzare quegli oggetti ovunque.
Migliore utilizzo della classe di applicazione. Esempio: supponiamo che sia necessario riavviare il gestore allarmi all'avvio completato.
public class BaseJuiceApplication extends Application implements BootListener {
public static BaseJuiceApplication instance = null;
public static Context getInstance() {
if (null == instance) {
instance = new BaseJuiceApplication();
}
return instance;
}
@Override
public void onCreate() {
super.onCreate();
}
@Override
public void onBootCompleted(Context context, Intent intent) {
new PushService().scheduleService(getInstance());
//startToNotify(context);
}
Non una risposta ma un'osservazione : tieni presente che i dati nell'oggetto esteso dell'applicazione non devono essere collegati a un'istanza di un'attività, poiché è possibile che tu abbia due istanze della stessa attività in esecuzione contemporaneamente (una in il primo piano e uno non visibile) .
Ad esempio, si avvia normalmente l'attività tramite il programma di avvio, quindi "si riduce a icona". Quindi avvii un'altra app (ad esempio Tasker) che avvia un'altra istanza della tua attività, ad esempio per creare un collegamento, perché la tua app supporta android.intent.action.CREATE_SHORTCUT. Se viene quindi creato il collegamento e questa chiamata all'attività di creazione del collegamento ha modificato i dati dell'oggetto applicazione, l'attività in esecuzione in background inizierà a utilizzare l'oggetto applicazione modificato una volta riportato in primo piano.
Vedo che a questa domanda manca una risposta. Estendo Application
perché utilizzo l' implementazione di Bill Pugh Singleton ( vedi riferimento ) e alcuni dei miei singoli hanno bisogno di un contesto. La Application
classe si presenta così:
public class MyApplication extends Application {
private static final String TAG = MyApplication.class.getSimpleName();
private static MyApplication sInstance;
@Contract(pure = true)
@Nullable
public static Context getAppContext() {
return sInstance;
}
@Override
public void onCreate() {
super.onCreate();
Log.d(TAG, "onCreate() called");
sInstance = this;
}
}
E i singoli appaiono così:
public class DataManager {
private static final String TAG = DataManager.class.getSimpleName();
@Contract(pure = true)
public static DataManager getInstance() {
return InstanceHolder.INSTANCE;
}
private DataManager() {
doStuffRequiringContext(MyApplication.getAppContext());
}
private static final class InstanceHolder {
@SuppressLint("StaticFieldLeak")
private static final DataManager INSTANCE = new DataManager();
}
}
In questo modo non ho bisogno di avere un contesto ogni volta che utilizzo un singleton e ottengo un'inizializzazione sincronizzata pigra con una quantità minima di codice.
Suggerimento: l'aggiornamento del modello singleton di Android Studio consente di risparmiare molto tempo.
Penso che tu possa usare la classe Application per molte cose, ma sono tutte legate alla tua necessità di fare alcune cose PRIMA che qualsiasi attività o servizio venga avviato. Ad esempio, nella mia applicazione utilizzo caratteri personalizzati. Invece di chiamare
Typeface.createFromAsset()
da ogni attività per ottenere riferimenti per i miei caratteri dalla cartella Risorse (questo è un male perché provocherà una perdita di memoria poiché manterrai un riferimento alle risorse ogni volta che chiami quel metodo), lo faccio dal onCreate()
metodo nella mia classe Applicazione :
private App appInstance;
Typeface quickSandRegular;
...
public void onCreate() {
super.onCreate();
appInstance = this;
quicksandRegular = Typeface.createFromAsset(getApplicationContext().getAssets(),
"fonts/Quicksand-Regular.otf");
...
}
Ora, ho anche un metodo definito come questo:
public static App getAppInstance() {
return appInstance;
}
e questo:
public Typeface getQuickSandRegular() {
return quicksandRegular;
}
Quindi, da qualsiasi parte della mia applicazione, tutto ciò che devo fare è:
App.getAppInstance().getQuickSandRegular()
Un altro uso della classe Application per me è verificare se il dispositivo è connesso a Internet PRIMA delle attività e dei servizi che richiedono una connessione effettivamente avviata e intraprendono le azioni necessarie.
Fonte: https://github.com/codepath/android_guides/wiki/Understanding-the-Android-Application-Class
In molte app, non è necessario lavorare direttamente con una classe di applicazione. Tuttavia, ci sono alcuni usi accettabili di una classe di applicazione personalizzata:
- Attività specializzate che devono essere eseguite prima della creazione della prima attività
- Inizializzazione globale che deve essere condivisa tra tutti i componenti (segnalazione di arresti anomali, persistenza)
- Metodi statici per un facile accesso a dati statici immutabili come un oggetto client di rete condiviso
Non si dovrebbe mai archiviare i dati di istanza mutabili all'interno dell'oggetto Applicazione perché se si presume che i dati rimarranno lì, l'applicazione si arresterà inevitabilmente a un certo punto con una NullPointerException. L'oggetto applicazione non è garantito per rimanere in memoria per sempre, verrà ucciso. Contrariamente alla credenza popolare, l'app non verrà riavviata da zero. Android creerà un nuovo oggetto Applicazione e avvierà l'attività in cui l'utente era prima per dare l'illusione che l'applicazione non fosse mai stata uccisa in primo luogo.
È possibile accedere alle variabili a qualsiasi classe senza creare oggetti, se è esteso dall'applicazione. Possono essere chiamati a livello globale e il loro stato viene mantenuto fino a quando l'applicazione non viene uccisa.
L'uso dell'applicazione di estensione rende l'applicazione sicura per qualsiasi tipo di operazione desiderata durante il periodo di esecuzione dell'applicazione. Ora può essere qualsiasi tipo di variabile e supponiamo che se si desidera recuperare alcuni dati dal server, è possibile inserire l'applicazione asincrona in modo che venga recuperata ogni volta e continuamente, in modo da ottenere automaticamente i dati aggiornati. Utilizzare questo collegamento per ulteriori conoscenze ....
http://www.intridea.com/blog/2011/5/24/how-to-use-application-object-of-android
Per aggiungere alle altre risposte che affermano che si potrebbero desiderare di memorizzare variabili nell'ambito dell'applicazione, per eventuali thread a esecuzione prolungata o altri oggetti che devono essere associati all'applicazione in cui NON si sta utilizzando un'attività (l'applicazione non è un'attività). come non essere in grado di richiedere un servizio associato .. quindi si preferisce l'associazione all'istanza dell'applicazione. L'unico avvertimento ovvio con questo approccio è che gli oggetti vivono per tutto il tempo in cui l'applicazione è viva, quindi è necessario un controllo più implicito sulla memoria, altrimenti si verificano problemi relativi alla memoria come le perdite.
Qualcos'altro che potresti trovare utile è che nell'ordine delle operazioni, l'applicazione si avvia prima di qualsiasi attività. In questo lasso di tempo, puoi preparare le pulizie necessarie che si verificherebbero prima della tua prima attività se lo desideri.
2018-10-19 11:31:55.246 8643-8643/: application created
2018-10-19 11:31:55.630 8643-8643/: activity created