2011-02-22 14 views
8

Qualcuno potrebbe spiegare come il controllo dell'esecuzione scorre in un'applicazione iOS? So che UIApplicationMain viene chiamato prima da main. Allora cosa? Qual è la relazione tra i miei metodi definiti e principale? È tutto guidato dagli eventi o può esserci qualche sequenza strutturata?Qual è l'ordine di esecuzione dell'obiettivo C dopo UIApplicationMain in Main?

Non intendo essere così vago, ho solo bisogno di sapere da dove cominciare. Forse lo sto guardando nel modo sbagliato.

Ad esempio, in C++ vorrei fare qualcosa di simile:

#include "myMethods.h" 
int main (int argc, char * const argv[]) { 

    Method1(); // Initialization 
    Method2(); // Opening views and options 
    Method3(); // Meat of the program 

    return 0; 
} 

Grazie in anticipo.

+2

FYI, 'UIApplicationMain()' non ritorna mai. L'app è terminata tramite una chiamata a 'exit()'. Quindi tutto ciò che mettete dopo 'UIApplicationMain (argc, argv, nil, nil);' in 'main()' non * mai * verrà eseguito. Mai e poi mai. –

+1

Ugh. @Dave se è vero, questo mi fa davvero impazzire. È come tornare ai tempi di BASIC quando abbiamo messo STOP nel mezzo di un GOSUB! –

risposta

7

come hai detto UIApplicationMain crea un esecuzione delle applicazioni nel sistema. Tra le cose che fa il processo di caricamento delle applicazioni, presumo che tu sia interessato a ciò che è rilevante per un'applicazione specifica. Presumo anche un caso tipico, che è illustrato in molti modelli di progetto forniti da Xcode.

Il processo di caricamento dell'applicazione esamina l'elenco delle proprietà delle informazioni dell'applicazione. Qui trova il 'Nome base del file del pennino principale' e l'istanza dell'applicazione UIA dell'applicazione carica il file del pennino corrispondente dal pacchetto dell'applicazione. Questo file di pennino specifica una classe di delega dell'applicazione e indica di connettere un'istanza della classe alla proprietà delegato dell'istanza di UIApplication.

seconda del file pennino principale, altri oggetti possono essere create e collegati così, ad esempio, la finestra dell'applicazione, il controllore vista principale, ecc

Ora la sequenza di caricamento termina, e tutto è evento -drive, a partire dalla classe del delegato dell'applicazione per ottenere il famoso messaggio -applicationDidFinishLaunching:.

2

da Apple Documenti -

Il ciclo di vita dell'applicazione costituisce la sequenza di eventi che si verifica tra il lancio e la cessazione della propria applicazione. In iOS, l'utente avvia l'applicazione toccando la relativa icona nella schermata Home. Poco dopo il rubinetto si verifica, il sistema visualizza alcuni grafici di transizione e procede per avviare l'applicazione chiamando la sua funzione principale. Da questo momento in poi, la maggior parte del lavoro di inizializzazione viene trasferito a UIKit, che carica il file di pennini principale dell'applicazione e prepara il ciclo degli eventi.

Application Life Cycle

17

Quindi, come già menzionato, la funzione main() in main.m è il punto di partenza, che quindi chiama UIApplicationMain(). Se si controlla i documenti, vedrai che UIApplicationMain prende quattro argomenti:

  • argc,
  • * argv [],
  • * principalClassName
  • * delegateClassName.

I primi due di questi sono solo il conteggio degli argomenti e l'elenco delle variabili passato da main(). Ma il terzo e il quarto argomento sono puntatori a NSStrings. Il terzo argomento specifica quale classe deve essere UIApplication. A meno che non si intenda sottoclasse UIApplication, si specifica nil per il terzo argomento.Il quarto argomento specifica quale classe deve essere la classe delegato di UIApplication, che risponderà a qualsiasi cosa specificata nel protocollo UIApplicationDelegate. Non dovete fare muck con questo direttamente, come è incluso in tutti i modelli di Xcode:

int main(int argc, char *argv[]) 
{ 
    @autoreleasepool { 
    return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); 
    } 
} 

Non lasciate che il bit NSStringFromClass([AppDelegate class])) si getta. Questo è solo un modo ingegnoso per specificare il quarto argomento in modo che venga chiamato il delegato giusto in caso di modifica successiva del nome di AppDelegate.m.

UIApplication avvia main event loop e chiama -application:didFinishLaunchingWithOptions:, uno dei metodi che il suo delegato deve gestire. Dai uno sguardo allo AppDelegate.m e troverai del codice template per questo metodo. Questo è dove si può iniziare la personalizzazione, la creazione di cose che devono essere a posto prima che gli altri UIWindow e istanze di UIView vengono creati:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 
{ 
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]]; 
    // Override point for customization after application launch. 
    self.viewController = [[ViewController alloc] initWithNibName:@"ViewController" bundle:nil]; 
    self.window.rootViewController = self.viewController; 
    [self.window makeKeyAndVisible]; 
    return YES; 
} 

Così, ora la finestra dell'applicazione e la vista della radice del controller vengono definiti, e l'applicazione è spento e funzionante.

Tutto questo, e un bel po 'di più, è ottimamente spiegato qui: http://oleb.net/blog/2012/02/app-launch-sequence-ios-revisited/