2010-08-06 4 views
2

problème rapide:Problèmes avec l'interface Orientation et UITabBarController

J'ai un UITabBarController avec 2 contrôleurs de navigation [permet de les appeler contrôleur gauche et droite]

Sur le défaut sélectionné Controller gauche je peux pousser un nouveau View Controller qui détecte l'orientation de l'interface.

Sur le contrôleur droit je peux pousser le même contrôleur de vue, mais il ne détectera pas l'orientation de l'interface, ou pour cette matière, il ne va pas même dans la méthode shouldAutoRotateInterface du tout T___T

Haaalp !!

Si cela est pertinent, le contrôleur de vue que j'utilise utilise la propriété hidesBottomBarWhenPushed.

Répondre

0

Votre uitabbarcontroller est-il compatible avec la rotation automatique? Tout viewcontroller enfant qui veut implémenter autorotate doit avoir son autorotate parent implémenter.

+0

Pourriez-vous me dire où puis-je définir cette propriété? Le projet a été créé avec le modèle TAB BAR. Par conséquent, tabBarController se trouve sur le fichier mainwindow.xib en tant qu'IBOutlet de l'assistant. La chose étrange est .... le contrôleur sur la gauche fonctionne bien ..il s'autorise ... mais celui de droite ne fait pas partie de T___T –

13

Très probablement c'est votre problème:

contrôleurs de barre d'onglets prennent en charge une orientation portrait par défaut et ne le font pas tourner à une orientation paysage à moins que tous les contrôleurs de vue racine soutenir une telle orientation . Lorsqu'un changement d'orientation du périphérique se produit, le contrôleur de barre d'onglets interroge sa matrice de contrôleurs de vue. Si l'un d'entre eux ne prend pas en charge l'orientation , la barre d'onglets ne modifie pas son orientation .

La solution consiste à remplacer la méthode suivante sur chaque contrôleur de vue menant à votre vue:

- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)orientation { 
    return YES; 
} 

Par exemple, en utilisant à la place la valeur par défaut UITabBarController dans IB, le remplacer par votre propre sous-classe contenant juste la méthode ci-dessus.

+0

+1, bien que dans mon expérience il ne soit pas nécessaire de sous-classer UITabBarController. (Au moins, c'est le cas de iOS SDK 4+, je ne suis pas sûr des versions précédentes.) – Tom

+0

c'est incroyable comment tout est là dans la documentation, mais nous prenons rarement la peine de le lire. Merci Jano pour l'extrait, ça m'a sauvé de beaucoup de chagrin. – bizsytes

8

Je suis un peu en retard à la fête sur ce sujet, mais j'ai rencontré un problème avec l'autorotation au démarrage pour une application de barre d'onglets que je voulais toujours exécuter en portrait.

Le plist de l'application dispose des paramètres nécessaires pour démarrer et autoriser uniquement le mode portrait, et tous mes contrôleurs de vue autorisent uniquement le mode portrait. Pourtant, quand j'ai commencé l'application en tenant mon iPhone en paysage, l'application a commencé en portrait, mais ensuite tourné vers le paysage!

Plutôt que de sous-classe UITabBarController, je simplement l'emportaient sur la méthode de shouldAutorotateToInterfaceOrientation:UITabBarController en utilisant une catégorie de la classe UITabBarController. J'inclus ce code dans mon délégué app:

@implementation UITabBarController(UITabBarControllerCategory) 

-(BOOL)shouldAutorotateToInterfaceOrientation: 
       (UIInterfaceOrientation)toInterfaceOrientation 
{ 
    return (toInterfaceOrientation == UIInterfaceOrientationPortrait); 
} 

@end 

fonctionne à merveille, et est tout à fait léger.

+0

Je viens de lire un gros fil sur SO qui dit qu'il n'est pas conseillé de surcharger les méthodes d'une classe dans une catégorie de la classe. Cela peut marcher, mais parler de façon pédante n'est pas un bon design. Parce que, en effet, ce que vous avez fait ici est de remplacer l'implémentation originale de la classe UITabBarController 'shouldAutorotateToInterfaceOrientation par votre implémentation. Contrairement aux sous-classes qui surchargent l'implémentation de la méthode de la superclasse et peuvent invoquer [super méthode], les catégories ayant les mêmes noms de méthode que dans la classe d'origine remplacent les implémentations de méthodes originales. – SayeedHussain

+0

En général, je suis d'accord avec vous. Mais, dans l'exemple que j'ai cité, j'ai voulu remplacer l'implémentation originale de la classe, partout. C'était la façon la plus simplifiée de le faire, plutôt que de sous-classer 'UITabBarController'. Si j'avais sous-classé 'UITabBarController' mon implémentation de' shouldAutorotateToInterfaceOrientation' n'aurait pas appelé la méthode super-classe de toute façon. Donc, les frais généraux supplémentaires de sous-classement n'aurait pas valu l'effort, les meilleures pratiques en dépit. Parfois, vous devez faire des compromis pour l'efficacité et le temps qui ne sont pas toujours considérés comme des «meilleures pratiques». :-) –

Questions connexes