WEBVTT

1
00:01.100 --> 00:02.180
Bentornati.

2
00:02.180 --> 00:08.960
Abbiamo introdotto il database Builder e
abbiamo passato i tre parametri:

3
00:08.960 --> 00:11.720
il contesto, il tipo di database e il nome
del database.

4
00:11.720 --> 00:16.430
Ma questo non è un approccio molto
professionale.

5
00:16.430 --> 00:25.130
Dobbiamo creare una sola istanza del
nostro database, evitando

6
00:25.130 --> 00:26.750
istanze multiple di database e perdite di
memoria.

7
00:26.780 --> 00:35.060
Esiste una sola istanza del database,
evitando così un

8
00:35.060 --> 00:35.960
inutile sovraccarico associato alla
creazione ripetuta del database.

9
00:35.960 --> 00:41.630
Seguiremo quindi un modello chiamato
singleton design pattern.

10
00:41.630 --> 00:48.890
Vorrei che vi concentraste su questo punto
perché è un argomento molto importante per
la creazione di un database.

11
00:48.890 --> 00:49.580
All'inizio.

12
00:49.580 --> 00:54.320
Inizio con una variabile astratta di note.

13
00:54.350 --> 00:55.340
Dao e di seguire il design pattern
singleton, che

14
00:59.690 --> 01:06.900
prevede l'esistenza di una sola istanza
del database.

15
01:06.930 --> 01:15.630
Per evitare l'inutile overhead associato
alla creazione ripetuta di un DB,

16
01:15.630 --> 01:19.980
è necessario utilizzare due importanti
parole chiave: companion object e
volatile.

17
01:20.010 --> 01:24.030
Cominciamo con l'oggetto compagno.

18
01:24.060 --> 01:26.010
Oggetto compagno.

19
01:26.010 --> 01:31.620
In Kotlin, l'oggetto companion è un
oggetto singleton associato a una classe.

20
01:31.620 --> 01:40.170
È possibile accedere ai membri di questo
oggetto utilizzando il nome della classe
senza creare un'istanza della stessa.

21
01:40.170 --> 01:45.240
Qui abbiamo bisogno che l'oggetto
companion contenga l'istanza singleton.

22
01:45.240 --> 01:48.960
La logica per ottenere o creare il
database.

23
01:48.990 --> 01:54.150
All'interno di questo oggetto companion,
dobbiamo creare una nuova variabile
chiamata instance.

24
01:54.150 --> 01:59.190
È di tipo node db ed è uguale a null.

25
01:59.220 --> 02:09.630
Mark this instance with volatile Questa
variabile contiene un

26
02:09.630 --> 02:11.400
riferimento alla singola istanza del
database DB del nodo.

27
02:11.430 --> 02:21.420
Inizialmente è impostato su null, a
indicare che il database non

28
02:21.420 --> 02:22.920
è ancora stato creato e per questo si usa
l'annotazione volatile.

29
02:22.950 --> 02:30.780
La volatilità impedisce qualsiasi
condizione di gara in scenari di
multithreading in un ambiente multithread.

30
02:30.810 --> 02:38.070
Senza volatilità, è possibile che un
thread legga il valore di

31
02:38.100 --> 02:40.530
stato di un'istanza mentre un altro thread
l'ha già inizializzata.

32
02:40.530 --> 02:49.710
L'annotazione volatile evita questo
problema, garantendo che il valore sia
visibile in modo coerente in tutti i
thread.

33
02:49.740 --> 02:57.330
Immaginiamo due thread, il thread A e il
thread B, che cercano entrambi

34
02:57.330 --> 03:00.120
di accedere alla variabile di istanza per
ottenere l'istanza del database senza
volatilità.

35
03:00.120 --> 03:06.850
Senza l'annotazione volatile, il thread A
legge l'istanza come nulla e

36
03:06.850 --> 03:08.770
inizia a inizializzare il database prima
che il thread A finisca.

37
03:08.800 --> 03:09.610
Filetto B.

38
03:09.640 --> 03:18.070
Inoltre, leggendo l'istanza come null e
poiché il valore non è stato aggiornato
nella cache, entrambi

39
03:18.100 --> 03:24.970
i thread finiscono per creare istanze
separate del database, vanificando lo
scopo di avere un singleton.

40
03:24.970 --> 03:27.160
Abbiamo quindi due fili.

41
03:27.190 --> 03:34.870
Due thread cercano di creare istanze di
database e alla fine abbiamo

42
03:34.870 --> 03:39.880
due database, due versioni diverse di
database, due istanze di database.

