[vc_row css=”.vc_custom_1487155703438{padding-bottom: 40px !important;}”][vc_column][vc_column_text]
iOS App MVC
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_tta_tour][vc_tta_section title=”Page 1″ tab_id=”1549349554682-69b59f9b-d65a”][vc_column_text]The best part of the COCOA touch framework is that, lot of the design patterns are given to us readymade. We do not have to create these patterns; we just need to use them. The most important design pattern is MVC pattern. MVC stands for Model-View-Controller.
Each class needs to be part of any of these three camps, model, view or controller. Model holds the app data. View holds the GUI of the App and Controller is a junction where Model meets the View. View is always dependent on the Model.
Thus Controller will always have “hasA” relationship with Model and View. Controller first communicates with the Model to get the data and than inflates
the View with the corresponding data. In order to make MVC more clear, imagine me standing with the blackboard. The data what I have to write on the blackboard is in my brain. Thus my brain is the model. Data will be displayed on the blackboard. Thus the blackboard is the view. My hand is a junction where data from my brain is put on the blackboard. Thus my hand is the Controller. We will use this example to understand this chapter. Every framework has its own MVC pattern. For COCOA touch every controller will have compulsory hasA relationship with the View. Thus when you create a controller, controller will have a view as a property. Thus in the above real world example whenever a hand is created it is associated with or hasA blackboard. Now we understand that controller is important element of the application. Without the controller, model and view cannot meet. Thus we will be creating the controller variable in the AppDelegate class. The abstract class, which represents the controller, is UIViewController.
The abstract class, which represents the view, is UIView. The abstract class, which represents the model, is NSObject. UIViewController or UIView class has root class as NSObject only. Template already creates a default class,ViewController for us. This ViewController class extends UIViewController, thus it is a valid controller class. We will be creating the variable of type ViewController in the AppDelegate.[/vc_column_text][/vc_tta_section][vc_tta_section title=”Page 2″ tab_id=”1549349554702-7222c0a2-1e4c”][vc_column_text]But if you have seen AppDelegate.swift, we have one more variable of type UIWindow. UIWindow extends UIView so it is a view class. The question that arises is, is this window same as controller’s view? The answer is NO.
This window is a special kind of view class. It gives support to the view hierarchy of the app. Window is the root view of the view hierarchy in any iOS App. Just like how the blackboard cannot stand without support, it needs the support of a wall. The wall is the window.
So we first create the wall. Second we create the hand with which we get the blackboard.
Third we place the blackboard on the wall and forth we make wall visible to the audience.
When the wall becomes visible automatically, blackboard will be visible as it will be in the focus area. This step needs to be done when application launches.
Lets update the AppDelegate.swift as follows
class AppDelegate: UIResponder, UIApplicationDelegate {
var window: UIWindow?
var baseController: ViewController?
func application(application: UIApplication!,
didFinishLaunchingWithOptions launchOptions: NSDictionary!) -> Bool {
// Override point for customization after application launch.
println(“didFinishLaunchingWithOptions”)
window = UIWindow(frame: CGRectMake(0, 0, 320, 480))
baseController = ViewController()
window!.rootViewController = baseController
window!.makeKeyAndVisible()
return true
}
.
.
}[/vc_column_text][/vc_tta_section][vc_tta_section title=”Page 3″ tab_id=”1549349557845-a23b6ec5-f0a6″][vc_column_text]As you notice we implement the 4 step architect in didFinishLaunchingWithOptions callback as this is the first callback we receive from the iOS app. First step we create the window and initialize its frame. Every view component needs to be initializing with a frame, which is a rectangle area in which the view will be visible.
Window’s frame should always be full screen. The reason we will see when we get to touch events. We are starting our journey from 2008 where only iPhone was there. The resolution of iPhone then was 320 by 480. For creating the frame we need the top left coordinate as the origin and size of width and height. Thus we pass 0,0,320 and 480 as values.
Second step is to create the base controller.
In the third step we need to associate the base controller to window. In simple words placing the controller’s view on the window.
The fourth step is making the window visible. When we run this app we get full screen of black colour. Now we need to change the color of the screen. So we want to change the color of the controller’s view, we will override the viewDidLoad method in the ViewController.swift so that we can initialize the view background color.
override func viewDidLoad() {
super.viewDidLoad()
// Do any additional setup after loading the view, typically from a nib.
self.view.backgroundColor = UIColor.yellowColor()
}
In other language you have “this” pointer. Here we use self. Super indicates to the immediate super class. We change the background color of the view to the yellow color by setting the backgroundColor property, which is declared in the UIView class. We use the override word for function overriding before the function name as part of the Swift syntax.[/vc_column_text][/vc_tta_section][vc_tta_section title=”Page 4″ tab_id=”1549349559328-1a1b9771-3cd2″][vc_column_text]
When we run the app we get a full screen with yellow color as shown below
[/vc_column_text][/vc_tta_section][/vc_tta_tour][/vc_column][/vc_row]
