In this post, as the title suggests, I’ll discuss why one shouldn’t emit View States (or as some people prefer to call it Resource nowadays) from Repository, and why is it Anti-Pattern IMO. While discussing that, this post will also address why returning
LiveData from Repository doesn't make sense.
So let us get started by understanding each of the layers in an Android app, and their purposes/function.
Note: I'm not advocating structuring your project by layer here, in-fact I prefer structuring by feature. However, the layers are still there within feature-based modules or packages (in case of monolithic apps).
There can be multiple layers in an Android app, however, 3 of them are most significant. …
There is a very thin lining of difference between Service Locator (in short SL) and Dependency Injection (in short DI). Most people get confused with these terms, even I was confused with them for so long. …
Ever thought organizing test cases in Android are cumbersome? For instance, you have a function and there are 3 scenarios you want to test, for example, for 3 different inputs, it’s supposed to return 3 different outputs, and you want to test this behavior, now what we mostly do in Android and
JUnit 4 is create 3 different functions and name the functions like
fun `test functionName should return output1 for input1`()
If the target class has 10 more functions then, assuming you’ll want to test each function in multiple scenarios, this Test class may end up with about 25–30 more such test cases, but there’s no way to group them.
Let me be more specific about what I want, I still want all those tests within a single file, because they cover a single class that I’m testing, but I want to group all the test cases for a single function together, this way it’s easy to find issues if something is broken. …