OHA (Open Handset Alliance): è un accordo di differenti compagnie con Google: Asus, HTC,

Intel, …, il cui obiettivo è sviluppare standard aperti per dispositivi mobili. E’ un gruppo di
aziende che lavorano con le tecnologie mobili. Membri:
 Operatori mobili (Mobile Operator): Vodafone, T-Mobile, Telecom, etc.
 Produttori di semiconduttori (Semiconductor Companies): Intel, NVIDIA, ARM, etc.
 Produttori di dispositivi (Handset Manufacturers): ACER, ASUS, HTC, Lenovo, etc.
 Produttori di software (Software Companies): OMRON, Google, eBay, etc.
 Compagnie per la commercializzazione (Commercialization Companies): Aplix, Noser
Engineering, etc.

BYTECODE
 Sviluppo in Java, trasformazione in bytecode Dalvik fino alla versione 4.4
 Dalvik è una macchina virtuale, ottimizzato per sfruttare la poca memoria presente
nei dispositivi mobili.
Essa è spesso associato alla Macchina Virtuale Java, anche se il bytecode con cui
lavora non è Java.
E’ basato su tecnologia JIT (just-in-time): l’app è compilata in parte dallo
sviluppatore, poi Dalvik (interprete) esegue il codice compilandolo in linguaggio
macchina in tempo reale per ogni esecuzione dell’app stessa.
Funzionamento:
1. Si scarica un file .apk dal Playstore.
2. Una volta installato si crea un file .dex contenente il bytecode.
3. Durante l’esecuzione di un programma la Dalvik si occupa di tradurre il
bytecode in linguaggio macchina così da divenire eseguibile.
4. Una volta terminata l’operazione il codice tradotto viene per e alla prossima
esecuzione del programma si ricomincia dal punto 1.
 ART (android 5.0+) è il nuovo ambiente di Runtime che ha migliorato vari aspetti
critici (per esempio la gestione della memoria).
E’ basato su tecnologia AOT(ahead-of-time): esegue l’intera compilazione del codice
durante l’installazione dell’app e non durate l’esecuzione stessa del software.
Ne consegue un vantaggio in termini di prestazioni e gestione delle risorse, ma un
maggior tempo per l’installazione di un app.
Funzionamento:
1. Come Dalvik.
2. Al momento dell’installazione l’applicazione viene anche compilata creando un
file .ELF eseguibile.
3. Una volta avviata l’app il codice sarà già pronto per essere eseguito e al
termine dell’esecuzione rimarrà tale.
ACTIVITY MANAGER
 Activity: è un qualcosa che possiamo associare a una schermata, che permette non
solo la visualizzazione o la raccolta di informazioni ma, in modo più generico, è lo
strumento fondamentale il quale l’utente interagisce con l’applicazione.
 E’ fondamentale capirne il ciclo di vita, gestito dall’Activity Manager: responsabilità
di questo componente sarà l’organizzazione delle varie schermate di un’applicazione
in uno stack (pila LIFO) per la navigazione, a seconda dell’ordine di visualizzazione
delle stesse sullo schermo dei diversi dispositivi.
 Quando si avvia un’app, per esempio musica, ad ogni azione compaiono nuove
attività.

PACKAGE MANAGER
 Database che tiene traccia delle app installate nel dispositivo.
 Consente ad un’app di trovare, mettersi in comunicazione, richiedere servizi ad
un’altra app.
 Classe per il recupero di vari tipi di informazioni relative ai pacchetti applicativi che
sono attualmente installati sul dispositivo.
 E’ possibile trovare questa classe attraverso il metodo getPackageManager().

WINDOW MANAGER
 Gestisce le finestre che compongono un’app, esempio:
- notification bar;
- main application;
- subwindow.
 L’interfaccia che le applicazioni utilizzano per comunicare con il window manager.
 Utilizzare Context.getSystemService(Context.WINDOW_SERVICE) per ottenere una di
queste.
 Ogni istanza window manager è associata a un particolare display.
 Per ottenere un WindowManager per un differente display, usare
createDisplayContext(Display), per ottenere un Context per quel display utilizzare
Context.getSystemService(Context.WINDOW_SERVICE) per avere il WindowManager.
 Il modo più semplice per mostrare una finestra su un altro display è di creare una
Presentation (presentazione). Essa permetterà di ottenere automaticamente un
WindowManager e un Context per il display.

VIEW SYSTEM
 Elementi della UI (icone, testo, pulsanti, …).
 Nell’app del telefono vi sono diversi componenti del View System, p.e i pulsanti e
textViews.
 Questa classe rappresenta gli elementi base per i componenti dell’interfaccia utente.
 Una View occupa un’area rettangolare sullo schermo ed è responsabile del disegno e
della gestione degli eventi.
 Una View è la classe base per i widgets, che vengono usati per creare componenti UI
interattivi (pulsati, campi di testo, ecc).
  La sottoclasse ViewGroup è la classe base per i layout, che sono contenitori invisibili
che contengono altre Views (o altre ViewGroup) e definiscono le proprietà dei loro
layout.

RESOURCE MANAGER (R)

 Gestisce risorse non compilate (stringhe, elementi grafici, file di layout).
 Ad esempio le stringhe sono in inglese, cambiando le impostazioni si possono
utilizzare quelle in italiano.
 Ci vuole più di un semplice codice per costruire una grande applicazione.
 Le Resources sono file aggiuntivi sono file aggiuntivi e contenuti statici che il codice
utilizza, come ad esempio immagini di bitmap, le definizioni di layout, stringhe e
interfaccia utente, istruzioni di animazioni e altro.
 Si tratta di un componente con responsabilità di ottimizzazione delle risorse.

CONTENT PROVIDER
 Database che consente alle app di memorizzare e condividere le informazioni
(persistenti).
 Ad esempio, l’app del telefono accede alle informazioni dei contatti e li usa per
effettuare le telefonate; allo stesso modo l’app di messaggistica utilizza le
informazioni presenti nei contatti per inviare sms, come le app dei social media.
 Questo deve avvenire in modo controllato e sicuro, attraverso interfacce (per
l’esecuzione delle operazioni di CRUD Create Retrieve Update Delete) predefinite che
caratterizzano il ContentProvider.
 I ContentProviders gestiscono l’accesso a un insieme strutturato di dati.
 Incapsulano i dati e forniscono meccanismi per la definizione di dati sicuri.
 Sono l’interfaccia standard che collega dati di un processo con codice in esecuzione
in un altro processo.

LOCATION MANAGER
 Le applicazioni che gestiscono, tra le informazioni disponibili, quelle relative alla
localizzazione si chiamano Location Based Apllication (LBA) e possono essere
realizzate utilizzando API messe a disposizione del Location Manager.
 Esso permette alle app di ricevere informazioni sul movimento e ralative alla
