Quand un callback Cocoa est-il contrôlé?

Question

J'ai cherché sur le web une réponse à celui-ci, mais je n'ai pas trouvé de réponse, de l'autre côté je pense que c'est quelque chose de très courant, donc il y a une possibilité que je manque des mots clés ici. Quoi qu'il en soit, le problème est le suivant:

Quand le contrôle est-il donné à une fonction de rappel dans ObjC (iPhone)?

Est-ce que cela se produit après le contrôle d'un haut dans la classe de hiérarchie responsable du cycle de démarrage? Peut-il se produire au milieu d'un autre appel de fonction en cours d'exécution?

À titre d'exemple, prenons le NSURLConnection, nous ne savons pas ou ne peut pas prédire quand il va appeler didReceiveResponse ou les autres méthodes de rappel, peut-il être le cas que didReceiveResponse get appelé quand je suis au milieu d'une autre fonction? (Doute fortement, mais n'a pas pu trouver des informations sur les callbacks wating pour la fin de la boucle d'exécution)

Cheers, Kaspa

Answer 1

peut-il être le cas que didReceiveResponse get est appelée lorsque je suis au milieu d'une autre fonction?

Non, dans un seul thread, le code n'est pas exécuté en parallèle. Le runloop planifie l'exécution de tous les messages et les distribue en séquences. Même les NSTimers ne sont pas sûrs de tirer avec la précision dont ils sont théoriquement capables, car ils doivent attendre le runloop comme tout le reste.

Answer 2

Les callbacks ne seront pas appelés à partir en milieu de votre fonction, en effet. Vous devez redonner le contrôle au runloop principal pour qu'il puisse traiter les événements et appeler votre callback.

Si vous voulez savoir exactement qui appelle votre rappel, placez un point d'arrêt et vérifiez la trace de la pile.

Answer 3

La seule fois où didReceiveReponse sera appelé alors que quelque chose d'autre est en cours d'exécution, c'est si vous avez lancé la connexion sur son propre thread (généralement dans une NSOperation). C'est pourquoi lorsque vous avez des connexions dans un thread d'arrière-plan, vous utilisez habituellement quelque chose comme performSelectorInMainThread pour changer la valeur pour d'autres parties de l'application - mais vous pouvez ajuster les propriétés directement si elles ne sont pas marquées collections.

Answer 4

Par défaut, toutes les classes tactiles de cacao fonctionnent par défaut dans un seul thread, y compris de nombreuses opérations asynchrones telles que les appels réseau d'arrière-plan. Les exceptions principales sont NSOperation et les amis, et les choses liées à NSThread.

Le système d'exploitation peut le faire en insérant ses rappels dans la planification de la boucle d'exécution. Il existe également quelques cas où l'un de vos appels entraînera également un rappel sur la même pile - par exemple, si vous appelez resignFirstResponder sur un objet qui notifie son délégué lorsque cela se produit, tel que UITextField.

Un couple messages de blog pertinents:

• quick intro to NSRunLoop
• Friendly overview of Objective-C callbacks