Retained Dagger Component over Configuration Changes
If you write an Android Application and uses Dagger to inject dependencies to your Activities, chances are you do it like this:
This code works well and will run perfectly on most occasions. However, if your application somehow supports multiple orientations or any other things that trigger configuration changes, and if by any chances you don’t handle them manually (you let the system recreates your Activity), then when you try to access your dependencies (e.g. myDependency), you will not get the same instance when you access it after configuration changes happened.
Again, in many cases, it is still acceptable as you don’t need to persist data or state in those dependencies. However, in case you need to persist some data or state in those dependencies after configuration changes, then the code above will not work for you as it will always return a different instance every configuration changes.
Luckily, we now have a powerful version of Dagger called Hilt in Android. Hilt provides us with so many components and one of them can be used to solve this issue. The component that I mean is ActivityRetainedComponent. As the name suggest, putting dependencies under this component allow them to be retained when configuration changes happened, so that you will still get the same instances.
However, in reality, not all of our applications can just suddenly be plugged in with Hilt library and uses it. There are some reasons that may kept you from using Hilt in your project and ends up staying to use vanilla Dagger.
If you are using vanilla dagger and still wants to achieve a Dagger component that is retained over configuration changes, there is actually a way by utilizing Android’s ViewModel library.
We all know that Android ViewModel library can “survived” over configuration changes if used properly with the correct ViewModelProvider and ViewModelStoreOwner. And we also know that a Dagger component can be either an interface or an abstract class, as long as it is not a concrete class.
By combining these two knowledges, we can create a dagger component that behaves like Android’s ViewModel, so that it can “survived” over configuration changes.
As you can see from the code above, we now create our Dagger component as an abstract class that extends Android’s ViewModel rather than creating it as an interface. You may need to adjust some of the functions’ syntax to be compatible with an abstract class.
After making our Dagger component act like a ViewModel, we can now initialize our Dagger component just like how we initialize our usual ViewModel. The only difference is that we need to create a custom ViewModelProvider.Factory that creates and returns our dagger component. And with that factory, we can pass it as an argument to get Dagger component to ViewModelProvider.
After doing this, whenever you inject your Activity, the instances of the dependencies that you get will be the same even when configuration changes occurred, as long as you are scoping your dependencies to the component.
That is how you create a dagger component that can withstand configuration changes.
