Chapter 8. Developing with view models

View models and the view

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.

Example: Tic-tac-toe

Drawing the game grid

Making it interactive

Events vs. reactive state

Immutable data and the game grid

Adding the code for interaction

Coffee break

Wrapping the logic into a view model

Click coordinate processing

Changing turns

Coffee break

Filtering illegal moves

Winning conditions

One more thing: Restarting the game

Summary