posizione (GPS) del dispositivo.
 Consente di svolgere task precisi e specifici come trovare la posizione e direzione.
 Questa classe fornisce l’accesso ai servizi di localizzazione del sistema.
 Questi servizi consentono alle applicazioni di ricevere aggiornamenti periodici della
posizione geografica del dispositivo e il fuoco dell’Intent della specifica applicazione
quando il dispositivo entra in prossimità di una determinata area geografica.
 Non si può istanziare questa classe direttamente; invece la si può recuperare
attraverso Context.getSystemService(Context.LOCATION_SERVICE).
 Se non espresso diversamente, tutti i metodi LOCATION API richiedono i permessi
ACCES_COARSE_LOCATION o ACCESS_FINE_LOCATION.
NOTIFICATION BAR
 Consente alle app di inserire informazioni nella Notification Bar, per esempio per
avvisare che si è verificato un dato evento.
 Questo è il modo per avvisare l’utente che qualcosa è successo in background.
 Le notifiche possono assumere varie forme diverse: segnale attraverso una
vibrazione, un LED, un’icona.
 Ognuno dei metodi di notifica accetta un parametro int id e opzionalmente un tag
String, che può essere null.
 Questi parametri vengono utilizzati per formare una coppia (tag, id) o (null, id); questa
coppia identifica la notifica della tua app per il sistema, in modo tale che la coppia sia
unica all’interno dell’app.

GRADLE
 Gradle è uno strumento di build, Open Source che automatizza lo sviluppo di
applicazioni; inoltre esso usa un grafo aciclico diretto per determinare l’ordine di
esecuzione dei processi.
 La caratteristica principale è quella di mettere a disposizione un Domain Specific
Language (DSL), ovvero un linguaggio specifico per un determinato dominio, che in
questa caso è la gestione della fase di build di applicazioni con Android.
 Chiunque può estendere e personalizzare il proprio processo di build estendendo
task offerti dai plugin standard.
 Ogni script Gradle è infatti equivalente al codice di un programma, ed esso esegue tre
diverse fasi:
- Inizializzazione: Gradle leggerà tutti i file di configurazione, creando per ciascuno
di questi un oggetto di tipo Project.
- Configurazione: l’oggetto Project viene alimentato dalle informazioni relative ai
vari task (compilazione, esecuzione di test, creazione di file apk e così via) da
eseguire; i task non sono indipendenti l’uno dall’altro, ma sono legati da vincoli di
sequenzialità; non possiamo testare se prima non abbiamo compilato.
- Esecuzione: Tutti i task vengono effettivamente eseguiti.
 Tutti i file di Gradle sono contenuti in una cartella che si chiama Gradle Scripts, dove
vi è la presenza dei seguenti tre file:
- settings.gradle: viene usato da Gradle nella fase di inzializzazione per capire quali
siano i progetti e i moduli da gestire e di cui leggere le configurazione;
- build.gradle (Project: ApoBus): contiene alcune configurazioni che riguardano tutti
i moduli del nostro progetto; ed è composta da:
o buildscript: contiene la definizione delle dipendenze, ovvero delle eventuali
librerie di cui lo stesso Gradle necessita per il build della applicazione.
o repositories: definiamo le sorgenti delle nostre librerie, ovvero i repository
da cui ottenerle.
- build.gradle (Module: app): è associato al modulo principale che si chiama app.
SEMANTIC VERSIONING
 Le librerie hanno un nome strutturato come segue:
<package-or-company>:<name>:<version>
 Dopo i due punti (:) la seconda parte identifica il nome della libreria.
 Le prime due parti sono obbligatorie, mentre la versione è opzionale ma iportante.
 Il versioning presenta diverse cifre, nel caso della versione di build di Gradle sono tre
e rappresentano:
major.minor.patch
 Il simbolo + indica tutte le release successive rispetto ad un livello di versioning,
quindi +, 1., 1.1.+

IL FILE build.gradle DEL MODULO PRINCIPALE

BUILD TYPE E BUILD VARIANT
 Le informazioni del modulo defaultConfig sono quelle di default per i vari build type.
 I build type sono modi diversi di eseguire l’operazione di build della nostra
applicazione.
 E’ uno strumento molto potente, in quanto consente di gestire configurazioni diverse
o librerie diverse.
 Per ciascun modulo, Gradle crea un particolare build type che si chiama debug e che
contiene alcune impostazioni utili in fase di sviluppo.
 Altre sono invece definite nel file build.gradle attraverso un elemento che si chiama
buildTypes, che contiene la definizione di tutti i build type in aggiunta a quello di
default che si chiama debug.
 Nel caso del progetto creato da Android Studio notiamo la presenza di un build type
di nome release che contiene l’impostazione di alcune informazioni che sono utili per
la versione dell’applicazione da pubblicare sul Play Store.
 Build flavor: permette di definire applicazioni diverse che hanno in comune una
stessa base di risorse e codice.
 Esempio: diversi flavor si una stessa applicazione sono, la versione a pagamento e
quella che contiene dei banner; Flavor diversi si possono distinguere per l’icona nel
caso in cui si riutilizzasse lo stesso codice per aziende diverse.
 Build variants: è la combinazione di un build flavor e un build type.

GRADLE WRAPPER
 Consente di avere sempre di avere la versione più aggiornata di Gradle
 gradle –wrapper.properties

COMPONENTI PRINCIPALI DI ANDROID

 Principali Classi (BB): Activity (UI)
 Dietro le quinte: Intent e Intent Filter, Broadcast Intent Receiver, Service, Content
Provider
 La caratteristica principale di un componente è quella della sua riutilizzabilità, ma
anche quello di possedere un ciclo di vite che regola le interazioni con il container

ACTIVITY
 Ciascuna schermata definisce due aspetti: l’insieme degli elementi grafici e la
modalità di interazione con essi.
 Queste regole potranno essere definite attraverso righe di codice (modo imperativo)
oppure attraversi opportuni documenti XML di layout (modo dichiarativo) sfruttando
l’IDE di Android Studio.
 Una activity gestisce gli elementi della GUI (equivale al controller dell’MVC).
 Importante capirne il ciclo di vita e i metodi di callback.
 Riceve le azioni degli utenti per consentirne l’interazione.
 Esso specifica un compito elementare che un utente può compiere (esempio
effettuare una chiamata, aggiungere un contatto in agenda).
 Una normale applicazione è composta da più schermate, esse si alternano molte
volte scambiandosi delle informazioni.
  Per questo motivo Android organizza le attività secondo una struttura a stack dove
l’attività in cima è sempre quella attiva in un particolare momento.
 La visualizzazione di una nuova schermata la porterà in cima allo stack mettendo in
