boilerplate code to calling classes • Leads to cluttered Presenters/Views/etc. • Mocking or changing dependencies is difficult • Ideally we’d want all instantiation of dependencies in centralized area
dependency injection framework developed by Google • Forked from Dagger which was created by Square (surprise!) • Group your dependency instantiation in “Modules”
dependency injection framework developed by Google • Forked from Dagger which was created by Square (surprise!) • Group your dependency instantiation in “Modules” • Provide scope to your dependencies using “Components”
Injected classes • Allow you to manage scope • Build the “dependency graph” out of only the modules you need for current state • Scoped dependencies will be reused if injected by same component instance
Injected classes • Allow you to manage scope • Build the “dependency graph” out of only the modules you need for current state • Scoped dependencies will be reused if injected by same component instance • Creating component in Activity#onCreate == new instances after config change
(~13% performance gain) • Less flexible • Almost perfect compile time checks • Runtime errors are rare and easily avoided • Easier to debug* Dagger 1 • More flexible • Object graphs aren’t typed • Potential for Runtime failures • Inject calls in super class inject base class • Not a huge deal, but a nicety
purpose • Splitting up code may seem like it’s increasing complexity, but it makes maintenance easier in the future • Manually dealing with Bundles and re-setting up your state on config changes is a pain
purpose • Splitting up code may seem like it’s increasing complexity, but it makes maintenance easier in the future • Manually dealing with Bundles and re-setting up your state on config changes is a pain • DI Frameworks make passing dependencies around to “helper” classes easier
extends View, Activities) should be dumb • Delegate the handling of “state” to something else besides your views • Tell your views what to show and have them tell you what the user did
extends View, Activities) should be dumb • Delegate the handling of “state” to something else besides your views • Tell your views what to show and have them tell you what the user did • All of these combined make testing / maintaining far easier