В чем разница между этими двумя нажатиями ViewController?

Question

Каковы различия и последствия различий между стандартным нажатием, предоставляемым 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];

, и этим методом (из Книги разработки PrakProg iphone SDK) добавлен контроллер интерфейса и интерфейс @synthesize вреализация:

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

я бы отнес это к новизне SDK, с которым я работаю, по сравнению с книгой ... но это кажется действительно другим и, кажется, подразумевает ОЧЕНЬ другое владение, если это правильнослово.Моя главная проблема, если вопрос слишком сложен, чтобы ответить на него, является ли один из этих методов более эффективным для памяти.

РЕДАКТИРОВАТЬ: хорошо, хорошо, после очистки моего зрения, опубликовав этот вопрос ... яне думайте, что здесь так много различий.стандартный метод выделяет память по требованию, где метод books делает свойство кабинета видимым.я думаю, что это делает метод как-то лучше ... или равным ... в той части, на которой я все еще размыта.кажется, что оба выпускают одинаково, но, возможно, память раньше удерживалась с помощью метода books.

Answer 1

Версия Apple более эффективна с точки зрения памяти, поскольку detailViewController и ее представление будут освобождены, когда выскочит из стека навигационного контроллера.В отличие от версии PragProg, которая сохраняет cabinetController в переменной экземпляра (и, следовательно, предотвращает ее освобождение), код Apple не хранит ссылку на контроллер подробностей, который он создает.

Реализация PragProgможет иметь смысл, если пользователь, вероятно, будет часто перемещаться назад и вперед между контроллером статива и контроллером представления, который его удерживает, поскольку это позволяет избежать некоторой дополнительной загрузки ЦП, возникающей при многократном создании и освобождении объектов, но вам придется профилироватьчтобы увидеть, имеет ли это какое-либо существенное значение (чего обычно не будет).

Answer 2

Во втором случае может показаться, что cabinetController является свойством класса, указанного в self.В шаблоне это не так.