Comments 43
Больше всего раздражает что каждая программа создает в корне флешки папку для себя, и лишь единицы дают эту папку указать. Неужели нельзя все это складывать в одну папку? Разработчики, договоритесь уже а?..
Надеюсь гугл запретит создавать программам папки где то кроме /data /var и /tmp.
>>Надеюсь гугл запретит создавать программам папки где то кроме /data /var и /tmp.

нуну
просто все программеры создают свои папки на карте, вместо того чтобы использовать getExternalStorage(), который создает папку для приложения на карте в папке Android. то есть все приложения должны хранить данные на карте по такому адресу
/sdcard/Android/package_name/data
имхо проще выделить для себя на флэшке папку с пользовательскими данными, чем заставить гугл и программистов работать по своему стандарту ;)
Раз статья называется хранение данных, то можно было бы вскользь упомянуть о том, что БД не единственный способ хранения. Есть еще:
Shared Preferences
Store private primitive data in key-value pairs.
Internal Storage
Store private data on the device memory.
External Storage
Store public data on the shared external storage.
«В android есть несколько способов хранения данных: общие настройки, бд и тд. В этом посте я расскажу о том как хранить данные в БД. „
читайте внимательнее
на самом деле производительность у sqlite3 так себе на андроиде
прошу прощение, он же там native? на сях и скомпилен под ARM просто? тогда возможно проблема в биндингах и обертках, т.к. даже на слабой машинке под управлением Windows Mobile, sqlite выдает поразительные результаты.
да? а у нас тормозило, правда, мы юзали с биндингами.

правда, конечно, мы не делали замеры.

так получилось, что даже на айфоне мы перестали юзать sqlite3
а как вы скорость тогда оцениваете? «производительность так себе» — это в каких попугаях? андроид здесь роли не играет, я в этом практически на 100% уверен.

крайне рекомендуется статик билд и использование амальгамейшена.

я не понимаю как так. весь мир осознает, что sqlite3 жгуч, крупнейшие вендоры начинает наконец-то деплоить его со своими осями (nokia, apple, google), а вы от него отплевываетесь как от чумы )

давайте попробуем сделать пару бенчей вместе, выявить что не так. может быть разберемся.
мы в одном приложении у себя вообще от sql'я отказались и получили нехилый прирост в скорости
вот-вот

мы тоже к такому переходим

sqlite оказался реально медленным…
да парочка таблиц без связей и все

а если в БД пихать еще по 10-20кб в строку, то все совсем уныло становится
странно, что же разрабы андроида не предусмотрели, что при парочке таблиц скорость так сильно падает.
в моём случае вопрос скорее даже не в медленности sqlite (его-то как раз можно _сильно_ ускорить prepared'ами и особенно транзакциями), а в быстроте той же (де)сериализации — она по определению работает быстрее, да и работать с ней зачастую проще (даже поверх контент-провайдеров)
Ну это в общем-то объясняется тем, что sqlite открывает и закрывает базу при каждой записи, при использовании транзакций этого не происходит.
прошу прощение, но смысл в использовании sqlite (или иную СУБД) без prepare и транзакций там где это возможно? тут речь идет все-таки не об ускорении, а о грамотном использовании.
про транзакции/prepare нужно знать и уметь, а в большинстве примеров/доков (втч и этом, прошу обратить внимание!)
опять же андроид не очень способствует использованию всего этого в плане написания boilerplate-кода
Спасибо! Больше! Еще больше качественных постов о разработке под Android на русском!
1) не стоит делать длительные операции (к коим в общем случае относится и работа с БД) в UI-треде
2) стоит проверять результат insert'а
А если обращение к sqlite реализовано через провайдер, то обращение будет выполняться в ui треде?
зависит откуда вы обращаетесь к провайдеру, если ui треда, то конечно же в нем.
оно будет в том же треде, в котором будет вызов провайдера — вызовы-то синхронны
UFO landed and left these words here
UFO landed and left these words here
А возможно ли использовать другую СУБД под Андроид? Существуют ли другие аналоги, более полноценные, чем SQLite? В последнем, к примеру, отсутствуют мульти-инсерты и alter table неполноценен. Но важнее всего для меня мульти-инсерт, так как в приложении требуется сохранять большие объемы данных (по несколько тысяч, а то и 2-3 десятка тысяч записей), чтобы в процессе работы пользоваться ими. Построчный инсерт такого количества строк занимает очень много времени, а процедура эта происходит несколько раз в день.
Only those users with full accounts are able to leave comments. Log in, please.