uno stato di pausa quelle precedenti.
 Quando una Activity termina il proprio lavoro farà in modo di ritornare le eventuali
informazioni raccolte alla precedente, la quale diventerà nuovamente attiva.
 In una logica di ottimizzazione delle risorse, è necessario prevedere che una Activity
non visualizzata, possa essere eliminata dal sistema per poi essere eventualmente
ripristinata successivamente.
 Il programmatore attraverso alcuni metodi di callback deve gestire i passaggi di stati.

INTENT E INTENT FILTER

 Quando un’applicazione ha la necessità di eseguire una particolare operazione non fa
altro che creare un Intent = intenzione richiedendo l’utilizzo di una qualche risorsa, o
componente in grado di poterlo soddisfare, senza pensare a come questa verrà
effettivamente eseguita.
 Serve un meccanismo che permetta di dire al sistema che un particolare componente
è in grado di soddisfare un Intent.
 IntentFilter: meccanismo per informare la piattaforma delle azioni che l’app (le sue
componenti) sono in grado di soddisfare.

BROADCAST INTENT RECEIVER

 Assume importanza la possibilità di reagire a eventi che non sono avviati dall’utente,
ma che sono scatenati da eventi esterni, come l’avvicinarsi a una particolare location,
etc. (geofence).
 Esistono degli eventi di diverso tipo, cui le varie app devono poter associare
particolari azioni.
 Questi componenti vengono descritti dal concetto di Broadcast Intent Receiver, che
sono in grado di attivarsi a seguito del lancio di un particolare Intent che si dice
appunto di Broadcast.
 Il loro compito è quello di attivarsi in corrispondenza di particolari eventi,
raccogliendone le informazioni da utilizza poi per l’esecuzione di operazioni
complesse.

BROADCAST RECEIVER
 Ascolta e risponde agli eventi.
 Esso ha il ruolo di registrare gli eventi in un pattern pubblicazione/sottoscrizione.
 Gli eventi sono rappresentati dalla classe Intent, poi sono mandati in broadcast.
 Essi sono mandati agli oggetti che si sono registrati.
 L’assp dei Messaggi è una di quelle che usano il broadcast.
 Esempio: Se qualcuno mi manda un SMS, alla ricezione Android inserirà l’icona che
indica l’arrivo del messaggio nella Notification Bar. Perché non si sa esattamente
quando l’SMS arriva, Android ha un software che resta in attesa di SMS. All’arrivo il
componente invia in broadcast l’intent sms_received, un altro broadcast receiver,
che riceve l’intent, inizializza un servizio che scaricherà a memorizzerà il messaggio.
CONTENT PROVIDER
 Come sopra.

SERVICE
 Si ha la necessità di un meccanismo che permetta di mantenere in vita il più possibile
alcuni oggetti (thread) senza correre il rischio che questi vengano eleminati al fine di
una politica di ottimizzazione delle risorse.
 Peri i casi in cui un task (non app) deve essere sempre attivo si può utilizzare un
Service.
 Gira in background, in modo indipendente da ciò che è eventualmente visualizzato
sul display.
 Operazioni long-run.
 Interazione con processi remoti.
 Esempio: app musiaca e MediaPlaybackService.

EMULATORE
 L’ambiente Android mette a disposizione una serie di emulatori istanziabili attraverso
un AVD (Android Virtual Device), che rappresenta una possibile configurazione di cui
un dispositivo reale può essere dotato.
 La creazione dell’AVD viene effettuata attraverso un tool chiamato AVD Manager,
che permette di creare diversi emulatori per smartphone, dispositivi wereable, TV e
auto.
 Vantaggi:
- Economico;
- Non si necessita del dispositivo;
- L’hardware è riconfigurabile (dimensione scheda SD);
- Modifiche sono isolate nel dispositivo, è meno rischioso.
 Svantaggi:
- Lento…molto lento.
- Alcune caratteristiche non sono supportate, ad esempio Bluetooth e usb;
- Alcune caratteristiche variano tra l’emulatore e il dispositivo.
- Non è un dispositivo.
 Si possono impostare:
- Velocità network/ latenza;
- Stato batteria;
- Coordinate geografiche.

DEBUGGER
L’ambiente Android mette a disposizione una serie di emulatori
MEMORY LEAK
 Java ed Android prevedono l’uso di un garbage collector, ovvero di un processo che,
a intervalli non prevedibili, scandisce la memoria a caccia di oggetti non più utilizzati,
per poterli eliminare.
 I problemi si verificano quando un oggetto che dovrebbe essere eliminato rimane in
memoria perché mantenuto in vita da collegamenti diventati inutili, ma comunque
esistenti e vivi.
 Questa è la situazione che caratterizza un memory leak.
 Può portare a un errore di tipo Out of Memory e che porta inesorabilmente al crash
dell’applicazione, in quanto la memoria viene comunque condivisa da più
applicazioni.

CICLO DI VITA ACTIVITY

 Quaderno.

LOGGING E ADB (Android Device Bridge)

 Quaderno.

PASSAGGIO DI OGGETTI
 Interfaccia Serializable: un oggetto si dice serializzabile se può essere trasformato in
uno stream di byte da cui può essere riconosciuto.
Si tratta della tecnologia che Java utilizza per passare degli oggetti come parametri di
operazioni remote, dove per remoto si intende in esecuzione in un’istanza diversa
dalla Virtual Machine oppure in processi diversi.
 Dal punto di vista del linguaggio è serializzabile se implementa l’interfaccia
Serializable
 Intent.putExtra(BusStop.keys.ID, busStop)
 busStop è una variabile di tipo BusStop che implementa l’interfaccia citata
 Per la ricezione basterà usare:
 getSerializableExtra(BusStop.keys.ID);
 L’interfaccia serializable è poco efficiente in ambito mobile dovuto a un problema di
performance
 Per questo motivo, venne introdotta la tecnica di parcelizzazione, rappresentata
dall’interfaccia android.os.Parceable.
 Essa permette di ottenere prestazioni migliori, soprattutto nella comunicazione tra
processi.
 Un aspetto negativo riguarda la necessità di scrivere codice aggiuntivo che deve
seguire un certo schema che abbiamo implementato nelle nostre classi di modello.
 Tale interfaccia prevede la definizione di due operazioni:
- public int describeContents(): restituisce un insieme di flags che permettono di
indicare se il nostro oggetto contiene oggetti da gestire in modo particolare
durante le fasi di parcellizzazione.
- public void writeToParcel(Parcel dest, int flaga): invocate nel momento in cui si
deve trasferire un oggetto; il parametron Parcel rappresenta il contenitore dal
 quale andare a scrivere I vari parametric atttraverso una serie di metodi del tipo
writexxx().

