Le Multithreading dans iOS - comment forcer un thread à attendre pour un état?

Je suis en création d'une application qui extrait un ensemble de résultats à partir d'une base de données - je utiliser MBProgressHUD pour montrer le progrès de la requête avec une animation. La méthode que j'utilise les appels de l'animation lors de l'exécution d'une méthode dans un autre thread, et une fois que c'est fait, il se cache de l'animation. Ma question est, après l'appel:

[HUD showWhileExecuting:@selector(getResults) onTarget:self withObject:nil animated:YES];

Je voudrais, si il n'y a pas de résultats, afficher un message d'alerte disant cela, et si il y a, de charger la vue suivante. Jusqu'à présent, j'ai ce code:

[HUD showWhileExecuting:@selector(getResults) onTarget:self withObject:nil animated:YES];

if(self.thereAreEvents) {
    [self performSegueWithIdentifier:@"searchResults" sender:self];
} else {
    UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"No results" message:@"Sorry, there are no results for your search. Please try again." delegate:self cancelButtonTitle:@"OK" otherButtonTitles:nil, nil];
    [alert show];
    [alert release];
}

self.thereAreEvents obtient à la fin de la getResults méthode. Toutefois, cette méthode est appelée dans un autre thread dans cette ligne de l'exécution continue et montre l'alerte, même si il y a des événements dans la base de données.

Donc, d'ici la, j'ai deux questions: Quelle est la façon la plus simple à mettre en œuvre une attente du signal mécanisme iOS et quel est le moyen le plus efficace pour mettre en œuvre ce type de mécanisme dans iOS?

Merci!

InformationsquelleAutor KerrM | 2012-03-06
  1. 2

    Vous pourriez aussi envisager un NSConditionLock.

    De sorte qu'il serait quelque chose comme ça sur le thread 1:

    [conditionLock lockWhenCondition:kConditionOkayToProceed];
[conditionLock unlockWithCondition:kConditionGettingResults];

[HUD show...]

[conditionLock lockWhenCondition:kConditionResultsFetched];
[conditionLock unlockWithCondition:kConditionOkayToProceed];

    Et de la PALETTE:

    - (void)show...
{
    [conditionLock lockWhenCondition:kConditionGettingResults];

    //stuff here

    [conditionLock unlockWithCondition:kConditionResultsFetched];
}

    Si une bien meilleure solution serait de passer d'un bloc ou d'une cible de sélection de la PALETTE qu'il consiste à effectuer lorsque les résultats sont récupérés.

    EDIT: donc vous retrouver avec un code comme:

    [HUD showWhileExecuting:@selector(getResults)
     onTarget:self
     withObject:nil
     animated:YES
     performWhenFinished:
     ^{
         if(self.thereAreEvents) {
             [self performSegueWithIdentifier:@"searchResults" sender:self];
         } else {
             UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"No results" message:@"Sorry, there are no results for your search. Please try again." delegate:self cancelButtonTitle:@"OK" otherButtonTitles:nil, nil];
             [alert show];
             [alert release];
         }
      }];

    Et de la PALETTE:

    - (void)showWhile... performWhenFinished:(dispatch_block_t)block
{
     //all the other stuff you were going to do here, then
     //eventually...

     //if no guarantees, maybe just:
     block();

     //otherwise, if promised to dispatch to the main queue:
     dispatch_async(dispatch_get_main_queue(), block);
}

    Avec la PALETTE d'avoir le supplément de l'intelligence de prendre un dispatch_block_t comme un dernier argument, et de l'appeler quand les résultats sont (si garantissant l'expédition de retour vers le thread principal ou autre).

    • Je vois. Il y a encore beaucoup de choses que j'ai à apprendre la programmation pour iOS! Je vais jeter un oeil dans cette. Merci!
    • Le "pass un bloc" motif est relativement nouveau, mais qui semble être la direction d'Apple sont dirigés par la nouvelle Api d'iOS 5. Découvrez par exemple TWRequest ou ACAccountStore. En fait, il serait probablement préférable d'utiliser completionHandler: plutôt que performWhenFinished: pour alimenter le bloc, conformément à la convention qui semble émerger.
    InformationsquelleAutor Tommy
  2. 11

    Vous pouvez utiliser une longue boucle d'attente pour un accès rapide et sale solution:

    __block BOOL finished = NO;
dispatch_async(/* global queue */, ^{
    //…
    finished = YES;
});
while (!finished) /* waiting */;

    Dans la “vraie” code il est préférable d'utiliser un sémaphore:

    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
dispatch_async(/* global queue */, ^{
    //…
    dispatch_semaphore_signal(semaphore);
});
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
dispatch_release(sempahore);

    C'est mieux que la boucle occupée parce que le thread bloqué ne mange pas de temps CPU.

    La meilleure solution est de garder de blocage et de refonte de votre code afin de travailler de manière asynchrone. Dans votre cas, vous devez afficher un spinner et démarrer le téléchargement des données. Lorsque les données est terminé le téléchargement, vous devriez recevoir un rappel asynchrone (soit par le biais d'un bloc ou d'un objectif/action de rappel) et d'afficher les résultats ou afficher les alertes d'erreur. Blocage avec une longue boucle ou un sémaphore est un homme pauvre solution dans ce cas.

    • Merci pour la réponse. En toute honnêteté, je suis complètement perdu quand il s'agit de la programmation iOS, mais je vais regarder dans les rappels asynchrones. Merci encore!
    • Juste un commentaire, dispatch_release n'est pas nécessaire, car iOS6
    InformationsquelleAutor zoul
  3. 0

    Ne sais pas si c'est la meilleure façon de le faire, mais je vais essayer, à l'aide d'une boucle while pour observer certains booléenne avec quelque chose comme [NSThread sleepForTimeInterval:1]; à l'intérieur de la boucle.

    Peut-être définir un délai d'attente ainsi.

    InformationsquelleAutor Jiho Kang
  4. 0

    C'est votre manière:
    La Simultanéité Guide De Programmation

    Aussi: La synchronisation

    Plus forte: L'Utilisation De Verrous. Je crois que le dernier pourrait donner la meilleure aide.

    Une autre approche simple, c'est mauvais, mais fonctionne

    NSAssert(![NSThread isMainThread], @"Do not run on MAIN thread");
while (yourCondition) { [NSThread sleepForTimeInterval:0.2]; }
    InformationsquelleAutor SVGreg
  5. 0

    vous pouvez utiliser dispatch_time_t comme..

    double delayInSeconds = 2.0;
dispatch_time_t popTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(delayInSeconds * NSEC_PER_SEC));
dispatch_after(popTime, dispatch_get_main_queue(), ^(void){
    <#code to be executed on the main queue after delay#>
});
    InformationsquelleAutor Hardik Darji