Данные неосновных данных в UITableView с базовыми данными

Question

Взгляните на Music.app (или iPod.app). В корневом представлении «Альбомы» есть строка «Все песни». В корневом представлении Songs есть строка «Shuffle». В корневом представлении «Плейлисты» есть строка «Добавить плейлист ...». Статические данные смешиваются в одном и том же UITableView с (предположительно) базовыми данными. Мне интересно, как Apple достигла этого.

Я пробовал два разных подхода, оба потерпели неудачу. Как и Music.app, мои представления также имеют UISeachBar в tableHeaderView. Моя первая попытка отслеживала, сколько у меня было «статических» строк, и корректировала indexPath, предоставленный для различных методов UITableView и NSFetchedResultsController, которые требуют информацию о секции и строке. Все работало отлично, пока я не реализовал методы NSFetchedResultsControllerDelegate, чтобы позволить создавать, редактировать и удалять. Метод insertRowsAtIndexPaths:withRowAnimation: (и аналогичный) срабатывает на моих скорректированных indexPaths. Индексные пути по умолчанию также не работают как есть.

Моя вторая попытка заключалась во вложении другого UITableView в tableHeaderView моего основного UITableView для использования для статических строк (и для размещения UISeachBar в его собственном tableHeaderView). Этот подход даже не дошел до стадии редактирования. UISearchBar в конечном итоге перекрывается корневым скруббером sectionIndex UITableView и больше не скользит за UINavigationBar при прокрутке короткого списка.

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

Answer 1

Я недавно столкнулся с этой же проблемой. Я хотел добавить строку в верхней части таблицы со статическим содержимым (Все песни). Я решил эту проблему, просто вставив свой собственный раздел для раздела 0, а затем увеличив при этом основные разделы данных. 0 становится 1, 1 становится 2 и т. Д.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView {
    return [_fetchedResultsController sections] + 1;
}

- (NSInteger)tableView:(UITableView *)tv numberOfRowsInSection:(NSInteger)section {
    if( section == 0 ) {
        return 1;
    }
    id <NSFetchedResultsSectionInfo> sectionInfo = [[_fetchedResultsController sections] objectAtIndex:section-1];
    return [sectionInfo numberOfObjects];
}

- (UITableViewCell *)tableView:(UITableView *)tv cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    // All Charts
    if( indexPath.section == 0 && indexPath.row == 0 ) {
        // Set up the custom cell
    }
    // Sets
    else {
        // Set up the core data cells
    }
}

Остальное - просто настройка разделов indexPath при удалении строк и тому подобного.

Answer 2

Я бы так и сделал (создаю свой кеш).Кажется, что морщина в вашем приложении против iPod.app - это бит NSFetchedResultsControllerDelegate.Я не думаю, что iPod.app предлагает именно этот интерфейс, верно?Таким образом, нет никакой автоматической поддержки создания / редактирования / переупорядочения.

Как вы сами заявили, это добавляло, что это привело к тому, что ваш метод indexPath перестал работать.

Я думаю, вам просто нужноРуку это.Это выглядит довольно типично для API-интерфейсов Apple: как только вы отклоняетесь от простых сценариев использования, функциональность их удобства начинает сталкиваться с проблемами.Вы должны регистрировать ошибки в отчете об ошибках, предлагая, как бы вы хотели, чтобы это работало - надеюсь, они что-нибудь придумают в будущем, так как это похоже на случай использования, с которым могут столкнуться другие.

Также яне знаю, нужно ли вам пройти весь путь до хранения в NSArrays, но если вы это сделаете, выгрузите свои выборки и кэшируйте только то, что необходимо в ОЗУ, если набор может стать действительно большим.

У меня естьЯ работаю над простым приложением для работы с фотографиями, а кэш поддерживается чем-то, что эффективно работает как курсор.На данный момент я тоже все храню в памяти, но детали скрыты за интерфейсом, который я смогу довольно легко реорганизовать.Интерфейс выглядит как массив, но автоматически знает, что нужно идти в сеть для получения дополнительных наборов результатов, кэшировать их в CoreData и смешивать результаты с разных страниц.Итак, мой делегат UITableView просто выполняет [cursor objectAtIndex: blah], и магия скрыта за кулисами.Это очень выполнимо.

Суджал