This Tutorial Series is divided into 3 Parts.

  1. Introduction and Project Setup
  2. MVVM concept and coding
  3. Simple Unit Testing

This is the part 2 of the tutorial, you can check the part 1 here: Link to Part 1 if you haven’t read it yet.

MVVM stands for Model-View-ViewModel. Below is a diagram that shows the flow of the MVVM architecture using a Room Database. We will also follow this diagram and discuss each component as we create our classes for our Parcel Tracker App.

mvvm room diagram
Image Source: Google Code Labs -


Components that is responsible for handling the data for an app. In Android using Room Persistence Library with its 3 major components could already compose the model structure for the app which is Entity, Dao, and Database.


It represents the table and fields of the database. Let’s check our database table using SQLite Browser before we make our Entity class.

blog1 parcelTableFields

Now base on the table and fields here let’s create now our Entity class inside model folder and we will call it ParcelEntity.kt since our table name is also called Parcel.


@Entity(tableName = "Parcel")
data class ParcelEntity(
    @PrimaryKey(autoGenerate = true) @ColumnInfo(name = "event_id") @NotNull val event_id: Int,
    @ColumnInfo(name = "tracking_num") @NotNull val tracking_num: Int,
    @ColumnInfo(name = "status") val status: String?,
    @ColumnInfo(name = "date_time") val date_time: Int,
    @ColumnInfo(name = "location") val location: String?,


DAO stands for Data Access Object that contains methods used for accessing the database which also known as CRUD(Create Read Update Delete). Since the aim for this app is to make it simple but still having to learn the concept of MVVM, we will just gonna use Read for now by using Query. Let’s start by making our DAO class and named it ParcelDao.kt inside model folder.


interface ParcelDao {
    @Query("SELECT * FROM Parcel WHERE tracking_num = :tracking_num ORDER BY date_time")
    fun getParcelStatusByTrackingNum(tracking_num: Int): LiveData<List<ParcelEntity>> //Use LiveData to run the query asynchronously and get results via observer pattern

Like our Entity class we also use some annotation here like @Dao and @Query so our Room Database will be able to generate an implementation of this class at compile-time when it is referenced by it. Dao class should either be an interface or an abstract. Here we use a simple sql statement on our method to query the results if a tracking number match from the table and will also sort it by the date_time field that is ascending order by default.


Database is an organized collection of data, generally stored and can be manage and access in different ways. Let’s create our database class and named it ParcelTrackerDatabase.kt still inside the model folder.


@Database(entities = [ParcelEntity::class], version = 1, exportSchema = false)
abstract class ParcelTrackerDatabase  : RoomDatabase() {
    abstract fun parcelDao(): ParcelDao

    companion object{
        // Singleton prevents multiple instances of database opening at the
        // same time as each RoomDatabase instance is fairly expensive,
        // and you rarely need access to multiple instances within a single process

        private var instance: ParcelTrackerDatabase? = null

        const val DB_NAME = "CopiedParcelTracker.db"
        fun getDatabase(context: Context): ParcelTrackerDatabase
            return instance ?: synchronized(this)
                val dbInstance =  Room.databaseBuilder(context.applicationContext, , DB_NAME)
                    //.addMigrations(MIGRATION) // do migration if you want to get the updated prepopulated database
                instance = dbInstance


You should also take note the comment in the code where we must make it a singleton to prevent multiple instances of database opening at same time. We also need to annotate it with @Database to mark the class as a Room Database.

Did you notice that we have two different database names? InitialParcelTracker.db and CopiedParcelTracker.db What happens here is that when we use createFromAsset from Room DatabaseBuilder, it will just copy the one we put on our assets/database folder and generate a new database inside our app that we named it CopiedParcelTracker.db, this copy is what our app will going to use for different database transactions. If we already initialize our database we can use a tool in android studio which is Device File Explorer to see if it’s there, it should be copied to the path data/data/[app package name]/databases/ like shown in the image.

blog1 deviceExplorer

We are done doing our Model Component, with just that we can even have a working app just by initializing our database in the activity and use it but that would ruined our MVVM architecture, let’s continue and make the other components for it.


It is a class use for managing queries and allows you to use multiple data sources. Repository implements the logic for deciding whether to fetch data from a network or use results cached in the local database. Let’s create our class and name it ParcelTrackerRepository.kt inside repository folder.


//Pass in the DAO instead of the whole database, because you only need access to the DAO
//Normally we use custom annotate @OpenForTesting see
open class ParcelTrackerRepository private constructor(private val parcelDao: ParcelDao) {

    companion object{
        private var instance: ParcelTrackerRepository? = null

        fun getInstance(parcelDao: ParcelDao) : ParcelTrackerRepository
            return instance ?: synchronized(this){
                instance ?: ParcelTrackerRepository(parcelDao).also { instance = it }

    open fun getParcelStatusByTrackingNum(tracking_num: Int): LiveData<List<ParcelEntity>> {
        return parcelDao.getParcelStatusByTrackingNum(tracking_num)


Here we also made this to a Singleton as we just only need one instance for repository. We make it an open class so we can use it for our Unit Testing in part 3 but usually we can use a custom annotation for that so it would work only during our development. You may notice also it is kinda redundant on what our DAO class can do but trust me they have each own role, it is just not obvious in our app as it is simple and only have a single method. For bigger apps a repository can have multiple DAO or reference to a web api to handle the logic for the data. If an app gonna use a webservice using retrofit and a local database, the app diagram would look like the diagram below.

Image Source: Android Developers -


The View Model is a class that provides the data for a specific UI component, such as a fragment or activity and survive configuration changes. It acts as a communication center between the repository and the view. It transforms inputs to data so model will be able to store or update it. It should not know if any view subscribes to it and should not have any references from the view. Let’s create our class and named it ParcelTrackerViewModel.kt inside viewmodel folder.


//Normally we use custom annotate @OpenForTesting see
open class ParcelTrackerViewModel(private val parcelTrackerRepository: ParcelTrackerRepository): ViewModel()
    var trackingNumber = MutableLiveData<Int>()

    open fun getParcelStatus(): LiveData<List<ParcelEntity>> {
        return Transformations.switchMap(trackingNumber){
                trackNoInput ->

    fun setTrackingNum(trackingNo_input: Int)
        trackingNumber.value = trackingNo_input

Like in our Repository class we will make it open so we can use it for Unit Testing as the default modifier in kotlin is final. We also need to make a custom View Model Factory since we have a repository parameter in our View Model constructor, we will use this View Model Factory later when we initialize our view model into our view or activity. Let’s name it ParcelTrackerViewModelFactory.kt inside viewmodel folder.


class ParcelTrackerViewModelFactory(private val context: Context) : ViewModelProvider.Factory {

    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        if (modelClass.isAssignableFrom( {
            val repository = ParcelTrackerRepository.getInstance(ParcelTrackerDatabase.getDatabase(context).parcelDao())
            return ParcelTrackerViewModel(repository) as T
        throw IllegalArgumentException("Unknown ViewModel class")


The simplest explanation for this is view is the UI(User Interface) or which our naked eye can see in our app. In Android this is commonly from fragments or activity. Let’s now modify our MainActivity.kt and use the ParcelTrackerViewModel to observe the result and bind it into a textview.


class MainActivity : AppCompatActivity() {

    lateinit var viewModel: ParcelTrackerViewModel

    override fun onCreate(savedInstanceState: Bundle?) {

        //initialize viewModel
        val factory = ParcelTrackerViewModelFactory(this)
        viewModel = ViewModelProvider(this,factory).get(

        //initialize ui reference
        val etxtTrackNum = findViewById<EditText>(
        val txtResult = findViewById<TextView>(
        val btnTrack = findViewById<Button>(

        btnTrack.setOnClickListener(View.OnClickListener {
            val trackNum = etxtTrackNum.text.toString()
            if (trackNum != "") {
                    .observe(this, Observer { results ->

                        val stringBuilder = StringBuilder()
                        results.forEach {parcelEntity ->

                            //Normally we use a TypeConverter class for such datetime fields
                            val sdf = SimpleDateFormat("yyyy-MM-dd HH:mm")
                            sdf.timeZone = TimeZone.getTimeZone("GMT")
                            val netDate = Date(parcelEntity.date_time.toLong() * 1000)
                            val date  = sdf.format(netDate)

                        //bind result to ui
                        txtResult.text = stringBuilder.toString()


Let’s run our app and check whether the result is same as the one with our prepopulated database. Let’s try to input a tracking number “3333” as an example and click the track button.

blog1 finalmvvmresult


We have finished our simple Parcel Tracker App, we learn how to use a Prepopulated Database using Room and also learn about the different components of MVVM and their role which helps us to separate business logic and UI to write much cleaner architecture. In the final part of tutorial series we will make a simple Unit Testing and get to know why it is important. Part 3 Tutorial

Buy Me A Coffee


  • Loading...