Step #2: Getting and Using Our Repository

Ideally, an activity or fragment does not work directly with a repository. Instead, the ViewModel works with the repository, and the activity or fragment work with the ViewModel. The big benefit that we get from a ViewModel is that it is stable across configuration changes, so data that we have retrieved from the repository is not lost when the user rotates the screen and our activity/fragments are destroyed and recreated. Right now, that is not a big benefit, since our model objects are just held in memory. If it took network I/O to get those model objects, though… now caching that data becomes a lot more important. So, we will be switching to having the repository be something the ViewModel talks to.

That implies that RosterMotor will need access to the repository, and that RosterMotor will need to expose an API that our RosterListFragment can use in lieu of the fragment working directly with the repository.

Revise RosterMotor to look like this:

package com.commonsware.todo

import androidx.lifecycle.ViewModel

class RosterMotor(private val repo: ToDoRepository) : ViewModel() {
  val items = repo.items
}

Here, we get our ToDoRepository via the constructor. In our next step, Koin will be supplying our RosterMotor, and Koin will be able to give the motor its repository. We also expose the list of items, right now just by having a reference to the repository’s list of items. That part will change a lot later on, as we start moving towards having the to-do items in a database, but this will do for now.