Che materia stai cercando?

Mobile Computing - Teoria

Appunti per il modulo di Fondamenti di Mobile Computing da 3 CFU, utili per il superamento dell'esame teorico basati su appunti personali del publisher presi alle lezioni del prof. Mascetti dell’università degli Studi di Milano - Unimi. Scarica il file in formato PDF!

Esame di Sviluppo di Applicazioni per Dispositivi Mobili docente Prof. S. Mascetti

Anteprima

ESTRATTO DOCUMENTO

Matteo Seragiotto

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 MC richiede di affrontare problemi in diverse discipline informatiche:

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, oppure.

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),

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. E’ 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.

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

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 più 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# perche 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 molte

parti del codice possono essere scritte una sola volta. Ottime performance quando viene

eseguita l’applicazione, garantendo una user experience analoga a quella nativa (non per

Unity che solitamente presenta un’interfaccia diversa da quella nativa).

Svantaggi: alcune parti del codice devono essere comunque riscritte per ogni piattaforma

target, per esempio in tutte le parti in cui l’interazione con il SO è diversa tra iOS e Android.

Viene aggiunto un ulteriore livello di astrazione e di tecnologia su uno stack già complesso

ed in rapida evoluzione.

Considerazioni generali sullo sviluppo cross-platform

Queste tecniche, in linea di principio, permettono di dimezzare i costi di sviluppo, testing e

manutenzione del codice. Nella pratica viene introdotto un livello di astrazione in un ambiente

tecnologico in rapida evoluzione e non ancora del tutto consolidato. La scelta di utilizzare una

soluzione cross-platform deve essere preceduta da un’accurata valutazione di costi/benefici.

ANALISI E PROGETTAZIONE

L’analisi delle applicazioni per dispositivi mobili

Le app per i dispositivi mobili presentano delle differenze di contesto d’uso rispetto ai dispositivi

tradizionali: l’interazione può avvenire mentre l’utente è concentrato in altre attività (in mobilità,

tramite assistente vocale, ecc).

L’utente spesso utilizza le app per risolvere un problema contingente della vita quotidiana (es:

chiamare un amico, non scuocere la pasta, trovare la farmacia aperta, guardare il meteo), sfruttando

la caratteristica dei dispositivi mobili di essere sempre pronti all’uso (sempre accesi).

Un’altra importante differenza è la durata delle sessioni d’uso, mediamente molto più brevi: gli

utenti infatti vogliono risolvere il loro problema il più velocemente possibile. È necessario

minimizzare:

 Tempi di apprendimento – ESEMPIO quando Whatsapp ha iniziato a diffondersi c’erano

molte altre app alternative. I fattori principali che hanno reso Whatsapp l’app di riferimento

sono 1) l’assenza di registrazione e 2) l’aggiunta automatica dei contatti tra quelli presenti in

rubrica;

 Tempi di setup o registrazione al servizio;

 Tempi di utilizzo – ESEMPIO uno dei primi giochi che ha basato il suo successo su sessioni di

gioco molto brevi è Angry Birds. Una partita può durare anche solo pochi secondi e le

istruzioni fornite al primo livello sono presentate in un video di meno di 3 secondi.

Analizzando le funzionalità di un’app mobile, è tollerabile avere meno funzionalità rispetto a quelle

disponibili per dispositivi tradizionali, a patto che siano immediate da usare e semplici da imparare.

Nel caso dei tablet, essi sono visti come sostituti dei laptop, svolgendo quindi un ruolo ibrido. In

questo caso è ragionevole valutare di inserire più funzionalità e aumentare la complessità di quelle

presenti. Principi di progettazione delle interfacce

L’interazione con il dispositivo da parte dell’utente avviene tramite touch-screen e pochi pulsanti

fisici. Il touch screen permette un’interazione molto più sofisticata del mouse:

 È possibile definire azioni associate a gesti complessi;

 È possibile realizzare gesti con più dita;

 Negli ultimi dispositivi dotati di iOS è possibile considerare la forza della pressione sul touch

(force-touch o anche 3D touch).

Riguardo alle dimensioni dello schermo, nei dispositivi mobili si progettano GUI differenti in base

alle dimensioni degli schermi: gli ambienti di sviluppo supportano l’adattamento della GUI alla

