Mobile Computing - Teoria

Sviluppo di applicazioni per dispositivi mobili

Mobile Computing (MC)

Per MC si intende lo studio di varie problematiche in un contesto caratterizzato da:

• Mobilità dei dispositivi durante la fruizione di servizi;
• Mobilità degli utenti;
• Eterogeneità delle capacità dei dispositivi e delle loro interfacce utente;
• Comunicazione via reti wireless;
• Connessione non costante;
• Dispositivi con sensori avanzati.

Il Mobile Computing richiede di affrontare problemi in diverse discipline informatiche:

Discipline coinvolte nel MC

1. Data Management – i dispositivi mobili richiedono il trattamento di dati particolari (posizione, sensori);
2. Sistemi Distribuiti – le applicazioni eseguite su dispositivi mobile sono spesso parte di un sistema distribuito che può includere l'accesso a servizi remoti (cloud) e la comunicazione con altri dispositivi (tramite servizi web).
3. Reti – i dispositivi mobili pongono nuovi problemi di rete. Non a caso sono nati nuovi protocolli appositamente per le loro necessità (reti cellulari, NFC, Bluetooth). Da tener conto è l'affidabilità della connessione di rete, fornita attraverso canali multipli e sempre differenti.
4. HCI – i dispositivi mobili presentano strumenti di I/O differenti dai dispositivi tradizionali, per cui hanno reso necessario ripensare completamente il paradigma di interazione con l'utente.
5. Sistemi Operativi – il MC ha posto nuovi problemi dal punto di vista dei sistemi operativi, quali le capacità limitate di computazione, il risparmio energetico, l'accesso semplificato all'hardware per gli sviluppatori, la privacy/sicurezza, i vincoli real-time.
6. Aspetti economici/sociali – il market delle applicazioni ha aperto un enorme mercato, sia per le grandi aziende che per i programmatori singoli.

I sensori

Composti dai trasduttori, ovvero dispositivi che trasformano una forma di energia in un’altra.

• Trasduttori di input – convertono una quantità in un segnale elettrico (sensori);
• Trasduttori di output – convertono un segnale elettrico in una quantità (attuatori).

Tipicamente nei dispositivi mobili sono presenti:

• Microfono;
• Camera (foto+video);
• Accelerometri: misurano l'accelerazione (inclusa quella di gravità) sui tre assi del dispositivo;
• Giroscopio: misura la rotazione attorno ai tre assi del dispositivo;
• Magnetometro;
• Barometro;
• GPS;
• Sensore di profondità;
• Sensore di luce;
• Lettore di impronte digitali;
• Sensori biometrici: ECG, battito, temperatura, pressione, saturazione, conduttività, glucosio, ecc.

Molto diffusi sono i sensori indossabili, ovvero capi o accessori che contengono determinati sensori.

Sensori virtuali

In assenza di un sensore fisico cercano di fornire le informazioni richieste. Un ottimo esempio è dato dai servizi remoti, che forniscono informazioni di contesto a più client (meteo).

Un altro tipo è la simulazione: ad esempio, si può simulare il giroscopio utilizzando insieme accelerometri e magnetometro. Un sensore virtuale è un’astrazione che permette di calcolare informazioni di alto livello aggregando dati da altri sensori. Esempi concreti sono il contapassi (accelerometri e giroscopi) e l'attitude (calcola orientamento device rispetto ad un asse di riferimento).

Sistemi operativi per i dispositivi mobili

Un sistema operativo per dispositivi mobili deve rispettare le seguenti peculiarità:

• Vincoli real-time – ricezione con notifica immediata di una chiamata;
• Gestione energetica – garanzie di consumi minimali;
• Risorse computazionali ridotte – smartphone di fascia bassa e wearable necessitano di ottimizzazioni per l’utilizzo delle risorse;
• Connettività – non costante e realizzata tramite diversi tipi di connessione;
• Eccellente user experience.

Caratteristiche peculiari

Nei sistemi operativi per mobile (Android, iOS) sono condivise alcune caratteristiche.

1 - Mancanza tecniche di paging

Quando la memoria principale termina, alcune applicazioni devono essere arrestate, ciò potrebbe compromettere l'utilizzo di app o l'esecuzione di particolari azioni da parte dell'utente.

