APIs
The subject of this chapter is to introduce APIs, which are the cornerstones of your app. The APIs include the following: Databases Scheduling Loaders Notifications Alarm Manager Contacts Search Framework Location and Maps
- PDF / 714,700 Bytes
- 76 Pages / 504 x 720 pts Page_size
- 54 Downloads / 211 Views
8
APIs The subject of this chapter is to introduce APIs, which are the cornerstones of your app. The APIs include the following: Databases Scheduling Loaders Notifications Alarm Manager Contacts Search Framework Location and Maps
Databases Android provides two realms for dealing with databases: either you use the SQLite library included in the Android OS, or you use the Room architecture component. The latter is recommended since it adds an abstraction layer between the database and the client, simplifying the mapping between Kotlin objects and database storage objects. You can find exhaustive information about SQLite in the online docs and lots of examples on the Web. In this book, we talk about Room since the separation of concerns induced by the abstraction helps you to write better code. Also, since Room helps to avoid boilerplate code, you can shorten your database code significantly if you use Room instead of SQLite.
© Peter Späth 2018 P. Späth, Pro Android with Kotlin, https://doi.org/10.1007/978-1-4842-3820-2_8
115
116
CHAPTER 8: APIs
Configuring Your Environment for Room Since Room is a support architecture component, you must configure it in your Android Studio build script. To do so, open the module’s build.gradle file (not the one from the project!) and on top level (not inside any of the curly braces) write the following: apply plugin: 'kotlin-kapt'
This is the Kotlin compiler plugin that supports annotation processing. In the dependencies section, write the following (on three lines; remove the newlines after implementation and kapt): // Room implementation "android.arch.persistence.room:runtime:1.0.0" kapt "android.arch.persistence.room:compiler:1.0.0"
Room Architecture Room was designed with ease of use in mind; you basically deal with three kinds of objects. Database: Represents a holder for the database. Talking in SQL language idioms, it contains several tables. To say it in a technologyagnostic way, a database contains several entity containers. Entity: Represents a table in the SQL world. To say it in a technologyagnostic way, this is a usage-centric aggregate of fields. An example would be an employee inside a company or a contact holding information about how to communicate with people or partners. Data Access Object (DAO): Contains the access logic to retrieve data from the database. It thus serves as an interface between the program logic and the database model. You often have one DAO per entity class but possibly more DAOs for various combinations. You could, for example, have an EmployeeDao and a ContactDao for the two employee and contact entities, as well as a PersonDao that combines the employee and the contacts information of a person.
The Database To declare a database, you write the following: import android.arch.persistence.room.* @Database(entities = arrayOf(Employee::class, Contact::class), version = 1) abstract class MyDatabase : RoomDatabase() { abstract fun employeeDao(): EmployeeDao
CHAPTER 8: APIs
117
abstract fun
Data Loading...