FRAGMENT
 E’ descritto da particolari specializzazioni dell’omonima classe del package
android.app.
 Si tratta di un componente diverso dall’Activity, che consente di gestire delle sotto-
attività non solo per quello che riguarda la loro UI, ma anche lo loro history, quel
meccanismo che permette di mantenere lo stato di navigazione per la gestione del
pulsante Back.
 Dopo la creazione dell’istanza Fragment, il metodo invocato dal sistema è onAttach(),
che offre la possibilità di ottenere un riferimento all’Activity contenitore.
 Una volta che il Fragment è stato associato a una attività, viene invocato il metodo
onCreate().
 In questo metodo si eseguono tutte le operazioni di inizializzazione legate al
componente che qui si traducono nell’assegnazione di un Adapter (componente in
grado di accedere a informazioni memorizzate in una base di dati e di creare delle
View per la loro visualizzazione all’interno di un componente come la ListView).
 Il Fragment viene creato e gli viene associato un layout all’interno
dell’implementazione del metodo onCreateView().
 Il metodo invocato, successivamente all’associazione della View, è onViewCreated().

CICLO DI VITA FRAGMENT

 I Fragment sono caratterizzati da un proprio ciclo di vita.
 Non si può utilizzare un Fragment senza un’attività che lo contenga, per cui i due cicli
di vita dovranno sicuramente essere legati tra loro.
 La prima operazione è la creazione, che può avvenire in due modi:
- Implementazione di un metodo statico di factory;
- Utilizzo nel layout del tag <fragment/>.
 La prima modalità è un modo per creare un’istanza del Fragment, passando tutto
quello di cui necessita e che verrà salvato all’interno di un bundle che viene associato
al concetto di parametri e argomenti.
 Esempio Static Factory Method:
public static MyFragment getMyFragment(String arsg1, int args2){
MyFragment myFrag = new MyFragment();
Bundle args = new Bundle();
args.putString(KEY1, args1);
args.putInt(KEY2, args2);
myFrag.setArguments(args);
return myFrag;
}
 Il Fragment è stato creato ma non è stato associato a nessun layout, cosa che dovrà
avvenire in modo esplicito attraverso un FragmentManager.
 La fase successiva è quella che lo lega all’Activity che lo contiene. Esso viene infatti
attaccato attraverso l’invocazione del metodo
 public void onAttach(Context context).
 Quest’ultimo permette al Fragment di ottenere un riferimento all’attività in quanto
tale o perchè dotata di alcuni metodi implementati da una particolare interfaccia di
callback.
 Si ottiene un riferimento a un’attività che non è comunque ancora completamente
inizializzata.
 La fase successiva consiste nell’invocazione del metodo
public void onCreate(Bundle savedInstanceState)
Un punto in cui si eseguono operazioni di inizializzazione oltre che gestire lo stato
attraverso il parametro savedInstanceState;
 Mentre per le Activity questo è anche il metodo di inizializzazione del layout, per i
Fragment è stato deciso di delegare tale funzione al metodo di callback:
public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle
savedInstanceState)
 Il metodo di notifica dell’avvenuta conclusione del metodo onCreate() da parte
dell’Activity è il seguente:
public void onActivityCreated(Bundle savedInstanceState).
 Quando viene richiesta la visualizzazione di un Fragment, esso segue un
procedimento analogo all’Activity tranne per l’unica differenza che riguarda il
metodo onDestroyView e onDetach():
public void onDestroyView()
 Questo metodo viene invocato quando il Fragment è nello stato di STOPPED, il
sistema può decidere di rilasciare le relative risorse eliminando la gerarchia di View
associata.
 Il metodo onDetach() stacca il Fragment dalla corrispondente Activity o Context.

FRAGMENT MANAGER E FRAGMENT TRANSACTION

 Il FragmentManager permette di gestire i vari Fragment e il relativo back stack.
 FragmentManager fragmentManager = getFragmentManager();
 Un primo aspetto gestito da questo oggetto riguarda i Fragment creati e la possibilità
di ottenere un rifermento attraverso l’id o il tag:
 public Fragment findFragmentById(int id)
 public Fragment findFragmentByTag(String tag)
 Metodi utili quando si ha la necessità di ottenere il riferimento ai diversi Fragment
per modificarne, le informazioni nella UI o interagire con I task che essi possono
incapsulare in caso di assenza dell’interfaccia grafica.
 Ma come viene reso attivo?
 La responsabilità di questo è di un altro componente che prende il nome di
FragmentTransaction, di cui si ottiene un riferimento a partire dal FragmentManager
in questa maniere:
 FragmentTransaction fragmentTransaction = fragmentManager.beginTransaction();
ExampleFragment fragment = new ExampleFragment();
fragmentTransaction.addToBackStack(“my frag”);
fragmentTransaction.add(R.id.fragment_container, fragment);
fragmentTransaction.commit();
  Si ottiene una FragmentTransaction attraverso il metodo beginTransaction()
 Esso indica che si sta iniziando qualcosa che dovrà contenere un insieme di
operazioni che dovranno comunque essere considerate come una sola, quindi essere
applicare oppure essere eliminate tutte insieme.
 Per far ciò, deve esistere un modo per aggiungere operazioni alla transazione ed
accade con i seguenti tre metodi:
 public FragmentTransaction add(int containerViewId, Fragment fragment)
 public FragmentTransaction add(Fragment fragment, String tag)
 public FragmentTransaction add(int containerViewId, Fragment fragment, String tag)
 La differenza è relative alla presenza o meno di una UI.
 Una transazione può contenere un numero qualunque di operazioni tra cui anche la
rimozione di un fragment attraverso il metodo:
 public FragmentTransaction remove(Fragment fragment).
 Utilizzando I metodi:
 public FragmentTransaction replace(int containerViewId, Fragment fragment, String
tag)
 public FragmentTransaction replace(int containerViewId, Fragment fragment)
 possiamo aggiungere alla transazione un’operazione che consiste nel rimuovere un
fragment precedentemente aggiunto sostituendolo con uno nuovo.
 Possiamo osservare come si tratti di metodi che restituiscono un’istanza dell’oggetto
stesso, al fine di semplificare il codice attraverso un meccanismo che si chiama di
chaining, cioè consente di semplificare la scrittura del codice attraverso istruzioni
del tipo obj.metodo1().metodo2().metodo3() ed è utile se si usa insieme allo Static
Factory Method.
 Quando tutte le operazioni sono state registrate all’interno della transazione, si deve
invocare il metodo commit(), che la rende effettiva.
 Il raggruppamento di una serie di operazioni all’interno di un’unica transazione ha
come vantaggio la possibilità di tornare indietro, annullandone l’effetto.
 Questo non avviene in modo automatico, ma deve essere esplicitato attraverso
