2014-10-02 7 views
18

Ho un UITableViewController in uno storyboard. Ho selezionato il mio prototipo UITableViewCell per avviare un seguito per presentare un altro controller. La presentazione stessa sta funzionando.Selezione UITableViewCell La storyboard successiva è lenta - il doppio tocco funziona sebbene

Ho notato uno strano bug (probabilmente introdotto in iOS 8) che toccando la cella evidenzia la cella come previsto, ma a volte richiede alcuni secondi prima di eseguire il seguito. Toccando sulla cella due volte il seguito avviene immediatamente.

Qualcun altro ha notato questo in iOS 8?

EDIT: Ho notato che non è solo un doppio tocco che fa scattare il passo più velocemente. È anche un tocco sulla cella seguito da un colpo ovunque. Cominciando a sembrare un problema di threading per me ...

+1

Nessun codice, solo segue nello storyboard? Cosa succede se si aggiunge 'performSegue' su' didSelectRow'? PS: Odio usare segues, l'unica ragione per cui li aggiungo è contrassegnare il flusso dell'applicazione. –

+0

Sì, inserisco il codice, ma non ce n'è, in pratica. Ho provato quello che hai detto, lo stesso problema. – Keller

+0

Devi fare qualcosa. Ho provato con vecchi progetti e ne ho creato uno nuovo, ma non c'è alcun ritardo tra selezione e push, proprio come prima iOS8. –

risposta

23

Nel mio caso, la soluzione è stato quello di chiamare performSegue manualmente dal didSelectRow sulla coda principale utilizzando GCD invece di utilizzare l'uscita UITableViewCell selezione nella Storyboard.

- (void) tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath { 
    dispatch_async(dispatch_get_main_queue(), ^{ 
    [self performSegueWithIdentifier:kShowDetailSegue 
          sender:nil]; 
    }); 
} 

io non sono sicuro perché questo è diventato necessario- certamente si potrebbe pensare che la presa di selezione nella Storyboard opererebbe sulla coda principale, ma forse si tratta di un bug di iOS 8.

+1

Questo risolve il problema, grazie! @Keller –

+2

Se vuoi che questo segue si comporti allo stesso modo del seguito originale. Invece di 'sender: nil' usa' mittente: [tableView cellForRowAtIndexPath: indexPath] '. Ciò significa che, in preparazione per i passaggi, è possibile utilizzare il mittente per determinare IndexPath come è spesso necessario quando si imposta il controller della vista di destinazione. – nacross

+0

Stavo riscontrando un problema simile in cui la chiamata programmatica performSegueWithIdentifier richiedeva letteralmente 10+ secondi prima di caricare effettivamente la vista successiva.Non sapevo che tipo di assurdità di thread stesse succedendo dietro le quinte, ma l'invio sulla coda principale ha risolto anche il mio problema. Per quello che vale, stavo facendo un uso significativo della connettività multipeer (e non molto altro); non sono sicuro che sia correlato – GrandOpener

3

Carlos Vela è corretto, il bug si sta esaurendo solo quando la selezione di UITableViewCell è nullo e solo sul dispositivo reale. Riattivare CFRunLoop dopo la selezione risolve il problema e questo mi ha portato a questa soluzione "universale" (che è una categoria su UITableViewCell).

AGGIORNAMENTO: funziona perfettamente con iOS7 ma sotto iOS8 si rompe lo sfondo trasparente di UITableViewCell (sarà bianco).

#import <objc/runtime.h> 

@implementation UITableViewCell (WYDoubleTapFix) 

+ (void)load 
{ 
    Method original, swizzled; 

    original = class_getInstanceMethod([UITableViewCell class], @selector(setSelected:animated:)); 
    swizzled = class_getInstanceMethod([UITableViewCell class], @selector(mySetSelected:animated:)); 
    method_exchangeImplementations(original, swizzled); 
} 

- (void)mySetSelected:(BOOL)selected animated:(BOOL)animated 
{ 
    [self mySetSelected:selected animated:animated]; 
    CFRunLoopWakeUp(CFRunLoopGetCurrent()); 
} 

@end 
Problemi correlati