Использование SQLite в Android-разработке. Tips and tricks

[@alexios]

Можете дать ссылку на приложение? Хотя бы для теста? Возникают ещё вопросы: 2Мб базы — это все данные в приложении или только необходимая часть? Приложение клиент-серверное или без сервера?

[@Sash0k_k]

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

2 метра — это данные справочников, которые инициализируются в локальную БД при первом запуске.
Есть ещё удалённый сервер MS SQL, с которым работаю через jtds, но это уже не относится непосредственно к теме статьи.

[@nicolausYes]

А хотелось бы, чтобы предзаполненные таблицы с данными уже были готовы к началу работы пользователя с приложением. И нашёлся альтернативный вариант — библиотека android-SQLite-asset-helper

А вы пробовали потом заменить эту базу новой при использовании этой библиотеки?
Т.е. выпускаете новую версию, кладете новую базу в apk, у пользователя, у которого уже было ваше приложение, новая база с новой версии перезапишет старую, уже скопированную базу?

[@Sash0k_k]

Не пробовал. Вообще в описании библиотеки фича заявлена, скорей всего — столкнусь с этим в дальнейшем :)

[@nicolausYes]

Попробуйте. По-моему, issue на эту тему уже полгода висит.

[@j_wayne]

Иногда так напрягает возиться со схемами в мелких приложениях… а не практиковали использование какого-нибудь простенького schemaless хранилища?

[@Sash0k_k]

В самых простых случаях — да, не гнушаюсь хранить в Prefence набор каких-нибудь JSONObject.toString() и парсить их оттуда по необходимости.

Конкретно тут — у таблиц есть структура, которая сохранена для совместимости с удалённым sql-сервером. В частности, справочники ведь необходимо будет обновлять.

[@Wertugo]

Использовал ormlite в своем приложение на android, очень удобная ORM библиотека для SQLite.

[@Alexey_Bespaly]

Ваша база данных больше одного мегабайта. Вы копируете её из assets при первом запуске, если Вы планируете запускать Ваше приложение на андроид меньше или равно 2.2, то в assets нужно разбить файл на части, не превышающие 1 мегабайт.

[@nicolausYes]

Это касается только «несжатых» типов. Дописываете до имени базы расширение .jpeg и все нормально копируется.

[@Alexey_Bespaly]

Спасибо, теперь я тоже это знаю!

[@djvu]

использовал .mp3 в своё время )

[@Sash0k_k]

Спасибо за дополнение.
Об этой проблеме у старых версий aapt мне известно, и разрабам android-sqlite-asset-helper — тоже. Поэтому, кстати, у них предполагается, что база должна быть упакована в zip.
А у меня проект API 14+

[@knott]

Хотел бы задать вопрос комментирующим:
А часто ли вы используете ContentProvider для работы с данными, при условии что эти самые данные не нужно перекидывать между приложениями?
Мне показался вариант использовать ContentProvider для целей хранения внутренних данных очень громоздким.

[@Sash0k_k]

имхо, если данные необходимо отображать в списке, то ContentProvider без вариантов (чтобы пользоваться лоадером). А если база нужна как промежуточное/внутренне хранилище, можно работать с ней напрямую.
Например, приходилось писать велосипед кэшер картинок с небольшими постобработками, который сохранял некоторые данные в базе. В подобных случаях провайдер — лишнее звено.

[@knott]

А что если между этими вариантами? Она нужна как и внутреннее хранилище так и для отображения данных в списке.

Думаю стоит пояснить что я имею ввиду под громоздкостью:
мало того, что есть аспект общей громоздкости (нужно написать много boilerplate'а), который, в принципе, можно обойти, так есть еще аспект очень неудобной работы со всякими хитрыми JOIN'ами.

[@Sash0k_k]

много boilerplate'а

Много, но ведь и пишется 1 раз, а потом таскается из проекта в проект. По сути оно зло конечно, остаётся только смириться и третий раз апеллировать к лоадерам.

аспект очень неудобной работы со всякими хитрыми JOIN'ами

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

Поначалу не очень понимал, зачем ContentProvider-ы нужны, и старался их не использовать. Привык...)

И кстати, было бы интересно посмотреть исследования, сколько оверхеда даёт провайдер по сравнению с прямыми запросами к базе (полгода назад не смог найти такой информации)

[@WatsOne]

Насколько я понимаю, если есть необходимость использовать курсор в адаптере, например для ListView то без ContentProvider теперь (то есть начиная с API15) не обойтись. Курсор теперь назначается адаптеру списка через реализацию интерфейса лоадера. Старый способ теперь depricated. В свою очередь лоадеру нужен URI, что обязывает создавать ContentProvider.

[@knott]

Необязательно. Есть SQLiteCursorLoader сделанный многоуважаемым господином CommonsGuy который работает напрямую с SQLite курсорами.

[@WatsOne]

Благодарю, не знал.

[@zlatko]

… т.е. мониторит курсор и автоматически передаёт адаптеру списка изменившиеся данные.

Вы уверены что передает только изменившиеся? Было бы интересно взглянуть на код вашего лоадера