Доступ к базе данных в Android
Я создаю приложение для Android, которое является в основном списком информации о Грибах. Я получаю эту информацию от sqlite базы данных. У меня есть глобальный одиночный элемент с сервисным классом в нем, в котором я использую для доступа к моему дб. Почти каждое действие получает доступ к дб. Лучше оставить мой дб открытым все время или открытым и закрыть его, поскольку мне нужны данные?
Если лучшая практика должна оставить это открытым все время, где я должен удостовериться, что закрыл его и каков худший вариант развития событий, если я оставил это открытым, когда действие было уничтожено?
3 ответа
Основываясь на моем прошлом опыте работы с Java, я бы сказал, что лучше закрыть соединение, это Вероятно, это не имеет значения для небольшого Android-приложения, но если у вас работает 10 приложений и все они обращаются к базе данных, у вас будет 10 ожидающих подключений. Запустите еще несколько, и рано или поздно другому приложению придется ждать, потому что сервер SQL больше не сможет обрабатывать запросы.
Я полагаю, вы можете думать об этом как о файле на вашем компьютере. Вы читаете из него данные, а затем закрываете его, когда закончите. Зачем оставлять файл открытым в вашем приложении?
Теперь я новичок в программировании под Android, поэтому у меня не было времени для реализации вызовов базы данных. Но когда несколько лет назад я столкнулся с той же проблемой в приложении Java, я реализовал объект базы данных, в котором у меня было соединение с базой данных. «Все остальные» (классы) должны были вызвать объект базы данных (singleton или final методы) для получения данных, вроде как хранимые процедуры, но вместо этого в приложении.
Благодаря этому я знал, когда звонки были сделаны и когда они прекратились. Затем я поставил таймаут, чтобы, как если бы через несколько минут ничего не произошло, я закрывал соединение с базой данных. (Это также позаботилось о некоторых исключениях тайм-аута, потому что тайм-аут соединения никогда не произойдет.) Когда поступил новый вызов, я мог легко начать новое соединение и использовать новое соединение с базой данных.
В основном я абстрагировался от вызовов SQL, используя такие методы, как public Fungus [] getAllFungus () и public Fungus [] getFilteredFungus (string where) .
Я бы открыл db по мере необходимости. Таким образом, вы точно знаете, что соединение закрывается после завершения определенного действия, которое его открыло. Хотя в Android есть встроенные проверки, чтобы убедиться, что приложение закрывается после завершения работы приложения, это не повредит подстраховаться. Я также предполагаю, что если он будет постоянно открыт, это может вызвать утечки или что-то в этом роде.
Лучшим вариантом здесь будет рефакторинг, чтобы ваше приложение обращалось к базе данных через ContentProvider. Ваша реализация ContentProvider является единственной вещью с открытым хэндлом к базе данных.
Это дает вам несколько преимуществ:
- только одна вещь имеет открытую базу данных, поэтому ваша проблема просто исчезает.
- множество стандартных классов поддержки для автоматизации таких вещей, как управление базой данных.
- лучшая интеграция со стандартными представлениями управления списками Android, которые все разработаны для автоматической работы с курсорами, предоставляемыми ContentProviders.
- Ко всем вашим данным можно обращаться по URI (обычно в форме 'content://com.fnord.mushroom/mushroom/43'), что означает, что другие приложения тоже могут получить доступ к вашим данным.
Используя ContentProvider, можно склеить вместе три или четыре стандартных класса для создания интерфейса браузера к вашей базе данных и никогда не писать никакой реальной логики.
С другой стороны, ContentProvider поддерживает доступ только через ограниченный интерфейс --- в терминах SQL, вы получаете INSERT, SELECT, UPDATE и DELETE без вложенных пунктов. Если вы работаете со сложными SQL-запросами, может быть немного больно направлять запросы от вашего приложения к ContentProvider и обратно. Однако большинству людей это не нужно (а если нужно, то лучше использовать пользовательские намерения).