Mobile APP

Un'app per dispositivi mobili si differenzia dalle tradizionali applicazioni sia per il supporto con cui viene usata sia per la concezione che racchiude in sé.

Si tratta a tutti gli effetti di un software applicativo che per struttura informatica è molto simile a una generica applicazione, ma che generalmente è caratterizzata da una semplificazione ed eliminazione del non strettamente necessario, al fine di ottenere leggerezza, essenzialità e velocità, in linea con le limitate risorse hardware dei dispositivi mobili rispetto ai desktop computer, questo fa sì che le funzionalità delle app siano molto limitate in quanto molto mirate ad una determinata funzione.

Web APP

Mentre una mobile app è installata fisicamente e interamente sul dispositivo dell'utente, una web app è sostanzialmente un collegamento verso un applicativo remoto, scritto in un linguaggio cross-platform come HTML5, con il codice dell'interfaccia utente che può risiedere sul dispositivo mobile o anch'essa in remoto.

Questa soluzione comporta delle importanti conseguenze in termini di funzionamento: il vantaggio principale di una web app consiste nel fatto di non incidere in alcun modo o in maniera minima sulle capacità di memoria del dispositivo e sulle sue capacità di calcolo dei dati in quanto il nucleo elaborativo e/o l'interfaccia utente dell'applicazione è presente su server remoti.

Tuttavia, per funzionare, una web app richiede il costante accesso a internet e le sue prestazioni dipenderanno in modo sensibile dalla velocità di connessione.

Android APP

Android, nonostante la sua recente creazione, si è da tempo affermato come il sistema operativo protagonista del mercato dei dispositivi mobili, in particolare smartphone e tablet; i dispositivi mobili con sistema Android siano più della metà di quelli attualmente in circolazione. Esso è sia un sistema operativo che una collezione di software di base per l'utilizzo di un dispositivo mobile. Android è per gran parte realizzato tramite software open source: il sistema operativo è infatti costituito da un kernel basato sulla versione 3 di Linux che comprende i driver per il controllo dell'hardware del dispositivo (tastiera, touchscreen, Wi-Fi, Bluetooth, ecc.). Anche molte delle librerie fondamentali per l'esecuzione delle App derivano da software open-source. Completano infine la struttura di base del sistema operativo una macchina virtuale per l'esecuzione di bytecode Java – denominata Dalvik – e la libreria che implementa le API sulle quali sono realizzate tutte le App Android.

Componenti di una Android APP

I componenti fondamentali utilizzati per realizzare una App Android sono 4: Activity, Service, Broadcast Receiver e Content Provider; ciascuno di questi si ottiene estendendo una classe predefinita della libreria che implementa le API

Activity

La loro definizione ufficiale è «una singola cosa precisa che l'utente può fare»; per questo quasi tutte le activity interagiscono con l'utente per mezzo dello schermo o della tastiera. Normalmente si fa coincidere una activity con una singola schermata di una App (un menu, una lista, una pagina web, ecc.). Pur essendo possibile avviare più applicazioni contemporaneamente soltanto una può occupare il display, mentre le altre saranno ”nascoste” in background. Questo è il motivo per cui, il concetto di chiusura è secondario e normalmente non troveremo il pulsante ”Esci".

Una activity ha diversi stati tra cui:

• In esecuzione/Running : L'activity è in cima allo stack, è visibile ed ha il focus. È quella che riceve gli eventi da parte dell'utente
• Terminata/Stopped : Activity non attiva ne visibile
• Non attiva/Inactive : Una activity si trova in questo stato quando viene eliminata oppure prima di essere creata Inoltre esiste un 4° stato, che si sta diffondendo grazie alla nuova concezione di multitasking:

• Attività in pausa/Paused : L'activity non è attiva ma è ancora visibile a causa della trasparenza di quelle superiori o perche queste non occupano tutto lo spazio a disposizione. Non è sensibile agli eventi da parte dell'utente.

• onCreate(Bundle): è invocato quando l'activity viene avviata per la prima volta. Il Bundle savedInstanceState serve per riportare l'Activity nello stesso stato in cui si trovava la precedente istanza dell'Activity terminata.

• onStart(): è invocato quando l'activity sta per essere visualizzata

