Using Room Database | Android Jetpack

For dem af jer, der ikke ved, hvad Android Jetpack er, så

Android Jetpack er en samling af Android-softwarekomponenter, der gør det nemmere for dig at udvikle gode Android-apps.
De vil hjælpe dig med at

• Følge bedste praksis
• Fri dig fra at skrive boilerplate-kode.
• Forenkle komplekse opgaver, så du kan fokusere på den kode, du holder af.

Her er videoen fra Android Developers Channel:

Nu skal vi tale om Room

Room er et persistensbibliotek, der er en del af Android Jetpack.

Her er videoen fra Android Developers Channel:

Room giver et abstraktionslag over SQLite for at muliggøre flydende databaseadgang og samtidig udnytte den fulde styrke af SQLite.

Room anses nu for at være en bedre tilgang til datapersistens end SQLiteDatabase. Det gør det nemmere at arbejde med SQLiteDatabase-objekter i din app, hvilket mindsker mængden af boilerplate-kode og verificerer SQL-forespørgsler på kompileringstidspunktet.

• Kompileringstidskontrol af SQL-forespørgsler. hver @Query og @Entity kontrolleres på kompileringstidspunktet, hvilket bevarer din app fra nedbrudsproblemer på køretid, og ikke kun den kontrollerer kun syntaksen, men også manglende tabeller.
• Boilerplate-kode
• Let integreret med andre Architecture-komponenter (som LiveData)

Største problemer med SQLite-brug er

• Der er ingen kompileringstidskontrol af rå SQL-forespørgsler. Hvis du f.eks. skriver en SQL-forespørgsel med et forkert kolonnenavn, der ikke findes i den rigtige database, vil den give en undtagelse under kørselstiden, og du kan ikke fange dette problem under kompileringstiden.
• Som dit skema ændres, skal du opdatere de berørte SQL-forespørgsler manuelt. Denne proces kan være tidskrævende og fejlbehæftet.
• Du skal bruge masser af boilerplate-kode til at konvertere mellem SQL-forespørgsler og Java-dataobjekter (POJO).

Room vs SQLite

Room er et ORM, Object Relational Mapping-bibliotek. Med andre ord vil Room mappe vores databaseobjekter til Java-objekter. Room giver et abstraktionslag over SQLite for at muliggøre flydende databaseadgang, samtidig med at den fulde styrke af SQLite udnyttes.

Forskellen mellem SQLite og Room persistensbibliotek:-

• I tilfældet SQLite er der ingen kompileringskontrol af rå SQLite-forespørgsler. Men i Room er der SQL-validering på kompileringstidspunktet.
• Du er nødt til at bruge masser af boilerplate-kode til at konvertere mellem SQL-forespørgsler og Java-dataobjekter. Men Room kortlægger vores databaseobjekter til Java-objekter uden boilerplate-kode.
• Når dit skema ændres, skal du opdatere de berørte SQL-forespørgsler manuelt. Room løser dette problem.
• Room er bygget til at arbejde sammen med LiveData og RxJava til dataobservation, mens SQLite ikke gør det.

Komponenter i Room DB

Room har tre hovedkomponenter i Room DB :

• Entity
• Dao
• Database

Entity

Repræsenterer en tabel i databasen. Room opretter en tabel for hver klasse, der har @Entity annotation, felterne i klassen svarer til kolonnerne i tabellen. Derfor har entitetsklasserne tendens til at være små modelklasser, der ikke indeholder nogen logik.

Entities annotationer

Hvor vi går i gang med at modellere vores entiteter, skal vi kende nogle nyttige annotationer og deres attributter.

@Entity – hver modelklasse med denne annotation vil have en mappingtabel i DB

• foreignKeys – navne på fremmednøgler
• indices – liste over angivelser på tabellen
• primaryKeys – navne på entitetens primære nøgler
• tableName

@PrimaryKey – som navnet antyder, denne annotation peger på enhedens primære nøgle. autoGenerate – hvis den er sat til true, genererer SQLite et unikt id for kolonnen