Soluzione: App e SO collaborano per nascondere all’utente la chiusura delle app. È definito un ciclo di vita dell’applicazione (o di alcune parti) organizzato in eventi, i quali sono richiamati dal SO. Ad ogni evento l’applicazione può eseguire un codice definito dal programmatore. Il ciclo di vita dell’applicazione è associato ad una Activity, ovvero la componente che rappresenta una schermata di un’applicazione.

Esempio

1. L’utente scrive la mail nel Mail Client.
2. Arriva una telefonata, il SO, prima di far partire l’app per rispondere al telefono, richiama un metodo (es: “stai per andare in background”) al Mail Client.
3. Il Mail Client salva tutte le informazioni (es: in un file): destinatari, l’oggetto e il testo della mail.
4. Il SO fa partire l’app per gestire la telefonata, finisce la memoria e dunque termina il Mail Client.
5. Finisce la telefonata e l’utente (o il SO) fa partire nuovamente il Mail Client.
6. Alla partenza il Mail Client controlla se c’è qualche informazione che è stata memorizzata. Trova queste informazioni, dunque fa ripartire la schermata di composizione della mail e inserisce i dati salvati.
7. L’utente può continuare a scrivere la mail e non si accorge neppure che l’applicazione sia stata terminata.

2 – Gestione della GUI con single thread

È definito un thread principale (main thread) il quale è l’unico che può gestire gli eventi e modificare l’interfaccia grafica.

Problema: Potrebbe emergere il problema di blocco del sistema: un’app al tocco su un pulsante effettua una comunicazione di rete. Il SO genera un evento che viene gestito dall’app. Al tocco, l’app effettua la comunicazione (operazione di I/O), ma la chiamata è bloccante, poiché il thread rimane in attesa della risposta. Il thread bloccato è il main thread, che è in attesa della risposta alla comunicazione. Dato che nessun altro thread può modificare la GUI, il sistema risulta bloccato.

Soluzione: Tutte le operazioni di I/O devono essere svolte da thread secondari. Ciò comporta l’introduzione della gestione della sincronizzazione, poiché quando il thread secondario termina non può aggiornare l’interfaccia, ma deve far intervenire il main thread. Utilizzo dei costrutti wait/notify.

3 – Supporto alle push notification

Le push notification sono un sistema che permette ad un server di inviare informazioni ad un client.

4 – Integrazione con i servizi internet

Esistono diverse API di SO che permettono di interagire con i più diffusi servizi internet (in particolare i social network).

In teoria, per interagire con un web service remoto, un client dovrebbe implementare il relativo protocollo di rete, ma per semplificare la scrittura del codice ci sono due soluzioni:

• Creare librerie che implementano il protocollo di rete e permettono ai client di interagire con web service facendo chiamate locali alle librerie;
• Integrare le librerie direttamente nel SO (principio diffuso: prima inserisco nel software, successivamente lo integro nel SO).

5 – Integrazione con store online

Normalmente sui SO di dispositivi mobili è possibile eseguire solo applicazioni scaricate dallo store (App Store, Google Play Store), cosicché le app scaricate siano firmate. La procedura di gestione delle firme per il rilascio sullo store può essere complessa, in particolare per iOS. Le app pubblicate sullo store sono infatti verificate:

• iOS – verifica automatica + manuale prima della pubblicazione;
• Android – verifica automatica prima della pubblicazione, verifica manuale in seguito.

Differenze tra Android e iOS

Entrambi i SO permettono il multitasking, ovvero oltre all’applicazione in foreground possono essere in esecuzione anche app in background (la cui GUI non è visualizzata), ma l’approccio è diverso tra le due piattaforme.

ANDROID

È possibile eseguire codice arbitrario in background, basta che venga comunicato esplicitamente al SO. Tecnicamente si creano delle istanze della classe Service. Quando il SO esaurisce la memoria e deve terminare un’app, dà la precedenza a quelle che non stanno eseguendo in background.

iOS

Le applicazioni non possono eseguire codice arbitrario in background, ma possono però specificare del codice che può essere eseguito in risposta ad alcuni eventi (anche in background). Le applicazioni hanno un tempo ridotto per gestire l’evento. Se non terminano entro tale tempo, potrebbero essere arrestate.

Esempio

Un’app può utilizzare la posizione anche in background. In questo caso, ogni volta che il SO osserva un cambio di posizione lo segnala all’app. Gli eventi da gestire in background devono essere specificati in un file di configurazione e devono essere consistenti con l’effettivo uso dell’applicazione: questo aspetto viene verificato manualmente nel momento in cui l’app viene inviata allo store.

