h4. Update
I have done research for the work. Currently our SDK is implementing similar approach to Dagger2. We
I posted some attempts to spike that at the moment it as part of the :
https://github.com/ secondsun/ aerogear -android-sdk / pull/1
Alternative, in-house option is done as part of the
https://github.com/ aerogear /aerogear -android-sdk/pull/2
h4. Moving to dagger
TL;DR - My take here is that dagger is perfect for end user application but terrible choice for library.
Moving to dagger is not possible at the moment: and will not provide any benefit.
- we do not have enough services like httpd Library is designed where injectors need to connected with providers on top level application.
This will complicate user api as they will need to provide local bindings.
- Unable to provide Dagger Components on runtime complicates setup.
Integration is done on compilation level. I could not manage to get that running with the library aproach.
- current solution will require some refactoring to get that and this may interfere with current work we doing .
h4. Migration Proposed solution
Migration will require replacing our current dependency mechanism with While I do not recommend dagger .
We should create modules for http, logging, storage etc and make them available as top level application component.
I have spiked that would like to spike Interface based aproach on sample application:
https://github . com/googlesamples/android-architecture-components/tree/master/GithubBrowserSample
Our core gradle module should export modules. To do
This will be alternative that users will need simplify user setup to register core as part of their application. something like this:
[Dagger modules| https:// raw gist . githubusercontent github .com/ codepath wtrocki / android_guides/master/images/dagger_general.png] 5774f883a9a2ae0b33c5aa63986cae45
|
|
