In simple terms, Application Life cycle means the life of an application (software) when it is running as a process. From the moment, you execute a program (app) and it starts running in memory, to the point when you exit the program (app) and it is flushed out of the memory by the system (generally an OS or a Virtual Machine).
Let me state the same thing as stated in iPhone’s documentation:
“Application life cycle constitutes a sequence of events that occurs between the launch and termination of your application.”
So, one thing is clear and it does not take a rocket scientist to understand the app life cycle from UI perspective. The application on my iPhone starts when I click on the app icon situated on my iPhone’s desktop (I like to call it the desktop). I see some screens that I flip through and finally when I am done playing with the app, I click on “home” button on my iPhone and somehow the application gets terminated. This is the boring mundane stuff.
What happens behind the scene requires us to pay attention to another important fundamental concept of programming. “Event Driven Model”.
In most computer schools, training institutes or courses they harp too much on Object Oriented Concepts and talk too little about the “flow of control” in a program. In simple terms, they talk about Classes and Objects but the coverage of how these objects are created, destroyed, scoped, moved and what is the relationship of objects with events is not covered adequately, rather I should say ignored to an extent that it hampers an engineer’s ability to design good programs. It generally takes a developer 6-8 years to get the hang of these patterns. Lets cut this cycle to 1 day and talk about events before I come back to iPhone Application Life cycle.
An event is an occurrence of a message that represents some activity in your process (note I did not write program). This message is generated by an external system or an internal component within your application. An analogy I can compare it with is Newton’s First Law: An object at rest remains at rest and object in motion remains in motion till an external force is applied. Does it not sound similar? A process at rest remains at rest till an event is received by it, and a process remains in motion till it completes the action in response to an event. kinda, sorta similar, isn’t it?
Lets analyze what things we need in place before a message can be received and acted upon.
1. There should be some address where a message is received.
2. The message must be in some format.
3. Someone might be interested in listening to the message.
4. There might be more than one entity (objects) interested in listening to the message.
5. The message itself could be an object (really who cares till we get the message).
6. The interested parties may need to register with the entity where message occurs.
7. The interested parties may need to register with the entity who receives this message.
8. Or may be, someone is collecting message on behalf of all who are interested in getting the message so that as soon as the message arrives, it can be forwarded to all who are interested in getting that message.
Now a thought: Can I give a new name to this “message”? Lets call it an EVENT.
Lets structure it a bit:
1. Event occurs at an event source
2. One object can be responsible for occurrence of multiple types of events
3. The same event (type) can occur in multiple objects
4. The object which is interested in receiving the event implements a delegate (you can call it listener as well)
5. The object that was interested in receiving the event implements a function (method) that implements the logic that is run in response to occurrence of the event.
Its a simple logical deduction:
You need an event source, an event object (the message) and an event listener at min. to implement an event driven model.
Lets revisit the iPhone App. life cycle again (now, with an understanding of event driven model). Lets simply try to learn through pictures. For details you can alway read iPhone App. Programming guide.
Let me give you some tips:
1. Understand the structure of an application
2. Understand its starting point
3. Understand the flow
4. Don’t bank on garbage collector to clean your mess
5. Understand its point of exit
6. Think use cases, think transactions
Can you imagine getting a grip on App Life Cycle without understanding events, event loops and delegates? Go figure them out now.