l’invocazione del metodo:
 public FragmentTransaction addToBackStack(String name)
 Questo inserisce la transazione all’interno del back stack, con il quale si può
interagire in diversi modi, tra cui, semplicemente, premendo il pulsante di Back.

LISTFRAGMENT E DIALOGFRAGMENT
 Libro.
ACTION BAR
 La ActionBar è stata introdotta per permette il posizionamento del brand
dell’applicazione oltre che per dare indicazioni sullo stato della navigazione,
consentendo un accesso alle sue funzionalità più importanti e dirette che necessitano
di essere trovate in modo semplice e veloce.
 L’ActionBar è un componente che viene inserito nella gerarchia delle View, ma sena
sovrapporsi a esse.
 Il metodo della classe Activity che permette di ottenere l’acceso alla ActionBar si
chiama getActionBar(), nel caso dell’utilizzo delle librerie di supporto si utilizza il
metodo getSupportActionBar().
 Nel caso in cui si volesse sottrarre spazio al layout dell’Activity, si può utilizzare il
seguente attributo, che permette di ottenere un’ActionBar che, quando visualizzata,
si sovrappone al layout dell’attività senza portarle via spazio, ma nascondendolo in
parte:
 <item name=”android:windowActionBarOverlay”>true</item>.
 Le applicazioni non fanno altro che ottenere un riferimento all’ActionBar, invocando I
metodi show() e hide().
 E’ possibile inserire delle opzioni all’interno di un’ActionBar.
 Le opzioni possono essere visualizzate come azioni dell’ActionBar, attraverso
un’opportuna configurazione in un file delle risorse di tipo menu.
 android:showsAction, può avere un valore tra i seguenti:
- always: ci permette di richiedere che vengano sempre e comunque visualizzate
nell’ActionBar;
- never: non verranno mai inserite nell’ActionBar;
- withText: ci permette di richiedere la visualizzazione dell’etichetta anche nel caso
in cui le fosse associata un’immagine;
- ifRoom: ci consente di chiedere al sistema di aggiungere tali opzioni solamente se
c’è abbastanza spazio;
- collapseActionView: indica particolari View e layout per azioni personalizzate.
 Queste opzioni vengono create all’interno del metodo;
 public boolean onCreateOptionsMenu(Menu menu)
MENU CONTESTUALE
 Sono un insieme di opzioni che descrivono azioni che possono essere eseguite su uno
o più oggetti.
 I menu contestuali sono di due tipi:
- Floating Context Menu;
- Contextual Action Mode;
 Il primo è un menu che compare all’interno di una finestra di dialogo al centro del
display.
 Il secondo consiste in una vera e propria personalizzazione dell’ActionBar per la
visualizzazione di un insieme di operazioni da eseguiere su uno o più elementi
selezionati.
 Dettagli libro.

TOOLBAR
 La ActionBar è un componente, che fa parte della gerarchia di View legate a una
Activity e non per esempio a un Fragment.
 A differenza della ActionBar, una Toolbar può essere inserita in un qualunque
layout e gestita da Activity o da un Fragment.
 Questo aspetto rende la Toolbar un componente più versatile rispetto a un’ActionBar
che può essere utilizzata al suo posto.
 Una Toolbar dispone dei seguenti elementi che possono essere presenti oppure no e
che sono caratteristici di una Toolbar:
- Button di navigazione;
- Una immagine come logo;
- Un titolo e un sottotitolo;
- Delle custom View;
- Delle azioni associate.
 Dettagli libro.

VIEW E LAYOUT
 Le diverse schermate, descritte da altrettante Activity e Fragment, contengono dei
componenti che tipicamente sono dei Button per l’interazione con l’utente, degli
EditText per l’inserimento di informazioni testuali e delle TextView per la
visualizzazione delle stesse.
 Si tratta di componenti descritti da altrettante specializzazione della classe View, che
contiene tutte le informazioni comuni a ogni elemento grafico con cui l’utente
interagisce.
 L’interfaccia grafica può essere descritta attraverso un approccio dichiarativo,
definizione di un documento XML (cioè documento di layout); o un approccio
imperativo cioè descrizione della UI attraverso righe di codice.
 L’XML a differenza del codice Java, ha diversi vantaggi:
- Attraverso il layout editor è possibile avere subito un feedback sul risultato.
- Sono risorse che possono essere qualificate (per esempio rispetto a diversi
orientamenti del display) utilizzando l’apposito meccanismo messo a disposizione
dalla piattaforma.
 - All’Activity non viene anche data la responsabilità di definire l’interfaccia, ma
solamente quella di gestire gli eventi sui diversi componenti e di fungere da
controller in un contesto MVC.
- Lo stesso documento di layout potrebbe essere riutilizzato per la definizione di
altre attività o parti di esse.
 Model View Controller (MVC) è un’architettura di sviluppo che consente di attuare
una suddivisione di responsabilità tra chi è deputato alla gestione dei dati (il Model),
alla loro visualizzazione (la View) e al mapping tra gli eventi sulla View e le operazioni
sul Model (il Controller).
 Il metodo setContentView() utilizza l’overload, che prevede come parametro
l’identificativo della risorsa di tipo layout:
 setContentView(R.layout.buttons_layout);
 findViewById() per ottenere un riferimento a una particolare View dato il suo id;
l’operazione di cast serve in quant oil metodo findViewById() vale per una qualunque
View che corrisponde al tipo di dato restituito.
 La classe ViewGroup anch’essa una specializzazione della classe View, con la
fondamentale proprietà di poter aggregare altre View.
 Attenzione: questo significa che un ViewGroup potrà aggregare un insieme di altre
View, alcune delle quali potranno essere a loro volta dei ViewGroup che aggregano
altre View e così via.
 E’ possibile creare un albero di componenti da poter applicare a ciascuno di essi, in
modo ricorsivo, delle operazioni come può essere quella di visualizzazione.
 Composite Pattern (immagine sul libro pag 274)
 Per quanto riguarda il posizionamento, vedi libro pag. 276.

LINEAR LAYOUT
 Il LinearLayout, permette di disporre le View in esso contenute su una singola riga o
colonna a seconda della sua proprietà orientation.
 Per specificare se disporre i componenti su una riga o colonna si può utilizzare
l’attributo:
 android:layout_orientation
 Il quale può assumere i valori horizontal e vertical.
 La stessa informazione può essere specificata attraverso il metodo
 public void setOrientation(int orientation).
 con I due possibili valori rappresentati dale costanti statiche HORIZONTAL e VERTICAL
della classe LinearLayout.
 La classe LinearLayout estende la classe ViewGroup che sappiamo definre una classe
interna di nome ViewGroup.LayoutParams per gli attributi che le View contenute
dovranno specificare.
 Si tratta di quelle relative alle dimensioni, alle quali la classe LinearLayout, attraverso