dimensione dello schermo del dispositivo. Non vengono adattate solo le singole schermate, ma

viene a modificarsi il flusso di navigazione nell’app (es: menu a scomparsa/menu sempre visibile).

La GUI deve adattarsi anche all’orientamento dello schermo.

Integrità estetica

L’aspetto estetico dell’applicazione deve rifletterne la natura stessa, ad esempio per applicazioni

per la produttività è necessario un aspetto serio, semplice e lineare, al contrario un’app ludica

fornisce maggiore spazio alla grafica ricercata, divertente ed appassionante.

Consistenza

La consistenza con le altre applicazioni che l’utente conosce permette di creare app più semplici e

rapide da usare. Un esempio è essere consistenti con lo standard del sistema operativo. Da tenere

conto è l’auto-consistenza, ovvero la presenza di stessi termini, grafica, comportamenti per indicare

gli stessi oggetti e task.

Affordance

La capacità di un oggetto o un ambiente di suggerire ad un individuo la possibilità di compiere

un’azione. Attraverso il proprio aspetto l’interfaccia deve invitare l’utente ad interagire

intuitivamente con essa, sfruttando l’esperienza pregressa.

È importante tener conto del principo del minimo sforzo, ad esempio l’inserimento dell’input: esso

va richiesto solo se indispensabile. Inoltre è necessario pensare come un utente, quindi no dettagli

tecnici o termini specifici.

Progettazione delle interfacce grafiche

1 - Prerequisiti: elenco di attori (utenti), elenco di funzionalità (ciascuna con importanza per ogni

attore). Principi di ingegneria del software.

2 - Navigazione

Generalmente, nelle app per dispositivi mobili ogni schermata mostra solamente un task, ma

possono essere anche di più in funzione della grandezza dello schermo. L’applicazione deve

permettere di navigare tra diversi task.

Lo schema di navigazione definisce come l’utente si muoverà tra le varie schermate. È importante

indicare la funzionalità di ogni schermata, non necessariamente il dettaglio grafico. Le funzionalità

più importanti (o frequenti) vanno presentate il prima possibile all’utente. La prima schermata

mostrata può variare (in base al primo avvio o successivi).

La navigazione tra le schermate dell’app avviene principalmente in due modi:

 Sequenzialmente, da una schermata posso spostarmi avanti o indietro.

Grazie alla barra di navigazione l’utente sa sempre dove si trova e può tornare indietro nella

navigazione. È sempre implementata con gli stessi strumenti di interfaccia.

 Per task, l’utente può spostarsi da una schermata ad un’altra in qualsiasi ordine.

Esistono vari strumenti d’interfaccia per implementare questo tipo di navigazione.

Molte applicazioni prevedono una navigazione combinata:

Per cosa progetto?

È necessario progettare per dispositivi con diverse dimensioni dello schermo. È conveniente iniziare

a progettare per i dispositivi supportati che hanno schermo più piccolo, per poi adattare la

progettazione a schermi più grandi.

Progressive enhancement

Similitudine con l’omonima strategia di web design, che prevede di progettare un sito che funzioni

su tutti i browser (inclusi quelli più datati), per poi cercare di renderlo migliore su alcuni di essi

(ovvero i più recenti).

Graceful degradation

In antitesi alla precedente strategia, prevede di progettare un sito che funzioni bene su alcuni

browser (i più recenti), per poi definire le funzionalità da rimuovere per adattarlo a funzionare su

tutti gli altri browser (anche i più datati).

3 – Progettazione delle singole schermate

Una volta completato lo schema di navigazione si passa alla progettazione delle singole schermate.

Molte volte ci si rende conto che una schermata va divisa in due o più, oppure che più schermate

vanno accorpate -> da qui si torna a modificare lo schema di navigazione.

Oggetti di interfaccia

In genere si utilizzano quelli offerti dal framework (pulsanti, caselle di testo, liste, eccetera).

Per Android si segue la documentazione sul Material Design

https://material.io/guidelines/material-design/ elenco components;

Per iOS la Human Interface guideline

https://developer.apple.com/ios/human-interface-guidelines/overview/themes/ sezioni bars,

views e controls;

Ma è anche possibile creare nuovi oggetti di interfaccia.

