iOS App Life Cycle

We will first see the Life Cycle of an iOS App. We are aware that software starts execution from the main function. But in iOS Application using Swift main function is internally manage by the system. We denote binding of main function with Swift class by using @UIApplicationMain Which ever class which writes @UIApplicationMain becomes the first class to be executed by the Swift complier and run time system. This indicates which is application object and which class will be listening to the application level state changes which are captured by the iOS.
Every iOS application needs to have a class which will listen to the iOS. We called it AppDelegate. If you notice AppDelegate.swoft class is created automatically by the Xcode. We use world delegate for the listeners. As application level changes will be listen by the AppDelegate we will start investigating the AppDelegate.swift class. The life cycle of an iOS App will also be captured by the AppDelegate.swift as these are application state changes. Select AppDelegate.swift from navigation pan you will find following code in the editor

 

We find following code in the AppDelegate.swift
import UIKit
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
var window: UIWindow?
func application(application: UIApplication!,
didFinishLaunchingWithOptions launchOptions: NSDictionary!) -> Bool {
// Override point for customization after application launch.
return true
}
func applicationWillResignActive(application: UIApplication!) {
}
func applicationDidEnterBackground(application: UIApplication!) {
}
func applicationWillEnterForeground(application: UIApplication!) {
}
func applicationDidBecomeActive(application: UIApplication!) {
}
func applicationWillTerminate(application: UIApplication!) {
}
}

As we see by default few lines of code is added by the template. Lets discuss one by one each line of code. First AppDelegate class import UIKit framework. In Swift we can import framework or file by writing import nameofFile In Swift one does not have to import the files or framework. Swift will automatically import the relevant files and framework when needed. As this file is listener to the iOS and also bind with the main function, @UIApplicationMain is written. We declare class as follow in swift
class ClassName: SuperClassName {
}
Like in JAVA and Objective C, Swift also will not allow a class to be derived from two base Classes. We have concept of Protocol which is similar to concept of Interface in JAVA and pure virtual class in C++. If class confirms the protocol than class declaration will be as follows. class ClassName: SuperClassName, ProtocolName1, ProtocolName2 {
}
Thus as per the code, AppDelegate extends UIResponder and confirms UIApplicationDelegate protocol. A class is called valid swift class if root class of the class is NSObject. AppDelegate extends UIResponder and UIResponder extends NSObject.
Thus AppDelegate is a valid Swift class. Swift protocols are key in making it a run time language. One must understand protocols properly to make code, dynamic and flexible. Protocols are the mechanisms by which a thread is interrupted or in simple words, they are callbacks.

Protocols are similar to interfaces in JAVA and pure virtual classes in C++. All of these are meant for callbacks. How do these things work? How does this world work? Is there only one thing, which can perform all the tasks together in this world? The answer is obviously, NO. We have to communicate between objects to get any task done and for communication to be completed one needs to give appropriate feedback. We all know that feedback is one of the most important parts of communication. When we communicate, we get a message from the calling object and after we complete the task we give the calling object appropriate feedback. If a task is heavy, we do it without making the object to wait. When giving feedback we interrupt the calling object; this causes the simultaneous execution of tasks. Interrupts or callbacks help the feedback mechanism.
Lets take an example of a company hiring you. The first official bit of communication between the company and you is the signing of the contract which is the means of communication for the future. This is similar to how protocols work in Swift. Protocol declares the methods once, which can be implemented in any class provided that it confirms the protocol. Protocol is declared as follows protocol protocolname : superprotocol
method1;
method2;
optional method3;
@end
By default, protocol methods are required but it can also have optional methods.This is the major difference between the JAVA interface and Swift protocols. In JAVA, a class, which implements an interface, HAS to implement all its methods (compulsory). Whereas, in Swift, a class, which confirms the protocol, has to only implement all the required methods and optional methods from a case to case basis.

