App lifecycle functions from Android to Ios,ios

Because of their C-base is still satisfied, spent one months intermittent to see OC, recently in the knowledge of some iOS development. When you first create an iOS project, Xcode automatically generates these files and directories

From the beginning, the first execution of the application begins with the main function.

int main (int argc, char * argv[]) {    @autoreleasepool {        return Uiapplicationmain (argc, argv, Nil, Nsstringfromclas S ([Appdelegate class]));}    }

See the notes for the Uiapplicationmain () method in the source code:

IF Nil is specified for Principalclassname, the value of Nsprincipalclass from the info.plist is used. If there is no//nsprincipalclass key specified, the UIApplication class is used. The delegate class would be instantiated using init. Uikit_extern int uiapplicationmain (int argc, char *argv[], nsstring *principalclassname, NSString *delegateclassname);

If the third parameter is nil, it is read from the Info.plist. You can think of info.plist as a manifest file in Android that lets the compiler know some basic information about the app.

The fourth parameter is the managed class name of the application, where you can first understand the managed class as a activity.class.

The application class in Android uses application to callback the activity's various life cycle functions. iOS, the first Uiapplicationmain () method creates and initializes an instance of UIApplication based on the name of the Appdelegate class we provide, and Appdelegate acts as a delegate to the UIApplication and invokes the life cycle methods in Appdelegate.

< Span style= "Background-color:rgb (255,255,255)" > Just as there is an interface in the application class in Android that contains the activity's various life cycle functions (see the Declaration in the application class for details: interface activitylifecyclecallbacks Not much to explain here) we can also find a similar protocol by looking at the UIApplication class. Limited space, only six methods explicitly listed in the Appdeletegate class are listed here

@protocol uiapplicationdelegate<nsobject> @optional-(BOOL) Application: (UIApplication *) application Didfinishlaunchingwithoptions: (nsdictionary *) launchoptions Ns_available_ios (3_0);-(void) Applicationdidbecomeactive: (UIApplication *) application;-(void) applicationwillresignactive: (UIApplication *) application;-(void) Applicationwillterminate: (UIApplication *) application;-(void) Applicationdidenterbackground: ( UIApplication *) Application Ns_available_ios (4_0);-(void) Applicationwillenterforeground: (UIApplication *) Application Ns_available_ios (4_0);

Then these six methods are the six life cycle methods in iOS apps. The specific validation rules are not much to say, we have to make a log to see the application of the status of the callback on the line. In fact, from the name also basically can understand a general. Referring to the activity life cycle of several methods callback diagram, I also summed up the Appdelegate several methods callback diagram is a kind of note.

Viewcontroller, this class I understand is used to do some view definition and initialization related operations. Similar to an activity in Android Decorview (if you want to ask what Decorview is ...) Think of it as a view in the Setcontentview.

Every app in Android can have multiple window objects, because each activity has a window, and in iOS, there's only one window (at least for now I know only one of my levels), Then the implementation of the jump interface is actually switching the viewcontroller to achieve. It's like switching fragment in activity to achieve a page jump.

Next, storyboard, this is actually a file for dragging the control to implement the layout. However, unlike Android's Layout.xml, there are three ways to create layouts in Android, the first is the pure drag control, the second is to manually write the XML code, the third is to manually write Java code, here I will not say more. There are only two options in iOS, pure drag control, manual write OC code. Yes, the storyboard file of the drag control you can't edit it with code (or I won't edit it yet). So now there is a lot of controversy, some people say that in order to maintain the convenience of the code layout should be advocated, some people say that according to the development trend, more should be used to drag the control of the way. As a developer from Android, I suggest you go with the code implementation, as in Android, write code layout can make you more convenient to understand the control in the interface of the drawing process, on the other hand as a novice, more familiar with the code is a good thing.

Further down, there is a Ios3test folder, the book is used to write unit tests, so there is no need to consider too much.

Further down, the product folder is equivalent to the bin directory in Android, which is used to store the compiled files.

App lifecycle functions from Android to Ios,ios