la definizione della classe interna LinearLayout.LayoutParams, aggiunge quelle
relative a gravità (gravity) e peso (weight).
 layout_weiht indica il peso che una View ha rispetto all’occupazione dello spazio
disponibile in un particolare momento.
  Si esprime tramite un valore numerico che indica in quale proporzione una View
occuperà tutto lo spazio che ha a disposizione rispetto alle altre.
 Uno stesso valore di peso per le due View consente di dividere lo spazio in parti
uguali.
 La posizione in cui le View contenute vengono inserite a partire dal vertice superiore
sinistro e poi la direzione relativa all’orientamento, viene descritta dall’attributo
android:layout_gravity.

RELATIVE LAYOUT
 Consente di specificare la posizione di ogni View relativamente a quella del container
o di altre.
 Attraverso l’attributo android:layout_alignParentRight a true stiamo comunicando
l’intenzione di allinearlo a destra con il proprio contenitore.
 Attraverso l’attributo android_layout_toRight stiamo dicendo che questo
componente dovrà stare alla destra di quello dell’id specificato dal corrispondente
valore.

FRAME LAYOUT
 Il FrameLayout consente di avere un controllo sulla visualizzazione delle view che
contiene, fornendo gli strumenti per visualizzarne o nasconderne alcune.

RISORSE DI TIPO COLOR

 Vedi libro, pag. 290.

DRAWABLE
 Vedi libro, pag. 293.

RISORSE DI TIPO SHAPE

 Le risorse di questo tipo vengono create attraverso l’uso dell’elemento <shape/>, che
dispone di diversi attributi che ci permette di decidere de è un rettangolo, una linea,
un ovale o un anello.
 Attraverso l’elemento <corners/> possiamo specificare il raggio di arrotondamento
degli angoli.
 <solid/>, il colore di riempimento della figura.
 <stroke/>, un bordo di cui abbiamo specificato il colore e lo spessore.
 <gradient/>, permettono di specificare il colore di partenza, quello centrale, quello
finale del gradiente; se non specificato diversamente, il gradiente andrà da sinistra a
destra.

ASSENTS E FONT
 Vedi libro, pag. 305.
CREAZIONE DI UN COMPONENTE PERSONALIZZATO
 Componente personalizzato per la scelta della data.
 Due approcci diversi.
 Il primo ci permetterà di creare il componente attraverso la definizione di un
particolare layout.
 Il secondo approccio utilizzerà invece gli strumenti di più basso livello, come quelli
che ci permettono di scrivere sul Canvas del componente.

LA GESTIONE DELLE LISTE: ListView e RecyclerView

LISTVIEW E ADAPTER
 Un’Adapter è una particolare interfaccia che descrive un’astrazione la cui
responsabilità è quella di disaccoppiare la modalità di acquisizione dei dati, dalla loro
visualizzazione.
 Spesso si fa un’analogia fra l’Adapter e il DAO (Data Access Object), in quanto si tratta
di pattern con caratteristiche molto simili.
 La differenza sostanziale sta nel fatto che, mentre un DAO si occupa solo di dati, un
Adapter ne fornisce anche le possibili rappresentazioni.
 Un Adapter è qualunque componente la cui responsabilità è quella di reperire
informazioni da una base di dati e di fornire, per ciascuna di esse, una
rappresentazione attraverso una particolare specializzazione della classe View, che
sappiamo essere la generalizzazione di ogni elemento della UI da inserire in
un’Activity.
 Un ViewGroup è una particolare View con responsabilità di layout.
 Una particolare specializzazione di ViewGroup potrebbe aggregare, e quindi
visualizzare, in modo diverso un insieme di View che gli vengono fornite da un
particolare Adapter.
 Stiamo parlando della classe AdapterView che implementa tutta la logica di
collaborazione tra un ViewGroup e un Adapter.
 La ListView è una specializzazione della classe AdapterView che visualizza le View
fornite da un Adapter secondo una modalità a lista che si può far scorrere
verticalmente.

ADAPTER NEL DETTAGLIO

 Vedi libro, pag. 351.

IL PATTERN HOLDER
 Vedi libro, pag.373.
RECYCLERVIEW
 La Listview è un componente che dal punto di vista object oriented, si è rivelato poco
coeso.
 La coesione è una caratteristica di un oggetto di gestire più aspetti che in un certo
senso non sono collegati tra loro.
 Questo ha lo svantaggio che la modifica in uno di questi aspetti comporta delle
modifiche anche nel codice che dovrebbe gestire aspetti diversi.
 Dalla versione Lollipop (Android 5.0) Google ha deciso di implementare una serie di
componenti più coesi.
 Il principale di questi componenti è proprio quello descritto dalla classe
RecyclerView, la cui responsabilità è quella di riciclare View al fine di una migliore
gestione delle risorse.
 Riciclare significa, ottenere migliori performance, in quanto non dobbiamo ripetere
operazioni di inflate che sono molto pesanti; inoltre si ha un migliore utilizzo della
memoria.
 Ma se il RecyclerView ha responsabilità del riciclo, chi ha la responsabilità di creare le
varie View da visualizzare?
 Anche in questo caso esiste il concetto di Adapter, in questo caso però, le View
vengono gestite in modo esplicito da quello che si chiama ViewHolder.
 Le RecyclerView obbligano a creare ViewHolder che mantengono i riferimenti alle
View nel layout associato a ciascun elemento del modello.
 Una RecyclerView è in grado di riciclare istanze di ViewHolder gestite da un
particolare Adapter in grado di accedere ai dati.
 La successiva responsabilità è quella di posizionare questi elementi all’interno dello
spazio disponibile.
 Questa è la responsabilità del LayoutManager.

LAYOUTMANAGER
 Il LayoutManager è responsabile dell’esecuzione delle fasi di measure e layout dei
componenti che la RecyclerView dovrà gestire.
 La particolare implementazione di LayoutManager deve inoltre stabilire quando una
particolare View (o relativo ViewHolder) possa essere riciclata quando non più
visibile.
 Dettagli libro, pag. 393.

ITEMDECORATION
 Vedi libro, pag. 402.
LE CARDVIEW
 Viene utilizzata per gestire dati molto diversi tra loro.
 E’ un layout che permette di aggiungere a un particolare contenuto un aspetto più
vicino alle specifiche Material Design e quindi con bordi arrotondati e utilizzo di
elevation, con conseguente ombra.
 Si tratta di un caso particolare di FrameLayout che decora il suo contenuto
aggiungendo un aspetto Material.

RECYCLERVIEW E ANIMAZIONI MATERIAL DESIGN

 Vedi libro, pag. 424.

GESTIONE DELLA PERSITENZA

