Блог

У меня есть пользовательское представление, которое загружает объект модели (давайте назовем его Person , почему бы и нет). Эти объекты хранятся в БД, получаются через a Loader и вставляются в a ListView через a CursorAdapter , который создает экземпляры указанных представлений. Пока все хорошо.

Теперь, Person скажем, имеет ссылку на другой объект модели Country . Countries находятся в собственной таблице, и мне нужно название страны (с идентификатором, конечно), чтобы представить его в элементах списка.

Я вижу три варианта:

1. Запрашивайте базу данных из метода view, который загружает данные пользователя ( setPerson() ?).
2. Глубокая предварительная загрузка (я думаю, я только что придумал термин, извините) моих объектов модели с информацией о стране.
3. Запрос на асинхронный запрос данных о стране, а затем возврат в пользовательский интерфейс.

Проблема с (1) заключается в том, что пользовательский интерфейс может блокироваться. Проблема с (2) заключается в том, что это приводит к сильному дублированию данных в памяти. Проблема с (3) заключается в том, что это усложняет поток, возможно, излишне.

Что мне делать? Важно ли снижение производительности (1)? Может быть (1) запросить данные из представления, но реализовать кеш, чтобы избежать повторного обращения к базе данных для одного и того же Country ? Может быть (2), с указанным уровнем кэша, чтобы гарантировать уникальность экземпляров объекта? 4-й вариант, который я не рассматривал? Что делают ORM?

Спасибо!

В вашем запросе, который вы используете для вашего CursoLoader, выполните ВНУТРЕННЕЕ СОЕДИНЕНИЕ с таблицами Person and Country . В результате запроса будет вся необходимая информация в одном курсоре.

РЕДАКТИРОВАТЬ В ОТВЕТ НА КОММЕНТАРИЙ

Это, вероятно, лучший / самый чистый способ решения проблем. На данный момент не беспокойтесь о дублировании в памяти, это преждевременная оптимизация. Кроме того, насколько большими будут ваши таблицы? Давайте немного вернемся к вычислению конверта. Если каждая строка объединенной таблицы занимает 100 байт (что является огромной строкой, поэтому я думаю, что здесь сценарий наихудшего варианта), то даже если бы у вас было 10000 строк в вашем результирующем запросе (опять же, это слишком много), вы бы использовали только 1 000 000 байт или меньше1 мегабайт памяти.