Problème après avoir ignoré une vue modale utilisée en conjonction avec un contrôleur uisplitview

Question

Je n'arrive pas à comprendre pourquoi ce qui suit se produit (et comment le réparer).

J'ai créé une application en utilisant l'application basée sur la vue partagée.

J'ai ajouté un UIBarButtonItem appelé showTheModal qui appelle cette méthode trouvée dans RootViewController.m:

- (IBAction)showTheModal:(id)sender { 
theModalController.modalPresentationStyle = UIModalPresentationFullScreen; 
theModalController.modalTransitionStyle = UIModalTransitionStyleCrossDissolve; 
[self presentModalViewController:theModalController animated:YES]; 

if ([detailViewController popoverController] != nil) 
    [[detailViewController popoverController] dismissPopoverAnimated:YES]; 

Le BarButtonItem bien sûr, est indiquée au bas du contrôleur racine par défaut (côté gauche du de la vue partagée dans le paysage) ou en bas de la fenêtre contextuelle (si en paysage).

La vue modale est ignorée par un bouton placé dans une barre d'outils. Il appelle ce qui suit:

[self dismissModalViewControllerAnimated: YES]; 

Le problème que j'ai est de faire pivoter l'écran, tandis que le modal est en hausse. Voici ce qui se passe dans différents scénarios (start fait référence à l'orientation lorsque le bouton showTheModal est touché, end fait référence à l'orientation lorsque j'appuie sur le bouton dismissModal).

1) Démarrer paysage, mettre fin paysage: Tout semble bien. Les méthodes willHideViewController et willShowViewController ne sont pas appelées dans le RootViewController (comme prévu)

2) Démarrer le paysage, mettre fin au portrait: l'interface utilisateur semble bien. willHideViewController est exécuté DEUX FOIS (POURQUOI?)

3) Démarrer le portrait, mettre fin au portrait: L'interface utilisateur semble bien. willHideViewController est exécuté une fois (comme prévu)

4) Démarrer le portrait, mettre fin au paysage: Le bouton 'Liste des racines' reste dans la vue détaillée (à droite de la vue partagée.) willHideViewController et willShowViewController sont invoqués (POURQUOI ??)

Toute pensée pour expliquer pourquoi # 2 et # 4 ne se comportent pas tout à fait de la manière attendue?

Answer 1

pour le diagnostic, avez-vous essayé de rejeter la vue popover d'abord? Ou l'exploitation forestière qui appelle la méthode en imprimant (id) sender?

Answer 2

J'ai eu exactement le même problème (# 4, ci-dessus). autour de lui en utilisant viewDidAppear:animated, puis en vérifiant la hauteur de la vue pour voir si elle est en mode paysage ou portrait. (Yuck, gag, etc.) Je ne suis pas du tout satisfait de cette "solution". Possiblement lié: J'ai remarqué que le bouton en mode portrait est lent à disparaître après la rotation en mode paysage, c'est-à-dire que le bouton apparaît une seconde après la fin de la rotation. Cependant, dans Mail.app, le bouton "Boîte de réception" disparaît dès que la rotation commence. Apple fait-il les choses différemment de ce qu'ils recommandent dans leurs documents? Peut-être existe-t-il un moyen plus efficace d'afficher/masquer le bouton de la vue principale?

Answer 3

Je pense que c'est un bug qui doit être signalé à Apple Development.

J'ai travaillé autour d'une partie de ce problème en présentant ma vue modale en utilisant le format UIModalPresentationPageSheet.

Answer 4

J'avais exactement le même problème.

En réponse à (2), il semble être un bug.J'ai remarqué que lorsqu'une vue modale est poussée sur un splitview, les messages d'orientation sont mis en attente quelque part et ne sont pas traités jusqu'à ce que la vue modale soit fermée et que la splitview soit visible, mais je m'attendrais à recevoir seulement un rappel.

Pour (4), cela semble également être un bug. Heureusement, les didRotate ... événements se encore à travers, donc ma solution était de sous-classe UISplitViewController et appeler explicitement la méthode willShowViewController du délégué dans ce cas:

- (void)didRotateFromInterfaceOrientation:(UIInterfaceOrientation)fromInterfaceOrientation 
{ 
    [super didRotateFromInterfaceOrientation:fromInterfaceOrientation]; 

    //Work around a bug where UISplitViewController does not send 
    //willShowViewController after a modal is presented in portrait 
    //but dismissed in landscape. 
    UIInterfaceOrientation orientation = self.interfaceOrientation; 
    if ((orientation == UIInterfaceOrientationLandscapeLeft) 
     || (orientation == UIInterfaceOrientationLandscapeRight)) 
    { 
     UINavigationItem* item = [detail.navigationBar.items objectAtIndex:0]; 
     UIBarButtonItem* barButtonItem = [item leftBarButtonItem]; 
     [super.delegate splitViewController:self willShowViewController:master invalidatingBarButtonItem:barButtonItem]; 
    } 
} 

Ici, « maître » est un IBOutlet qui fait référence au maître Contrôleur de vue (côté gauche) de la vue éclatée et "détail" est un IBOutlet pour le contrôleur de vue de détail (taille de la main droite).

Notez que dans mon cas, la vue détaillée est un UINavigationController. Vous pouvez avoir besoin de code différent pour obtenir le barButtonItem de votre contrôleur de vue.

En outre, cela a pour effet secondaire d'appeler deux fois willShowViewController pour une rotation normale, mais ce n'est pas un problème dans mon cas.

Answer 5

Malheureusement, ce n'est pas un bug. Il semble être un comportement attendu.

Je trouve cela dans iOS Notes de version pour iOS 5.0, dans la section « Notes et problèmes connus »:

callbacks de rotation dans iOS 5 ne sont pas appliquées pour voir les contrôleurs qui sont présentés sur un plein écran. Cela signifie que si votre code présente un contrôleur de vue sur un autre contrôleur de vue, l'utilisateur fait ensuite pivoter le périphérique dans une orientation différente, après , le contrôleur sous-jacent (c'est-à-dire le contrôleur de présentation) ne recevra aucune rotation. rappels. Notez cependant que le contrôleur présentateur recevra un appel viewWillLayoutSubviews quand il est réaffiché, et la propriété interfaceOrientation peut être interrogée à partir de cette méthode et utilisée pour disposer le contrôleur correctement.