Лучшие практики для SQLite DB и ContentProvider

Мое приложение для Android - это чтение и запись в локальную базу данных SQLite из нескольких разных видов деятельности и службы. Довольно стандартный. Но я не доволен тем, что у меня есть все данные БД, хранящиеся в виде констант, которые затем я использую везде, где я обращаюсь к БД. Мне рекомендуется обернуть БД в ContentProvider. Звучит неплохо. Пока я реорганизую свой код, я решил, что спрошу:

  • Каковы ваши лучшие практики для локального хранения данных БД в Android?
  • Где и как вы храните инструкции CREATE TABLE, имена столбцов, другие SQL?
  • Не могли бы вы поделиться списком классов, которые вы создаете, и что входит в каждый (ContentProvider, DatabaseProvider, DatabaseHelper...)?
  • Как вы координируете структуру вашей локальной базы данных Android с серверной БД, доступной через интерфейс REST?

Да, я понимаю, что я нахожусь в многолетнем "контексте рамки привязки объектов к объектам Android"? вопрос. На данный момент мне в основном интересно узнать, как вы структурируете свои приложения для Android с тем, что доступно в стандартном SDK.

Как всегда, спасибо за указатели!

Ответы

Ответ 1

Мы настраивали ORMLite на Android некоторое время, и он работает хорошо. ORMLite поддерживает Android с собственными вызовами базы данных, а также поддерживает другие базы данных через JDBC. Вы комментируете свои классы/поля и используете базовые классы DAO для продолжения SQLite.

  • Операторы CREATE TABLE обрабатывают мои классы утилиты ORMLite. Большинство SQL позаботятся классами DAO.
  • Раздел Android онлайн-документации объясняет иерархию классов. Вы реализуете DatabaseHelper, который помогает создавать обновление вашей базы данных. Ваши действия расширяют OrmLiteBaseActivity (или службу или вкладку), которая дает доступ к помощнику и DAO.
  • ORMLite не обеспечивает решение для слияния с удаленными серверами REST.

Надеюсь, что это будет несколько полезно.

Ответ 2

В настоящее время мне в основном интересно узнать, как вы структурируете свои Android-приложения с тем, что доступно в стандартном SDK.

Я не являюсь настоящим поклонником SQL и тем, как он обрабатывается в android, поэтому я использую базу данных объектов NeoDatis, В основном это просто позволяет хранить/извлекать объекты Java в плоский файл, хранящийся на устройстве, очень легко. db40 также является другой альтернативной базой данных объектов, которая будет работать на android.

У вас не было проблем с использованием этого подхода, вы можете заметить, что в том числе библиотека NeoDatis увеличит ваш размер APK на ~ 700 кб.

Ответ 3

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

В связи с этим я работаю над собственной мини-структурой ORM, используя аннотацию и управляя всем этим. Пока все работает нормально, но я все еще не работал.

Ответ 4

Вы также можете посмотреть Androrm. Это инструмент Orm с открытым исходным кодом, разработанный специально для android. Это должно помочь вам со всеми материалами, связанными с базой данных.

Ответ 5

Просто, чтобы завершить список все больше и больше... Еще одна ORM - это решение ORM, предоставляемое BARACUS Framework. Он не собирается создавать базы данных корпоративного размера, тем больше для хранения нескольких объектов в базе данных и делает его доступным для приложения. Внутри него нет подходов когенерации; вы просто пишете свой объект pojo, rowmapper и таблицу def. Поэтому вы можете использовать DAO, Injection Dependency Injection, поддержку жизненного цикла стиля IOC и многое другое.

Возможности ORM:

Для более сложного материала базы данных (использование ORM - это немного ручная работа, например, в старом spring rowmapper time). Я сейчас думаю о добавлении интеграции ormlite.

Подробнее о деталях кода просто проверьте учебное приложение на github