Architecture: The data layer - MAD Skills

How do you test a repository with two different data sources (LocalDataSource and RemoteDataSource)? Should I create one interface and make local and remote data source classes implement this interface? –I saw this approach in one of Google's app samples, but I don't like it because you are forcing each class to implement methods they don't need– Or should I create two separate interfaces, one for local data source and another one for remote data source and then make the repository depend on these two interfaces? I would prefer the second approach, but honestly writing tests for 3 separate classes (Repository class, LocalDataSource class and Remote Data Source class) might be a bit of a hassle.

Great! It is a lot of informatin! I think I have to watch this video many times, and deep dive into the additional documentation to fully understand all the topics mentioned here...

📱🇨🇴🙋🏻‍♂️👍🏼🤝🏼

I love this app for is a life best activity

Is it good practice to update local database on separate thread with the data received from networkDataSource...?
suspend fun fetchNews(): List<Article> {
try {
val news = remoteNewsDataSource.fecthNews()
Thread { localNewsDataScource.updateNews(news) }.start()
return news;
} catch(ex: Exception) {
}
return localNewsDataSource.fetchNews()
}

Very nice

Hello from August 8, 2022.

Perfect Architecture, but still after I have built many projects I don't believe we should always create "Repository per one Resource" and "Data Source per one Resource and Source Type".

Yes, as I said before it is perfect architecture, but I don't think this should be implemented for all projects, maybe only for large huge projects, right?

I used to create many many classes and files to follow previous architecture rules, and each time I wanted to refactor my data layer because of changing for example specific API Layer Data Source (which may responsible for 30% of all used APIs), this will cause to change many classes and files including their definitions, and in my opinion this is too much to do, there is no point of doing this.

In my point of view, we should separate Repositories and Data Sources only if we have "need" to do this otherwise even if that considered as good from an architecture point, but still it is not proper to be implemented until being really needed.

Any thoughts?

What is the motivation behind moving business logic down to the data layer?

Боольшое спасибо автору,классное видео)

Thanks for the great video!
I hope you talking about error handling across all layers and which layer is responsible for what, with a simple example!

I found a small inconsistency in the naming of the Repository. The naming convention in the documentation is `NewLocalDataSource`, but in the video it is named `LocalNewDataSource`, a correction is suggested. doc:

Cool video

Very good info. I started my architecting journey with MVP architecture. It could be an overwhelming experience, but totally worth the hassle.

Thanks for the great video Jose!
I'm curious why did the Android team decide to have the data layer depend on the domain layer and not the other way around?

What does the data layer say when it's initialized?

Data da daaaaaa!

Great start to your modelling career, Jose

Where does the MonsterRepository live?

In the data lair

Jose is the MVP

Good demonstration.I am waiting for the next <3

Keeping separate model for Remote and Local data sources is good for long term ... Like: RemoteArticle and LocalArticle ... and expose "Article" domain object only from Repositories

Nice overview Jose!! This video is a great "repository" of information! 😜

Neat🤜

Love the style 😎

Eagerly waiting for next.

Great 👍

"This is out of the scope of this video" I see a joke that can be made here..


Kotlin coroutine scope 🤣

Awesome video! Thanks for the detail!

Great 🔥👏

🔥🥂 Mad Skills