Quelle est la différence entre ces deux ViewController Pushes?

Question

Quelles sont les différences et les conséquences des différences entre la poussée boilerplate fourni par Apple

 <#DetailViewController#> *detailViewController = [[<#DetailViewController#> alloc] initWithNibName:@"<#Nib name#>" bundle:nil]; 
NSManagedObject *selectedObject = [[self fetchedResultsController] objectAtIndexPath:indexPath]; 
// ... 
// Pass the selected object to the new view controller. 
[self.navigationController pushViewController:detailViewController animated:YES]; 
[detailViewController release]; 

et cette méthode (de PragProg livre de développement iPhone SDK) contrôleur de l'armoire est ajouté à l'interface et @synthesize mise en œuvre:

[self.navigationController pushViewController:self.cabinetController 
             animated:YES]; 

Je voudrais craie jusqu'à la nouveauté du SDK je travaille avec le livre par rapport ... mais qui semble vraiment différent et semble impliquer très différente propriété, si tel est le mot correct. Ma principale préoccupation, si la question est trop alambiquée pour répondre, est de savoir si l'une de ces méthodes est plus efficace sur le plan de la mémoire.

EDIT: ok, eh bien, après avoir effacé ma vision en postant cette question ... je ne pense pas qu'il y ait une grande différence. la méthode boilerplate alloue de la mémoire à la demande où la méthode books fait de la vue cabinet une propriété. Je pense que cela rend la méthode plus simple en quelque sorte ... ou égale ... cette partie je suis toujours floue. il semble que les deux vont sortir exactement la même chose mais peut-être que la mémoire est tenue plus tôt en utilisant la méthode des livres.

Answer 1

La version Apple est plus efficace en termes de mémoire, car la vue detailViewController sera désallouée lorsqu'elle sera retirée de la pile du contrôleur de navigation. Contrairement à la version PragProg, qui conserve le cabinetController dans une variable d'instance (et empêche donc son désallocation), le code Apple ne stocke pas de référence au contrôleur de détail qu'il crée. L'implémentation de PragProg peut avoir un sens si l'utilisateur navigue fréquemment entre le contrôleur de l'armoire et le contrôleur de vue qui le conserve, car cela évite un peu de surcharge de l'UC en créant et en libérant les objets à plusieurs reprises, mais vous devrez le profiler pour voir si cela fait une différence significative (ce qui normalement ne le ferait pas).

Answer 2

Dans le second cas, il semblerait que cabinetController soit une propriété de la classe indiquée par self. Dans le passe-partout, ce n'est pas le cas.