Analisi

È necessario porsi le seguenti domante:

 Quale problema vuole risolvere la mia app?

 Quali attori la useranno?

 In quali contesti la useranno?

 Su quali dispositivi?

 Quali sono, in ordine di importanza per ciascun attore, le funzionalità necessarie?

Cosa sviluppo?

Si individuano le funzionalità minime che caratterizzano il servizio e le si implementano, curando gli

aspetti importanti per l’utente: l’user experience è fondamentale.

Dopodichè la si pubblica appena possibile, cercando di ottenere feedback, usando strumenti di

analytics.

Proseguire nell’analisi per individuare le successive funzionalità da rendere disponibili.

Il modello di sviluppo

Il Primo avvio

È necessario analizzare il primo avvio dell’applicazione da parte dell’utente, per cercare di capire se

è utile fornire istruzioni. L’utente deve capire a cosa serve l’applicazione.

La possibile assenza di contenuti è un problema? (esempio: se creo un social network e al primo

avvio l’utente non ha contatti).

È necessario analizzare quali funzionalità specifiche servono per il primo avvio, progettando

apposite soluzioni di interfaccia (tutorial, help, eccetera).

Provare a ideare diverse soluzioni prima di passare all’implementazione, presentandole a qualcuno

(meglio non tecnico).

Schema principale per la progettazione di GUI (vedi anche HCI)

1. Carta-matita-gomma

Bisogna focalizzare l’attenzione prima sull’idea, la presentazione viene dopo.

Progettare sia lo schema di navigazione che le singole schermate, presentando la bozza a

qualcuno che non conosce l’applicazione: Capisce di cosa si tratta? Capisce come interagire?

