premier, un petit fond. Je suis nouveau au développement de l'IOS, je suis dans la terre .Net depuis longtemps, et c'est probablement pourquoi je pose même cette question, mais voilà.
La configuration de base est ceci. Vous avez un C'est à ma compréhension, que dans les versions précédentes du SDK (avant IOS 5), l'approche était similaire à celle-ci: Toujours cependant, Dans iOS 5, il semble que cela soit fait à l'aide du storyboard et des segues. Dans XCode, vous avez configuré la SEGUE à partir du MasterViewController vers les DétailsViewController, puis dans le code, vous faites quelque chose comme ceci: Ma question est essentiellement la suivante: l'approche plus ancienne estime en quelque sorte beaucoup plus propre pour moi. Vous êtes très explicite sur le type de uinavigationController avec un rootviewcontroller Nous appellerons MasterViewController . Lorsque certaines actions se produisent sur cette maîtriseviewController, nous souhaitons percer dans un DétailsViewController . Cependant, nous souhaitons également transmettre certaines données sur le DétailsViewController . ViewController Vous appuyez sur la pile de navigation et vous pouvez définir facilement les propriétés dessus. Dans la nouvelle approche, DestinationviewController est de type ID (pour des raisons évidentes), et cela se sent beaucoup moins propre pour moi. Encore une fois, cela pourrait être mon côté .Net sortez, mais est-ce commun dans iOS? Utilisez simplement une pièce d'identité et jetez prudence au vent?
3 Réponses :
avec des storyboards, vous pouvez attribuer un identifiant nommé à la SEGUE, Sélectionnez la Segue et dans l'inspecteur des attributs, vous pouvez ajouter un nom à l'identifiant de Segue.
et dans la méthode PrepareforSegue, vous devez vérifier cet identifiant et savoir explicitement quelle SEGUE est sur le point d'être effectuée et de la vision de la pageViewController. être.
Mieux vaut mieux, mais vous avez toujours ce casting moche là-bas. Est-ce l'approche préférée?
C'est l'approche préférée. Vous avez raison, l'ancien chemin est plus clair et plus explicite. Avec la nouvelle méthode que vous «accrochez-vous dans» le storyboard. Malheureusement, il existe de nouvelles fonctionnalités que dans des storyboards qui ne se sont pas entrés dans le concepteur XIB, tels que le nouveau support statique et dynamique de concepteur de concepteur.
Cet extrait de code est-il inséré dans la méthode PREPARYFORSEGUEGE ?
Dans de nombreux cas, le contrôleur de visualisation de la destination pour une SEGUE peut être un uinavigationviewController et, dans ce cas, la solution (une légère modification de la solution de Dennis Mathews ci-dessus) devra utiliser le message "TopViewController":
Cela m'a fait le tour pour moi, sauf que je pense que vous voulez dire "UINAVIGATIONCONTROLLER * NAVCONTROLLER" plutôt que "NAVITATIONVIEWCONTROLLER * NAVCONTROLLER".
Je n'ai pas travaillé avec IOS aussi longtemps, mais j'ai vu quelques exemples où vous n'avez pas à couler à cause du système de messagerie couplé en vrac de l'objectif-C.
au lieu de vérifier l'identifiant de la Segue ou CASTING À UNE VIEWCONTROLLER SPÉCIFIQUE Vous pouvez le faire: P>
-(void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
if ([segue.destinationViewController respondsToSelector: @selector(setCompany:)]) {
[segue.destinationViewController performSelector: @selector(setCompany:) withObject: self.company];
}
}
Beaucoup de respect pour remettre en question comment cela se fait plutôt que de simplement copier et coller des extraits. J'ai également eu des questions similaires et avec une certaine expérience ici est ma réponse: avec iOS5, je vois que la logique UI a été scindée en deux: 1) ViewController Lifecycle et transitions 2) Flux de données. Storyboard s'occupe de 1 et les développeurs devraient s'occuper de 2. Dans un tel scénario, ces moulages se produiront. Pour moi, la question est que cette scission ait-elle un sens? Ces deux concepts peuvent-ils être découplés? Je suppose que Apple va comme ça et nous verrons comment ça marche.