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.

Fragment permette di gestire la History dell’interazione fatta dall’utente sulla User Interface.

Fragment supportato e necessario per realizzare le guidelines del Material Design.

Aggiunta dinamica Fragment

E’ più facile. Tramite il FragmentManager. Abbiamo una sequenza di istruzioni.

E’ bene iniziare una FragmentTransaction. E’ una transazione.

C’è un commit() alla fine.

La transazione, è una sequenza di istruzioni che viene identificata dal Programma O.S. Android, come unica.

Se va male una delle istruzioni in sequenza, viene annullato tutto. Non c’è un commit()

begin e commit()

All’interno dell’Activity:

FragmentManager fragmentManager = getFragmentManager()

fragmentManager = fragmentManager.beginTransaction()

fragmentManager.beginTransaction() dovrà gestirsi il caricamento dei Fragment.

Essendo una Transazione. Se qualcosa va male c’è il CallBack. Se tutto invece va bene, c’è il Commit()

Con il Commit() siamo sicuri che la sequenza è andata a buon fine.

L’istanziazione avviene nell’onCreate(). All’inizio. Quando l’Activity sta iniziando anche lei a fare l’onCreate(). Inizio Ciclo di Vita dell’Activity.

Chiamata al setContentView(R.layout.main). Dove carichiamo il Layout principale

Nel Layout non ci sono più i Fragment → <fragment>

Ma c’è un LinearLayout → <LinearLayout> con 2 <FrameLayout>

<?xml version="1.0" encoding="utf-8"?>
<androidx.appcompat.widget.LinearLayoutCompat xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">

<FrameLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="@+id/frame_one">
</FrameLayout>

<FrameLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="@+id/frame_two">
</FrameLayout>

</androidx.appcompat.widget.LinearLayoutCompat>

---

<?xml version="1.0" encoding="utf-8"?>
<androidx.appcompat.widget.LinearLayoutCompat xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">

<FrameLayout
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="1"
android:id="@+id/frame_one">
</FrameLayout>

<FrameLayout
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="2"
android:id="@+id/frame_two">
</FrameLayout>

</androidx.appcompat.widget.LinearLayoutCompat>

---

<?xml version="1.0" encoding="utf-8"?>
<androidx.appcompat.widget.LinearLayoutCompat xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">

<FrameLayout
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="1"
android:id="@+id/frame_one">
</FrameLayout>

<FrameLayout
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="2"
android:id="@+id/frame_two">
</FrameLayout>

</androidx.appcompat.widget.LinearLayoutCompat>

<?xml version="1.0" encoding="utf-8"?>
<androidx.appcompat.widget.LinearLayoutCompat xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">

<FrameLayout
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="1"
class="com.example.frag_statico.NuovoFr"
android:id="@+id/frame_one">
</FrameLayout>

<FrameLayout
android:layout_width="0dp"
android:layout_height="match_parent"
android:layout_weight="2"
class="com.example.frag_statico.nuovo"
android:id="@+id/frame_two">
</FrameLayout>

</androidx.appcompat.widget.LinearLayoutCompat>

Anche se i Fragment sono aggiunti in modo programmatico il Layout è comunque statico, avendo 2 pannelli che non cambiano.

Uno degli aspetti interessanti è quello di permettere alle transazioni di cambiare dinamicamente l’interfaccia utente.

Permettere: alle transazioni di cambiare dinamicamente l’interfaccia utente.