UTILIZZO DELLE PREFERENZE

 Preferenze o settings: si tratta di una serie di schermate attraverso le quali l’utente
può impostare alcune informazioni di configurazione legate a una o più applicazioni.
 Gestire la lettura di informazioni implica l’utilizzo del seguente metodo definito in
Context, che anche le nostre Activity ereditano e cui i Fragment hanno accesso.
 public abstract SharedPreferences(String name, int mode)
 Questo consente di accedere a un’istanza SharedPreferences associata a un
particolare nome e a un identificatore dei permessi di accesso da parte delle altre
applicazioni.
 Il valore di default di mode è descritto dalla costante statica Context.MODE_PRIVATE,
che indica che le informazioni sono accessibili solo ai componenti di una stessa
applicazione.
 Qualora si volesse rendere queste informazioni accessibili in lettura anche alle altre
applicazioni, la costante da utilizzare sarà Context.MODE_WORLD_READABLE,
mentre per l’accesso in scrittura basterà specificare il valore
Context.MODE_WORLD_WRITEABLE.
 Una volta ottenuto il riferimento all’oggetto di tipo SharedPreferences possiamo
utilizzare una serie di metodi getxxx() che ci consentono di accedere ai valori di
configurazione associati a una particolare chiave per i principali tipi primitivi e la
String.
 Modalità con cui le informazioni vengono salvate e quindi modificate:
 La stessa classe SharedPreference diventa Factory per un oggetto di tipo
SharedPreferences.Editor, il quale ci permette di gestire le informazioni come se
fossero all’interno di una transazione
 SharedPreference.Editor editor = prefs.edit();
 editor.commit();
 Dall’oggetto di tipo SharedPreferences otteniamo l’oggetto di tipo Editor attraverso il
metodo di Factory edit().
 Attraverso una serie di metodi putxxx() che riflettono i corrispondenti metodi
gettxxx() impostiamo i valori da memorizzare, per poi eseguire il commit() sull’Editor
per renderli effettivi.
 E’ possibile eliminare alcuni valori attraverso il metodo: remove().
  Cancellare tutte le informazioni clear().
 Operazione andata a buon fine commit().

GESTIONE DELLE (BUS) PREFERITE

 Possiamo decidere se memorizzare tutte le informazioni oppure solamente quelle
relative agli id ed eseguire delle query successivamente per le altre informazioni.
 Si tratta della classica situazione di trade-off tra funzionalità da implementare e
performance.
 Serve un meccanismo che ci permetta di serializzare un elenco di (BusStop)
all’interno di uno dei tipi previsto dall’oggetto SharedPreferences.
 Una possibile soluzione è quella di rappresentare le informazioni all’interno di un
documento JSON (Java Script Object Notation).
 E’ un formato molto utilizzato per la serializzazione di dati complessi in un formato
compatibile con il Web e principalmente con i servizi di tipo REST.
 Esso permette di implementare quella che è una possibile rappresentazione del
dato.
 Dettagli, vedi libro pag. 468.

ACCESSO AL FILE SYSTEM LOCALE

 Vedi libro, pag. 480.

SQLITE
 Vedi libro, pag. 490.

SQULITEOPENHELPER
 Vedi libro, pag. 521.

IMPORTAZIONE DI DATABASE DI GRANDI DIMENSIONI

 Vedi libro, pag. 526.

UTILIZZO DI CONTENTPROVIDER
 Esistono determinati tipi di risorse che, per la natura stessa di Android, dovrebbero
essere condivise, per esempio l’insieme dei contatti.
 Per questo motivo la piattaforma ha ideato dei componenti che si chiamano
ContentProvider, i quali permettono di accedere a un particolare insieme di
informazioni attraverso un’interfaccia che ricorda da vicino i servizi REST
(REpresentational State Transfer).
 A ciascun ContentProvider possono essere associati uno o più Uri del tipo:
 content://<authority>/path
 Mentre la parte authority caratterizza in modo univoco il particolare
ContentProvider, la parte path consente di specificare il tipo di risorsa in esso
memorizzata.
 I ContentProvider sono di fondamentale importanza anche nel meccanismo di
IntentResolution, ovvero quell’insieme di regole che permette di individuare il
particolare componente in grado di soddisfare un particolare intent.
  E’ infatti responsabilità del ContentProvider indicare il particolare content type
associato a un determinato URI.

MULTITHREADING E SERVIZI

THREAD
 Per descrivere cos’è un thread (thread of control), possiamo partire definendo un
algoritmo come un insieme di operazioni, spesso descritte con linguaggio naturale,
che permettono la risoluzione di un particolare problema.
 Il Thread of Control gestisce infatti in modo indipendente parti diverse di uno stesso
oggetto.
 Un oggetto può essere scritto utilizzando diversi linguaggi di programmazione, dando
origine ai programmi.
 Concetto di processo, ovvero di esecuzione di un particolare programma.
 Due processi, in esecuzione di uno stesso programma, sono caratterizzati dal fatto di
utilizzare ciascuno una propria area di memoria, e quindi si possono considerare
indipendenti uno dall’altro anche se in esecuzione nello stesso momento.
 In diversi ambiti può essere utile estendere il concetto di “esecuzione simultanea”
anche alle diverse parti di una stessa applicazione.
 In questo caso non si parla di processo, ma ti thread, caratterizzato dal fatto di
condividere con altri le stesse aree di memoria, richiedendo strumenti che
consentono di mantenere l’integrità dei dati condivisi.
 La creazione di un normale thread in Android avviene utilizzando due modi diversi:
- estendere la classe Thread;
- implementare l’interfaccia Runnable.
 Nel primo caso è sufficiente estendere la classe Thread con l’override del metodo
run(), che contiene la logica relativa alle operazioni che dovranno essere eseguite in
modo concorrente in corrispondenza dell’esecuzione del metodo start().
 Un thread termina la propria esecuzione nel momento in cui il metodo run() giunge a
completamento .
 Terminata l’esecuzione, un thread diventa una normale istanza, che può mantenere il
proprio stato, eseguire operazioni, ma non potrà più essere riavviata attraverso una
nuova esecuzione di start().
 Il corpo del thread, ovvero le operazioni da eseguire in modo concorrente, vengono
implementate all’interno del metodo run().
 Rileviamo poi l’utilizzo della variabile booleana running, che serve per interrompere
l’esecuzione del metodo run() facendo terminare il ciclo while solitamente presente
in oggetti di questo tipo.
 Il secondo meccanismo utilizzato consiste nella creazione di un’istanza della classe
Thread cui viene però passata un’implementazione dell’interfaccia Runnable, che
descrive proprio l’unica operazione che ci interessa.
 L’implementazione dei metodi start() e stop() permette alla stessa istanza di essere
