Closed yschimke closed 2 years ago
We added ActivityRetainedLifecycle
only because there isn't an Android equivalent. For other cases, like for Activity, you can use the regular Lifecycle
class from androidx. You shouldn't need to do a downcast since one of the default bindings in Hilt is FragmentActivity
, so you can just inject that and grab the lifecycle off of it. In general, we prefer to keep Hilt as close to only dependency injection as possible and so we try not to add new concepts where we can help it.
@Chang-Eric Thanks, what is the situation for ServiceScoped?
I think you can use https://developer.android.com/reference/androidx/lifecycle/LifecycleService for services.
@Chang-Eric yep - I guess that is my question, do I need to manually call the lifecycle events from the Service (breaking DI?), or can the Service get passed into the provide function and I should cast it to a LifecycleService?
Ah, you can inject Service
into a provide function, but then would need to cast it to get the lifecycle.
Thanks, I now understand this section of the docs https://developer.android.com/training/dependency-injection/hilt-android#component-default
I've found ActivityRetainedLifecycle to be immensely useful for cleaning up things holding actual resources. A client of a bound service for example.
I'm wondering why it isn't supported for other scopes with obvious lifecycle - Application, Activity, Service (not sure this is as easy given the extra work for lifecycle-service).
Is it to avoid patterns of doing expensive work on shutdown, or it's expected that items in defined scopes are accessed only by clients aware of that lifecycle, and should put that explicitly in their onStop method?
Would it make sense to inject lifecycle instances with an annotation?
Is there another workaround here, like downcasting the ApplicationContext or ActivityContext and grabbing the lifecycle off that?