Understanding Model-View-Controller on iOS
- Basics of the Application Lifecycle
- How to Use MVC
- MVC and <tt>UICollectionView</tt>
This chapter is from the book
This chapter is from the book
This chapter is from the book
This book starts with the basics of the iOS application lifecycle and then discusses the Model-View-Controller (MVC) paradigm. Even if you’re an experienced iOS developer already familiar with these topics, I encourage you to read this chapter to make sure that you’re on the same page (or screen, so to speak) that I am while you’re reading the rest of this book.
Basics of the Application Lifecycle
The iOS application lifecycle differs a little from typical native applications on other platforms (although recent changes to OS X show Apple is interested in making the iOS lifecycle the norm). Developers no longer have hard-and-fast rules for when their applications are terminated, suspended, and so on. Let’s start with a simple scenario to describe a typical application lifecycle.
The user has just turned on his phone, and no applications are running except for those that belong to the operating system. Your application is not running. After the user taps your app’s icon, Springboard—the part of the OS that operates the Home screen of iOS—launches your app. Your app, and the shared libraries it needs to execute, is loaded into memory while Springboard animates your Default.png on the screen. Eventually, your app begins execution, and your application delegate receives the appropriate notification. When your application is running and in the foreground, it is in the active state.
On iOS, users tend to only use any given application for a few seconds before returning their phones to their pockets. After the user has put away your app by pressing the Home button on her iPhone or iPad, your application enters the background state. Typically, apps have 10 seconds to complete any database saves or other long-running tasks (though applications can request additional time from the OS). When all the background processing is complete, the application finally becomes suspended. While suspended, applications remain in memory but may not execute code. The state of your application is persisted. If the user opens your application while it is suspended, it begins execution exactly where it left off. If memory becomes low, the OS can kill your app while it is in the suspended state. The user can also manually terminate your app from the multitasking tray. Once terminated, applications return to their initial state of not running.
But wait, it gets more complicated! If the user receives a calendar alert, opens the multitasking tray, or gets a phone call, your application can be put into the inactive state. Your application is still running, but it is no longer the foremost thing the user interacts with. For example, games pause themselves. As an application developer, you need to be aware of this and use it as an indication that the user might leave your application soon.
The user can open your application without tapping its icon on the Home screen. If your application receives local or push notifications, or if it is registered for custom URL scheme handling, the user can open it in any number of ways.
The application lifecycle is important to understand for all iOS developers who want to make enriched, immersive experiences. These types of applications are exactly what UICollectionView is great for, so no comprehensive discussion of UICollectionView would be complete without a summary of the application lifecycle.
If your app enters the inactive state, stop updating your interface. It would be disconcerting for a user to see your collection-view contents move about while he’s deciding whether to view the details of an appointment that has popped up over your application. Likewise, don’t update your app’s interface while the application is in the background. The state of the user interface should remain fixed between the switch from active to background and back to active.