riavviata più volte.
 Al costruttore seguente si può passare il riferimento a una qualunque classe che
implementi l’interfaccia Runnable.
  public Thread (Runnable runnable)
 I thread di questo tipo sono i primi a essere eliminati dall’ambiente quando servono
risorse.
 Qualora si avesse la necessità di eseguire operazioni in background per lungo tempo,
Android mette a disposizione i Service.
 Spesso i thread vengono utilizzati per accedere a risorse esterne per l’acquisizione di
informazioni che poi dovranno essere visualizzate attraverso la UI.
 Serve un meccanismo che consenta l’invio di informazioni alla UI senza impattare
sulla reattività  Handler e Looper.

HANDLER E LOOPER
 I problemi si hanno quando si tratta di thread con la responsabiltà di procurare
informazioni da visualizzare all’interno di componenti grafici contenuti in un’Activity
o gli Intent Receiver.
 Per risolvere questo problema, Android fornisce un piccolo framework che semplifica
l’interazione tra thread diversi di una stessa applicazione e quindi anche l’interazione
tra lo UIThread e un thread da noi creato, che si indica come Worker Thread.
 Alla base di queste API ci sono le seguenti classi:
- Handler;
- MessageQueue;
- Message.
 A ciascun thread, Android associa una particolare MessageQueue che non è altro
che una coda di messaggi descritti da istane della classe Message.
 Un messaggio è una specie di transfer object, cioè un oggetto in grado di
memorizzare informazioni al fine di poterle trasferire in un’unica chiamata.
 E’ una classe che implementa l’interfaccia Parcelable.
 Per poter eseguire una particolare azione in un determinato thread basterà inserire
nella corrispondente cosa un messaggio che ne incapsuli le informazioni.
 L’oggetto responsabile della ricezione dei messaggi dovrà essere un oggetto
associato al thread di destinazione.
 Si tratta di una particolare istanza della classe Handler che riceve ed elabora i
messaggi della MessageQueue associati allo stesso thread nel quale l’Handler stesso
è creato.
 In pratica, i messaggi contenenti informazioni da utilizzare per l’aggiornamento dei
componenti della UI dovranno essere ricevuti da un’istanza della classe Handler
creata all’interno del Main Thread.
 Ultimo passo, relativo alla creazione e invio del messaggio da parte di un Worker
Thread.
 E’ sufficiente che quest’ultimo abbia il riferimento all’Handler per chiedergli
un’istanza del messaggio relativo alla sua coda.
LA CLASSE AsynTask
 Thread e task, sono due concetti legati tra loro, ma distinti.
 Un thread è una successione di operazioni che agiscono su informazioni che
possono essere condivise con altri thread.
 Un thread potrebbe comunque essere indefinito; un esempio è il thread relativo a un
ServerSocket che rimane in ascolto delle richieste dei client per un tempo indefinito.
 Un task è invece una successione di operazioni che prima o poi si completa e che di
solito produce un risultato.
 L’operazione di download è rappresentata da un task.
 Si tratta comunque di due concetti correlati, in quanto i task vengono eseguiti
all’interno di particolari thread.
 Java mette a disposizione due interfacce diverse: Runnable per i thread e Callable per
i task.
 Ora abbiamo a che fare con task; significa che attraverso la nostra implementazione
di AsynTask, ci aspettiamo di ottenere un risultato.
 Anche il significato della funzione stop è diverso, in quanto non rappresenta
l’interruzione temporanea, ma l’annullamento o cancellazione del task.
 Non sarà possibile fermare temporaneamente il task per poi farlo proseguire.
 AsynTask è una classe generica caratterizzata da ben tre diversi tipi di dato.
 Il primo un Integer, è il tipo dei parametri di input dei task.
 Il secondo è ancora un Integer e rappresenta il tipo di valore che potrà caratterizzare
il progredire del task.
 Il terzo è quello del risultato che il nostro task dovrà produrre.
 Quali sono i problemi che una classe di questo tipo intende risolvere?
- Eseguire un task in background.
- Notificare l’avvio e la fine del task all’interno del thread principale.
- Notificare il progredire del task attraverso l’interazione con lo UI thread.
- Gestire la cancellazione del task.
 La classe AsynTask ci fornisce poi gli strumenti per gestire in qualche modo l’avvio e
la conclusione del task attraverso due metodi:
 onPreExecute() e onPostExecute().
 Il primo viene invocato all’avvio del task, mentre il secondo al completamento dello
stesso.

NOTIFICATION SERVICE
 Vedi libro, pag. 575.
SERVICE
 Android non garantisce che una particolare attività venga sempre mantenuta in vita,
specialmente se non è visualizzata in un particolare momento.
 Questo fa sì che l’Activity non sia il luogo migliore dove descrivere operazioni di lunga
durata da eseguire in background.
 A tale scopo, Android fornisce un particolare componente che si chiama Service e che
ha un trattamento particolare che lo preserva dall’essere eliminato dal sistema.
 Un particolare Service vuole essere la soluzione di due casi ben precisi.
 Il primo è quello che permette l’esecuzione di un task di lunga durata in modo
indipendente dal ciclo di vita del componente che lo ha avviato.
 Questo scenario è il primo che trova la propria soluzione nell’utilizzo di un Service che
si dice Started.
 Lo scenario prevede che l’unico in grado di sapere se il task sia stato completato o
meno è proprio il servizio che sarà anche responsabile della sua eliminazione.
 Il secondo scenario prevede che questo esponga un’interfaccia in ambito enterprise
definiremo remota, in quanto in esecuzione di un processo diverso da quello del
client.
 Questo tipo di servizi viene indicato come Bound.
 E’ il client che sa quando inizia e quando finisce l’utilizzo delle operazioni messe a
disposizione del Service.
 Un aspetto consiste nel fatto che una stessa istanza di service potrebbe essere sia
Started e anche Bounded.
 Se un servizio è già attivo a seguito di una richiesta come Started, e un client ne
richiede l’utilizzo attraverso il metodo bindService(), non viene creata una nuova
istanza, ma viene utilizzata quella già presente.

CREAZIONE DI UN SERVICE (ciclo di vita)

 Service Started: onCreate()  onStartCommand()  RUNNING  onDestroy().
 Service Bounded: onCreate()  onBind()  RUNNING  onUnBind()  onDestroy().
 Quando un servizio non è in esecuzione e arriva una richiesta invocando il metodo
startService(), il Sistema ne crea un’istanza invocando il metodo onCreate.
 Si tratta del metodo che dovrà essere implementato per entrambi i tipi di servizio, in
quanto invocato in corrispondenza del primo utilizzo.
 Il metodo che invece viene sempre invocato a ogni richiesta di accesso al servizio è
onStartCommand.
 dettagli libro pag.599