WEBVTT 1 00:00.740 --> 00:01.850 Bentornati. 2 00:01.880 --> 00:04.610 La sezione dell'origine dati remota e il repository. 3 00:04.610 --> 00:07.400 Con questo abbiamo terminato il livello del modello. 4 00:07.430 --> 00:10.280 Passiamo ora al ViewModel. 5 00:10.310 --> 00:15.950 Il ViewModel espone i flussi di dati rilevanti per la vista. 6 00:15.980 --> 00:20.870 Inoltre, funge da collegamento tra il modello e la vista. 7 00:20.900 --> 00:27.020 Uno dei principali vantaggi di un ViewModel è la consapevolezza del suo ciclo di vita. 8 00:27.050 --> 00:32.630 Le istanze di ViewModel sopravvivono alle modifiche della configurazione, come la rotazione dello schermo. 9 00:32.630 --> 00:40.190 Ciò significa che i dati contenuti nel ViewModel non vengono 10 00:40.190 --> 00:41.360 persi quando l'attività o il frammento vengono creati e ricreati. 11 00:41.390 --> 00:44.420 Naturalmente, questo vale per i Composable. 12 00:44.420 --> 00:49.280 Se il componibile viene ricomposto, il ViewModel non viene perso. 13 00:49.310 --> 00:54.230 ViewModel fornisce l'ambito di ViewModel, che è legato al ciclo di vita del modello di vista. 14 00:54.260 --> 01:00.590 Le coroutine lanciate in questo ambito vengono annullate automaticamente 15 01:00.590 --> 01:01.640 quando il ViewModel viene cancellato, evitando perdite di memoria. 16 01:01.670 --> 01:08.980 Il ViewModel contiene i dati dell'interfaccia utente e la logica di business, ma non fa riferimento all'attività della vista. 17 01:09.010 --> 01:11.230 Fragment Composables direttamente. 18 01:11.230 --> 01:20.140 Questa separazione garantisce che i componenti dell'interfaccia utente siano gli unici responsabili del rendering dei dati 19 01:20.140 --> 01:24.160 e delle interazioni con l'utente, rendendo la base di codice più facile da mantenere e testare. 20 01:24.160 --> 01:30.460 Mantenendo la gestione dei dati e la logica di business 21 01:30.460 --> 01:30.820 nel ViewModel, si assicura una chiara separazione dalla vista. 22 01:30.850 --> 01:34.720 Questo rende il codice più modulare, testabile e manutenibile. 23 01:34.720 --> 01:42.520 Passiamo ad Android Studio e creiamo un nuovo pacchetto chiamato ViewModel. 24 01:42.520 --> 01:53.290 All'interno di questo pacchetto, creerò una nuova classe chiamata Post View 25 01:53.290 --> 02:00.970 Mode per dire ad Android Studio che questa classe agirà come 26 02:01.420 --> 02:03.040 ViewModel, dobbiamo ereditare il ViewModel ViewModel ereditato dal pacchetto Android lifecycle. 27 02:03.040 --> 02:05.350 Non perdete l'invocazione del costruttore. 28 02:05.350 --> 02:06.580 Ed eccoci qui. 29 02:06.580 --> 02:10.450 Ora siamo pronti a creare la nostra classe come ViewModel. 30 02:10.450 --> 02:14.560 Per la nostra applicazione, dobbiamo collegare il ViewModel con il repository. 31 02:14.560 --> 02:18.160 Quindi creerò un repository val privato. 32 02:18.160 --> 02:24.520 Inoltre, è possibile passarlo nel costruttore del ViewModel post uguale al repository post. 33 02:24.520 --> 02:32.140 Ma per renderlo più semplice e non creare un factory, dobbiamo usare come si può scrivere questo repository 34 02:32.170 --> 02:40.330 val repository e creare un factory per il ViewModel, come abbiamo fatto nell'esempio del database delle stanze. 35 02:40.330 --> 02:42.550 Ma va bene così, non preoccupatevi. 36 02:42.550 --> 02:48.760 Il secondo passo consiste nel creare una variabile e chiamare il repository dot get post. 37 02:48.760 --> 02:50.020 Quindi, ecco qui. 38 02:50.050 --> 02:51.790 Torniamo al repository. 39 02:51.820 --> 02:53.620 Dobbiamo chiamare questa funzione. 40 02:53.620 --> 02:57.130 Per chiamare questa funzione, dobbiamo creare una funzione di sospensione. 41 02:57.130 --> 03:01.750 Ma all'interno dei modelli di vista dobbiamo usare lo scoop ViewModel. 42 03:01.750 --> 03:04.390 Prestate attenzione e seguitemi qui. 43 03:04.390 --> 03:13.140 Dobbiamo creare una nuova variabile chiamata post per Stato mutabile dell'elenco dei post. 44 03:13.170 --> 03:14.760 Elenco vuoto. 45 03:14.760 --> 03:17.880 Importate il post e prestate attenzione. 46 03:17.910 --> 03:19.320 Postazioni VAR. 47 03:19.320 --> 03:25.590 Dichiara una proprietà mutabile denominata posts e la parola 48 03:25.590 --> 03:26.400 chiave var indica che la proprietà può essere riassegnata. 49 03:26.430 --> 03:34.860 A differenza di val, che è immutabile, by è una parola chiave usata per la delega di proprietà in Kotlin 50 03:34.890 --> 03:40.560 e la delega di proprietà consente di delegare il getter e il setter di una proprietà a un altro oggetto. 51 03:40.560 --> 03:47.280 Qui, il post è delegato allo stato mutabile di e lo stato mutabile 52 03:47.280 --> 03:51.780 di è una funzione di jetpack compose che crea un oggetto stato osservabile. 53 03:51.780 --> 03:59.730 Quando lo stato cambia, compose ricompone automaticamente tutti gli elementi dell'interfaccia utente 54 03:59.730 --> 04:08.070 che leggono questo stato e lo stato mutabile di list of post 55 04:08.100 --> 04:08.910 empty list inizializza lo stato con un elenco vuoto di oggetti post. 56 04:08.910 --> 04:16.880 Il parametro type list post specifica che lo stato contiene una lista di 57 04:16.880 --> 04:25.400 oggetti post e la funzione empty list è una funzione Kotlin che restituisce 58 04:25.400 --> 04:27.470 una lista vuota; per impostare questa variabile come privata, dobbiamo usare private set. 59 04:27.500 --> 04:33.410 Questo modificatore specifica che il setter della proprietà del post è privato. 60 04:33.410 --> 04:42.410 Ciò significa che mentre altre classi e compositori possono leggere il 61 04:42.440 --> 04:46.280 valore dei post, solo la classe ViewModel dei post può modificarlo. 62 04:46.310 --> 04:54.980 Questo incapsulamento garantisce che lo stato sia gestito in modo controllato, 63 04:54.980 --> 04:58.550 impedendo modifiche esterne che potrebbero causare errori e gli stati. 64 04:58.550 --> 05:07.130 Lo stato mutabile di crea un oggetto titolare di stato che 65 05:07.130 --> 05:07.940 Jetpack Compose utilizza per gestire e osservare i cambiamenti di stato. 66 05:07.940 --> 05:16.190 Quando lo stato del post viene aggiornato, qualsiasi funzione compostabile che legga questo 67 05:16.190 --> 05:20.030 stato si ricompone automaticamente per riflettere i nuovi dati, rendendo privato il setter. 68 05:20.060 --> 05:27.620 Il ViewModel assicura che solo la sua logica interna possa aggiornare la proprietà del post. 69 05:27.620 --> 05:34.820 Questo controllo è fondamentale per mantenere uno stato prevedibile e coerente all'interno del ViewModel. 70 05:34.850 --> 05:39.170 C'è una nota molto importante che si può notare qui. 71 05:39.170 --> 05:44.060 Abbiamo usato lo stato mutabile di invece di LiveData. 72 05:44.090 --> 05:52.880 In Jetpack Compose, preferiamo utilizzare lo stato mutabile di LiveData, perché questo 73 05:52.880 --> 05:57.950 stato mutabile della funzione consente di gestire direttamente lo stato della composizione. 74 05:57.950 --> 06:06.320 Invece di creare un LiveData e di trasformare questo LiveData in uno stato in un 75 06:06.320 --> 06:10.340 secondo momento, possiamo usare e gestire direttamente lo stato usando lo stato mutabile della funzione. 76 06:10.340 --> 06:15.290 Ecco l'importanza di utilizzare lo stato mutabile di.