Dissecting an iOS App

You find out about the typical components of an app and how they interact as it runs. Figure 6-1 shows these components. As you can see from this figure, the components of an app can be grouped into model, view, and controller components.

The model components are the Objective-C classes that implement the domain logic of the application as well as manage long-lived state. Some of these classes might also be persistent; that is, they may save their state across runs of the app on the file system or in a database.

The view classes represent the user interface of the app. They handle showing information to the user. These classes also handle interactions with the user; that is, they handle touches on the screen, keyboard input, and so on.

The controller classes are responsible for managing the execution of the app. Once the app is running, these controller classes also are the bridge between the views with the model. These classes consist of the Application Delegate, the root view controller, and app-specific view controllers.

The preceding model, view, and controller classes don’t simply materialize out of thin air when an app starts. App execution begins with the main function that is then responsible for instantiating all the other classes. Learn more at iOS App Development Course

The following code for the main program of the Tic-Tac-Toe application shows you how app execution begins (see file main.m in the folder Supporting Files):

... #import "TTTAppDelegate.h" int main(int argc, char * argv[]){    @autoreleasepool {        return UIApplicationMain(argc, argv, nil,                                  NSStringFromClass([TTTAppDelegate class]));    } }
Running this main function causes the following:
 1. A (singleton) instance of the class UIApplication is created.

 2. The UIApplication object, in turn, creates an instance of the app-specific application delegate (that is, a subclass of UIApplicationDelegate) and, in a separate thread, calls its initialize method.

3. The UIApplication object executes an event loop, where it listens for two kinds of events: 
  • User-interface  (UI) events, such as touches on a screen. The UI events are sent to the window object.
   • System events, such as for a low battery or when the app will be sent to the background because the device receives a phone call.  System events are sent to the application delegate by the UIApplication object.

4. The application delegate creates the window for the app (an instance of the class UIWindow), along with a Root view controller that manages the window.  The application delegate also creates a manager for the app’s model. This manager manages the Core Data objects for the app. (Turn to Chapter 7 for information about Core Data.) swift course

 5. The Root view controller creates additional view controllers as specified in the storyboard of the app. The creation of the view controllers results in the creation of their views. These views become part of a view hierarchy — an inverted tree of views and subviews.

When the app commences and is in a steady-state, only the event loop runs. This event loop listens for events and calls your code appropriately to respond to them. Once the app starts, it’s completely event-driven and does computation only when iOS or a user asks it to do so.

If you want to Get more Additional Information from iOS Development course online