interaction NSThread et UIViewController

Question

interaction NSThread et UIViewController

voix

5

Si je Spawn un nouveau fil, puis en son sein, je pousse un nouveau contrôleur sur mon UINavigationController, en utilisant le code comme ça ...

(A) ne fonctionne pas

-(void)myCallbackInThread
{
    // move on...
    UIApplication* app = [UIApplication sharedApplication];
    [app changeView];
}

je trouve que le point de vue semble, mais ne répond pas à l'entrée utilisateur.

Si je change le code comme celui-ci

(B) travailler

-(void)myCallbackInThread
{
    // move on...
    UIApplication* app = [UIApplication sharedApplication];
    [app performSelectorOnMainThread:@selector(moveToMain) withObject:nil waitUntilDone:FALSE];
}

Ensuite, tout fonctionne très bien.

Tous les conseils pour expliquer pourquoi?

iphone cocoa multithreading

Créé 03/10/2008 à 14:42
utilisateur Airsource Ltd

Dans d'autres langues...

4 réponses

voix

2

Je viens de trouver cela dans les documents de filetage iPhone

Si votre application dispose d'une interface utilisateur graphique, il est recommandé que vous recevez des événements liés à l'utilisateur et les mises à jour d'interface initiez du thread principal de votre application. Cette approche permet d'éviter des problèmes de synchronisation associés à la gestion des événements de l'utilisateur et le dessin contenu de la fenêtre. Certains cadres, comme le cacao, exigent généralement ce comportement, mais il a aussi l'avantage de simplifier la logique de la gestion de l'interface utilisateur.

Je ne vois toujours pas ce qui en fait causer quelque chose à afficher mais ne pas être en mesure de recevoir les commentaires des utilisateurs, mais je vais suivre cette ligne directrice à l'avenir.

Créé 03/10/2008 à 14:42
source utilisateur Airsource Ltd

voix

2

Comme la documentation dit: « Si vous n'êtes pas sûr d'une opération graphique particulière, prévoyez le faire à partir de votre thread principal. »

Une bonne règle à suivre est que, si une classe est pas explicitement documenté comme étant thread-safe, alors il est probablement pas. En outre, le code qui n'est pas documenté comme thread-safe ne défaille pas rapidement lorsqu'il est utilisé par plusieurs threads, mais peut simplement présenter un comportement non défini, comme vous l'avez vu.

Créé 03/10/2008 à 15:12
source utilisateur Evan DiBiase

voix

0

Presque aucun du code d'interface utilisateur dans UIKit ou AppKit est threadsafe. Comment ça échoue est irrelevent, parce que si vous vous inquiétez de la façon dont il ne vous faites quelque chose qui va donner lieu à toutes sortes de bugs étranges qui vont changer subtilement entre les différents OS version de toute façon.

Mon meilleur conseil est de ne pas utiliser les choses à partir de fils de fond à moins que les documents disent qu'il est sûr.

Créé 08/11/2008 à 00:11
source utilisateur Louis Gerbarg

Jason Coco · Accepted Answer · 2008-11-07 23:35

Dans votre cas, cela dépend vraiment de ce qui se passe dans [app ChangeView], mais la raison pour laquelle il cesse de répondre est plus probable que vous n'avez pas l'envoi d'événements boucle d'exécution sur votre nouveau thread secondaire (voir plus bas). En général, cependant, il est une très mauvaise idée de mettre à jour l'interface utilisateur graphique d'un thread secondaire. Comme vous l'avez déjà découvert, tous ces événements devraient passer par le fil conducteur.

La principale raison pour laquelle votre deuxième exemple fonctionne et non votre première est que UIApplication met en place et gère la boucle d'exécution et répartiteur d'événements pour vous sur le thread principal. Donc, lorsque vous appelez performSelectorInMainThread, le sélecteur se dépêcha à la boucle principale d'exécution qui est capable de gérer ensuite l'entrée de votre interface utilisateur graphique et d'autres événements. Le répartiteur d'événements est également dirigé et géré par UIApplication sur le thread principal.

Donc , fondamentalement, ne pas effectuer toutes les activités de gestion de l' interface graphique sur un fil secondaire. Expédition ceux du thread principal. Et si vous avez besoin de traitement sur un fil secondaire (pour des choses comme des minuteries ou des appels ASYNCH, etc.), vous devez démarrer et gérer votre propre boucle d'exécution sur ce thread (voir NSRunLoop pour en savoir plus sur la gestion de votre sur boucle d'exécution).