Parameter Injection for Android ViewModels
Tags: android, programming, mobile, kotlin
Published: 2022-08-23 07:45:24

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](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/27lccwdrj64exis6nigq.png)

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

![Fancy result](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mh5bq862znh98bylgx2m.png)

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.

```Kotlin
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)
    }
}
```

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.

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

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

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

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

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**.

```Kotlin
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)
        }
}
```

> **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](https://developer.android.com/training/dependency-injection/hilt-android)

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

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

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

```Kotlin
@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")
}
```

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.

```Kotlin
@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))
    }
}
```

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](https://github.com/a-frank/viewmodel-parameters)

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

See you in the next one :wave: