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 every file adds extra compile time for the file and will make migrations to other frameworks very slow and hard (Dagger itself keeps changing, so even if you keep Dagger but migrate to let's say Dagger 3.0 I won't be surprised if there will be breaking changes!).
2) Without Interface…
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()
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.
Hope this helps!
Razvan Alexandru Sandu
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 which rely on reflection (very slow and bad for performances) so I suggest you to use dynamic data structures for DTOs (JsonObject, JsonArray...) and map JsonObject to Domain model and vice-versa.
For storing in the DB, instead, you may want to use raw queries and skip ORMs since they too…
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 to domain models in the data mapper (instead of DTOs).
Libraries like Gson stream the Json content instead of allocating the whole object in memory.
PS: heap will not be tripled in size, the moment the DTO is mapped into Domain model it gets deallocated because no longer of use…
Why do we write tests?
Every company knows this absolute truth: bugs cost money.
Nasa’s Mars Climate Orbiter bug: $125 million
Ariane 5 Flight 501 bug: $500 million
EDS Child Support System bug: + $ 1 billion
Japanese bitcoin exchange, Mt. Got, bug: + $ 500 million
This truth creates the need for testing before going live.
Startups and small-sized companies heavily rely on Manual Testing and their focus is on delivering the minimum viable product.
Code quality is not a priority, which is understandable considering that there are limited funds and resources.
However, this comes with a cost.
What if I tell you that you can remove all the boilerplate code of your use cases and avoid writing them when not needed without affecting your presentation layer?
No, I’m not joking! 😎
A while ago I wrote why you need use cases and what they are so in this article I’m not going to dig too much into details, if you are new to them I suggest you read my previous article before.
To summarize we can say that Use cases are an evolution of Application Services that bring the following benefits:
A while ago I wrote a post about the Repository Pattern in which, among the other concepts, I explained the importance of model separation and data mapping.
After reading the comments on my article I was glad to see readers agreeing on the approach and overcoming the general hate over “extra models” and “annoying mappers”.
In the article, I also showed abstractions and generic implementations that can help to remove some boilerplate code. …
Since Clean Architecture became the new hot topic in the Android world there have been loads of code samples and articles that tried to explain how it works and which are its benefits.
However, I always hear these questions from developers that try to apply it:
What are these Use Cases/interactors supposed to do?
Why can’t I call directly the repository from the Presenter/ViewModel?
Why should I have a Use Case that does nothing other than just calling a Repository, isn’t this an overkill for my app?
Do I really need a Use Case for each repository method?
Over the years I’ve seen many implementations of the repository pattern, yet I think most of them are wrong and not beneficial.
These 5 are the most common mistakes I’ve seen (some of these are also in the official android documentation):