I have noticed that most of the unit tests I write are testing how my code transforms data or business logic. My class or business logic just needs data as input (thus I need some test data to write unit tests). For example, most of my android apps load a list of items from the backend and then the android app is transforming that data into some state object or front-end specific domain objects.
Continue...Finding the right abstraction is hard. In this blog post, I would like to share a technique that works well for us (my android teammates and me) when dealing with String resources on android. An abstraction layer for Strings? Why do we even need an abstraction to simply work with Strings on Android?
Continue...In my previous blog post we discussed how the Coordinator pattern can be applied on Android. This time I would like to show how this can be used in Model-View-Intent. If you don’t know yet what the Coordinator pattern is I highly recommend to go back and read the introdcution.
Continue...Over the last years we have established best practices for writing android apps: clean architecture, architectural patterns like MVP, MVVM, MVI, Repository pattern and so on. But what about in-app navigation? In this blog post I would like to talk about the Coordinator pattern and how we could apply this pattern in android development to organize our in-app navigation code.
Continue...In my previous blog post we discussed the importance of proper state management and why I think introducing a SingleLiveEvent as discussed in Google’s Architecture Components GitHub repo is not a good idea because it just hides the real underlying problem: state management. In this blog post I would like to discuss how the problem SingleLiveEvent claims to solve can be solved with Model-View-Intent and proper state management.
Continue...At I/O 2017 Google surprised us with a new initiative: Architecture Components. I really appreciate this initiative. In this blog post I would like to share my thoughts about ViewModel and some pitfalls you might stumble upon when using ViewModel and LiveData by taking a look at the official Google samples.
Continue...In the previous blog posts we have discussed Model-View-Intent (MVI) and the importance of unidirectional data flow. That simplifies state restoration a lot. How and why? We will discuss that in this blog post. There are two scenarios we will focus on in this blog post: Restoring state “in memory” (for example during screen orientation change) and restoring a “persistent state” (for example from Bundle previously saved in Activity.
Continue...In the previous blog posts we have discussed the Model-View-Intent (MVI) pattern and it’s characteristics. In part 1 we have talked about the importance of an unidirectional data flow and application state that is driven by the “business logic”. In this blog post we will see how this pays off when it comes to debugging to simplify the life of developers.
Continue...In this blog post we will discuss how to build independent UI components and clarify why Parent-Child relations are a code smell in my opinion. Furthermore, we will discuss why I think such relations are needless. One question that arises from time to time with architectural design patterns such as Model-View-Intent, Model-View-Presenter or Model-View-ViewModel is how do Presenters (or ViewModels) communicate with each other?
Continue...In the previous part we have discussed how to implement a simple screen with the Model-View-Intent pattern with an unidirectional data flow. In this blog post we are going to build a more complex screen with MVI with the help of a state reducer. If you haven’t read part 2 yet, you should read that before continue with this blog post, because there is described how we connect the View via Presenter with the business logic and how data flows unidirectional.
Continue...