iPhone Application Life cycle

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.


iPhone Application Life cycle

iPhone Application Life cycle



The (in)famous Event Loop


The Run Loop

The Run Loop

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.


16 thoughts on “iPhone Application Life cycle

  1. rahulregunathan says:

    Do correct me if there are any mistakes being done here…
    A short note about event,event loop and Delegate

    Event is basically a message sent by an object to signal the occurrence of an action.The action could be caused due to some user interactions like mouse click or even by some programming logic(like a scheduler).

    An event loop waits and dispatches the event or messages in a program.It works by polling some internal or external “event provider”, which generally blocks until an event has arrived, and then calls the relevant event handler (“dispatches the event”).For example if i set an alarm it is not allowed to executed until the particular time span is reached.

    Delegate is a communication channel between an event source and an event receiver.For example consider you calling a friend of yours.Then you would be the event source and your friend would be the event receiver and the telephone cable as the communication channel.

    On summarizing take an example that if i take cash from an ATM i receive an instant alert on my mobile phone stating that my bank account has been debited.So here i get an example for all the three.Like an event is being dispatched by the event loop and i receive a message from the bank server to my mobile where a delegate’s role come into play

  2. mobisynth says:

    Nice writeup Rahul. I agree with you on the explanation.

    Lets remember this: for event driven program to be a reality. You need a min. of 2 participants and an event.

    A Delegate is simply one method of hooking up the event source to event listener (the code that implements the response to occurance of an event).

    Generally speaking, delegate acts as an interface (medium or as you put it … communication channel) between the event source and and the party interested in handling the event.

    In Java, you have an event source and an event listener. The event listener registers with event source and when the event occurs, event source calls the method on the listener.

    In iPhone, the same thing is done using delegates. If you implement a delegate in your class, that means you are interested in listening to an event of a certain type (this pretty much means that you are registering as a listener), now when that event occurs, it calls the method on the delegate. As you have implemented the delegate’s method in your class, it means the method on your class gets called. (exactly like an interface of Java).

    In Java, you have a class, you implement a keyListener interface, so when the mouseclick event occurs, your class’s implementation of keyListener interface (can I call it delegate?) is called.

    • mobisynth says:

      That is a very abstract statement Kamlesh, still let me try and answer. All client server interaction is not event driven. Client server is more of a deployment paradigm where as event driven model is a design pattern.

  3. Abhimanyu singh says:

    One way to think about an event is like a communication network.I would like to give an example here.Suppose we click a button on a form.A mouse click is received and translated to a mouse down event.This event is then passed to other object that are set to listen to this event and are told to handle to this event.
    Events provide a generally useful way for objects to signal state changes that may be useful to clients of that object.

    Event loop is very similar to dispatcher which dispatches the events.All events are kept in queue and called one-by-one.

    The literal meaning of delegate is A person authorized to act as representative for another.In programming term it is a process in which a task is handed over to some other process so as to accomplish it.for example A manager is assigned a job which could be executed by one of his subordinates.

  4. Venu says:

    Example for Event-Driven Programming:
    If we press double click on “My computer” icon, it means to open a new windows and shows what are the drives present. In the same way ,here we are giving an event(i.e we are giving double click) and some action will be done..

  5. Siddhesh Naik says:

    Event, as name suggests, is an action. The iPhone OS system keeps on monitoring events, like tracking touch and motion events, and when received delivers them to the application.
    Event loops are queues that are used to queue the events, when events are received during handling of a previous one or when application is busy.
    UIKit contains complex objects for various events. To avoid subclassing of these objects, the delegate design pattern is used. Here the complex object is used as it is. The delegate object contains programmers code that is executed when the complex object makes calls to the delegate objects.

  6. Ravi Joshi says:

    An iPhone application can be one of the following states at any given time. The states are briefly described:
    Not Running: Not receiving any events.
    Inactive: Running in the foreground but not receiving any events.
    Active: Running in foreground and receiving events
    Background: Application in the background and executing code.
    Suspended: Application in background and not executing code.

  7. Derek Chong says:

    it is a very interesting and very informative blog about iPhone’s application life cycle, but one thing kept me thinking is, all these event handling tasks were done before iPhone has multitasking. And since iPhone now supports multitasking, does this algorithm still valid?

  8. David Wang says:

    In my sense, the differences between event driven and message driven is that, as for event driven, each event will definitely send one message, to trigger some objects to make response to the event. The event dispatcher does not need to wait until an appropriate response is given that it can deal with the next event; the message driven could be multiple messages, and the mode could be synchronized or desynchronized.

    Iphone event-driven model is simple. I feel the iOS would take complete control of it, developers do not need to concerned too much about that.

  9. Vidhya says:

    Gave a clear idea on how the user events are handled using the event driven model . This leaves me with a question are they handled with so much of nuances in the code that it never shows us a ANR or a force close like in Android?

  10. Jisna says:

    It is a well written article about iPhone application life cycle.For a fresher like me,it gives a clear idea
    about the role of events,event loops,and delegates played in the application life cycle.

  11. Vijayakumar says:

    It is so simple and easy way to remember the life cycle when we create an application. From my understanding, An event begins at Starting(tapping) of an application itself, then there mighty be some more events can occur and last the application will be terminated(also an event), these are all executed successfully only if we understand the “flow of control”.

  12. Rohit saraf says:

    Got a clear view about the event driven model and how the iPhone applications are event driven.
    Infact, from the launch of an iPhone app to it’s termination, it’s all about we performing an event, generation of the event objects and the object listeners responding to our events through delegates.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s