We have come a long way since the start of the book when we were just setting up Java and Android Studio. Back then, we went through everything step by step. But as we proceeded, we have tried to show you not only how to add x to y or feature a to app b, but we've also tried to enable you to use what you have learned in your own ways so that you can bring your own ideas to life.
This chapter is more about your future apps and is different than anything that we've covered in this book so far. We will look at a number of aspects of Java and Android that you can use as a framework or template to make even more exciting and complex apps at the same time as keeping the code manageable. Furthermore, in this chapter, I will suggest the areas of further study that you can take a look at, which are out of the scope of this book.
You will learn about the following topics in this chapter:
- Patterns and the model-view-controller pattern
- Android design guidelines
- Getting started with real-world designs and handling multiple different devices
- An introduction to Fragments
Let's get started.
MVC refers to the separation of different aspects of our app into distinct parts called layers. Android apps commonly use the model-view-controller pattern. A pattern is simply a recognized way to structure our code and other application resources, such as layout files, images, databases, and so on. Patterns are useful to us because by conforming to a pattern, we can be more confident that we are doing things right and are less likely to have to undo lots of hard work because we have coded ourselves into an awkward situation.
There are many patterns in computer science, but an understanding of MVC will be enough to create some really professional Android apps.
We have actually been partly using MVC already, so let's take a look at each of the three layers in turn.
The model refers to the data that drives our app and any logic/code that specifically manages it and makes it available to the other layers. For example, in our Note To Self app, the Note class along with its getters, setters, and JSON code was the data and logic.
The view of the Note To Self app referred to all the widgets in all the different layouts. Anything the user can see or interact with on screen is typically part of the view. And as you can probably remember, the widgets actually came from the View class hierarchy of the Android API.
The controller is the bit in between the view and model. It interacts with both and also keeps them separate. It contains what is known in geek language as the application logic. If a user clicks on a button, the application layer decides what to do about it. When the user clicks on OK to add a new note, the application logic listens for the interaction on the view layer. It captures the data contained in the view and passes it to the model layer. Almost...