Bentornati.
La sezione dell'origine dati remota e il repository.
Con questo abbiamo terminato il livello del modello.
Passiamo ora al ViewModel.
Il ViewModel espone i flussi di dati rilevanti per la vista.
Inoltre, funge da collegamento tra il modello e la vista.
Uno dei principali vantaggi di un ViewModel è la consapevolezza del suo ciclo di vita.
Le istanze di ViewModel sopravvivono alle modifiche della configurazione, come la rotazione dello schermo.
Ciò significa che i dati contenuti nel ViewModel non vengono
persi quando l'attività o il frammento vengono creati e ricreati.
Naturalmente, questo vale per i Composable.
Se il componibile viene ricomposto, il ViewModel non viene perso.
ViewModel fornisce l'ambito di ViewModel, che è legato al ciclo di vita del modello di vista.
Le coroutine lanciate in questo ambito vengono annullate automaticamente
quando il ViewModel viene cancellato, evitando perdite di memoria.
Il ViewModel contiene i dati dell'interfaccia utente e la logica di business, ma non fa riferimento all'attività della vista.
Fragment Composables direttamente.
Questa separazione garantisce che i componenti dell'interfaccia utente siano gli unici responsabili del rendering dei dati
e delle interazioni con l'utente, rendendo la base di codice più facile da mantenere e testare.
Mantenendo la gestione dei dati e la logica di business
nel ViewModel, si assicura una chiara separazione dalla vista.
Questo rende il codice più modulare, testabile e manutenibile.
Passiamo ad Android Studio e creiamo un nuovo pacchetto chiamato ViewModel.
All'interno di questo pacchetto, creerò una nuova classe chiamata Post View
Mode per dire ad Android Studio che questa classe agirà come
ViewModel, dobbiamo ereditare il ViewModel ViewModel ereditato dal pacchetto Android lifecycle.
Non perdete l'invocazione del costruttore.
Ed eccoci qui.
Ora siamo pronti a creare la nostra classe come ViewModel.
Per la nostra applicazione, dobbiamo collegare il ViewModel con il repository.
Quindi creerò un repository val privato.
Inoltre, è possibile passarlo nel costruttore del ViewModel post uguale al repository post.
Ma per renderlo più semplice e non creare un factory, dobbiamo usare come si può scrivere questo repository
val repository e creare un factory per il ViewModel, come abbiamo fatto nell'esempio del database delle stanze.
Ma va bene così, non preoccupatevi.
Il secondo passo consiste nel creare una variabile e chiamare il repository dot get post.
Quindi, ecco qui.
Torniamo al repository.
Dobbiamo chiamare questa funzione.
Per chiamare questa funzione, dobbiamo creare una funzione di sospensione.
Ma all'interno dei modelli di vista dobbiamo usare lo scoop ViewModel.
Prestate attenzione e seguitemi qui.
Dobbiamo creare una nuova variabile chiamata post per Stato mutabile dell'elenco dei post.
Elenco vuoto.
Importate il post e prestate attenzione.
Postazioni VAR.
Dichiara una proprietà mutabile denominata posts e la parola
chiave var indica che la proprietà può essere riassegnata.
A differenza di val, che è immutabile, by è una parola chiave usata per la delega di proprietà in Kotlin
e la delega di proprietà consente di delegare il getter e il setter di una proprietà a un altro oggetto.
Qui, il post è delegato allo stato mutabile di e lo stato mutabile
di è una funzione di jetpack compose che crea un oggetto stato osservabile.
Quando lo stato cambia, compose ricompone automaticamente tutti gli elementi dell'interfaccia utente
che leggono questo stato e lo stato mutabile di list of post
empty list inizializza lo stato con un elenco vuoto di oggetti post.
Il parametro type list post specifica che lo stato contiene una lista di
oggetti post e la funzione empty list è una funzione Kotlin che restituisce
una lista vuota; per impostare questa variabile come privata, dobbiamo usare private set.
Questo modificatore specifica che il setter della proprietà del post è privato.
Ciò significa che mentre altre classi e compositori possono leggere il
valore dei post, solo la classe ViewModel dei post può modificarlo.
Questo incapsulamento garantisce che lo stato sia gestito in modo controllato,
impedendo modifiche esterne che potrebbero causare errori e gli stati.
Lo stato mutabile di crea un oggetto titolare di stato che
Jetpack Compose utilizza per gestire e osservare i cambiamenti di stato.
Quando lo stato del post viene aggiornato, qualsiasi funzione compostabile che legga questo
stato si ricompone automaticamente per riflettere i nuovi dati, rendendo privato il setter.
Il ViewModel assicura che solo la sua logica interna possa aggiornare la proprietà del post.
Questo controllo è fondamentale per mantenere uno stato prevedibile e coerente all'interno del ViewModel.
C'è una nota molto importante che si può notare qui.
Abbiamo usato lo stato mutabile di invece di LiveData.
In Jetpack Compose, preferiamo utilizzare lo stato mutabile di LiveData, perché questo
stato mutabile della funzione consente di gestire direttamente lo stato della composizione.
Invece di creare un LiveData e di trasformare questo LiveData in uno stato in un
secondo momento, possiamo usare e gestire direttamente lo stato usando lo stato mutabile della funzione.
Ecco l'importanza di utilizzare lo stato mutabile di.