Chiaramente non tutte le applicazioni hanno bisogno di averle tutte e quattro, ma di norma le applicazioni sono una combinazione di queste.
Una volta che si è deciso quali componenti sono necessari per l'applicazione, vanno scritti nel file AndroidManifest.xml. Questo è un file (in formato XML) dove sono dichiarati tutti i componenti delle applicazioni ed i loro requisiti.
Activity
Le activity sono i blocchi più comuni per la creazione di applicazioni. Di norma un'activity è uno schermo singolo dell'applicazione. Ogni activity è implementata in una singola classe che estende la classe Activity e mostra la user interface composta da Views e risponde agli eventi. Molte applicazioni chiaramente consistono di schermi multipli. Per esempio un'applicazione per mandare SMS potrebbe avere uno schermo che mostra la lista di contatti per scegliere il destinatario di un messaggio, un secondo schermo per scrivere il messaggio al contatto ed altri schermi per vedere i messaggi già mandati. Ognuno di questi schermi deve essere implementato come Activity. Muoversi da uno schermo all'altro si esegue semplicemente startando una nuova activity. In alcuni casi un'activity può ritornare dei valori all'activity precedente. Per esempio un'activity che sceglie una foto dalla library ritornerà all'activity precedente la foto scelta.
Quando un nuovo schermo si apre, lo schermo precedente si mette in pausa ed è messo su una stack history. L'user può comunque navigare indietro, in schermi precedentemente aperti. Gli schermi possono anche essere eliminati dalla stack history quando non sono più necessari. Android mantiene la stack history per ogni applicazione lanciata.
Intent and Intent Filters
Android usa una classe speciale chiamata Intent per muoversi da schermo a schermo. Un intent descrive cosa un'applicazione vuole che venga effettuato. Le due parti più importanti della struttura dell'intent sono l'azione e i dati su dove deve agire. I tipici valori per l'azione sono MAIN (la principale per l'activity), VIEW, PICK, EDIT, ecc. I dati sono espressi come URI. Per esempio per vedere le informazioni di una persona (attraverso il contatto nella rubrica), bisogna creare un intent che con l'azione VIEW e con il data settato come URI che rappresenta quella persona.
C'è una classe legata all'intent che è l'IntentFilter. Mentre l'intent è l'effettiva richiesta di fare qualcosa, l'intent filter è una descrizione di quali intenti un'activity è capace di manipolare. Un'activity che mostra le informazioni di contatto di una persona pubblicherà un IntentFilter che mostrerà che è capace di manipolare l'azione VIEW quando applicata su un dato che rappresenta una persona. Le activity pubblicano i loro IntentFilters nel file AndroidManifest.xml.
Navigare da schermo a schermo è compiuto risolvendo intenti. Per navigare in avanti, un'activity chiama startActivity(myIntent). Il sistema quindi cerca gli intent filters per tutte le applicazioni installate e prende l'activity per l'acquale l'intent filter combacia meglio con myIntent. La nuova activity è informata dell'intent e la lancia. Il processo di risolvimento di intent avviene in run time quando startActivity è chiamato, il che offre due benefici:
- Le activity possono riutilizzare funzionalità di altri componenti semplicemente facendo una richiesta nella forma di un intent
- Le activity possono essere rimpiazzate in qualsiasi momento da una nuova activity con un IntentFilter equivalente
Intent Receiver
L'IntentReceiver è usato quando si vuole far eseguire qualcosa all'applicazione in reazione ad un evento esterno. Per esempio, quando il telefono suona, o quando c'è una rete a cui collegarsi, o quando è mezzanotte. Gli intent receivers non hanno una UI, ma possono usare il NotificationManager per avvertire l'utente se qualcosa di interessante è successo. Anche gli intent receivers sono registrati nell'AndroidManifest.xml, ma si possono anche registrare dal codice usando Context.registerReceiver(). L'applicazione che lancia l'intent receiver non deve star per forza runnando per fare in modo che l'intent receiver sia chiamato: il sistema starterà da solo l'applicazione se necessario quando un intent receiver è eseguito. Le applicazioni possono anche mandare i propri intent ad altre applicazioni attraverso Context.broadcastintent().
Due parole sui Service: un service è un codice che runna senza UI. Un buon esempio è un media player che sta riproducendo delle canzoni da una playlist. In un media player ci saranno una o più activities che permettono all'utente di scegliere le canzoni e farle riprodurre. In ogni caso la musica si suona continuerà a suonare anche se l'utente naviga altrove (in altre applicazioni per esempio), questo perche l'activity del media player può lanciare un service usando Context.startService() in background per fare in modo che la musica continui. La musica continuerà a suonare finchè non finisce. Un'altra cosa interessante è che ci si può connettere ai services attraverso Context.bindService(). Quando connesso ad un service, si può comunicare attraverso un'interfaccia esposta da quest'ultimo. Nell'esempio del media player, questo servizio potrebbe permettere all'utente di fermare o far ricominciare la musica.
Content Provider
Le applicazioni possono conservare dati in files, database SQLite, o ogni altri tipo di meccanismo che ha senso. Un content provider è utile quando si vuole condividere le informazioni di un'applicazione con altre applicazioni. Un content provider è una classe che implementa un set di metodi standard per lasciar depositare e ritirare informazioni dalle altre applicazioni. Per avere più informazioni riguardo al content provider comunque, consiglio di riferirsi all'API di Android sotto Accessing Content Providers.
Hope it helps ;).