Syntax on how a class confirms the protocol declaration:
class ClassName: SuperClassName, ProtocolName1, ProtocolName2 {
}
Similarly in JAVA we would have written:
Class className extends superclassName implements interface1, interface2
If a protocol contains all optional methods we term it as an “informal protocol” and if a protocol contains at least one required method we term it as a “formal protocol”. More about protocols will be covered while creating your own feedback mechanism in client-server architect MVC pattern. Protocols follow adaptive design patterns, which enable classes to adapt to the situation and extend its functionality to satisfy the situation. We see AppDelegate class extends UIResponder class and UIResponder class extends the NSObject class. Thus AppDelegate is a valid Swift class. The AppDelegate confirms UIApplicationDelegate protocol. Select the word UIApplicationDelegate and right click you will find an option caller “Jump to Definition”, we will select that option and see whether UIApplicationDelegate is a formal or informal protocol.
protocol UIApplicationDelegate : NSObjectProtocol {
optional func applicationDidFinishLaunching(application: UIApplication)
@availability(iOS, introduced=6.0) optional func application(application: UIApplication, willFinishLaunchingWithOptions launchOptions: [NSObject : AnyObject]) -> Bool
@availability(iOS, introduced=3.0)
optional func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject : AnyObject]) -> Boo

optional func applicationDidBecomeActive(application: UIApplication)
optional func applicationWillResignActive(application: UIApplication)
.
.
.
}
There are plenty of more methods declared in UIApplicationDelegate protocol and all are optional. Thus UIApplicationDelegate is an informal protocol. There is a optional variable of type UIWindow that is declared. You will find that template has already implemented few of the UIApplicationDelegate methods. Let us now see how these methods are called by doing a small exercise. We will be writing log statements with method name as output string and than we will run the app. If any log gets printed we will come to know which methods are called when user perform some tasks. In order to print the log we use println(”message string”).
class AppDelegate: UIResponder, UIApplicationDelegate {

var window: UIWindow?

func application(application: UIApplication!, didFinishLaunchingWithOptions launchOptions: NSDictionary!) ->
Bool {
// Override point for customization after application launch.

println(“didFinishLaunchingWithOptions”)
return true
}

func applicationWillResignActive(application: UIApplication!) {
println(“applicationWillResignActive”)
}

func applicationDidEnterBackground(application: UIApplication!) {
println(“applicationDidEnterBackground”)
}

func applicationWillEnterForeground(application: UIApplication!) {

              println(“applicationWillEnterForeground”)

    }

    func applicationDidBecomeActive(application: UIApplication!) {

              println(“applicationDidBecomeActive”)

    }

    func applicationWillTerminate(application: UIApplication!) {

             println(“applicationWillTerminate”)

    }

}

Now lets run the app. You have Run button on top left side of the tool bar (triangle symbol) or  you can use short cut key command + r. When you run the program you get the following output in the console didFinishLaunchingWithOptions applicationDidBecomeActive

So according to the console output on the launch of the app following two callbacks occur func application (application: UIApplication!, didFinishLaunchingWithOptions launchOptions: NSDictionary!) -> Bool
func applicationDidBecomeActive(application: UIApplication!)

There is only one hardware button on the iOS devices, which we call as “Home Button”. Now on the simulator you do not find the home button in order to simulate the home button press keys command + shift + h. When you press this key it is the same as a user pressing the home button and we get the following output on the console.

applicationWillResignActive
applicationDidEnterBackground

As per the output following methods are called func applicationWillResignActive(application: UIApplication!)

func applicationDidEnterBackground(application: UIApplication!)

Thus first the app is inactive. In simple words all the touch events are paused on the app and app enters into the background .When user double press the home button, multitask panel comes up and when user press
your app, the app resumes. In order to simulate this you have to press command + shift and double press h with command + shift pressed.
You will get the following output on the console applicationWillEnterForeground
applicationDidBecomeActive
Thus as per the output the following callbacks are triggered:
func applicationWillEnterForeground(application: UIApplication!)
func applicationDidBecomeActive(application: UIApplication!)
Thus app first will come to the foreground and again it will become active and all it’s threads will be resumed. The app can also take in touch events now.

Now if you press the home button, than double tap on the home button, multi task panel will come, If we slide the app upwards it will get terminated and we will get following output in the console
applicationWillTerminate

Thus as per the output following callbacks are triggered func applicationWillTerminate(application: UIApplication!)

Thus we now are aware of the typical life cycle of the app. Now lets see the Model View Controller or MVC architecture of the iOS App. You can refer to the code in 1.LifeCycle folder for the life cycle topics. There are many special life cycle of an iOS Application depending upon the need, the one we demonstrated is basic and thus template implements these protocol methods.