android.arch.persistence.room

Rather than hiding the detail of SQLite, Room tries to embrace them by providing convenient APIs to query the database and also verify such queries at compile time. This allows you to access the full power of SQLite while having the type safety provided by Java SQL query builders.

There are 3 major components in Room.

• Database: This annotation marks a class as a database. It should be an abstract class that extends RoomDatabase. At runtime, you can acquire an instance of it via Room.databaseBuilder or Room.inMemoryDatabaseBuilder.

  This class defines the list of entities and data access objects in the database. It is also the main access point for the underlying connection.

• Entity: This annotation marks a class as a database row. For each Entity, a database table is created to hold the items. The Entity class must be referenced in the Database#entities array. Each field of the Entity (and its super class) is persisted in the database unless it is denoted otherwise (see Entity docs for details).
• Dao: This annotation marks a class or interface as a Data Access Object. Data access objects are the main component of Room that are responsible for defining the methods that access the database. The class that is annotated with Database must have an abstract method that has 0 arguments and returns the class that is annotated with Dao. While generating the code at compile time, Room will generate an implementation of this class.

       Using Dao classes for database access rather than query builders or direct queries allows you
       to keep a separation between different components and easily mock the database access while
       testing your application.
       

 // File: User.java
 @Entity
 public class User {
   @PrimaryKey
   private int uid;
   private String name;
   @ColumnInfo(name = "last_name")
   private String lastName;
   // getters and setters are ignored for brevity but they are required for Room to work.
 }
 // File: UserDao.java
 @Dao
 public interface UserDao {
   @Query("SELECT * FROM user")
   List<User> loadAll();
   @Query("SELECT * FROM user WHERE uid IN (:userIds)")
   List<User> loadAllByUserId(int... userIds);
   @Query("SELECT * FROM user where name LIKE :first AND last_name LIKE :last LIMIT 1")
   User loadOneByNameAndLastName(String first, String last);
   @Insert
   void insertAll(User... users);
   @Delete
   void delete(User user);
 }
 // File: AppDatabase.java
 @Database(entities = {User.java})
 public abstract class AppDatabase extends RoomDatabase {
   public abstract UserDao userDao();
 }
 

 AppDatabase db = Room
     .databaseBuilder(getApplicationContext(), AppDatabase.class, "database-name")
     .build();
 

You can observe a particular table for changes using the InvalidationTracker class which you can acquire via RoomDatabase.getInvalidationTracker.

For convenience, Room allows you to return LiveData from Query methods. It will automatically observe the related tables as long as the LiveData has active observers.

 // This live data will automatically dispatch changes as the database changes.
 @Query("SELECT * FROM user ORDER BY name LIMIT 5")
 LiveData<User> loadFirstFiveUsers();
 

You can also return arbitrary Java objects from your query results as long as the fields in the object match the list of columns in the query response. This makes it very easy to write applications that drive the UI from persistent storage.

 class IdAndFullName {
     public int uid;
     @ColumnInfo(name = "full_name")
     public String fullName;
 }
 // DAO
 @Query("SELECT uid, name || lastName as full_name FROM user")
 public IdAndFullName[] loadFullNames();
 

Please see the documentation of individual classes for details.

Annotations

Classes

Enums

Exceptions