Tip Android #007 – Activity e Service quando usarli

AndroidBuongiorno a tutti,

l’argomento di questo post, contrariamente a quelli genericamente trattati, ha un obbiettivo più teorico e quindi sarà privo di snippets da usare per il copia incolla.

Le classi  fondamentali attorno alle quali ruota solitamente un’applicazione Android sono Activity e Service, la prima è una classe che si occupa di gestire l’interazione con l’utente mostrando l’output della procedura e gestendo l’input diretto dell’utente. La seconda è invece dedicata al lavoro di elaborazione vero e proprio.

Perchè esiste questa distinzione e come mai le applicazioni dovrebbero sempre essere strutturate tenendo conto dei compiti di questa classe sono i due punti fondamentali da chiarire.

Iniziamo subito col dire che, nella pratica, nulla vieta di gestire le elaborazioni all’interno di un’Activity ma proprio per la loro natura è sconsigliato farlo. Aggiungo inoltre che in teoria tutte le applicazioni dovrebbero avere oltre che un’Activity anche un Service.

Per comprendere il tutto dobbiamo fare qualche passo indietro nella storia dell’informatica. Questa disciplina si è evoluta tantissimo negli anni, non mi riferisco all’hardware, sicuramente esempio evidente, ma soprattutto al software ed a come esso viene scritto.

In poco meno di 30 anni si è passati da una programmazione a schede perforate e codice a spaghetti, alla programmazione struttura, a quella modulare, a quella ad oggetti, a quella a componenti, fino a raggiungere gli attuali paradigmi.

Lo scopo principale è sempre stato quello della riusabilità, spesso ci si trova a riscrivere blocchi enormi di codice per ripetere funzioni già implementate in altre applicazioni. Progettando correttamente le funzionalità, si riesce a ridurre di molto la quantità di codice riscritto, questo oltre a ridurre di molto il tempo di sviluppo ha permesso di ridurre il numero di errori, in quanto il riutilizzo di codice già testato permette di saltare intere sessioni di debug in merito alle specifiche funzionalità riutilizzate.

Con l’evolversi delle tecniche di programmazione, ma soprattutto con l’avvento delle interfacce grafiche prima e del web poi si sono venuti a creare, nel tempo, dei pattern architetturali che ormai sono imprescindibili dall’approccio allo sviluppo, al punto di essere presi, alcuni, come riferimento per lo sviluppo dei framework comunemente adoperati nella creazione delle applicazioni.

Il più famoso, e comunemente usato, tra questi pattern architetturali è quello denominato Model View Controller (contratto in MVC).

Questo pattern architetturale è tipico delle strutture a tre livelli dei siti web dinamici, ma anche delle applicazioni di recente sviluppo.

Brevemente esso identifica tre elementi:

  1. Il model, ovvero l’insieme dei dati e le regole per accedervi
  2. La view, ovvero gli algoritmi necessari per rappresentare il dato, ma anche per riceverlo in input da parte dell’utente
  3. Il controller, ovvero tutte le funzionalità necessarie alla validazione ed alla trasformazione del dato e che rappresente il collante tra il model e la view.

Questa struttura, se implementata correttamente, permette, a fronte di un incremento del codice da scrivere, una struttura più snella i cui componenti sono tutti riutilizzabili più facilmente.

Seguendo la premessa che classificava le Activity come classi dedicate all’interfaccia ed i Service come classi dedicate alla gestione delle regole di business è quasi automatico collocare le prime al punto 2 e le seconde al punto 3.

Il modello MVC, proprio per la struttura dell’SDK, andrebbe sempre adottato ed implementato correttamente, indipendentemente dall’entità dell’applicazione da scrivere. Questo perchè l’approccio permette di riadoperare le informazioni in modo più semplice in altre applicazioni.

Ad esempio se scriviamo un Service che accede ad un servizio web e si desidera riutilizzare il servizio in un’altra applicazione, probabilmente basterà riutilizzare il servizio, con poche e nulle modifiche, per ottenere nuovamente le funzionalità richieste.

L’uso dei servizi, soprattutto per qunto riguarda l’accesso ai dati siano essi interni al dispositivo che esterni è quasi imprescindibile, ed infatti è fortemente indicato da Google come metodo preferenziale. Questo per diversi motivi tra cui i più importanti sono:

  • I servizi girano su thread separati e, quindi, anche in caso di esecuzioni lente, l’interfaccia non subisce blocchi o ritardi
  • L’uso di un servizio è sostanzialmente slegato da un’Activity per cui anche se questa non è più visibile l’elaborazione può procedere regolarmente, lasciando la rappresentazione del risultato in un momento successivo.
  • Un servizio può essere disponibile anche all’esterno dell’applicazione e quindi essere richiamato da altre applicazioni.

In merito al secondo punto, spesso si desidera che l’output sia sincronizzato al termine dell’operazione, anche se apparentemente l’uso di un Service può apparire controproducente, in realtà permette comunque di avere un output sincronizzato sfruttando sapientemente i meccanismi di comunicazione tra le due tipologie di classi.

Riassumendo, quindi, Activity e Service sono due componenti fondamentali di un’applicazione per Android ed il loro uso è imprescindibile per una corretta implementazione.

Anche se apparentemente sembra di avere un overhead nello sviluppo del codice, nel medio/lungo termine i vantaggi sono sensibili, inoltre essendo questo il metodo consigliato da Google non è da escludere che evoluzioni future del sistema operativo non possano creare condizioni tali per cui operazioni attualmente permesse in futuro non possano essere difficoltose se non impraticabili.

Arrivederci al prossimo suggerimento,

Roberto S.



Related Posts Plugin for WordPress, Blogger...

Questa voce è stata pubblicata in Android Tips e contrassegnata con , , , , . Contrassegna il permalink.
Wordpress Code Snippet by Allan Collins