Bird
Raised Fist0
Android Kotlinmobile~3 mins

Why Entity, DAO, Database classes in Android Kotlin? - Purpose & Use Cases

Choose your learning style10 modes available
The Big Idea

Discover how these classes turn messy data into a clean, easy-to-use system!

The Scenario

Imagine you want to save a list of your favorite books on your phone. You try to write all the data directly into files or remember it in your app without any structure.

Every time you want to add, find, or change a book, you have to search through messy data manually.

The Problem

Doing this by hand is slow and confusing. You might lose data or make mistakes because there is no clear way to organize or find your books.

It's like having a messy desk where you keep all your papers scattered and have to dig through them every time.

The Solution

Using Entity, DAO, and Database classes gives you a neat system to store and manage your data.

Entities represent your data items (like a book), DAOs are the helpers that know how to save and get data, and the Database class ties everything together safely and efficiently.

Before vs After
✗ Before
fun saveBook(title: String, author: String) {
  // Write to file manually
}
✓ After
@Entity
data class Book(@PrimaryKey(autoGenerate = true) val id: Int = 0, val title: String, val author: String)

@Dao
interface BookDao {
    @Insert
    fun insert(book: Book)
}

@Database(entities = [Book::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun bookDao(): BookDao
}
What It Enables

This system lets you easily add, find, update, and delete data without worrying about messy details.

Real Life Example

Think of a recipe app where you save your favorite recipes. Entities store each recipe, DAOs help you search or add new ones, and the Database keeps everything organized and safe.

Key Takeaways

Entities define what data looks like.

DAOs handle how to access and change data.

Database classes connect everything for smooth data management.

Practice

(1/5)
1. What is the main purpose of an Entity class in Android Room?
easy
A. To define the structure of a database table
B. To provide methods for database queries
C. To manage database connections
D. To handle UI updates

Solution

  1. Step 1: Understand the role of Entity

    An Entity class represents a table in the database by defining its columns and data types.
  2. Step 2: Differentiate from DAO and Database

    DAO provides query methods, and Database manages connections, so they are not the main purpose of Entity.
  3. Final Answer:

    To define the structure of a database table -> Option A
  4. Quick Check:

    Entity = Table structure [OK]
Hint: Entity = table layout definition in Room [OK]
Common Mistakes:
  • Confusing Entity with DAO
  • Thinking Entity manages database connections
  • Assuming Entity handles UI
2. Which of the following is the correct way to annotate a Kotlin data class as an Entity with a primary key named id?
easy
A. @Entity data class User(@PrimaryKey val id: Int, val name: String)
B. @Entity class User(val id: Int, val name: String)
C. @Entity(primaryKeys = ["id"]) data class User(val id: Int, val name: String)
D. @Entity data class User(val id: Int @PrimaryKey, val name: String)

Solution

  1. Step 1: Identify correct primary key annotation

    The primary key must be annotated with @PrimaryKey on the property inside the data class.
  2. Step 2: Check syntax correctness

    @Entity data class User(@PrimaryKey val id: Int, val name: String) correctly places @PrimaryKey before the id property in a data class annotated with @Entity.
  3. Final Answer:

    @Entity data class User(@PrimaryKey val id: Int, val name: String) -> Option A
  4. Quick Check:

    Primary key uses @PrimaryKey annotation [OK]
Hint: Use @PrimaryKey before property inside @Entity data class [OK]
Common Mistakes:
  • Placing @PrimaryKey after property name
  • Using primaryKeys parameter incorrectly
  • Missing @PrimaryKey annotation
3. Given the DAO interface below, what will be the return type of getAllUsers() when called?
 @Dao
 interface UserDao {
   @Query("SELECT * FROM user")
   fun getAllUsers(): List<User>
 }
medium
A. A Cursor object
B. A single User object
C. A list of User objects
D. A LiveData object

Solution

  1. Step 1: Analyze the DAO method signature

    The method getAllUsers() returns List<User>, which means a list of User objects.
  2. Step 2: Understand Room query return types

    Since the return type is explicitly List<User>, it returns a list, not a single object or LiveData.
  3. Final Answer:

    A list of User objects -> Option C
  4. Quick Check:

    Return type List<User> means list of users [OK]
Hint: Return type in DAO method shows data returned [OK]
Common Mistakes:
  • Confusing List<User> with LiveData
  • Expecting a single User instead of list
  • Thinking Room returns Cursor by default
4. Identify the error in the following Room database class:
 @Database(entities = [User::class], version = 1)
 abstract class AppDatabase : RoomDatabase() {
   abstract fun userDao(): UserDao

   companion object {
     fun getInstance(context: Context): AppDatabase {
       return Room.databaseBuilder(context, AppDatabase::class.java, "app_db").build()
     }
   }
 }
medium
A. Missing @Entity annotation on User class
B. No singleton pattern to prevent multiple database instances
C. Incorrect version number format
D. Database class should be an interface, not abstract class

Solution

  1. Step 1: Review database class structure

    The database class is abstract and correctly annotated with @Database and version number.
  2. Step 2: Check instance creation method

    The getInstance method creates a new database instance every time, lacking a singleton pattern to reuse one instance.
  3. Final Answer:

    No singleton pattern to prevent multiple database instances -> Option B
  4. Quick Check:

    Database instance should be singleton [OK]
Hint: Use singleton to avoid multiple database instances [OK]
Common Mistakes:
  • Not using singleton for database instance
  • Confusing abstract class with interface
  • Ignoring @Entity annotation on User
5. You want to create a Room database with two entities: User and Book. You also want to provide DAOs for both. Which is the correct way to define the database class?
hard
A. @Database(entities = [User::class, Book::class], version = 1) abstract class AppDatabase { abstract fun userDao(): UserDao abstract fun bookDao(): BookDao }
B. @Database(entities = [User::class], version = 1) abstract class AppDatabase : RoomDatabase() { abstract fun userDao(): UserDao abstract fun bookDao(): BookDao }
C. @Database(entities = [User::class, Book::class], version = 1) class AppDatabase { fun userDao(): UserDao fun bookDao(): BookDao }
D. @Database(entities = [User::class, Book::class], version = 1) abstract class AppDatabase : RoomDatabase() { abstract fun userDao(): UserDao abstract fun bookDao(): BookDao }

Solution

  1. Step 1: Check entities list in @Database annotation

    Both User and Book entities must be included in the entities array.
  2. Step 2: Verify class declaration and DAO methods

    The database class must be abstract and extend RoomDatabase, with abstract DAO methods.
  3. Final Answer:

    @Database(entities = [User::class, Book::class], version = 1) abstract class AppDatabase : RoomDatabase() { abstract fun userDao(): UserDao abstract fun bookDao(): BookDao } -> Option D
  4. Quick Check:

    Entities list and abstract class with DAO methods [OK]
Hint: Include all entities and extend RoomDatabase abstract class [OK]
Common Mistakes:
  • Omitting one entity from entities list
  • Not extending RoomDatabase
  • Making database class non-abstract
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard