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?

The MVC architecture we have shown you works just fine for small, simple apps. It makes it 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 project grows larger than what we show in this book – as real-world projects 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 work 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-View Model” 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, as we said, 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 view model 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.