@PrimaryKey(autoGenerate = true)

@ColumnInfo – giver mulighed for at angive brugerdefinerede oplysninger om kolonnen

@ColumnInfo(name = "column_name")

@Ignore – feltet vil ikke blive persisteret af Room

@Embeded – indlejrede felter kan refereres direkte i SQL-forespørgsler.

Dao

DAO’er er ansvarlige for at definere de metoder, der har adgang til databasen. I den oprindelige SQLite bruger vi Cursor-objekterne. Med Room har vi ikke brug for al den Cursor-relaterede kode og kan blot definere vores forespørgsler ved hjælp af annotationer i Dao-klassen.

Database

Indeholder databaseholderen og tjener som hovedadgangspunkt for den underliggende forbindelse til din app’s persisterede, relationelle data.

For at oprette en database skal vi definere en abstrakt klasse, der udvider RoomDatabase. Denne klasse annoteres med @Database og indeholder en liste over de enheder, der er indeholdt i databasen, og de DAO’er, der har adgang til dem.

Klassen, der annoteres med @Database, skal opfylde følgende betingelser:

• Det skal være en abstrakt klasse, der udvider RoomDatabase.
• Inkluderer listen over enheder, der er tilknyttet databasen, i annotationen.
• Indeholder en abstrakt metode, der har 0 argumenter og returnerer den klasse, der er annoteret med @Dao.

På køretid kan du erhverve en instans af Database ved at kalde Room.databaseBuilder() ellerRoom.inMemoryDatabaseBuilder().

Trin 1: Tilføj Gradle-afhængigheder

1. For at tilføje det til dit projekt skal du åbne filen build.gradle på projektniveau og tilføje den fremhævede linje som vist nedenfor:

2. Åbn build.gradle-filen for din app eller dit modul, og tilføj afhængigheder:

Stræk 2: Opret en modelklasse

Room opretter en tabel for hver klasse annoteret med @Entity; felterne i klassen svarer til kolonnerne i tabellen. Derfor har entitetsklasserne tendens til at være små modelklasser, der ikke indeholder nogen logik. Vores Person-klasse repræsenterer modellen for dataene i databasen. Så lad os opdatere den for at fortælle Room, at den skal oprette en tabel baseret på denne klasse:

• Annoter klassen med @Entity og brug tableName-egenskaben til at angive navnet på tabellen.
• Sæt primærnøglen ved at tilføje @PrimaryKey-annotationen til de korrekte felter – i vores tilfælde er det brugerens ID.
• Sæt navnet på kolonnerne for klassens felter ved hjælp af @ColumnInfo(name = "column_name")-annotationen. Du er velkommen til at springe dette trin over, hvis dine felter allerede har det korrekte kolonnenavn.
• Hvis flere konstruktører er egnede, skal du tilføje annotationen @Ignore for at fortælle Room, hvilke der skal bruges og hvilke der ikke skal bruges.

Stræk 3: Opret Data Access Objects (DAO’er)

DAO’er er ansvarlige for at definere de metoder, der har adgang til databasen.

For at oprette en DAO skal vi oprette en grænseflade og annoteret med @Dao .

Stræk 4 – Opret databasen

For at oprette en database skal vi definere en abstrakt klasse, der udvider RoomDatabase. Denne klasse er annoteret med @Database, og den indeholder en liste over de enheder, der er indeholdt i databasen, og de DAO’er, der har adgang til dem.

Stræk 4: Håndtering af data

For at kunne håndtere dataene skal vi først og fremmest oprette en instans af databasen.

Dernæst kan vi indsætte slette og opdatere databasen.

Sørg for, at alle operationen skal udføres på en anden tråd. I mit tilfælde bruger jeg Executers (se her)

Query:

Insert:

Slet:

opdatering:

Udfører med Executer

Jeg har også linket en repo, hvis du har brug for at se et eksempel på Room Database.