Creare una applicazione Android: Shake & Shut!

19 settembre 2012

In questo articolo vedremo come realizzare un’applicazione per Android che azzittisca il telefono quando questi viene scosso con insistenza. Ovvero quando viene “shakerato” come un buon cocktail!

L’idea e il progetto

L’idea è di creare un’applicazione che rimanga “in ascolto” dello stato del telefono e, quando questo viene agitato in corrispondenza della chiamata, intervenga sulle impostazioni audio mettendo automaticamente il telefono in modalità silenziosa. Come vedremo, questa idea è percorribile ma, allo stato attuale, altamente perfettibile.

Un aspetto da tenere sempre presente, quando si progetta un’applicazione Android, è che il dispositivo su cui girerà l’app avrà risorse limitate. Perciò è molto importante progettare correttamente il software, usando i componenti adatti per ogni parte, per limitare l’uso della CPU (e della batteria!) al minimo indispensabile.

Per costruire un’applicazione Android ci si avvale di 4 componenti fondamentali, rappresentati ognuno da un’opportuna classe Java presente nelle librerie di sistema. Sviluppare significa estendere tali classi, creando delle istanze specifiche atte alle proprie esigenze. Una app è composta da una o più istanze di questi componenti. Brevemente, essi sono:

  • Activities
  • Service
  • Broadcast Receiver
  • Content Provider

Conoscendo il ciclo di vita di ciascuno di questi componenti è possibile intervenire, mediante il meccanismo dell’override, all’interno del ciclo stesso perché il componente reagisca secondo la volontà dello sviluppatore.

Activity, Servizi & altro

Una activity è il componente principale di un’applicazione poiché è l’unico responsabile dell’interfaccia con l’utente, l’unico ad avere una componente grafica. La sua logica, però, è di essere messa in pausa (e poi distrutta dal sistema) non appena ‘utente passa ad una nuova activity, poiché l’activity con cui l’utente sta interagendo ha sempre priorità massima su tutti gli altri processi. Sebbene dunque sia un componente fondamentale non può essere usato per “rimanere in ascolto”. Per il momento, dunque, lo mettiamo da parte.

Un service (servizio) è un componente che gira in background, nascosto all’utente, ma che viene mantenuto sempre attivo, con le giuste priorità (gestite dal sistema!) fino a che non abbia completato il suo task.

Un broadcast receiver, invece, è un componente che viene allertato a seguito di un evento di sistema, come la ricezione di un messaggio, il superamento di una certa soglia di livello di batteria, l’accensione o spegnimento del dispositivo o altro ancora.

Infine, un content provider è un componente che fornisce una sorgente di dati. Normalmente questi dati provengono da un database (Android è dotato di un database SQLite interno), ma potrebbero anche venire da un file o dalla rete. Il ruolo del content provider è di fornire un accesso standard ai dati e ottimizzare la loro organizzazione/lettura.

Il progetto

Visti i componenti a disposizione sembra evidente che quello più adatto alle nostre esigenze sia un servizio, il quale rimarrà in ascolto dello shake e, all’arrivo di una chiamata, intervenga sulle impostazioni audio del dispositivo.

Questa soluzione però è ancora imperfetta: un servizio che rimanga sempre attivo “brucia” continuamente risorse di sistema.

Lo scenario ottimale è che il servizio sia installato ma inattivo e venga attivato solo all’arrivo di una chiamata. Tale scenario è raggiungibile attraverso l’uso un Broadcast Receiver, impostato sull’ascolto dell’arrivo una chiamata. Sarà il Receiver a svegliare e fermare il servizio al momento opportuno, mentre quest’ultimo “ascolterà” se l’utente agita o meno il telefono.

Rimane un problema: come rilevare lo “shake”. Per risolvere questo punto si può usare l’accelerometro, presente su molti dispositivi. Esso infatti rileva la posizione del telefono rispetto alla Terra valutandola in tre variabili secondo i tre classici assi cartesiani: X, Y e Z.

È possibile rilevare la posizione nell’intervallo di qualche millisecondo e, se questa cambia repentinamente su tutti e tre gli assi, possiamo supporre di essere in presenza di un evento di “shake”.

Per il progetto in questione, quindi, faremo uso di un broadcast receiver ed un service. Infine, per “ascoltare” l’accelerometro progetteremo un’opportuno Listener Java.

La struttura dell’applicazione sarà la seguente: Il broadcast receiver sarà impostato sullo stato delle chiamate e reagirà sia quando il telefono inizia a squillare che quando smette. Il servizio, infine, rimarrà in ascolto della posizione del telefono attraverso un opportuno “Listener” creato ad hoc.

Ecco lo schema:

Figura 1.

Se vuoi aggiornamenti su Creare una applicazione Android: Shake & Shut! inserisci la tua e-mail nel box qui sotto:
 
X
Se vuoi aggiornamenti su Creare una applicazione Android: Shake & Shut!

inserisci la tua e-mail nel box qui sotto:

Ho letto e acconsento l'informativa sulla privacy

Acconsento al trattamento di cui al punto 3 dell'informativa sulla privacy