Il Context è costituito da un insieme di informazioni riguardanti l’ambiente di esecuzione di un’app Android. Per il programmatore rappresenta, l’oggetto “magico” cui chiedere un riferimento a qualsiasi cosa sia al di fuori dell’applicazione ma all’interno del sistema operativo. Il neo-sviluppatore lo incontra ben presto, sin dai primi esempi di programmazione: basti ricordare che anche per ottenere un semplice Toast (rapida notifica che offre un messaggio all’utente) in un’Activity è necessario passare un riferimento al Context.

Toast.makeText(this, 
                     "Ciao!",
                              Toast.LENGTH_LONG).show();

Nell’esempio appena riportato, il this rappresenta il riferimento all’Activity ma soprattutto al Context che essa contiene.

Ma nonostante lo si usi sin dalle prime righe di codice Android, spesso permangono molti dubbi sul Context, alcuni dei quali – se non risolti – possono far incappare in pericolosi errori di memoria detti memory leak. Cerchiamo di dare una risposta ai più comuni.

Dove trovo un Context?

Durante l’esecuzione di un’applicazione, molti Context esistono contemporaneamente e tanti vengono via via deallocati e sostituiti da altri.

La figura seguente mostra alcune classi del framework che mediante il meccanismo dell’ereditarietà costruiscono il Context che usiamo nelle applicazioni

Ogni componente per applicazioni Android dispone di un riferimento al Context:

• Application che rappresenta l’applicazione nel suo complesso lo eredita (vedi figura);
• Activity e Service lo ereditano anch’essi (vedi figura anche in questo caso);
• i ContentProvider lo ottengono dal loro metodo getContext();
• i BroadcastReceiver lo ricevono come argomento nel loro metodo onReceive().

Quale Context usare?

In molti casi, possiamo scegliere tra più Context. Ad esempio, all’interno di un’Activity disponiamo del Context che l’Activity eredita e di quello offerto dall’oggetto Application.

Quali le differenze:

• il Context dell’Activity condivide il suo ciclo di vita pertanto va usato solo in classi che collaboreranno strettamente con essa. Quando l’Activity verrà fermata e (probabilmente) distrutta secondo quanto previsto dal suo ciclo di vita, anche il Context ad essa legato non sarà più utilizzabile. Conservare tale Context in elementi che potrebbero sopravvivere ad un’Activity espone l’applicazione a possibili memory leak;
• il Context dell’Application va utilizzato ogni volta che un suo riferimento deve sopravvivere ai componenti (si pensi ad Activity ma anche Service e altro ancora). Ciò protegge dai memory leak.

L’esempio del capo e dell’assistente

Spesso si usa un esempio per spiegare il vero ruolo del Context, quello del capo e dell’assistente. Immaginiamo un capo ufficio che sa gestire bene il suo lavoro ma per poterlo fare ha bisogno del continuo supporto dell’assistente. Ha bisogno di consultare un fascicolo dello schedario? Lo chiede all’assistente. Desidera un caffè per darsi la carica? Lo chiede all’assistente. E così via.

Trasponendo l’esempio in Android, il capo è l’applicazione mentre l’assistente è il Context. I fascicoli, il caffè e qualsiasi altra cosa l’assistente procuri al suo capo simboleggiano le risorse che il Context fornisce continuamente.

Conclusioni

Perchè si reputa necessario fornire un esempio come quello del capo e dell’assistente? Perchè il Context è facile da utilizzare, almeno in prima battuta fornendo un riferimento all’Activity, ma nasconde un significato più profondo che al complicarsi delle applicazioni può mettere in difficoltà il programmatore.

Con questo post abbiamo cercato di fare un pò di chiarezza. Cosa ne pensate? Avete qualche considerazione interessante sull’argomento?

Commentate e fateci sapere. Vi aspettiamo!