-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lifecycle support in dagger 2 #652
Comments
As for other DI libs, autofac has a similiar mechanics: http://autofac.readthedocs.io/en/latest/lifetime/disposal.html And Spring |
Unity: https://msdn.microsoft.com/en-us/library/ff660872(v=pandp.20).aspx (HierarchicalLifetimeManager) It is very necessary feature. |
I am looking for a similar feature. On top of that, imagine you have many objects depending on the same Closeable resource. Proper closure is not straight forward. |
Support for instance lifecycle events seems quite important. There are objects that refer precious resources i.e. open sockets,background threads. Those need disposal possibly aligned with a particular submodule/scope. So at minimum I would hope that I realize that such change is a complex one to maintain compatibility with current API etc. This is also important one. Dagger 2 looks immature lacking this simplest of mechanisms. It is also quite ugly (1) to maintain references to closeable objects in some external utility that will externally take care, (2) not be able to leverage Java language syntax for try with resources when working with short lived scopes. |
I think this is a difficult feature to support, and when we had a similar feature (releasable references), it was barely used (only 1 internal usage, and not even correctly). If I wanted to do something like this, I'd recommend just How does that sound? I'd be happy to help review an extension library to do this. |
@ronshapiro we're using this approach, the main downsides are:
|
Leaving this open but marking it as P3. While the One of the main downsides of supporting something like this is that I think it may add to the confusion about how Dagger works. Especially on Android, I see confusion thinking the component is destroyed when really it is just released and let to be GCed. I worry about people registering Also echoing the point before too that there was a releasable scopes feature a while ago that was similar and was used very little while adding a large amount of complexity to Dagger's internals. |
it would be nice if there were a |
I would like to discuss adding lifecycle support in dagger 2.
If the feature will be recognized useful I will proceed with a pull request.
We have a complex application with several scopes, and often components provide java.lang.Autoclosable/java.io.Closable objects, for example associated with database connections or files.
As for now, we have to track such objects manually and close them.
It would be very convinient and much more reliable to make AutoClosable dagger 2 components, which wold close all required objects when closed themselves.
Here is a raw idea how I would implement it:
The text was updated successfully, but these errors were encountered: