почему программисты используют configureCell: atIndexPath: метод для настройки ячейки tableView

Question

Ну, пока пару дней назад я не буду кодировать все для UITableViewCell в

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

метод. Но недавно я обнаружил, что разработчики iPhone (или Mac) используют configureCell:atIndexPath:, и даже большинство исходных кодов яблок имеют это как функцию класса. Итак, мой вопрос в основном, почему мы хотели бы создать еще одну функцию для предоставления содержимого ячейки, а затем просто написать весь код в методе cellForRowAtIndexPath:.

PS. для людей, которые не знакомы с этим, вы должны увидеть исходный код яблок. configureCell:atIndexPath: - это не другой метод в UITableViewDatasource, это просто функция класса, которую мы имеем в каждом классе, имеющем табличное представление. И мы используем это так.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"Cell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil)
    {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault 
                                       reuseIdentifier:CellIdentifier] autorelease];
    }
    [self configureCell:cell atIndexPath:indexPath];
    return cell;
}

- (void)configureCell:(UITableViewCell *)cell atIndexPath:(NSIndexPath *)indexPath
{
     cell.titleLabel.text = [NSString stringWithFormat:@"%d",indexPath.row];
}

И что еще более важно, после того, как я просто использовал этот стиль для пробных целей, я полюбил эту функцию и теперь я использую ее все время. (Когда я использую UITableView)

Редактировать: Хорошо, я думаю, что люди неправильно понимают мой вопрос, поэтому позвольте мне прояснить его.

Я имел в виду, зачем создавать другую функцию, когда вы можете поместить весь свой код в эту функцию

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

Меня не беспокоит название метода.

Answer 1

Это сделано, потому что вы можете обновить ячейки, когда они уже на экране. Вместо того, чтобы полностью обновить ячейку, вы можете просто извлечь существующую ячейку из табличного представления и запустить ее через configureCell:atIndexPath:. Если метод реализован правильно, он обновит все данные в ячейке без UITableView, удалит старую ячейку, удалит из очереди или выделит новую ячейку и выведет ее на экран.

---

Для исторического интереса:

Насколько я знаю, я парень, который отвечает за configureCell:atIndexPath:. Я уверен, что другие люди придумали ту же идею, но я верю, что фрагмент кода, который популяризировал его, был изначально написан мной. Затем он был распространен Apple и стал конвенцией.

Ранние версии NSFetchedResultsControllerDelegate имели метод controllerDidChangeContent:, но не вызывали controllerWillChangeContent:, что означало, что не было возможности вызвать -[UITableView beginUpdates] до изменения содержимого табличного представления.

Я подал Radar # 6708453 с просьбой добавить этот метод делегата и включил пример кода, чтобы показать им, что я хочу сделать. Этот код имел действительную логику обновления ячейки в вызове refreshCell:atIndexPath:, так что он мог вызываться как из tableView:cellForRowAtIndexPath:, так и controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:.

Когда вышло следующее начальное бета-тестирование, я обнаружил, что команда разработчиков iOS не только добавила предложенный мной метод, но и скопировала пример кода из моего отчета об ошибках в документацию NSFetchedResultsControllerDelegate , хотя они мудро изменились имя для менее запутанных configureCell:atIndexPath:.

Сегодня я фактически начал новый проект с шаблоном Core Data для основных / подробных данных iOS и заметил, что мой код - и метод configureCell:atIndexPath: с ним - был в шаблоне. Я запустил быстрый поиск в Google, чтобы увидеть, стало ли это общим соглашением. Кажется, что это так. Я горжусь тем, что этот маленький кусок кода сделал из себя!

Answer 2

Единственное время, когда я увидел реальное преимущество, если учесть удобочитаемость, - это когда у вас несколько типов ячеек.Тогда у вас могут быть отдельные методы, которые знают только, как заполнить этот конкретный тип клеток, например, если у вас было 3 разных типа клеток для собак, кошек и жирафов:

- (void)configureDogCell:(DogCell *)cell atIndexPath:(NSIndexPath *)indexPath
- (void)configureCatCell:(CatCell *)cell atIndexPath:(NSIndexPath *)indexPath
- (void)configureGiraffeCell:(GiraffeCell *)cell atIndexPath:(NSIndexPath *)indexPath

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

Answer 3

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

Answer 4

[self configureCell:cell atIndexPath:indexPath];

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

- (void)configureCell:(UITableViewCell *)cell atIndexPath:(NSIndexPath *)indexPath

Вы можете назвать это как угодно, но большинство решит назвать это так. Это потому, что этот метод получил передачу в объекте UITableViewCell и объекте indexPath, а затем возвращает «сконфигурированный» UITableViewCell, который затем возвращается в качестве возвращаемого объекта для

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

другими словами, вы можете использовать

- (void)configureCellXXX:(UITableViewCell *)cell atIndexPath:(NSIndexPath *)indexPath

и позвоните по номеру

 [self configureCellXXX:cell atIndexPath:indexPath];

и все равно будет работать :)