getApplication () vs. getApplicationContext ()

Non sono riuscito a trovare una risposta soddisfacente a questo, quindi eccoci qui: qual è il problema Activity/Service.getApplication()e Context.getApplicationContext()?

Nella nostra applicazione, entrambi restituiscono lo stesso oggetto. In un caso ActivityTestCase, deridere l'applicazione farà getApplication()tornare indietro con il finto, ma getApplicationContextrestituirà comunque un'istanza di contesto diversa (quella iniettata da Android). È un bug? È apposta?

Non capisco nemmeno la differenza in primo luogo. Esistono casi al di fuori di una suite di test in cui entrambe le chiamate possono tornare con oggetti diversi? Quando e perché? Inoltre, perché è getApplicationdefinito su Activitye Service, ma non su Context? Non dovrebbe sempre esserci un'istanza di applicazione valida disponibile da qualsiasi luogo ?

Domanda molto interessante. Penso che sia principalmente un significato semantico e potrebbe anche essere dovuto a ragioni storiche.

Sebbene nelle attuali implementazioni di attività e servizi Android getApplication()e getApplicationContext()restituisca lo stesso oggetto, non vi è alcuna garanzia che ciò avvenga sempre (ad esempio, in un'implementazione specifica del fornitore).

Quindi, se vuoi la classe Application che hai registrato nel Manifest, non dovresti mai chiamarla getApplicationContext()e lanciarla nella tua applicazione, perché potrebbe non essere l'istanza dell'applicazione (che ovviamente hai provato con il framework di test).

Perché getApplicationContext()esiste in primo luogo?

getApplication()è disponibile solo nella classe Activity e nella classe Service, mentre getApplicationContext()è dichiarato nella classe Context.

Questo in realtà significa una cosa: quando si scrive il codice in un ricevitore broadcast, che non è un contesto ma viene dato un contesto nel suo metodo onReceive, è possibile solo chiamare getApplicationContext(). Ciò significa anche che non è garantito l'accesso alla propria applicazione in un BroadcastReceiver.

Quando guardi il codice Android, vedi che quando è collegata, un'attività riceve un contesto di base e un'applicazione, e questi sono parametri diversi. getApplicationContext()delegati a cui è chiamata baseContext.getApplicationContext().

Ancora una cosa: la documentazione dice che nella maggior parte dei casi non è necessario sottoclassare l'Applicazione:

Normalmente non è necessario eseguire la sottoclasse Application. Nella maggior parte dei casi, i singoli statici possono fornire la stessa funzionalità in un modo più modulare. Se il tuo singleton ha bisogno di un contesto globale (ad esempio per registrare i ricevitori di trasmissione), la funzione per recuperarlo può essere assegnata a un oggetto Contextche utilizza internamente Context.getApplicationContext()durante la prima costruzione del singleton.

So che questa non è una risposta esatta e precisa, ma risponde alla tua domanda?

Confronta getApplication()e getApplicationContext().

getApplicationrestituisce un Applicationoggetto che ti consentirà di gestire lo stato globale dell'applicazione e rispondere ad alcune situazioni del dispositivo come onLowMemory()e onConfigurationChanged().

getApplicationContextrestituisce il contesto dell'applicazione globale - la differenza rispetto ad altri contesti è che, ad esempio, un contesto di attività potrebbe essere distrutto (o reso altrimenti non disponibile) da Android al termine dell'attività. Il contesto dell'applicazione rimane disponibile per tutto il tempo in cui esiste l'oggetto applicazione (che non è legato a uno specifico Activity), quindi è possibile utilizzarlo per cose come le notifiche che richiedono un contesto che sarà disponibile per periodi più lunghi e indipendente dagli oggetti IU transitori.

Immagino che dipenda da cosa sta facendo il tuo codice se questi possono o meno essere gli stessi - anche se in uso normale, mi aspetto che siano diversi.

Sembra avere a che fare con il contesto. La maggior parte delle classi derivate Contextsono in realtà a ContextWrapper, che essenzialmente delega in un altro contesto, possibilmente con modifiche da parte del wrapper.

Il contesto è un'astrazione generale che supporta derisione e proxy. Poiché molti contesti sono legati a un oggetto a durata limitata come un Activity, ci deve essere un modo per ottenere un contesto di maggiore durata, per scopi come la registrazione per le notifiche future. Ciò è ottenuto da Context.getApplicationContext(). Un'implementazione logica consiste nel restituire l' Applicationoggetto globale , ma nulla impedisce a un'implementazione di contesto di restituire un wrapper o un proxy con una durata adeguata.

Attività e servizi sono associati in modo più specifico a un Applicationoggetto. L'utilità di questo, credo, è che puoi creare e registrare nel manifest una classe personalizzata derivata Applicationed essere certo che Activity.getApplication()o Service.getApplication()restituirà quell'oggetto specifico di quel tipo specifico, che puoi trasmettere alla tua Applicationclasse derivata e usare per qualunque cosa scopo personalizzato.

In altre parole, getApplication()è garantito per restituire un Applicationoggetto, mentre getApplicationContext()è libero di restituire un proxy.

Per rispondere alla domanda, getApplication () restituisce un oggetto Application e getApplicationContext () restituisce un oggetto Context. Sulla base delle tue osservazioni, presumo che il contesto di entrambi sia identico (ovvero dietro le quinte la classe Application chiama quest'ultima funzione per popolare la parte Context della classe base o si verifica un'azione equivalente). Non dovrebbe importare davvero quale funzione chiami se hai solo bisogno di un contesto.