2009-08-31 8 views
15

J'ai une vue qui est chargée dans MainWindow.xib. C'est juste une vue avec une vue d'image qui montre une image sur tout l'écran (320 X 480). Lorsque les charges Appi afficher ce point de vue, puis je fais unIPhone - Gap d'ajout d'UIView en haut

[self.view addSubview:tabbarController.view]; 

Tab Bar Controller est juste un UITabBarController avec 2 contrôleurs de vue ajoutés. Quand il ajoute la vue de tabbarController à la sous-vue, il laisse un espace au sommet d'environ 20px. Mon application dispose d'une barre d'état, mais il s'agit essentiellement de la place pour un autre. Cela se produit à moins que j'ajoute ceci à mon contrôleur de vue:

self.view.frame = CGRectMake(0, 0, 320, 480); 

Quelqu'un peut-il expliquer cela. Je faisais

self.view = tabbarController.view; 

mais on m'a dit que je ne devrais pas faire cela. Donc maintenant j'ajoute une sous-vue, mais je ne comprends pas pourquoi je dois ajuster le CGRect de ma vue pour ne pas montrer le 20px.

Répondre

17

UITabBarController s'attend à ce que sa vue soit ajoutée en tant que sous-vue de UIWindow, pas en tant que sous-vue d'un autre UIView. La propriété frame définit le décalage de la vue dans sa vue d'ensemble, de sorte que l'implémentation UITabBarController décale par défaut de 20 pixels la vue de la vue pour laisser de la place à la barre d'état. Vous utilisez UITabBarController d'une manière non standard en l'ajoutant à une vue qui a déjà été décalée de 20 pixels pour la barre d'état. UITabBarController décale sa vue de 20 pixels supplémentaires par rapport à sa vue d'ensemble, provoquant l'écart que vous voyez.

Une façon propre pour résoudre ce problème est d'ajouter le point de vue de la UITabBarController en tant que sous-vue de la fenêtre au lieu d'une vue:

[[[UIApplication sharedApplication] keyWindow] addSubview:tabbarController.view]; 

(Note: La méthode keyWindow ne retournera votre fenêtre si vous avez déjà appelé makeKeyAndVisible Sinon, vous pouvez définir une propriété window sur votre UIViewController.)

+0

Merci pour une explication claire. Peut-être que je devrais revenir en arrière et restructurer une partie de mon application. Je veux faire les choses de la bonne façon, mais je pensais qu'il serait peut-être préférable de séparer la logique du contrôleur de vue du délégué de l'application - ainsi mon contrôleur de vue racine fait tout ce dont il a besoin. Cela expliquerait pourquoi dans mon contrôleur de vue racine si je faisais self.view = tabbarController.view au lieu d'ajouter comme sous-vue, je n'aurais pas l'écart. Très bonne réponse. Je voterais plus si je le pouvais. – Brian

+0

Il semble que votre instinct était bon ici. C'est juste une de ces limitations de conception dans Cocoa Touch que nous devons contourner pour l'instant. Gardez à l'esprit que vous n'avez pas nécessairement besoin d'ajouter tabbarController.view à votre fenêtre à partir du délégué de votre application. Vous pouvez l'ajouter dans votre contrôleur de vue si c'est là que vous pensez que cela a le plus de sens. Vous avez juste besoin d'avoir accès à l'objet window, soit via la méthode keyWindow, soit en le définissant comme une propriété sur votre contrôleur dans applicationDidFinishLaunching :. – cduhn

+0

mais cela ne signifie-t-il pas que tabbarcontroller.view est maintenant une sous-vue de window.view? Mais ce n'est pas correct dans mon cas j'ai une vue d'annonce, et puis une deuxième vue de contenu. Et j'ajoute le tabbarcontroller.view au contentview. De cette manière, le viewcontroller gérera le contenu/l'affichage en fonction des publicités. si j'ajoute le tabbarcontroller.view à la fenêtre, je ne pense pas que je serai capable de gérer les vues en utilisant mon viewcontroller. Qu'est-ce que tu penses? – LolaRun

Questions connexes