Esempio di approvazione

Voglio fare un’applicazione che calcoli, anche in background, se un numero molto grande è primo o meno.

• Faccio il furbo: dichiaro che l’app necessita dei permessi per le app di navigazione. In questo modo, ogni volta che il device cambia posizione, la mia app può eseguire in background per qualche secondo.
• Quando provo l’app sul computer di sviluppo, il tutto funziona.
• Quando la mando alla Apple per approvazione, viene respinta (perché non è un’app di navigazione).

Astrazione dell’hardware

Una delle funzioni principali del SO è permettere al programmatore di astrarsi dalle caratteristiche dell’hardware, e nel caso dei dispositivi mobili questo aspetto facilita molto bene il lavoro di sviluppo: per richiedere la posizione non è necessario che il programmatore interagisca direttamente con il GPS.

Esistono però alcuni casi dove subentrano dei problemi.

Experience report: astrazione dell’hardware nell’uso della camera

Problema: Accedere a basso livello a informazioni della camera per calcolare la quantità di luce in Android 4.x. Sono disponibili delle API, ma:

• L’accesso alla memoria della camera ha comportamenti diversi su hardware diverso. In alcuni casi viene chiamata una certa funzione, in altri casi ne viene chiamata un’altra.
• Alcuni modelli di smartphone scrivono il valore di luminosità dell’immagine, altri non lo fanno.
• I valori dell’exif (che contiene le caratteristiche di un’immagine) sono rappresentati in formati e scale differenti in base all’hardware della fotocamera.
• Il valore di tempo di apertura della camera a volte è indicato come valore numerico, altre volte come stringa (es: 1/200).
• Se il telefono è impostato su alcune lingue (es: Arabo o Giapponese), il formato di alcuni valori dell’exif è scritto in quei caratteri.

Tutti questi impedimenti sono stati rivisti nelle nuove API a partire da Android 5.

Strumenti e tecniche di sviluppo per dispositivi mobili

Android e iOS hanno molti aspetti concettuali in comune, tuttavia le applicazioni sono scritte in linguaggi differenti:

• Android – Java
• iOS – Objective C, SWIFT

Per fare un’applicazione commerciale, devo scriverla due volte? Scrivo per una sola piattaforma? La scelta della piattaforma deve seguire l’analisi di mercato, che non interessa in questo contesto. Si possono considerare alcuni fattori per ciascuna tipologia di device (smartphone, tablet, ecc):

• Quanti dispositivi sono venduti;
• Quanti dispositivi sono attivi;
• Quante app sono disponibili sullo store;
• Quante app sono scaricate dallo store;
• Revenue (reddito) derivanti da app scaricate dallo store.

Bisogna tener conto anche la fascia dei device, ovvero molti dispositivi Android sono di fascia bassa, e ciò è causa di minore attitudine degli utenti all’acquisto di app. Nel caso iOS, sebbene la media di dispositivi venduti e attivi sia minore, il reddito è nettamente più alto.

In conclusione, qualunque sia il nostro interesse, vendere le applicazioni e/o distribuirne un alto numero sviluppando su un’unica piattaforma porta a perdere come minimo 1/3 del nostro target. In genere lo sviluppo su una sola piattaforma non è accettabile.

Sviluppo di due versioni dell’applicazione in codice nativo

La soluzione più ovvia è sviluppare ogni applicazione due volte, per Android e iOS, che porta a raddoppiare i costi di implementazione, testing e manutenzione. Questi svantaggi possono però essere risolti dallo sviluppo cross-platform.

Sviluppo cross-platform

Permette di sviluppare l’applicazione, o una parte di essa, una sola volta per entrambe le piattaforme. Esistono diverse soluzioni per lo sviluppo cross-platform:

• Codice in comune (C/C++)

  Idea: scriviamo codice C/C++ che poi viene eseguito su iOS (ObjectiveC estende C/C++) e Android (tramite JNI, Java Native Interface, che permette l’esecuzione di codice C/C++ all’interno di codice Java).

  Vantaggi: il codice è scritto una sola volta, le performance sono elevate e possono essere usate librerie esistenti di C/C++.

  Svantaggi: non è possibile interagire direttamente con il SO, necessito di un bridge in linguaggio nativo, incluso per le funzioni di interfaccia grafica. In alcuni casi può essere una buona idea scrivere una libreria comune per iOS e Android usando C/C++, ma non è il metodo adatto per creare applicazioni complete.

