# Apostila Android

## Room Database Android

**Room** é uma das bibliotecas existentes dentro do conjunto “Android JetPack” apresentado durante o Google I/O de 2018, ela auxilia os desenvolvedores criando uma abstração das camadas de banco de dados (SQLite).

Suas camadas são representadas por três componentes:
* Entity
* Dao
* Database

### Entity:
São entidades responsáveis por mapear as tabelas. Representa uma tabela dentro do banco de dados. **Room** cria uma tabela para cada classe que possui `@Entity` anotação; os campos da classe correspondem às colunas da tabela. Portanto, as classes de entidade tendem a ser pequenas classes de modelo que não contêm nenhuma lógica.

@Entity(tableName = "user")data class User(@PrimaryKey val uuid: String, var name: String, 
@ColumnInfo(name = "user_age") var age: Int, 
@Embedded(prefix = "user_") val phone: Phone) data class Phone(
@ColumnInfo(name = "country_code") val countryCode: Int, val number: String)

#### Anotações de entidades
Antes de começarmos a modelar nossas entidades, precisamos conhecer algumas anotações úteis e seus atributos:

* **@Entity** - toda classe de modelo com esta anotação terá uma tabela de mapeamento no DB
* chaves estrangeiras - nomes de chaves estrangeiras
* índices - lista de indicadores na tabela
* primaryKeys - nomes das chaves primárias da entidade
* Nome da tabela
* **@PrimaryKey** - como o nome indica, esta anotação aponta a chave primária da entidade. autoGenerate - se definido como true, o SQLite gerará um ID exclusivo para a coluna

@PrimaryKey(autoGenerate = true)

* **@ColumnInfo** - permite especificar informações personalizadas sobre a coluna

@ColumnInfo(name = “column_name”)

* **@Ignore** - o campo não será mantido pelo quarto
* **@Embeded** - os campos aninhados podem ser referenciados diretamente nas consultas SQL.

### Dao (Data Access Object):
São as interfaces utilizadas para acessar os dados armazenados no banco. É possivel criar Querie’s personalizadas para os select’s, insert’s, delete’s e update’s. Os DAOs são responsáveis por definir os métodos que acessam o banco de dados. No SQLite inicial, usamos os Cursor objetos. Com o Room, não precisamos de todo o Cursor código relacionado e podemos simplesmente definir nossas consultas usando anotações na Dao classe.

@Dao
	interface UserDao {
	
	    @Query("SELECT * FROM user") fun getAllUsers(): List<User>

	    @Insert(onConflict = OnConflictStrategy.REPLACE) fun insertUsers(vararg users: User)

	    @Update fun updateUser(user: User)

	    @Delete fun deleteUser(user: User)
	}

**Database**: é a representação da classe abstrata do Banco de Dados. Esta receberá uma anotação que irá identificar as Entities, os Dao’s e seus Converters. Ele será responsável por fazer o controle do banco de dados.

Contém o detentor do banco de dados e serve como o principal ponto de acesso para a conexão subjacente aos dados relacionais persistentes do seu aplicativo.

Para criar um banco de dados, precisamos definir uma classe abstrata que se estenda RoomDatabase. Essa classe é anotada com @Database, lista as entidades contidas no banco de dados e os DAOs que os acessam.

A classe anotada @Database deve atender às seguintes condições:

* Seja uma classe abstrata que se estenda RoomDatabase.
* Inclua a lista de entidades associadas ao banco de dados na anotação.
* Contém um método abstrato que possui 0 argumentos e retorna a classe anotada @Dao.

Em tempo de execução, você pode adquirir uma instância Database chamando Room.databaseBuilder() ou Room.inMemoryDatabaseBuilder().

@Database(version = 1, entities = arrayOf(User::class))
	abstract class AppDataBase : RoomDatabase() {
	    abstract fun userDao(): UserDao
	}

### Por que usar o Room?
* Verificação em tempo de compilação de consultas SQL. cada @Query e @Entity são verificados no momento da compilação, o que preserva seu aplicativo de problemas de falha no tempo de execução e não apenas verifica a única sintaxe, mas também as tabelas ausentes.
* Código padrão
* Facilmente integrado a outros componentes da arquitetura (como o LiveData)

### Os principais problemas com o uso do SQLite são:
* Não há verificação em tempo de compilação de consultas SQL brutas. Por exemplo, se você escrever uma consulta SQL com um nome de coluna errado que não existe no banco de dados real, ela abrirá uma exceção durante o tempo de execução e não será possível capturar esse problema durante o tempo de compilação.
* À medida que o seu esquema muda, você precisa atualizar as consultas SQL afetadas manualmente. Esse processo pode ser demorado e propenso a erros.
* Você precisa usar muito código padrão para converter entre consultas SQL e objetos de dados Java (POJO).

### Room vs SQLite
Room é uma biblioteca ORM, Object Relational Mapping. Em outras palavras, o Room mapeará nossos objetos de banco de dados para objetos Java. O Room fornece uma camada de abstração sobre o SQLite para permitir acesso fluente ao banco de dados enquanto aproveita todo o poder do SQLite.

Diferença entre a biblioteca de persistência SQLite e Room:
* No caso do SQLite, não há verificação em tempo de compilação de consultas SQLite brutas. Mas no room, há validação SQL em tempo de compilação.
* Você precisa usar muito código padrão para converter entre consultas SQL e objetos de dados Java. Mas, o Room mapeia nossos objetos de banco de dados para o Java Object sem o código padrão.
* À medida que o seu esquema muda, você precisa atualizar as consultas SQL afetadas manualmente. Room resolve esse problema.
* O Room foi criado para trabalhar com o LiveData e o RxJava para observação de dados, enquanto o SQLite não.

### Componentes do Room DB

###### tags: `android` `apostila`