My team has adopted Dagger for dependency injection within our Android app and I must say that we love it so far. However, we want to make sure that we are using it efficiently. I was wondering if anyone can explain or if there is any documentation explaining the cases in which Dagger falls back to reflection for injecting dependencies?
相关问题
- How can I create this custom Bottom Navigation on
- Bottom Navigation View gets Shrink Down
- How to make that the snackbar action button be sho
- Listening to outgoing sms not working android
- How to create Circular view on android wear?
相关文章
- android开发 怎么把图片放入drawable的文件夹下
- android上如何获取/storage/emulated/下的文件列表
- androidStudio有个箭头不认识
- SQLite不能创建表
- Windows - Android SDK manager not listing any plat
- Animate Recycler View grid when number of columns
- Why is the app closing suddenly without showing an
- Android OverlayItem.setMarker(): Change the marker
Dagger's fall-back logic is embedded in its FailoverLoader class. It used to failover when it could not load a ModuleAdapter for a given module, but most recent releases will fail with an error if it cannot load a ModuleAdapter.
Currently, Dagger will fail-over if it cannot find an InjectAdapter class for a given type that needs injecting. The most common case is when you have an abstract parent of an injectable type, that has no @Inject fields. In this case, no InjectAdapter will have been created for it, and so when the concrete injectable type is loaded, it tries to lookup an adapter for the parent, cannot find one, and a reflective stand-in is created.
Similarly, if one does not run code-generation against classes that are decorated with @Inject fields or constructors, Dagger will fall-back to reflection for those as well. It's really the same logic as with the inheritance case above, it's just that inheritance is the only case that doesn't stem from a failure to run the code-generation.
As an aside, the Google fork at http://github.com/google/dagger currently generates adapters that handle their parent types without looking up an adapter for the parent (hard coded parent adapters), so this fail-over does not occur in the google fork. We haven't released the google fork to maven, as it's been nearly identical up until recently, but if failover logic in parent classes is an issue, you may wish to file an issue and ask for a release.