In GeoQuiz and CriminalIntent, you used the standard Android tools to build out your app: a model you built with Java objects, the view hierarchy, and controller objects – activities and fragments. And in those projects, this MVC architecture was good.
In this project, you will learn how to use a tool called data binding. Data binding is just a tool – it has no opinions about how you use it. We have opinions, though, so we will be showing you how we like to use data binding: to implement an architecture called Model-View-ViewModel, or MVVM. In addition, you will see how to use the assets system to store a sound file.
This chapter also starts a new application, BeatBox (Figure 20.1). BeatBox is not a box for musical beats. It is a box that helps you beat people up. It does not help with the easy part, though: the part where you wave your arms around dangerously, bruising and hurting another human being. It helps with the hard part: yelling in a manner calculated to frighten your opponent into submission.
Every app you have written so far has used a simple version of MVC. And, so far – if we have done our job well – every app has made sense to you. So why change? What is the problem?
MVC as written in this book works just fine for small, simple apps. It is easy to add new features and easy to think about the moving pieces of the app. It creates a solid foundation for development, gets your app up and running quickly, and works well in the early phases of a project.
The problem arises when your program grows larger than what we show in this book, as all programs do. Large fragments and activities are difficult to build on top of and difficult to understand. New features and bug fixes take longer. At some point, those controllers must be broken down into smaller pieces.
How do you do that? You figure out the different jobs your big controller classes are doing, and you give each job its own class. Instead of one big class, you have instances of a few classes doing the job as a team.
How do you determine what those different jobs are, then? The answer to that question is the definition of your architecture. People use descriptions like “Model-View-Controller” and “Model-View-Presenter” to describe at a high level the ways they answer this question. But answering this question is always your responsibility, so your architecture is always uniquely yours.
BeatBox is designed with an MVVM architecture. We are fans of MVVM because it does a great job of lifting a lot of boring controller code out into the layout file, where you can easily see which parts of your interface are dynamic. At the same time, it pulls the non-boring dynamic controller code into a ViewModel class, where it can be more easily tested and verified.
How large each view model should be is always a judgment call. If your view model grows too large, you can break it down further. Your architecture is yours, not ours.