One of the main responsibilities of all good little applications is to deal with low memory. So the first line of defense is (obviously) to understand how you as a programmer can help them avoid getting into that state.

In the iPhone OS, each program uses the virtual-memory mechanism found in all modern operating systems. But virtual memory is limited to the amount of physical memory available. This is because the iPhone OS doesn’t store "changeable" memory (such as object data) on the disk to free up space, and then read it in later when it’s needed. Instead, the iPhone OS tries to give the running application the memory it needs — using memory pages that contain read-only contents (such as code), where all it has to do is load the "originals" back into memory when they’re needed. Of course, this may be only a temporary fix if those resources are needed again a short time later.

If memory continues to be limited, the system may also send notifications to the running application, asking it to free up additional memory. This is one of the critical events that all applications must respond to.

Observing low-memory warnings

When the system dispatches a low-memory notification to your application, it is something you must pay attention to. If you don’t, it is a reliable recipe for disaster. (Think of your low-fuel light going on as you approach a sign that says "Next services 100 miles.") UIKit provides several ways of setting up your application so that you receive timely low-memory notifications:

✓ Implement the applicationDidReceiveMemoryWarning: method of your application delegate. Your application delegate could then release any data structure or objects it owns — or notify the objects to release memory they own.

✓ Override the didReceiveMemoryWarning: method in your custom UlViewController subclass. The view controller could then release views — or even other view controllers — that are off-screen.

✓ Register to receive the UIApplicationDidReceiveMemoryWarning Notification: notification. A model object could then release data structures or objects it owns that it doesn’t need immediately and can re-create later.

UIKit Your code

Each of these strategies gives a different part of your application a chance to free up the memory it no longer needs (or doesn’t need right now). As for how you actually get these strategies working for you, while I will mention a strategy for implementing the view controller’s didReceiveMemoryWarning: in Chapter 14, this is something that is dependent on your application’s architecture. That means you’ll need to explore it on your own.

Not freeing up enough memory will result in the iPhone’s OS sending your application the applicationWillTerminate: message and shutting you down. For many applications, though, the best defense is a good offense, and you need to manage your memory effectively and eliminate any memory leaks in your code.

Avoiding the warnings

When you create an object — a window or button for example — memory is allocated to hold that object’s data. The more objects you create, the more memory you use, and the less there is available for additional objects you might need. Obviously, it’s important to make available (deallocate) the memory that an object was using when the object is no longer needed. This is what is meant by memory management.

The Objective-C language — the application-programming language used to develop iPhone applications — uses reference counting to figure out when to release the memory allocated to an object. It’s your responsibility (as a programmer) to keep the memory-management system informed when an object is no longer needed.