Dependency Injection with Dagger 2
Creating the AppRepository - The single source of data for the UI
Up next
Previous
About
In this video we add a new module called repository, along with a class, AppRepository.
This class is responsible for fetching the data that our UI layer requests, abstracting away where that data comes from (in our case, GitHubApi).
Having a repository layer is important because this is where you can perform caching, or switching where you load data from (e.g. disk/network).
We'll also set up our ApplicationComponent to provide the AppRepository as an injectable dependency to other Components.
Instructor
Links
Comments
Hi Brandon,
I have always followed clean architecture that separates into the following layer modules: presentation, domain, and data. Where the data layer will make the network requests and the domain will be the interacters (use cases) and the presentation the UI layer. And where the presentation <-> domain <-> data flow will always go through the domain and the presentation and data should not know about each other.
Just wondering where all this fits into the architecture that you are building here. I am thinking that the githubApi would represent the data layer that will make network requests and the appRepository would be the domain. However, if this is the domain then it should be just a Kotlin Library that has no dependencies on the Android framework.
Hi Steve!
Architecture for sure comes down to preference/how it fits best for your or your team.
For myself, having a repository coordinate local/network loading of data and expose data as a single function (so users of the Repository don't know or care where the data comes from) is the most important separation. In a larger app, the loading from network or local disk would likely be handled by their own objects (meaning not using the Retrofit generated interface directly in the Repository), which the Repository would coordinate, but the idea remains mostly the same.
I feel presentation layers should communicate with the Repository--what goes on behind the scenes there can change depending on app complexity. So in that sense, it does sound like this would be the "Domain" in the architecture you use. I feel like Repositories should be able to be Kotlin multiplatform modules.
However, if this is the domain then it should be just a Kotlin Library that has no dependencies on the Android framework.
Which Android framework dependencies does the Repository have? If you're talking about the Gradle dependencies, then it's mostly because I wasn't super great about trimming them down for each new module :) Those should be able to be removed with no impact on building the module.
Lessons in Dependency Injection with Dagger 2
