will help you to avoid: • Strong coupling. When changes in one module affect other module. • Weakness. Changes in one part lead to unexpected errors in other part. • Inflexibility. Module is hard to separate from the application for reusing.
externally, that leads that components can be reused. • We are working with abstractions (interfaces), so any implementation can be easily changed with new one, without pain and minimal changes in codebase. Objects insertion are isolated and decoupled. • Dependencies can be injected into components. We even can inject mock implementation of these dependencies . This makes testing much easier.
solved using code generation; • No reflection: using dependencies graph, configured at compile-time; • Fully traceable → easy debugging (concrete and clear call stack); • Performance: according to Google more that 15% increase; • Code obfuscation: method dispatch like ‘hand written’ code
Retrofit, Database, etc. Presenter Layer - in the “middle” between View layer and Model Layer, doesn’t know anything about Activity/Fragment/View View Layer - combination of Activity/Fragment with implementation of the View interface and XML layout. Holds soft reference to Presenter.
it uses annotation processors, fast and flexible • Single module configuration - localised in a single point in our app, and we have full control over it • Separated and Isolated application logic • Portability - this makes your code used again and again
another; • Integration tests - easily mock any part of application; • Scopes - injection can be related to specific part of application; • Object decoupling - less connection between objects, code changes and refactoring is easier. Dagger pros
from the base classes). • Component implementation (e.g DaggerAppComponent requires rebuilding the project to appear). • In case of any injection-related compile errors previously generated classes will disappear.