A lot of developers really want to know what’s actually happening inside of even a basic single view iOS application. Like what did these other files represent? What an app delegate? Why don’t we see the main function to begin an iOS app? How does your application get from a user touching the icon, or running the simulator, to actually running some of our code? So let’s take a look at the process. I’ve made an iOS single view application and added nothing to it. The most basic idea is this. This is an Objective-C program, which means that the program does begin by running main.
In a default project, we do have a main.m file in our supporting files folder. As a rule, you won’t ever need to touch main. You’re going to leave it alone, which is why Xcode is putting it in that folder. So main has one call to UIApplicationMain, this is a predefined function in iOS that creates an object that represents the standard iOS application, the basic processing that every iOS app is going to need. Main calls UIApplicationMain that creates that object that sets up a run loop so that the application stays active, it continues to respond to events and doesn’t just terminate.
At this point, it also loads in our primary user interface file, usually a storyboard but could be an older style XIB file, although nothing’s visible yet. The thing is, our app is different from this generic UI application object, and we need to say how. So how do we add extra behavior at the application level? In a lot of other languages, you would use inheritance for this. You might inherit from, perhaps, a provided application class. Well, we don’t use inheritance for this in iOS mobile app development. We use delegation again.
So we have a separate class in our project that is the delegate for the standard built-in iOS app development. So it continues to run, but it can pass over any extra stuff that we need to do. And this is something Xcode does for us in these provided iOS templates. Looking at a project, you might have a pretty good idea of what might be the delegate for the application object. It is, of course, AppDelegate. This is where we can put our code to respond to application-level events, like our application starting, or our application going into the background, or even the application terminating.
So, at this part of the process, we have no user interface yet. This is all being done very quickly in the background. And one of the things the app delegate keeps a reference to is an object called a UIWindow. Now think about a window, a window is clear, it is transparent. Although it does have a certain size. It has boundaries. And really, that’s what’s happening in iOS. The UIWindow object represents the boundaries of an iPhone or an iPad screen. So the window object is immediately created and exists for the lifetime of our app, there’s just one UIWindow object.
But it is transparent because we then load our storyboard and, using the associated view controllers, into that UIWindow to provide that initial user interface. When we have a single view application, we’re loading a single view controller into that window with all its associated and contained user interface elements. In more complex applications, we can switch multiple different view controllers in and out of that UI window. Now if you’re finding this a little intimidating, a little complex, fair enough. There is a lot going on here.
But here’s the thing to remember, you don’t touch main, you don’t touch UI application main, you don’t even touch the UI application object. You don’t really do anything with the window object. Your interaction with this entire provided structure is in two primary places: one, your app delegate code, and two, your view controller user interface is in code. So, when this all starts up and an application first loads, there are several life cycle events that automatically get run. The built-in UI application object will get lifecycle methods like application colon did finish launching with options.
And it will pass them over to your app delegate in case you want to do something at that point. And then the window is loaded and our view controllers are loaded for the first time. And the view controllers will get lifecycle events like view did load and the view will appear. The view did the load is provided in the default code for a view controller, the view will appear isn’t but we can add it ourselves. Now the application is now considered fully active, and we’ll get more application level events like application did become active in the app delegate which we can then react to.
After that’s triggered we’ll actually see the view and we’ll get view did appear in the view controller rather than view will appear. If someone presses the home button to leave the application, we get events like application will resign or application did enter background, and we’ll see some of those later. But what’s important to understand is there’s nothing really hidden behind the scenes. If you know where to look, all this stuff is actually in the provided code, particularly in the app delegate. You’ll see these very explicitly well-described methods that you can interact with if you decide to do so.
The order is very explicit about what happens, what gets called, and which elements are calling other elements.
About Boston Technology Corporation – iOS App Development Company
BTC is a leading iOS/iPhone mobile app development company based in Boston with over 300+ apps built offering mobile app development, Enterprise mobile app development, custom Android app development, web development, Apple ResearchKit Development, IoT and Wearable’s, QA, Testing and consulting services in the USA. For more information, visit our website http://www.boston-technology.com/ or drop a mail at firstname.lastname@example.org.