Événements de minuterie et d'animation qui troncent les événements TouchesEnded

Question

J'ai implémenté un gestionnaire tap-and-hold en utilisant un NSTimer que j'ai d'abord défini dans la surcharge de TouchesBegan. Cependant, ce que je veux réellement, c'est qu'une action soit continuellement exécutée dans une succession de tirs rapides pendant que le contact est maintenu. Donc, à l'expiration de la minuterie, j'appelle un gestionnaire pour faire le travail, qui définit ensuite une autre minuterie et le cycle continue jusqu'à ce que le TouchesEnded arrive et l'annule, ou une autre condition de fin est remplie.

Cela fonctionne très bien, jusqu'à ce que mon code de gestionnaire déclenche une animation pour se déclencher en même temps. Maintenant, nous avons des événements d'animation et des événements de minuterie qui se déclenchent, et dans tout ce que nous devons également gérer TouchesEnded. Ce que je trouve c'est que, si l'animation est déclenchée, et que j'ai réglé mon timer à moins de 0.025 secondes, mon événement TouchesEnded n'arrivera que lorsque le cycle de la minuterie s'arrêtera (l'autre condition de terminaison). Régler une minuterie plus lente, ou ne pas déclencher l'animation, le faire fonctionner (TouchedEnded vient tout de suite), mais ne sont pas ce que je veux.

Évidemment, cela est tout sur l'appareil (version build - pas NSLogs) - dans la carte SIM tout fonctionne bien

Est-il possible de régler la priorty relative de ces événements - ou est-il probable que je suis manque quelque chose d'autre évident ici?

 
[Update] 

Je travaille autour de ce dans ce cas en faisant la partie continue sans rétroaction visuelle jusqu'à ce qu'il soit fait (qui, de ce point de vue des utilisateurs est instantanée). Je pense que c'est ok pour le moment. Je voudrais encore entendre d'autres réflexions à ce sujet (l'idée de Jeffrey était bonne), mais je n'attends pas les charbons ardents maintenant.

Answer 1

Essayez d'écrire votre propre classe de type Timer en apparaissant sur un fil. Exemple:

BOOL continue = YES; //outside of your @implementation 

-(void)doLoop 
{ 
    while(continue){ 
     [NSThread sleepForTimeInterval:.025]; 
     [self performSelectorOnMainThread:@selector(whateverTheFunctionIs) waitUntilDone:YES]; 
    } 
} 

et ce serait commencé par [NSThread detatchNewThreadSelector:@selector(doLoop) toTarget:self withObject:nil]. Ce n'est pas exactement threadsafe, mais vous pouvez choisir d'envelopper le boolean dans un NSNumber et ensuite @synchronize dessus si vous le souhaitez. Alternativement, après avoir écrit ce petit extrait, j'ai réalisé qu'il serait préférable de faire une vérification par rapport à l'actuel NSTime au lieu de sleepForTimeInterval: mais vous obtenez le point. :)