Проектирование больших объемов данных в приложении для iPhone

Question

У меня есть приложение I phone, которое при открытии должно отображать таблицу данных, содержащую примерно 25000 записей. Каждая запись состоит из двух полей: TITLE и DESCRIPTION. Оба поля видны в каждой ячейке таблицы. Табличное представление также полностью доступно для поиска с помощью UISearchBar.

Когда приложение запускается и это представление загружается, «объект коллекции» извлекает все данные из таблицы и загружает их в «объекты объектов». Так как мне нужны оба поля для поиска, мне действительно нечего гидратировать / обезвоживать; Таким образом, полная таблица находится в памяти. Должен быть лучший способ предложить полную возможность поиска, но радикально уменьшить количество объектов в памяти одновременно.

Есть идеи?

EDIT:

Полагаю, мне следует объяснить дальше.

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

Кроме того, если у меня есть только 100 записей по обе стороны от текущего выбора, как я могу искать ВСЕ записи (включая те, которые не находятся в памяти)?

Я рассмотрю предложение делегата таблицы.

Answer 1

Вы должны использовать SQL для поиска, а не загружать все в память и искать оттуда. Какой смысл в базе данных, если вы используете ее как плоский файл?

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

Answer 2

Возможно, я могу уточнить, что говорит остальная часть группы.

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

– tableView:cellForRowAtIndexPath:  
– tableView:numberOfRowsInSection:

Я подозреваю, что ваша текущая реализация – tableView:cellForRowAtIndexPath: просто извлекает две строки из вашего объекта глобальной коллекции, вставляет их в ячейку (надеюсь, что она используется повторно правильно!) И возвращает ее.

Что он, вероятно, должен делать, так это извлекать эти данные из базы данных по мере необходимости. Я бы реализовал класс (или классы) для посредничества между приложением и базой данных и возврата блоков, например, 100 строк одновременно для любого класса, выступающего в качестве источника данных (SQLite поддерживает ключевые слова LIMIT и OFFSET), который будет удерживать только этот ограниченный набор.

Когда – tableView:cellForRowAtIndexPath: вызывается tableView, вы можете проверить, находятся ли данные в локально сохраненном блоке (я бы сделал свойство для хранения текущего смещения записи), и если нет, обновите локальный блок с запросом БД для следующей (или предыдущей, в зависимости от обстоятельств) 100 записей.

Presto. Фиксированное количество (100) записей находится в памяти в любой момент времени, источник данных предоставляет данные для представления таблицы по мере необходимости. Вы могли бы полюбить, но это общая идея.

Что касается поиска, предположим, что вы выполняете свободный текстовый поиск по заголовку, просто попросите посредника базы данных выпустить что-то вроде

 'select id, title, description from yourTable where title like ?'

а связать? к тому, что пользователь вводил, с подстановочными знаками в соответствующих местах (не забудьте очистить вводимые данные ... не то, чтобы кто-то ужасно мог выполнить SQL-инъекцию в вашем приложении для iPhone, но привычки и все такое ...:)

Очевидно, что если вы просто ищете, а не фильтруете результаты, вам придется все немного откорректировать, но, надеюсь, это начало.

Удачи!

Answer 3

Я бы переосмыслил архитектуру вашего приложения.

Вы должны помнить, что iPhone не то же самое, что настольное приложение, и люди не используют свои телефоны, как обычный компьютер. IPhone используется в течение нескольких минут, а не часов. Никто никогда не захочет прокручивать более 20 000 записей. Если честно, я не уверен, что кто-то захочет сделать это в настольном приложении.

Вместо этого загрузите ограниченное количество записей, возможно, 100 или 200 вершин. Затем позвольте пользователю загружать больше (или искать то, что ему нужно).

Answer 4

Вы должны попытаться использовать делегат для своей таблицы и загружать элементы в память только по требованию. Если отображаются только первые десять элементов, ОС запросит их только у вас.

Вам также следует рассмотреть возможность хранения ваших записей в базе данных SQLite. Когда поиск активен, делегат будет работать с SQL-запросом, созданным с использованием текущего поискового запроса.

Answer 5

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

редактировать; SQL Lite также отличная идея, как упоминалось выше.