43
03:39.880 --> 03:47.860
Questo ci impedirà di avere un unico
database per

44
03:47.860 --> 03:48.340
la nostra applicazione, utilizzando il
thread di annotazione volatile.

45
03:48.370 --> 03:56.230
A legge l'istanza come nulla e inizia a
inizializzare il

46
03:56.230 --> 03:58.510
database un thread A scrive l'istanza del
database inizializzata all'istanza.

47
03:58.510 --> 04:06.160
La parola chiave volatile assicura che
questa modifica sia immediatamente
visibile a tutti gli altri thread.

48
04:06.160 --> 04:14.440
Ad esempio, il thread B legge il valore
aggiornato dell'istanza e vede che

49
04:14.440 --> 04:17.260
il database è già inizializzato, impedendo
la creazione di una seconda istanza.

50
04:17.260 --> 04:26.590
In questo modo si impedisce al thread B di
creare un'altra istanza

51
04:26.590 --> 04:28.810
del nostro database, ottenendo così un
solo database per l'intera applicazione.

52
04:28.840 --> 04:37.270
Occorre quindi creare una nuova funzione,
chiamata get instance,

53
04:37.270 --> 04:39.820
per restituire un'istanza dell'oggetto
contesto fornito dal database.

54
04:39.850 --> 04:40.720
Nota.

55
04:40.750 --> 04:41.410
DB.

56
04:41.800 --> 04:50.950
Importare il contesto e all'interno di
questa funzione occorre restituire
l'inizializzazione dell'istanza, se non

57
04:50.950 --> 04:55.660
è ancora stata creata, oppure restituire
l'istanza del database, se è stata creata.

58
04:55.660 --> 05:02.050
Quindi dobbiamo usare la parola chiave
synchronized e dobbiamo usare questo
synchronized.

59
05:02.050 --> 05:06.340
E lo abbiamo passato nella creazione del
database della stanza.

60
05:06.340 --> 05:10.670
E assicurarsi che solo un thread possa
essere eseguito.

61
05:10.670 --> 05:16.190
Il blocco di codice all'interno del blocco
sincronizzato in qualsiasi momento è molto
importante.

62
05:16.220 --> 05:22.940
Questo è molto importante per evitare che
vengano create

63
05:22.970 --> 05:24.710
istanze multiple del database della stanza
in ambienti multi-thread.

64
05:24.710 --> 05:34.760
Abbiamo quindi usato la parola chiave
synchronized per eseguire il codice una
sola volta

65
05:34.760 --> 05:39.830
in un determinato momento, solo un thread
può accedere, creare ed eseguire questo
codice.

66
05:39.860 --> 05:47.570
All'interno di questo codice dobbiamo
creare una var instance uguale a instance
che abbiamo creato in precedenza.

67
05:47.600 --> 05:52.160
Occorre quindi verificare se questa
istanza è uguale a null.

68
05:52.160 --> 05:55.880
Quindi, se è nullo, si esegue questo
blocco di codice.

69
05:55.880 --> 06:01.490
Qui dobbiamo usare il nostro codice per
creare l'oggetto database.

70
06:01.490 --> 06:03.110
Tagliatelo e incollatelo qui.

71
06:03.110 --> 06:07.130
Qui si crea un'istanza dell'oggetto
database.

72
06:07.160 --> 06:12.500
Rimuovere la var e impostare questa
istanza sull'istanza creata qui.

73
06:12.500 --> 06:17.660
Quindi, ragazzi, se il database è nullo,
andate a crearne uno.

74
06:17.660 --> 06:26.060
Altrimenti, restituire l'istanza come
istanza e restituire l'istanza in entrambi
i casi.

75
06:26.060 --> 06:30.830
Qui abbiamo un errore richiesto database
camera trovato note db.

76
06:30.860 --> 06:35.840
Se saliamo possiamo notare che si tratta
di un'annotazione di database.

77
06:35.840 --> 06:41.750
Inoltre, è necessario estendere il
database della stanza.

78
06:41.780 --> 06:49.490
Ok, in questo modo diciamo ad Android
Studio che il DB delle note

79
06:49.490 --> 06:51.770
fungerà da database con queste entità e si
estenderà dal database della stanza.

80
06:51.800 --> 06:55.100
Ok, questo è il modello di progettazione
dei singleton.

81
06:55.100 --> 06:57.500
In questo modo si crea un oggetto
companion.

82
06:57.500 --> 07:06.020
In questo modo si crea un'istanza del
database della stanza e si accede a un
solo thread in qualsiasi momento