In this chapter
- Architectural views and view models
- The view drawing cycle and reactive programming
- View models with multiple outputs
In the preceding chapter, you had a first look at view models. You learned that they’re vessels for the business logic, isolating it in a way that allows it to be scrutinized and unit tested. At the end of the day, view model is just a clear name for encapsulation of functional logic needed to show something on the screen.
What’s left in the presentation layer of the application after you remove this business logic is called the view layer. In the architectural sense of the term, the view layer shouldn’t be confused with the Android View class—the view layer usually contains instances of Views, but isn’t limited to them.
The view layer is everything and anything that displays the processed data to the user.
This defines the view as the endpoint of the factory line, where everything is ready and you can finally send the product to the customer. You have all the information you need and you just need to display it to the user.
In this drawing, you can see the relationships between view models and view—as well as the fact that the view doesn’t see the APIs at all because they’re all hidden in the dedicated view model.
In this chapter, you’ll explore view models further and learn some new Rx tools on the way. It’s a long chapter, so hang tight.