• onResume(): è invocato non appena l'activity inizia ad "interagire" con l'utente
• onPause(): è invocato non appena l'activity sta per essere ”ibernata” (per es. e' stata avviata un'altra activity)
• onStop(): è invocato nel momento in cui l'activity non e' piu' visibile all'utente.
• onRestart(): è invocato quando l'Activity sta per essere riavviata dopo essere stata precedentemente arrestata
• onDestroy(): è invocata poco prima che l'Activity sia distrutta
• onSaveInstanceState(Bundle): è invocata per salvare lo stato dell'Activity
• onRestoreInstanceState(Bundle): è invocata solo se in precedenza è stato salvato uno stato

Service

Svolge un ruolo opposto all’Activity. Sono lanciati per eseguire un'operazione caratterizzata da una lunga durata di esecuzione e dalla mancanza di interazione diretta con l'utente; in sostanza i service sono eseguiti in sottofondo mentre l'utente si dedica ad altro (oppure non utilizza il dispositivo).

I Service hanno un’importanza basilare nella programmazione proprio perchè spesso preparano i dati che le activity devono mostrare all’utente permettendo una reattività maggiore nel momento della visualizzazione.

Alcuni servizi possono essere visibili a schermo (il servizio che permette di vedere un video) oppure non visibili a schermo (quelli per effettuare richieste HTTP). Inoltre esistono i servizi Bound, cioè quelli che fanno richieste ad API come le Google Play Games API.

Quando viene invocato il metodo startService() il sistema verifica se tale servizio è in escuzione altrimenti esegue onCreate(). Successivamente è invocato il metodo onStartCommand() e il servizio è finalmente nello stato di esecuzione dove rimane fino a quando non sarà richiamato stopService() oppure stopSelf()

• onCreate(): a differenza delle Activity non presenta alcun parametro. Creato il servizio viene invocato il metodo onStartCommand(). Viene invocato una sola volta.
• onStartCommand(): invocato questo metodo il servizio resterà in esecuzione e rimarrà in questo stato fino a quando non sarà invocato stopService() da parte dell'Activity che lo ha generato, oppure stopSelf() da parte del servizio stesso. Può essere invocato più volte in seguito all'esecuzione di onStartService() da parte dell'Activity.
• onDestroy(): l'invocazione di stopService() da parte dell'Activity produrrà la chiamata di questo metodo del Servizio. In seguito a questa chiamata il servizio sarà eliminato

Broadcast Receiver

Sono utilizzati per intercettare lo scatenarsi di particolari eventi globali del sistema (in broadcast - come ad esempio il cambiamento dello stato di connessione alla rete), o definiti dal programmatore per mezzo di intent allo scopo di attivare funzionalità o eseguire altri processi (servizi o attività).

Android le usa per notificare l’avvenimento di un determinato evento, ad esempio l’arrivo di un SMS o di una chiamata, o sollecita l’esecuzione di azioni.

Questi componenti sono particolarmente utili per la gestione istantanea di determinate circostanze speciali.

Content Provider

Un Content Provider nasce con lo scopo della condivisione di dati tra applicazioni.

Sono impiegati per gestire l'accesso a insiemi di dati strutturati, principalmente per il recupero di informazioni e dati di sistema (eventi del calendario, nominativi della rubrica, ecc.).

Altri componenti

Intent. È la descrizione di una azione da eseguire. Una componente può attivarne un’altra mediante apposite invocazioni di sistema. Questa intenzione viene codificata con un Intent utilizzabile come normale classe Java, ma che sottintende un potentissimo strumento di comunicazione di Android. In generale gli intent sono messaggi che il sistema invia alle APP per attivare un'activity, un service o un broadcast reciver.

Fragment. Esso può essere considerato una porzione dell’interfaccia utente, completa non solo di layout ma anche di tutto il codice necessario a rappresentarne la logica di gestione. La loro nascita – risalente ad Android 3.0 – ha offerto la possibilità di creare interfacce utente composte da porzioni riutilizzabili e alternabili senza la necessità di distruggere l’Activity. Un Fragment ha bisogno di un’Activity che gli faccia da contenitore pertanto l’uso di questi componenti facilita, da un lato, la gestione del ciclo di vita di un’Activity (visto che questa non cambia ma si alternano solo i Fragment) ma dall’altro aggiunge ulteriore complessità considerando che i Fragment hanno un proprio ciclo di vita piuttosto articolato.

Gestione dei processi in Android

1. Processi in “foreground”
2. Processi visibili
3. Processi “service”
4. Processi in “background”
5. Processi “empty”

