À partir d'iOS7, les contrôleurs de vue utilisent la mise en page plein écran par défaut. Dans le même temps, vous avez plus de contrôle sur la façon dont il expose ses vues, et thats fait avec ces propriétés: Fondamentalement, avec cette propriété, vous définissez les côtés de votre vue peut être étendu pour couvrir l'écran entier. Imaginez que vous poussez un UIViewController dans un UINavigationController. Lorsque la vue de ce contrôleur de vue est disposée, elle débutera où la barre de navigation se termine, mais cette propriété définit les côtés de la vue (haut, gauche, bas, droite) qui peuvent être étendus pour remplir l'écran entier. Laissons le voir avec un exemple: Ici, vous ne définissez pas la valeur de edgesForAxtendedLayout. Donc la valeur par défaut est prise (UIRectEdgeAll), de sorte que la vue étend sa mise en page pour remplir l'écran entier. Ceci est le résultat: Comme vous pouvez le voir, le fond rouge s'étend derrière la barre de navigation et la barre d'état. Maintenant, vous allez définir cette valeur sur UIRectEdgeNone. Vous indiquez au contrôleur de vue de ne pas étendre la vue pour couvrir l'écran: Cette propriété est utilisée lorsque votre vue est un UIScrollView ou similaire, comme un UITableView. Vous voulez que votre table commence où la barre de navigation se termine, parce que vous ne verrez pas le contenu entier sinon, mais en même temps, vous voulez que votre table couvre l'ensemble de l'écran lors du défilement. Dans ce cas, l'ajustement de edgesForAxtendedLayout à None ne fonctionnera pas car votre table commencera à défiler où la barre de navigation se termine et elle ne va pas derrière elle. Voici où cette propriété est pratique, si vous laissez le contrôleur de vue automatiquement ajuster les encarts (en mettant cette propriété à OUI, également la valeur par défaut), il ajoutera inséré au haut de la table, de sorte que la table commencera où la navigation Bar, mais le défilement couvrira l'écran entier. C'est alors qu'est réglé sur NON: Et OUI (par défaut): Dans les deux cas, la table défile derrière la barre de navigation, mais dans le deuxième cas (OUI), elle commencera en dessous de la barre de navigation. Cette valeur est juste un ajout aux précédentes. Si la barre d'état est opaque, les vues ne seront pas étendues pour inclure la barre d'état trop, à moins que ce paramètre soit OUI. Donc, si vous étendez votre vue pour couvrir la barre de navigation (edgeForExtendedLayout à UIRectEdgeAll) et le paramètre est NO (par défaut), il ne couvrira pas la barre d'état si son opaque. Si quelque chose n'est pas clair, écrire un commentaire et réponse mal à elle. Comment iOS sait ce que UIScrollView à utiliser iOS saisit la première sous vue dans votre vue viewcontrollers, donc celle de l'index 0, et si c'est une sous classe de UIScrollView applique alors les propriétés expliquées à elle. Bien sûr, cela signifie que UITableViewController fonctionne par défaut (puisque l'UITableView est la première vue). Cycle de vie de l'objet: UIViewController Lors de la programmation dans iOS, it8217s inévitable que you8217ll besoin de sous classe UIViewController. Ces sous classes contiennent toute la logique qui rend vos applications apparaissent et se comportent comme ils devraient. Il est difficile de mettre en place une sous classe sans savoir quelles méthodes remplacées seront appelées et quand. Pour remédier à cette confusion potentielle, ce message examinera le cycle de vie d'un UIViewController. Une configuration simple C'est ce que ressemble notre configuration dans Interface Builder. Nous allons examiner la scène B. Ce contrôleur fait partie d'une pile UINavigationController et contient une autre scène via une vue de conteneur. Comme la plupart des contrôleurs, le contrôleur Scène B8217s a des références aux objets créés dans Interface Builder à l'aide des propriétés IBOutlet. Le contrôleur A pousse vers le contrôleur B Lorsque la scène A déclenche un suivi 8216show8217, ces méthodes surchargées sont appelées sur le contrôleur de scènes B8217 dans l'ordre suivant: initWithCoder: Lors de l'utilisation de storyboards, le contrôleur est initialisé avec cette méthode et non avec init ou initWithNibName: bundle : Méthodes. AwakeFromNib willMoveToParentViewController: Le contrôleur passé avec cet appel est UINavigationController. PrefitorsStatusBarHidden preferredStatusBarUpdateAnimation loadView UIViewController 8216s La fonction loadView affecte tous les objets avec 8216Referencing Outlets8217 (également appelés IBOutlets) dans Interface Builder à leurs propriétés IBOutlet correspondantes. Si vous avez besoin d'accéder à ces objets IBOutlet dans cette fonction, appelez d'abord super. PrepareForSegue: sender: Cet appel nous permet d'inspecter l'UIStoryboardEmbedSegue qui intègre la plus petite scène dans la vue de conteneur de Scene B8217s. ViewDidLoad Cette méthode est généralement où la plupart des controller8217s mis en place se produit. Notez que tous nos IBOutlets ont été connectés, mais nos points de vue n'ont pas encore été définis. ExtendedLayoutIncludesOpaqueBars edgeForExtendedLayout viewWillAppear: extendedLayoutIncludesOpaqueBars edgesForTexxtLayout updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Animation L'animation qui passe de la scène A à la scène B s'exécute. L'étape 18 ne se produit pas jusqu'à ce que l'animation se termine. ViewDidAppear: didMoveToParentViewController: Cet appel conclut le processus démarré à l'étape 2. Nous recevons ici la même instance de UINavigationController. UpdateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Cela répond à quelques questions sur les appels qui viennent en premier, en plus d'exposer certaines bizarreries intéressantes. Plusieurs appels apparaissent apparemment plus d'une fois. La vue scene8217s effectue sa mise en page deux fois, une fois avant et une fois après son animation. La scène interroge également de manière redondante le contrôleur sur la disposition étendue. Contrôleur B Pousse vers le contrôleur C De la même manière que pour notre dernière transition, la scène B déclenche maintenant un 8216show8217. Les méthodes contrôlées par le contrôleur 8217 sont appelées dans l'ordre suivant: prepareForSegue: sender: Cet appel nous permet d'inspecter l'objet UIStoryboardShowSegue qui suivra la scène C. viewWillDisappear: updateViewConstraints Animation L'animation qui passe de la scène B à la scène C s'exécute. L'étape 5 ne se produit pas tant que l'animation n'est pas terminée. ViewDidDisappear: Pas de surprises ici. Nous ne recevons que quelques appels et tous semblent avoir un sens dans ce contexte. Le contrôleur C Pops au contrôleur B Maintenant que nous avons passé la scène B, nous allons revenir. La scène B est chargée via un pop UINavigationController (par opposition à la poussée dans le premier exemple). Nous obtenons les appels suivants: prefersStatusBarHidden preferredStatusBarUpdateAnimation extendedLayoutIncludesOpaqueBars edgesForPageExclusiveLayout viewWillAppear: extendedLayoutIncludesOpaqueBars edgesForTexxtLayout updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Animation L'animation qui passe de la Scène C à la Scène B s'exécute. Étape 12 ne se produit pas jusqu'à ce que l'animation se termine. ViewDidAppear: updateViewConstraints viewWillLayoutSubviews viewDidLayoutSubviews Ces appels et leurs commandes doivent être assez familiers de la première transition. Notamment absents sont quelques unes des étapes d'installation ponctuelles. Le contrôleur est toujours à l'intérieur du UINavigationController de sorte qu'il n'y a pas d'appels concernant le contrôleur parent. Le contrôleur B Pops au contrôleur A We8217re maintenant fait avec notre contrôleur de Scène B. La suppression de la pile UINavigationController nous donne les appels suivants: willMoveToParentViewController: L'argument du contrôleur de vue dans cet appel est nil. Cela nous indique que la scène B est retirée de la hiérarchie. ViewWillDisappear: updateViewConstraints viewDidDisappear: Animation L'animation qui passe de la scène B à la scène A s'exécute. L'étape 6 ne se produit pas jusqu'à ce que l'animation se termine. DidMoveToParentViewController: Cet appel conclut le processus démarré à l'étape 1. Nous recevons ici le même argument nil. Dealloc Semblable à la deuxième transition, cette transition semble assez simple. Une fois que le contrôleur a été retiré de la hiérarchie, sa méthode dealloc est appelée comme tout autre NSObject. See For Yourself Le code que j'ai utilisé pour exécuter ce test est en place sur mon github ici. N'hésitez pas à l'essayer vous même, et insérez toutes les autres étapes que vous utiliserez dans vos propres contrôleurs. Catégories
No comments:
Post a Comment