Простая структура приложения. Как вы думаете?

Question

Меня интересует, как я сохраняю свои свойства и аспекты управления памятью. Это для простого приложения, которое редактирует информацию о классе, которая хранится в таблице. Есть 3 ViewControllers.

• Просмотр списка (список всех классов)
• подробный вид выбранного элемента (перечисляет свойства выбранного класса)
• представление редактирования (перечисляет одно свойство
  выбранного класса и позволяет ему быть отредактированный)

Вот как это структурировано в настоящее время, как вы думаете?

ListViewController

@ property (nonatomic, retain) NSMutableArray * пулы;
@property (nonatomic, retain) PoolFacilityEditController * childController;

Чтобы добавить новый экземпляр класса в таблицу, вы нажимаете кнопку добавления, которая запускает этот метод.

//Loads up the editPoolFacility controller to add a new pool

- (void) добавить {

PoolFacilityEditController *editController = self.childController;

PoolFacility *aPoolFacility = [[PoolFacility alloc] init];

[self.pools addObject:aPoolFacility];
[aPoolFacility release];


editController.thePoolFacility = aPoolFacility;

editController.pools = self.pools;

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

}

Следующий контроллер теперь загружен и вот его интересные переменные экземпляра. Мудро или нет, я решил просто назначить пул новому контроллеру, а не сохранять. Я не хочу без необходимости удерживать.

Детальный просмотр

@property (nonatomic, assign) PoolFacility *thePoolFacility; (assigned in the above add method)

@ свойство (неатомное, присваивать) NSMutableArray * пулы; (также назначается в методе add)

В подробном представлении есть метод, который выполняет следующие действия.

- (void)viewWillAppear:(BOOL)animated {


//Pass the copy onto the child controller
if (self.childController.thePoolFacility != self.thePoolFacility) {
    self.childController.thePoolFacility = self.thePoolFacility;
}

}

Пул передается в контроллер подробного редактирования, чтобы он знал, какой пул он редактирует.

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

Интересные свойства выглядят так:

@property (nonatomic, retain) PoolFacility *thePoolFacilityCopy;

@ свойство (неатомное, присваивать) PoolFacility * thePoolFacility;

И он создает копию для редактирования в случае, если пользователь изменяет значения, а затем хочет отменить. Если пользователь нажимает сохранить, он копирует значения из копии в не копию.

- (void)viewWillAppear:(BOOL)animated {

PoolFacility *poolCopy = [self.thePoolFacility copy];
self.thePoolFacilityCopy = poolCopy;
[poolCopy release];

}

Если нажата кнопка «Сохранить» или «Отмена», представление всплывет.

И затем мы возвращаемся к среднему виду, который отображает все поля.

Теперь, если пользователь нажимает сохранить, я просто запускаю контроллер управления, и мы возвращаемся к представлению списка. ИЛИ, если пользователь нажимает «Отмена», я запускаю этот метод.

-(void)cancel {

[self.pools removeObject:self.thePoolFacility];
[self.navigationController popViewControllerAnimated:YES];

}

Итак, подведем итог

Я назначаю свойство для разных контроллеров представления, а не сохраняю его.

Также мои контроллеры вида загружаются только один раз и не освобождаются, когда они «исчезают»

Надеюсь, это имело смысл! Мой вопрос ... Это хороший способ сделать это?

Спасибо

Dan

Answer 1

Я не видел здесь конкретного вопроса, поэтому я просто сделаю несколько общих замечаний.

1. В iPhone OS кнопки «Отмена» являются обычными в диалоговых окнах, предназначенных для добавления нового элемента, но в гораздо меньшей степени в диалоговых окнах редактирования. Фактически, единственный пример кнопки «Отмена» в диалоговом окне «Редактировать», о котором я могу думать, находится на панели «Будильник» приложения «Часы». Так что не беспокойтесь о копировании PoolFacility и копировании изменений обратно при сохранении; просто сделайте кнопку «Отмена» видимой только для новых объектов (или используйте значок «Корзина» - отмена нового пула и удаление существующего - это фактически одно и то же действие, как и сейчас).

2. Поскольку у вас есть вещи сейчас, нет опасности, что объект будет удален в неподходящее время. Однако, если вы когда-нибудь измените метод хранения - например, заставите приложение лениво загружать объекты PoolFacility с диска - оно вернется, чтобы укусить вас. Напишите это правильно сегодня, и завтра вы избавите себя от боли. Правильный способ - сделать свойство thePoolFacility сохраненным свойством и освободить его в вашем методе dealloc. (Если вы продолжаете управлять списком пулов так, как вы это делаете в настоящее время, вы должны сделать то же самое с ним.)

3. Кстати, вы не показываете, как загружаются существующие объекты PoolFacility. Откуда они? Если происходит какой-либо доступ к базе данных, может оказаться полезным, чтобы PoolFacility отправляла уведомления при создании, обновлении или удалении объекта, а затем наблюдала и реагировала на соответствующие уведомления по мере необходимости. Все приложения, которые я написал для хранения пользовательских данных, используют этот подход; Я нашел это очень удобным и гибким.

4. Поскольку существует только один список пулов, и он необходим нескольким контроллерам, не стыдно хранить его в делегате приложения, а не передавать его. Еще лучше написать одноэлементный объект FacilityList, который управляет списком. Это может позволить вам убрать много логики из ваших контроллеров. Как правило, вы должны помещать в свои модели все, что можете, кроме того, что взаимодействует с экраном. Это означает, что когда Apple делает iTablet или выпускает Apple TV SDK - или когда вы решаете сделать версию для Mac или переделать пользовательский интерфейс - вы можете перенести как можно большую часть своего приложения без изменений.