Android farà in modo di tenere in vita ogni processo il più a lungo possibile. Ciò non toglie che in alcune circostanze, ed in base alle risorse hardware a disposizione, il sistema operativo si troverà nella necessità di dover liberare memoria abbattendo processi.

Progetto di una applicazione Android

Res. Le principali sottodirectory di res sono: drawable, layout e values. La prima ospita le immagini che verranno impiegate dall'applicazione, mentre layout e values contengono file in formato XML che definiscono rispettivamente l'interfaccia utente e le costanti della App. Per una stessa risorsa è possibile specificare (in directory differenti) più file di origine in funzione di particolari caratteristiche del dispositivo sul quale viene eseguita l'App o delle impostazioni del sistema; questo perché una App deve poter essere eseguita su dispositivi molto diversi tra loro e da utenti con preferenze linguistiche differenti. Questo meccanismo funziona aggiungendo come suffisso del nome della directory uno o più qualificatori, secondo la forma nomeDirectory-xxxx

è buona norma separare le risorse condivise e metterle nei file xml dentro res/values.

In Java È necessario creare un oggetto Resources per inizializzare il collegamento con le risorse di una APP

AndroidManifest.xml. Nella directory di base del progetto si trova sempre un file chiamato «AndroidManifest.xml» generato automaticamente dall'ambiente di sviluppo: questo file viene utilizzato dal sistema operativo per interagire con la App ed è il descrittore della App stessa, in altre parole è un file che indica al sistema il contenuto dell'applicazione e le risorse di sistema che la sua esecuzione richiede.contiene al suo interno la dichiarazione di tutte le Activity, i Service, i Provider e i Receiver che compongono la App, al fine di renderli individuabili dal sistema operativo.

I permessi possono essere:

• Normal (concessi automaticamente)
• Dangerous (richiesta esplicita)

Src. Contiene il codice Java (o in altri linguaggi come Kotlin) dell'App android. Il codice utilizza database in SQLite oppure le SharedPreferences per salvare dati e impostazioni

Interfaccia grafica

Composta da widget (gli oggetti visibili sullo schermo), tra cui troviamo:

• Button

• TextView

• EditText

• ImageView

Normalmente ai widget vengono associati degli eventi e viene eseguito del codice tramite un listener.

La disposizione è gestita tramite layout, anche annidiati, tra cui:

• LinearLayout
• RelativeLayout
• TableLayout
• ListView

Finestre di popup: AlertDialog con titolo, contenuto e pulsanti

Notifiche in-app: Toast e snackbar, entrano nello schermo a partire dal basso e permangono in sovraimpressione per un po’

Material design: standard uniforme per il design su Android e dei prodotti Google.

iOS APP

Linguaggio di programmazione: Objective-C, Swift (Contro Java e derivati)

Interfaccia grafica: file XIB (NON leggibili, contro XML ben leggibili)

IDE: XCode (contro Android Studio, Eclipse, IntelliJ Idea, ...)

Costo: 99$/anno (contro 25$ all'iscrizione)

Xamarin APP

Xamarin è un framework, il quale permette di scrivere app in ambiente nativo, quindi con la creazione di apk e ipa e pubblicazione sui rispettivi store e possibilità di usare le risorse del sistema, usando (quasi) esclusivamente il linguaggio C#. Questo è possibile utilizzando l'ambiente Mono, personalizzato per Android e iOS (Xamarin.Android e Xamarin.iOS).

Il solo fatto di poter scrivere app in C# è già una gran cosa, soprattutto in ambiente iOS, e ad oggi è possibile scrivere lo strato Model di una generica app per entrambe le versioni in un colpo solo e condividerlo tra le due piattaforme. Addirittura tre, se si considera Windows Phone. Il risparmio di tempo è notevole, soprattutto se la app gestisce una certa mole di dati (se interagisce con un gestionale, questa parte può essere composta tranquillamente da 3000 e più righe di codice)

La parte grafica, invece, deve essere composta singolarmente per ogni piattaforma. Se comunque si usa il linguaggio C#, ci si appoggia alle risorse dell'ambiente sottostante. In iOS si usano le storyboard e i file .nib, in Android si richiamano i file xml. Lato Android in questo settore il framework risulta una sorta di binding, infatti le sintassi tra ambiente nativo e ambiente Xamarin risultano estremamente simili, dove la differenza è più dovuta al name convention che al linguaggio di programmazione.