Activity:
Activity: è il processo. Quindi il codice che ha delle risorse e gira sul processore (in maniera semplice)
Le istruzioni dell’Activity vengono eseguite dal processore
inoltre
Activity_main.xml è il Layout. La parte Frontend
Main_Activity.java è la parte Backend
App Android è una collezione di:
Activity, Servizi, Fragment
Però fondamentalmente alla base di tutto ci sono le Activities
L’App è una serie di Activity, di cui cambierà il Focus fondamentalmente
Tali Activity, possono essere in onPause(), onResume(), onStop(). Hanno i loro stati.
L’activty è il codice che viene allocato in quel momento nel dispositivo.
L’App deve avere almeno un’Activity. L’entry point di un’app è un’Activity
Il Manifesto (AndroidManifest.xml) della nostra app, troveremo:
<action android:name=”android.intent.action.MAIN” />
La funzionalità associata a questa App, sia “Main” → Principale, quella di Avvio;
Nell’AndroidManifest.xml ci sarà l’elenco delle Activity. Se noi volessimo cambiare l’Activity principale, cioè quella che deve avviare l’app, ci basta cambiare: <action android:name=”android.intent.action.MAIN” />
E’ importante capire e sapere che nell’AndroidManifest.xml ci sono l’elenco delle Activity che creamo.
Ogni volta che un’Activity, apre un’altra Activity. L’Activity chiamante è inserita nel BackStack (nella PILA). L’Activity chiamante é messa in Stop.
PILA: Lifo. L’activty attiva nella nostra App è sempre una. Se ci sono più Activity, a turno a seconda dell’input dell’utente, vengono messe in stato di Stop e vanno nella Pila. Questo stato di stop, ci fa capire che il processo dell’Activity ha vari stati. Ricordando il modello a stato del Sistema Operativo. Ogni cambio di stato è notificato da evento, abbiamo un callback. Questo vuol dire che possiamo intercettarlo. E possiamo capire quanto un’activity è stata messa fuori e cioè in onStop(). Pensando all’Activity Manager. L’evento si può intercettare e si possono fare azioni compensative (ad esempio il salvataggio dei dati). O.S. Android ogni volta che fa un cambio di Activity, i dati vanno persi ed è bene gestire i dati. E’ da gestire ogni volta, perché l’Activity può essere messa fuori.
Se l’utente cambia App, la nostra App, viene messa in Stop nella Pila. Perchè l’utente cambia App, come dicevo, ne sceglie un’altra. Ed è bene gestire i dati;
Anche O.S. Android, che tende ad allocare memoria e quindi l’O.S. Android che ha tante App aperte, decide di mettere da parte la nostra App. Se l’O.S. Android decide di liberare memoria e quindi è bene gestire i dati dell’Activity, perché il sistema deve liberare memoria. E noi perderemmo tutti i dati.
La gestione delle Activity è dinamica. Le Activity hanno il focus() e vanno anche in onPause()
Activity → Activity2 ma se non salviamo i dati in Activity, Activity2 andrà persa!
App1 → App2, ma se non salviamo i dati in App1, andrà persa
Le Activity hanno una gestione dinamica, vanno continuamente in Run(), quindi hanno il focus() e poi vanno in onPause()
Fragment:
Un’App può girare su Device molto diversi. L’App è una, ma deve assicurare sempre un comportamento coerente.
Scenario 1:
User Interface e Schermi.
Fragment: sono nati per gli schermi grandi. E’ bene da precisare questo. E’ importante l’interazione con gli schermi grandi.
Interagire con uno schermo piccolo ad esempio di un Device (Smartphone), le funzionalità su uno Schermo grande non vanno più bene.
Schermo Piccolo (Smartphone) → Schermo Grande (Tablet)
Cambiano le funzionalità.
L’interfaccia in base allo schermo Grande, si deve adattare.
Euristiche di Design → ciò che si progetta sugli Smarpthone, sui Tablet non va bene
Scenario 2:
Un’Activity supporta al massimo un’operazione da parte dell’utente.
Input → Bottone
Input → editText
Input → textView
L’iterazione
App Complesse → Creano Task con diverse Activity
Se Avessi: La mia App
Formata da diversi Task
Activity 1 → Activity2, ma Activity 1 (passa nella Pila al secondo Posto).
Activity2 → Activity3, ma Activity 2 (passa nella Pila al secondo Posto)
Avremo nel primo caso: Activity2 e poi Activity 1 (NELLA PILA)
Avremo nel secondo caso: Activity3, Activity2, Activity1 ultimo (NELLA PILA)
Ogni intent crea ed alloca risorse a nuove Activity → continua navigazione porta spreco di risorse e può peggiorare prestazioni.
Anche il passaggio di dati (Bundle ) sovraccarica e gestisce ed esaurisce la memoria.
La continua navigazione, selezionare un elemento, vedere dei dettagli di quell’elemento.
Selezionando un altro elemento, vedere i dettagli e poi tornare indietro. E’ una navigazione tra Activity.
Ogni Intent crea ed alloca Risorse a Nuove Activity.
Se ho un’Activity → Activity2, tramite Intent. Creo e alloco Risorse.
Il passaggio dei dati con Bundle, sovraccarica la gestione ed esaurisce la memoria.
Gestire il tutto (ad esempio anche il Bundle) con le tante Activity
Spreco di RISORSE. Le prestazioni possono peggiorare.
Gestire il tutto con le Activity, sovraccarica ed esaurisce la Memoria.
Scenario 1: l’iterazione, ciò che si vede cioé, l’interfaccia. Come l’utente interagisce con l’App.
Scenario 2: Prestazioni.
2 Scenari, ben diversi, che propongono dei problemi, che vanno risolti.
Esempio Visualizzatore di Libri. E’ lo scenario che ci dimostra che progettare con il Fragment, vuol dire sprecare meno risorse.
I FRAGMENT
Permettono di risolvere dei problemi
1) in merito all’usabilità (Lo schermo)
2) Gestione Memoria
Per quanto riguarda lo schermo, può capitare di avere una diversa User Experience a seconda dello Schermo stretto/grande.
2 modi di progettare: Activity A mostra l’elenco dei titoli
Activity B, è invocata quando l’utente ha selezionato un titolo.
FRAGMENT
Rappresenta una porzione interattiva della User Interface
I 2 pannelli interattivi sono i 2 Fragment.
1 Activity → PIU’ FRAGMENT
Ci sono vari pezzi della User Interface dell’Activity ma che sono coordinati tra di Loro.
Ci sono 2 Vantaggi utilizzando il Fragment.
Vantaggio 1: si risparmia la creazione/distruzione di Activity (+ dati e risorse associate) che prima O.S. Android doveva gestire durante il Task
Vantaggio 2: un Fragment può essere riusato in più Activity
Fragment scompone e gestisce la User Interface e quindi vuol dire che scompone anche i Task.
Ha il ciclo di vita proprio. Activity ha il suo Ciclo di Vita, anche il Fragment ha il suo Ciclo di Vita.
Avendo già visto la Comunicazione tra Activity.
Non solo c’è la comunicazione tra Activity, ma c’è anche il Fragment.
I Fragment devono anche comunicare tra Loro, sia con le Activity che li ospitano.
→ Da ricordare che il Fragment è ospitato all’interno dell’Activity
Non solo i Fragment comunicano tra di Loro, ma anche l’Activity che lo ospita. Stiamo quindi aggiungendo della Complessità.
Un’Activity può chiamare i Metodi del Fragment? Si
Fragment frag = (Fragment) getFragmentManager().findFragmentById(R.id.frame_one);