Strumento utile per avere un miglior effetto: POP (https://popapp.in/) applicazione mobile

che permette di definire un prototipo partendo da foto di disegni fatti a mano.

http://pttrns.com/ per il confronto di diverse soluzioni agli stessi problemi.

2. Software di disegno

Applicazioni tradizionali con l’uso di stencil appositi (Google rende disponibili gli stencil per

Android: http://goo.gl/tV44W ).

Applicazioni apposite di progettazione, ad esempio Balsamiq (https://balsamiq.com/ ).

3. Tool WYSIWYG di progettazione o sviluppo

Xcode o Android Studio. RETI E ARCHITETTURE

Introduzione alle reti wireless

I dispositivi mobili trasmettono dati a livello geografico utilizzando Internet. Ciascun dispositivo è

identificato da un indirizzo IP assegnato dinamicamente quando il dispositivo si collega ad un router

(ad esempio via WiFi) oppure ad una rete cellulare che supporta la trasmissione dati.

Esistono varie tipologie di reti Wireless:

 1

WWAN (Wireless Wide Area Networks) – Ampia copertura, throughput molto variabile. Di

questo tipo sono le reti GSM – 3G – 4G.

 Reti satellitari – Copertura globale, caratterizzate da un basso throughput ma con costi

elevati.

 WLAN (Wireless Local Area Networks) – Copertura locale, caratterizzate da un alto

throughput. Di questo tipo è la rete WiFi (802.11b,g,n,ac …).

 WPAN (Wireless Personal Area Networks) – Copertura di pochi metri, caratterizzate da un

medio throughput con un basso costo. Di questo tipo è la rete Bluetooth.

Evoluzione delle reti cellulari

 1G (anni ’80) – telefonate in analogico. Caratterizzate da terminali poco maneggevoli

(“cellulari” grandi come valigette 24 ore);

 2G (anni ’90) – telefonate in digitale, SMS e pochi dati. Lo sono le reti GSM, GPRS, EDGE;

 3G (anni 2000) – dati in commutazione a pacchetto, si inizia a parlare di velocità in Mbps. Lo

sono le reti UMTS, HSPA;

 4G (anni 2010) – evoluzione fino all’attuale stato, con velocità di connessione paragonabili

(e a volte migliori) alla banda larga. Rete LTE;

 5G (anni 2020) – attualmente in sperimentazione.

1 Throughput : capacità di trasmissione "effettivamente utilizzata". Di solito indicato con THR.

Rete GSM

Principi di funzionamento di una rete GSM

L’idea di base sta nella suddivisione del territorio in celle (rete cellulare appunto), in ognuna delle

quali è presente una BTS (Base Transreceiver Station) o Stazione Radio Base, la quale trasmette e

riceve su un particolare range definito di canali radio, diverso da quello delle celle contigue per

evitare interferenze.

A grandi linee il funzionamento del network avviene nel modo seguente: la Mobile

Station comunica, attraverso l'interfaccia Um, con la Base Station Subsystem e precisamente con

una BTS di essa.

La BTS, a sua volta, si collega con il BSC tramite l'interfaccia Abis. Il BSC gestisce i collegamenti

provenienti da una o più BTS e li instrada verso l'MSC. Questo avviene tramite l'interfaccia A e il

collegamento segna il passaggio dalla Base Station Subsystem alla Network Subsystem.

Come presente nello schema, la rete può essere divisa in tre grossi blocchi:

 Mobile Station (MS), ovvero il terminale + SIM card;

 Base Station Subsystem (BSS), gestisce la connessione radio con le MS, composta dalla BTS

e dalla BSC;

 Network Subsystem, che realizza le connessioni tra una MS ed altre MS o telefoni fissi e

gestisce l’autenticazione e mobilità delle MS.

Mobile Station (MS)

Il terminale è identificato univocamente da un codice IMEI (International Mobile Equipment

Identity), mentre la SIM card contiene:

1. il codice IMSI (International Mobile Subscriber Identity);

2. una chiave segreta per l’autenticazione;

3. i codici PIN/PUK per controllare l’accesso.

I compiti principali della MS riguardano le operazioni di trasmissione/ricezione.

Base Station Subsystem (BSS)

Questa stazione è composta dall’insieme di una o più BTS (Base Transreceiver Station) controllate

da una BSC (Base Station Controller):

 BTS – Rappresenta l’entità funzionale costituita dall’insieme dei ricetrasmettitori e da tutti

gli apparati che forniscono la copertura radio di una singola cella (che colloquiano quindi con

le altre MS). In termini pratici la BTS è un traliccio sul quale sono collocate una serie di

antenne che trasmettono e ricevono.

 BSC – Ha il compito di organizzare il lavoro delle BTS che ad essa fanno riferimento,

governandone il funzionamento sia in termini di instaurazione/abbattimento delle

2 3

connessioni, sia in termini di gestione dei vari handover , frequency hopping , eccetera. In

altri termini la BSC è il tramite per il quale una MS può dialogare con un particolare apparato

della Network Subsystem.

Una cella di una data BTS è quindi un’area dove la potenza del segnale di quella BTS è più forte

rispetto alla potenza delle BTS circostanti. I contorni di una cella sono definiti dai punti dove la

potenza del segnale della BTS che la ospita diventa uguale a quello delle BTS adiacenti.

In un territorio si ha la presenza di numerose BTS governate da una o da poche BSC.

Network Subsystem

È composta dalla MSC (Mobile services Switching Center) e dai database HLR, VLR, EIR, AuC:

2 Handover: meccanismo automatico tramite il quale avviene la sintonizzazione sulla frequenza della cella in cui si trova

la MS. Risolve il problema di interruzione della chiamata, poiché prosegue grazie alla frequenza della nuova cella.

3 Frequency Hopping: o salto di frequenza, meccanismo tramite il quale il messaggio di una stessa comunicazione è

trasmesso su frequenze portanti diverse, in modo da risolvere il problema di fading (dissolvenza del segnale), poiché se

una frequenza è soggetta ad un certo tipo di fading, è molto improbabile che frequenze diverse siano soggette allo

stesso tipo di fading. In questo modo il segnale, “saltando” da una frequenza all’altra, riesce a non essere intaccato dalla

dissolvenza.


PAGINE

51

PESO

1.38 MB

PUBBLICATO

4 mesi fa


DETTAGLI
Corso di laurea: Corso di laurea magistrale in informatica
SSD:
Università: Milano - Unimi
A.A.: 2018-2019

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher matteo.seragiotto di informazioni apprese con la frequenza delle lezioni di Sviluppo di Applicazioni per Dispositivi Mobili e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Milano - Unimi o del prof Mascetti Sergio.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Corso di laurea magistrale in informatica

Appunti di Gestione dell'Informazione
Appunto