0

Consider the following situation. I have an application scoped repository, dependent on a Retrofit client for supplying some of its resources. Retrofit on the other hand, because the API requires authentication, is dependent on an authentication key obtained from the shared preferences. The authentication key can be invalidated at any time. If the repository tries to make an unauthenticated request, the login activity is invoked. The login activity refreshes the authentication key and switches back to the home activity of the application. The problem which arises at this stage, is that only after the application is killed and restarted the Repository will be recreated, and thus the authentication key of the Retrofit client refreshed.

One inelegant solution would be, to change the scope of the repository from the application level to the activity level. However this would create unnecessary copies of the repository. Is there a way to refresh parts of the dependency tree? (Think something like an invalidate method on a singleton, setting its instance to null).

What is the general correct approach if only one object of a type is necessary in an application, but one of the dependencies of this object is fundamentally mutable? Should possibly mutable elements ever be injected?

Lukasz
  • 2,257
  • 3
  • 26
  • 44
  • Similar conversation from a while back about whether Dagger supports specific invalidation (it doesn't) and what to do instead: [Refreshing Dagger 2 instance from Android Application class](https://stackoverflow.com/questions/43138560/refreshing-dagger-2-instance-from-android-application-class) – Jeff Bowman Jan 10 '18 at 13:20
  • @JeffBowman Thanks for the link. So to recap, the general approach would be, not to scope those mutable elements and manage the instance creation inside the modules `@Provide` method. Is that correct? – Lukasz Jan 10 '18 at 14:24

0 Answers0