WEBVTT

1
00:00.860 --> 00:03.050
Abbiamo terminato l'origine dati remota.

2
00:03.080 --> 00:05.390
Passiamo ora al repository.

3
00:05.420 --> 00:12.350
Il repository è un componente cruciale che
funge da mediatore tra le diverse fonti di

4
00:12.350 --> 00:17.930
dati e il resto dell'applicazione ed è una
parte molto importante del livello del
modello.

5
00:17.960 --> 00:21.410
Il livello del modello rappresenta il
livello dei dati dell'applicazione.

6
00:21.410 --> 00:27.920
Questo include il modello dei dati e la
logica per il recupero e la manipolazione

7
00:27.920 --> 00:30.290
dei dati, sia che provengano da un
database, dalla rete o da altre fonti.

8
00:30.290 --> 00:33.830
In questa applicazione, recupereremo i
dati dalla rete.

9
00:33.860 --> 00:41.690
Lo schema del repository viene utilizzato
per creare un'API pulita per l'accesso ai
dati al resto dell'applicazione.

10
00:41.690 --> 00:50.090
Astrae le fonti di dati sottostanti e
fornisce un luogo centralizzato per
gestire le operazioni sui dati.

11
00:50.090 --> 00:57.050
Torniamo ad Android Studio, creiamo il
pacchetto di retrofit e completiamo
l'implementazione del retrofit.

12
00:57.080 --> 01:00.320
Ora creeremo un nuovo pacchetto.

13
01:00.350 --> 01:03.020
Lo chiamerò repository.

14
01:03.020 --> 01:10.290
All'interno di questo pacchetto di
repository, creare una nuova classe Kotlin
chiamata Post repository.

15
01:10.320 --> 01:16.770
Ancora una volta, è molto importante
ricordare che il repository funge da
mediatore tra

16
01:16.800 --> 01:20.220
l'origine dei dati, in questo caso le API
di rete, e il ViewModel.

17
01:20.220 --> 01:25.020
La sua responsabilità principale è quella
di recuperare i dati e fornirli al
ViewModel.

18
01:25.050 --> 01:31.230
Tralasciando i dettagli dell'origine dei
dati, inizierò a creare il primo passo.

19
01:31.260 --> 01:40.170
Una variabile di servizio privata val API
uguale all'istanza retrofit dot API.

20
01:40.200 --> 01:43.800
Accedo al singleton da qui.

21
01:43.830 --> 01:53.490
Ora questa proprietà API è un'istanza
dell'interfaccia del servizio API,

22
01:53.490 --> 01:54.690
che retrofit può creare per effettuare
chiamate di rete.

23
01:54.690 --> 02:01.950
La riga assicura che il repository Post
abbia accesso ai metodi definiti nel
servizio API.

24
02:01.950 --> 02:04.890
Poi abbiamo bisogno di una funzione per
recuperare i post.

25
02:04.890 --> 02:09.630
Quindi, se torniamo al servizio API,
abbiamo solo una funzione.

26
02:09.630 --> 02:17.190
Se avete molte API e molte altre
interfacce e molte

27
02:17.190 --> 02:19.290
altre funzioni, dovreste menzionare tutte
queste funzioni nel repository.

28
02:19.290 --> 02:23.520
Quindi viene creato un solo metodo per
ottenere i messaggi.

29
02:23.520 --> 02:26.130
Dobbiamo chiamare questa funzione "get
posts".

30
02:26.130 --> 02:31.560
Inizierò con la funzione di sospensione,
perché è una funzione di sospensione.

31
02:31.560 --> 02:40.890
Get posts restituisce un elenco di post e
richiama il servizio API dot get posts.

32
02:40.920 --> 02:48.810
Get posts è una funzione di sospensione,
cioè può essere richiamata da una
coroutine o da un'altra funzione di
sospensione.

33
02:48.810 --> 02:55.140
Questo è importante per eseguire
operazioni di rete senza bloccare il
thread principale

34
02:55.140 --> 03:02.640
e la funzione get posts sul servizio API è
una funzione di sospensione,

35
03:02.640 --> 03:04.080
quindi sto chiamando questa funzione di
sospensione all'interno della funzione di
sospensione.

36
03:04.080 --> 03:12.810
Posts qui è annotato con get, a indicare
che

37
03:12.810 --> 03:14.760
eseguirà una richiesta Get all'endpoint
posts dell'URL di base.

38
03:14.760 --> 03:24.270
La funzione di sospensione restituisce un
elenco di oggetti post che retrofit
deserializza dal repository dei

39
03:24.270 --> 03:31.260
post con risposta JSON, in questo caso
astraendo la fonte di dati dal resto
dell'applicazione.

40
03:31.260 --> 03:38.850
Il ViewModel non deve sapere come vengono
recuperati i dati,

41
03:38.850 --> 03:39.810
ma solo che può richiedere i dati dal
repository.

42
03:39.840 --> 03:48.630
Lo schema del repository aiuta a fornire
un'unica fonte di verità per i dati, in
qualsiasi momento e indipendentemente

43
03:48.630 --> 03:52.950
dal fatto che i dati provengano da una
chiamata di rete, da un database o da una
cache.

44
03:52.950 --> 03:56.790
Il ViewModel interagisce solo con il
repository.

45
03:56.790 --> 04:03.690
Utilizzando il repository, si mantiene la
logica di recupero dei dati separata

46
04:03.720 --> 04:07.560
dal ViewModel e dall'interfaccia utente,
aderendo al principio della separazione
delle preoccupazioni.

47
04:07.560 --> 04:15.180
Anche se non viene mostrato in questo
semplice esempio, il repository può
gestire

48
04:15.180 --> 04:17.700
gli errori ed eseguire trasformazioni dei
dati prima di passarli al ViewModel.

49
04:17.700 --> 04:25.110
Utilizzando il repository Post,
l'architettura MVVM viene mantenuta
pulita, assicurando che ogni componente

50
04:25.110 --> 04:31.200
abbia una responsabilità ben definita e
che il codice rimanga modulare e
testabile.