Exploring four different approaches — Since the dawn of layered architectures, Use Cases have had a controversial reputation. While on the one side, they help you adhere to S.O.L.I.D. principles and improve your code readability; on the other, they are sometimes “useless” (the only thing they do is call a repository method). Because of that…

If you think good architecture is expensive, try bad architecture. ~ Brian Foote and Joseph Yoder — Clean Architecture has been probably the hottest topic in the Android community in the past few years and this trend doesn’t seem to go away (thankfully). This series is based on the following books and documentation: Clean Code by Robert C. Martin Clean Architecture by Robert C. Martin Patterns of…

Few comments based on your reply: 1. Use cases can receive only entities, if they receive DTOs it means they know about the outer layer and so the dependency rule is violated (Dependencies point only inwards never outwards, so framework layer sees interface adapter layer which sees the use case…

Hi Bawenang, thanks for reading the article! The repository is the interface adapter of the persistence, where the repository interface is the secondary port of the domain and the repository implementation is the adapter that converts DataStores data (DTOs) into Entities and viceversa. The domain models like Product, User... are the entities. The datastores (api service, preferences) are the framework.

Hi Eric, thanks for reading the article! I used `ProductDTO` in the example where both network and database datasources where sharing the same model object rather than having 1 model each (which is, as explained, wrong). I'm using `NetworkProduct` and `DbProduct` instead in the correct example

Hi Callum, thanks for reading the article! 1) If you put @ViewModelScoped in the use case you are coupling the use case with the DI scope, therefore you can't inject your use case in another use case with a different DI scope (Singleton for example). Also importing DI annotations in…

Hi Kyn, thanks for reading the article! The first approach is the correct one. The job of the repository is isolate and encapsulate persistence logic. Also whenever you come across this scenario, where you have 2 sequential invocations of the same dependency: ``` val result = dependency.getSomething() dependency.saveSomething(result) ``` It means you should just have a single function inside `dependency` which will take care of both actions, because you are basically leaking private implementation details.

If you are downloading a large amount of data having too many models might be bad for performances. What you should do in that case, assuming that is the real issue, is to keep the domain model and get read of DTOs. DTOs are usually generated with libraries like Gson…

Hi Farid, thanks for reading the article! Wow 130MB sounds quite a lot! At that point even serializers/deserializers are harmful. Few key points for dealing efficiently with the problem: 1. Remove the remote DTO so you are not getting delayed by the reflection of Gson, Moshi, Jackson... 2. Map JsonObjects/JsonArrays…