DEV Community

Alex
Alex

Posted on

Parameter Injection for Android ViewModels

Injecting dependencies into our ViewModel is already a good practice, it keeps the implementation flexible and easy to test.

But what about parameters provided to the screen or Fragment? For example Fragment Args or Compose navigation parameters. Often something like an init method is used to receive the parameters from the View and setup the ViewModel. This adds extra steps to our ViewModel we needs to be aware of. Therefore it would be more favourable to, not only get the dependencies, but also the parameters in the constructor.

Setup

For this example let's keep it simple and focus mainly on the handling of the parameter.

We create an App with two screens.

  1. Screen 1 is just a button. Tapping it gets a random number and navigates to Screen 2, handing the random number over as parameter.

Random Button

  1. Screen 2 receives the random number, creates a View State and simply displays the result as a text.

Fancy result

The screens are created with Jetpack Compose and the example also uses Composes NavHost to navigate, but the same ViewModel code applies for the use of Activities and Fragments. The only difference are the types allowed to be used as parameter. We can see in the following setup, Compose Navigation only allows us to pass parameters as part of the navigation route String.



val navController = rememberNavController()
NavHost(
    navController = navController,
    startDestination = "home
) {
    composable(route = "home") {
        HomeScreen {
            navController.navigate("details/$it")
        }
    }
    composable(route = "details/{randomNumber}") {
        val viewModel = viewModel<DetailsFlowViewModel>()
        DetailsScreen(viewModel = viewModel)
    }
}


Enter fullscreen mode Exit fullscreen mode

As we can see our second screen has the route details/{randomNumber} declaring the parameter randomNumber.

Handle a saved state

Now to the important question. How can we retrieve the parameter in our ViewModel on the second screen after navigation?

The SavedStateHandle class contains the information we need and it is directly injectable into the constructor of a ViewModel.



class DetailsFlowViewModel(
    savedStateHandle: SavedStateHandle
) : ViewModel() {
    ...
}


Enter fullscreen mode Exit fullscreen mode

This is possible with or without the help of a dependency injection framework like Hilt.

SavedStateHandle provides us with two methods to get to our parameter



operator fun <T> get(key: String): T?


Enter fullscreen mode Exit fullscreen mode


fun <T> getStateFlow(key: String, initialValue: T): StateFlow<T>


Enter fullscreen mode Exit fullscreen mode

Depending on what we want to achieve we can use either method. In our case we want to offer a View State flow from our ViewModel to the UI, therefore let's use getStateFlow.



class DetailsFlowViewModel(
    savedStateHandle: SavedStateHandle
) : ViewModel() {
    val state: Flow<DetailsState> = savedStateHandle
        .getStateFlow<String?>("randomNumber", null)
        .map {
            val number = it?.toIntOrNull() ?: throw IllegalArgumentException("You have to provide randomNumber as parameter of type Int when navigating to details")

            // call dependencies as needed
            val result = "Fancy processing: $number"
            DetailsState(result)
        }
}


Enter fullscreen mode Exit fullscreen mode

Important: Since we are using Compose Navigation we first have to retrieve the parameter as a String before we can convert it to its actual type Int. With Fragment Args it would be possible to directly get the parameter as an Int.

One step further

We can already provide our parameter directly to the ViewModels constructor. But there is still a drawback: The ViewModel constructor does not tell us exactly what it wants, but e.g. in tests we need to know to set randomNumber of type String to the SavedStateHandle before passing it to the constructor. Sounds like it requires a lot of knowledge of implementation details.

Wouldn't it be better if the constructor just tells us: I want to have the parameter randomNumber of type Int.

With the help of dependency injection frameworks like Hilt we can achieve this.

To keep it short I'm not going in to details on the basic usage of Hilt in this post. In case you want to read up on Hilt you can go to its Android Developers tutorial

First we create a Qualifier annotation, allowing us to identify our parameter to Hilt.



@Qualifier
@Retention(AnnotationRetention.BINARY)
annotation class RandomNumber


Enter fullscreen mode Exit fullscreen mode

With the Qualifier RandomNumber we can create a small Hilt module, providing our parameter in a ViewModel scope.



@Module
@InstallIn(ViewModelComponent::class)
object DetailsModule {
    @Provides
    @RandomNumber,
    @ViewModelScoped
    fun provideRandomNumber(savedStateHandle: SavedStateHandle): Int =
        savedStateHandle.get<String>("randomNumber")?.toIntOrNull()
            ?: throw IllegalArgumentException("You have to provide randomNumber as parameter with type Int when navigating to details")
}


Enter fullscreen mode Exit fullscreen mode

We install the module in ViewModelComponent making the parameter available for the lifetime of the ViewModel it is injected in. The actual provideRandomNumber method is basically the code we had in the ViewModel earlier, with one difference. We don't use a Flow, but get the value directly.

With the module our ViewModel becomes really simple.



@HiltViewModel
class DetailsHiltViewModel @Inject constructor(
    @RandomNumber randomNumber: Int
) : ViewModel() {
    override val state: Flow<DetailsState> = flow {
        // call dependencies as needed
        val result = "Fancy processing: $randomNumber"
        emit(DetailsState(result))
    }
}


Enter fullscreen mode Exit fullscreen mode

We ask for the parameter we want, using the Qualifier and simply use it to create our View State.

Conclusion

Using parameter injection like shown in this post, does require a little bit more code than injecting a SavedStateHandle or creating an init method, but it separates the different aspects of our app better, allowing for a more readable and testable code.

The whole example with different variants using the SavedStateHandle, Hilt and an Activity can be found on GitHub

In case you are wondering, the same concept can be achieved using Koin as well.

See you in the next one πŸ‘‹

Top comments (0)