• Sviluppo di una web app

  Idea: invece che creare un’app, creiamo un sito o una web app con HTML 5, CSS 3 e Javascript, facendo accedere l’utente tramite browser. Per creare una web app è indispensabile: single page app (AJAX), responsive design.

  Vantaggi:

  • La stessa app può funzionare anche sui dispositivi tradizionali;
  • Le tecnologie sono ampiamente diffuse, note e ben documentate.

  Svantaggi:

  • User Experience non sempre paragonabile a quella delle app native;
  • Accesso ad alcuni sensori del dispositivo non disponibile;
  • Performance limitate;
  • Accesso al SO limitato;
  • L’app realizzata non è disponibile sullo store (importanza commerciale).
• Hybrid app

  Idea: viene scritta una web app (HTML, CSS, JS), che viene eseguita all’interno di un’app nativa che contiene una web view (componente grafico nativo in grado di mostrare contenuto web). L’app nativa può essere generata in automatico.

  Esempio: Apache Cordova

  È il framework opensource più diffuso per realizzare hybrid app. Il programmatore scrive in HTML+CSS+JS e le applicazioni sono impacchettate per l’uso come le app native (pubblicabili sugli store). È possibile accedere ad alcune API del device (batteria, connessione, accelerometri) e si possono scrivere parti di codice in linguaggio nativo (funzioni native JS).

  Esempio: PhoneGap

  Framework commerciale di Adobe in aggiunta ad Apache Cordova, fornisce l’interfaccia grafica per la gestione di Apache Cordova e strumenti avanzati di sviluppo e testing. Precedentemente PhoneGap era il nome di Apache Cordova, ora i framework sono differenti.

  Vantaggi: è possibile adottare tecniche che permettono l’accesso ad alcune funzionalità del sistema operativo oltre a quanto consentito da HTML. Inoltre l’app realizzata è disponibile sullo store.

  Svantaggi: l’user experience delle app ibride non è sempre soddisfacente. Vedi statistica Facebook:

• Conversione del codice

  Idea: scrivo il codice una volta sola in un qualunque linguaggio e tramite uno strumento automatico lo converto in codice nativo per varie piattaforme.

  Esempio: React Native

  Molto simile allo scrivere applicazioni ibride: vengono utilizzati HTML, CSS, JS. Al posto che essere eseguito in una web view, il codice viene convertito in codice nativo. L’obiettivo è risolvere i problemi di user experience (utilizzo di oggetti grafici nativi) e prestazioni (codice nativo più performante). Due soluzioni analoghe sono Titanium e Electron.

  Esempio: Xamarin

  Società nata nel 2011 e ora di proprietà Microsoft: il programmatore scrive codice in C#, può usare strumenti specifici delle piattaforme (Xcode per iOS), ha accesso a tutte le API dei vari SO (tramite la libreria C#). Il framework genera automaticamente il codice nativo per varie piattaforme (iOS, Android, Windows).

  Esempio: Unity

  Motore grafico multipiattaforma (PC, console, mobile) usato principalmente per realizzare giochi. Si sviluppa in C# o Javascript: il codice viene convertito per essere usato nativamente sulle varie piattaforme. Piattaforma più usata per lo sviluppo di giochi.

  I SO dei dispositivi mobili hanno alcune funzionalità in comune (non tutte, ad es: background) e le espongono in modo diverso. Come si possono comportare i framework per la conversione del codice?

  Esempio: acquisizione della posizione

  iOS e Android rendono disponibili delle API che permettono di far richiamare un metodo quando l’utente si sposta più di una certa soglia (es: 100m). Il nome delle chiamate, la sintassi e i parametri sono diversi. Tuttavia è concettualmente semplice scrivere una libreria che astragga il comportamento e che fornisca un’unica interfaccia per le due API.

  Esempio: il funzionamento in background

  Per iOS e Android il comportamento del background è diverso: anche se posso scrivere un’app in un unico linguaggio (es: C# perché uso Xamarin) devo scrivere il codice per gestire il background due volte, una per Android e una per iOS. Vantaggi: il programmatore può conoscere un solo linguaggio di programmazione e sviluppare per entrambe le piattaforme.