Эффективный способ разработки и управления iPhone-приложением, аналогичный настройкам

Question

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

У меня есть приложение, похожее на приложение с собственными настройками.Проблема, с которой я столкнулся, заключается в том, что она не следует тому же четкому стилю MVC.Другие приложения имеют тенденцию фокусироваться на отображении одного вида вещей.Например, в случае приложения периодической таблицы это элементы.Элементы четко составляют модель, и они имеют схожие свойства и поведение, то есть они могут отображаться и взаимодействовать одинаково.Такое приложение почти само проектируется!

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

Как вы проектируете что-то подобное?

В данный момент я делаю все это в контроллере представления, и соответствующие строки отслеживаются с помощьюперечисление:

enum {
    kNameRow,
    kGenderRow,
    kJobTypeRow,
    kLevelOfExerciseRow,
    kEmailAddressRow,
    kTelephoneNumberRow
};

Как я описал, все эти ячейки очень разные, поэтому отображение ячеек обрабатывается так:

// - tableView:cellForRowAtIndexPath pseudocode.

switch (indexPath.row) {
    case kNameRow: // create name cell.
    case kGenderRow: // create gender cell.
    case kJobTypeRow: // create job type cell.
    case kLevelOfExerciseRow: // create level of exercise cell.
    case kEmailAddressRow: // create email address cell.
    case kTelephoneNumberRow: // create telephone number cell.
}

И взаимодействие с ячейками обрабатывается аналогично:

// - tableView:didSelectRowAtIndexPath pseudocode.

switch (indexPath.row) {
    case kNameRow: // do name-specific stuff.
    case kGenderRow: // do gender-specific stuff.
    case kJobTypeRow: // do job type-specific stuff.
    case kLevelOfExerciseRow: // do level of exercise-specific stuff.
    case kEmailAddressRow: // do email address-specific stuff.
    case kTelephoneNumberRow: // do telephone number-specific stuff.
}

Это кажется очень громоздким, и есть дополнительная проблема не работает, когда таблица разбита на несколько разделов.

Есть ли лучший способ сделать это?Существуют ли какие-либо шаблоны проектирования, которые я мог бы использовать при работе с большими таблицами в основном несвязанных данных?

Любые советы вообще приветствуются.

Answer 1

Вы когда-нибудь задумывались о том, чтобы просто иметь массив объектов для класса, который содержит элемент пользовательского интерфейса и некоторые другие идентифицируемые данные?

@interface settingsOption {
    NSString *key;
    UIView *displayElement;
}

+ (settingsOption *)optionWithKey:(NSString *)key andDisplayElement:(UIView *)displayElement;

@property (nonatomic, retain) UIView *displayElement;
@property (nonatomic, retain) NSString *key;

@end

Где будет выглядеть метод класса

+ (settingsOption *)optionWithKey:(NSString *)key andDisplayElement:(UIView *)displayElement;
    settingsOption *option = [[settingsOption alloc] init];
    option.key = key;
    option.displayElement = displayElement;
    return [option autorelease];
}

Ваш класс настроек будет иметь массив экземпляров settingsOption.

- (void)somewhereInMySettingsClass
    mySettings = [[NSMutableArray alloc] init];
    [mySettings addObject:[settingsOption optionWithKey:@"age" andDisplayElement:[UIButton buttonWithStyle:UIButtonStyleRect]]];

    [mySettings addObject:...];
}

cellForRowAtIndexPath таблицы будет просто делать

[cell addSubview:[[mySettings objectAtIndex:indexPath.row] displayElement]];

Вы говорили о разделах, которые добавили бы еще один слой к данным. Это может быть просто делением mySettings на массив массивов, где каждый массив в массиве - это один раздел.

Не уверен, что я что-то пропустил выше. Не стесняйтесь указывать и тыкать.

Вы можете еще больше упростить класс settingsOption, добавив дополнительные вспомогательные классы для различных типов элементов, например

+ (settingsOption *)buttonWithKey:(NSString *)key;
+ (settingsOption *)switchWithKey:(NSString *)key;
+ (settingsOption *)pickerWithKey:(NSString *)key withDataSource:(id <UIPickerViewDataSource>)source withDelegate:(id <UIPickerViewDelegate>)delegate;

и т. Д. И т. Д.

Answer 2

Вот мое предложение - обрабатывать каждую ячейку как элемент представления.

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

вместо перечисления используйте:

NSThingyCell *nameRow;
NSThingyCell *genderRow;

@property IBOutlet NSThingyCell *nameRow;
@property IBOutlet NSThingyCell *genderRow;

- (IBAction) nameRowChanged:(id)sender;
- (IBAction) genderRowChanged:(id)sender;

и затем вместо вызова таблицы с коммутатором просто подключите каждую отдельную ячейку в Интерфейсном Разработчике.

Это дает дополнительное преимущество, заключающееся в независимости от строк, поэтому, если вам нужно поместить «ageRow» между именем и полом, ничего не испортится.

Это также станет довольно большим, поэтому, если в вашем представлении есть несколько таблиц, вы можете разделить эти таблицы на отдельные кончики / контроллеры и загрузить представления во время выполнения.

Answer 3

Мне нравятся реализации контроллеров секций, которые извлекают логику из вашего подкласса UITableViewController (или другого хост-контроллера) и перемещают их в автономные классы.

В итоге я реализовал базовый протокол, которыйопределяет, что должен делать контроллер раздела - для меня это включает количество строк в разделе и ячейку для строки (не нужен полный путь индекса, так как контроллер работает с одним разделом).У меня есть дополнительный метод для возврата имени раздела и высоты строки.Это все, что я реализовал до сих пор, так как это все, что мне действительно нужно.

Это работает для меня, потому что мои отдельные разделы имеют тенденцию быть однородными, но вы могли бы легко использовать эту идею для возврата гетерогенных ячеек в одной и той жераздел или рефакторинг идея иметь контроллеры типа ячейки вместо контроллеров раздела.В конце мои методы UITableViewDelegate и UITableViewDataSource просто должны выяснить, какой контроллер секций вызывать, а не внедрять всю логику в подкласс UITableViewController.

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

Answer 4

Возможно, вы захотите взглянуть на проект coreyfloyds http://github.com/coreyfloyd/Generic-Heterogeneous-Table-Views Я думаю, это может иметь необходимую вам функциональность.