Комментарии 21
Можете дать ссылку на приложение? Хотя бы для теста? Возникают ещё вопросы: 2Мб базы — это все данные в приложении или только необходимая часть? Приложение клиент-серверное или без сервера?
приложение пишется для внутреннего использования на предприятии, поэтому, к сожалению, не могу.
2 метра — это данные справочников, которые инициализируются в локальную БД при первом запуске.
Есть ещё удалённый сервер MS SQL, с которым работаю через jtds, но это уже не относится непосредственно к теме статьи.
2 метра — это данные справочников, которые инициализируются в локальную БД при первом запуске.
Есть ещё удалённый сервер MS SQL, с которым работаю через jtds, но это уже не относится непосредственно к теме статьи.
А хотелось бы, чтобы предзаполненные таблицы с данными уже были готовы к началу работы пользователя с приложением. И нашёлся альтернативный вариант — библиотека android-SQLite-asset-helper
А вы пробовали потом заменить эту базу новой при использовании этой библиотеки?
Т.е. выпускаете новую версию, кладете новую базу в apk, у пользователя, у которого уже было ваше приложение, новая база с новой версии перезапишет старую, уже скопированную базу?
Не пробовал. Вообще в описании библиотеки фича заявлена, скорей всего — столкнусь с этим в дальнейшем :)
Попробуйте. По-моему, issue на эту тему уже полгода висит.
Иногда так напрягает возиться со схемами в мелких приложениях… а не практиковали использование какого-нибудь простенького schemaless хранилища?
В самых простых случаях — да, не гнушаюсь хранить в Prefence набор каких-нибудь JSONObject.toString() и парсить их оттуда по необходимости.
Конкретно тут — у таблиц есть структура, которая сохранена для совместимости с удалённым sql-сервером. В частности, справочники ведь необходимо будет обновлять.
Конкретно тут — у таблиц есть структура, которая сохранена для совместимости с удалённым sql-сервером. В частности, справочники ведь необходимо будет обновлять.
Использовал ormlite в своем приложение на android, очень удобная ORM библиотека для SQLite.
Ваша база данных больше одного мегабайта. Вы копируете её из assets при первом запуске, если Вы планируете запускать Ваше приложение на андроид меньше или равно 2.2, то в assets нужно разбить файл на части, не превышающие 1 мегабайт.
Это касается только «несжатых» типов. Дописываете до имени базы расширение .jpeg и все нормально копируется.
Спасибо за дополнение.
Об этой проблеме у старых версий aapt мне известно, и разрабам android-sqlite-asset-helper — тоже. Поэтому, кстати, у них предполагается, что база должна быть упакована в zip.
А у меня проект API 14+
Об этой проблеме у старых версий aapt мне известно, и разрабам android-sqlite-asset-helper — тоже. Поэтому, кстати, у них предполагается, что база должна быть упакована в zip.
А у меня проект API 14+
Хотел бы задать вопрос комментирующим:
А часто ли вы используете
Мне показался вариант использовать
А часто ли вы используете
ContentProvider для работы с данными, при условии что эти самые данные не нужно перекидывать между приложениями?Мне показался вариант использовать
ContentProvider для целей хранения внутренних данных очень громоздким.имхо, если данные необходимо отображать в списке, то ContentProvider без вариантов (чтобы пользоваться лоадером). А если база нужна как промежуточное/внутренне хранилище, можно работать с ней напрямую.
Например, приходилось писатьвелосипед кэшер картинок с небольшими постобработками, который сохранял некоторые данные в базе. В подобных случаях провайдер — лишнее звено.
Например, приходилось писать
А что если между этими вариантами? Она нужна как и внутреннее хранилище так и для отображения данных в списке.
Думаю стоит пояснить что я имею ввиду под громоздкостью:
мало того, что есть аспект общей громоздкости (нужно написать много boilerplate'а), который, в принципе, можно обойти, так есть еще аспект очень неудобной работы со всякими хитрыми JOIN'ами.
Думаю стоит пояснить что я имею ввиду под громоздкостью:
мало того, что есть аспект общей громоздкости (нужно написать много boilerplate'а), который, в принципе, можно обойти, так есть еще аспект очень неудобной работы со всякими хитрыми JOIN'ами.
много boilerplate'аМного, но ведь и пишется 1 раз, а потом таскается из проекта в проект. По сути оно зло конечно, остаётся только смириться и третий раз апеллировать к лоадерам.
аспект очень неудобной работы со всякими хитрыми JOIN'амивот ими пусть sqlite и занимается. Думаю логично, если интерфейс к базе максимально прост, а все сложные запросы написаны вьюхами.
Поначалу не очень понимал, зачем ContentProvider-ы нужны, и старался их не использовать. Привык...)
И кстати, было бы интересно посмотреть исследования, сколько оверхеда даёт провайдер по сравнению с прямыми запросами к базе (полгода назад не смог найти такой информации)
Насколько я понимаю, если есть необходимость использовать курсор в адаптере, например для ListView то без ContentProvider теперь (то есть начиная с API15) не обойтись. Курсор теперь назначается адаптеру списка через реализацию интерфейса лоадера. Старый способ теперь depricated. В свою очередь лоадеру нужен URI, что обязывает создавать ContentProvider.
… т.е. мониторит курсор и автоматически передаёт адаптеру списка изменившиеся данные.
Вы уверены что передает только изменившиеся? Было бы интересно взглянуть на код вашего лоадера
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование SQLite в Android-разработке. Tips and tricks