Pro Android with Kotlin

122
CHAPTER 8: APIs
In this example, we declare three DAOs for use by Room. For the actual implementation, we 
don’t need fully fledged DAO classes. It is enough to declare interfaces or abstract classes, 
and Room will do the rest for us.
The DAO classes, for example, for the following entity:
@Entity
data class Employee(
@PrimaryKey(autoGenerate = true) var uid:Int = 0,
@ColumnInfo(name = "first_name") var firstName:String,
@ColumnInfo(name = "last_name") var lastName:String)
might look like this:
@Dao
interface EmployeeDao {
@Query("SELECT * FROM employee")
fun getAll(): List
@Query("SELECT * FROM employee" +
" WHERE uid IN (:uIds)")
fun loadAllByIds(uIds: IntArray): List
@Query("SELECT * FROM employee" +
" WHERE last_name LIKE :name")
fun findByLastName(name: String): List
@Query("SELECT * FROM employee" +
" WHERE last_name LIKE :lname AND " +
" first_name LIKE :fname LIMIT 1")
fun findByName(lname: String, fname: String): Employee
@Query("SELECT * FROM employee" +
" WHERE uid = :uid")
fun findById(uid: Int): Employee
@Insert
fun insert(vararg employees: Employee): LongArray
@Update
fun update(vararg employees: Employee)
@Delete
fun delete(vararg employees: Employee)
}
You see that we used an interface here, which is possible because the complete access 
logic is defined by method signatures and annotations. Also, for insert, update, and 
delete, the method signature is all that Room needs; it will send the right commands to the 
database just by looking at the signatures.

---

123
CHAPTER 8: APIs
For the various query methods, we use @Query annotations to provide the correct database 
commands. You can see that Room is smart enough to see whether we want to return a list 
of objects or a single object. Also, we can pass method arguments into the pseudo-SQL by 
using :name identifiers.
The @Insert annotation allows for adding the attribute onConflict = "" where 
you can specify what to do if a conflict occurs because a unique or primary key constraint is 
violated. Possible values for the  are given inside constants:

OnConflictStrategy.ABORT to abort the transaction

OnConflictStrategy.FAIL to fail the transaction

OnConflictStrategy.IGNORE to ignore the conflict

OnConflictStrategy.REPLACE to just replace the entity and otherwise 
continue the transaction

OnConflictStrategy.ROLLBACK to roll back the transaction
The other DAOs from the example entities used earlier will look similar. PersonDao might do 
outer joins to combine the employee and contact entities:
@Dao
interface ContactDao {
@Insert
fun insert(vararg contacts: Contact)
@Query("SELECT * FROM Contact WHERE uid = :uId")
fun findById(uId: Int): List
@Query("SELECT * FROM Contact WHERE" +
" employeeId = :employeeId")
fun loadByEmployeeId(employeeId: Int): List
}
data class Person(@Embedded var name:Name?,
var emailAddr: String?)
@Dao
interface PersonDao {
@Query("SELECT * FROM empl" +
" LEFT OUTER JOIN Contact ON" +
" empl.uid = Contact.employeeId" +
" WHERE empl.uid = :uId")
fun findById(uId: Int): List
}
Observable Queries
In addition to performing a query with returning entities or lists or arrays of entities as they 
are at the moment when the query happens, it is also possible to retrieve the query result 
plus register an observer that gets invoked when the underlying data change.

---