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.

Spreco di RISORSE. Le prestazioni possono peggiorare.

Gestire il tutto con le Activity, sovraccarica ed esaurisce la Memoria.

Scenario 1: ciò che si vede, l’interfaccia. Come l’utente interagisce con l’App.

Scenario 2: Prestazioni.

Esempio Visualizzatore di Libri. E’ lo scenario che ci dimostra che progettare con il Fragment, vuol dire sprecare meno risorse.