Google Android - это несложно

Всем привет! Вот никогда не пользовался ContentProvider'ом, решил попробовать. Понравился сам подход, всё классно но как всегда возникло одно НО.
ContentProvider по умолчанию обязательными методами для переопределения являются delete, getType, insert, onCreate, query, update. Вот а мне допустим нужно сделать "insert or replace" или скажем добавить свой метод, не важно какой. Вроде как и добавил но обращаемся к провайдеру мы через ContentResolver по Uri, и соответственно я могу обратится только к стандартным методам базового ContentProvider'а а не к тем методам что я дописал.
Так что я ошибаюсь и есть выход? Или работа с ContentProvider'ом действительно такая ограниченная?

Слава, да, работа ограниченная данными методами.

Смотри на параметр, который тебе нужно возвратить. Например, когда идет апдейт или инсерт - то там количество записей по-моему возвращается, можно совместить, если реплейс или инсерт - придется выбрать где тебе разместить данный метод, и придется вернуть фейковый uri, например (тот, который пришел на входе).
Свои методы вписывать и вызывать нельзя.

Foenix писал(а):Слава, да, работа ограниченная данными методами.

Смотри на параметр, который тебе нужно возвратить. Например, когда идет апдейт или инсерт - то там количество записей по-моему возвращается, можно совместить, если реплейс или инсерт - придется выбрать где тебе разместить данный метод, и придется вернуть фейковый uri, например (тот, который пришел на входе).
Свои методы вписывать и вызывать нельзя.

ты и там успеваешь заходить в интернет? Тогда вопрос, смысл в ContentProvider'e если он такой ограниченный?

Я тут без рук, без ног да еще и без головы
интернет есть, но времени на него нету)

Пользу от него я вижу только в том, что с ним можно работать с курсорлоадером (к.л. может без к.п. но с велосипедом).
Сама реализация, особенно при большом количестве таблиц получается громоздкой и неизящной Но у меня есть метод, где я или удаляю или добавляю или редактирую строку в зависимости от данных. Получилось что нужно было возвращать тот же ури что и на входе, не считаю это правильным, если честно, но другого выхода не вижу.

гугл зарапортовался. Вначале сказал, что если не будете шарить базу, то к.п. вам не нужен, и вообще он нужен в исключительных случаях. Затем изобрел к.л. и объявил вне закона startmanagingcursor и requery(). А к.л. без к.п. смысла особого нет использовать.
Зато загрузка к.л.-ом данных в списки мне даже визуально нравится больше.

rezak90 писал(а):Всем привет! Вот никогда не пользовался ContentProvider'ом, решил попробовать. Понравился сам подход, всё классно но как всегда возникло одно НО.
ContentProvider по умолчанию обязательными методами для переопределения являются delete, getType, insert, onCreate, query, update. Вот а мне допустим нужно сделать "insert or replace" или скажем добавить свой метод, не важно какой. Вроде как и добавил но обращаемся к провайдеру мы через ContentResolver по Uri, и соответственно я могу обратится только к стандартным методам базового ContentProvider'а а не к тем методам что я дописал.
Так что я ошибаюсь и есть выход? Или работа с ContentProvider'ом действительно такая ограниченная?

Слава, все ограничивается фантазией разработчика.
К примеру "insert or replace" ты можешь реализовать в методе insert, просто определяя спец Uri для таких запросов и обрабатывая их иначе.
А так же там есть переопределяемый метод public ContentProviderResult[] applyBatch(ArrayList<ContentProviderOperation> operations)..., через который можно делать множество запросов в одной транзаксации.

П.С. Да свои методы там нет возможности создать, чтоб достучаться через стандартные механизмы, но внутри существующих методов, можно варьироваться, хватило бы фантазии.

neoksi писал(а):Слава, все ограничивается фантазией разработчика.
К примеру "insert or replace" ты можешь реализовать в методе insert, просто определяя спец Uri для таких запросов и обрабатывая их иначе.
А так же там есть переопределяемый метод public ContentProviderResult[] applyBatch(ArrayList<ContentProviderOperation> operations)..., через который можно делать множество запросов в одной транзаксации.

П.С. Да свои методы там нет возможности создать, чтоб достучаться через стандартные механизмы, но внутри существующих методов, можно варьироваться, хватило бы фантазии.

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

rezak90 писал(а):та я так сразу и сделал... но мне такое не нравится что приходится куеву тучу гарадить, потому что база может быть же и не маленькая, и по этому как то мне такая реализация не нравится

Ну все зависит от того как ты строишь саму логику работы с БД. У меня операции типа "insert or replace" возникают обычно при загрузке множества новых данных в БД. Поэтому я все делаю через метод applyBatch, сначала передаю в него селекты для проверки наличия данных, а далее по результатам отправляю пачку запросов insert и update. Вообще такие операции нежелательно делать внутри самого CP, он должен отвечать только за связь с БД. Вариации работы с данными должны быть классом выше, и реализованы в классе, который вызывает CP. Желание сократить код в Java, это как себе же подножку делать в будущем .

Та просто как то сразу негативное мнение о ContentProvider'e возникло, своего мало что напишешь, только нужно в рамки втиснуться... не люблю когда ущемляют в правах

neoksi,
Как вовремя вы про applyBatch затронули.
Недавно наваял кусок кода, где обновляются данные для списка (всего списка). Естественно все это получилось с циклом. Решил улучшить производительность и завернул все это в одну транзакцию (т.е. использовал applyBatch).
Однако, сравнение методов обновления не выевело какого-либо существенного преимущества.
На 100 элементном списке
1) метод без applyBatch занимает от 40 до 80 мсек на запись
2) метод с applyBatch от 30 до 60
Конечно, эти цифры относительные, да и тригер на таблице висит, но все же берут меня сомнения, что applyBatch метод шибко выгоден в плане производительности. Да и дополнительную память ест на свои методы.

Есть ли какая-нибудь инфа по производительности applyBatch? Поделитесь пожалуйста.

PS если не сложно, направьте в правильную сторону, как определить куда тратится время при подобных операциях (использую Эклипс).

Idol,

Когда мы используем одну транзакцию, то мы уменьшаем кол-во операций чтения-записи файла БД. Тобишь он читается один раз, а не 100 для 100 записей. Чем больше строк, тем заметнее результат. Для меня время сократилось существенно, но я не засекал с секундомером. А вообще, чтоб выяснить скорость работы обоих методов, нужно взять метку времени до начала цикла и отнять ее от метки времени после окончания цикла, результат можно вывести в лог. Таким образом вы получите реальное время выполнения цикла в одном и в другом случае. Чисто ориентироваться на логи нельзя, так как прерывания на вывод логов тоже происходят с определенными интервалами, примерно раз в 5-10мс.

neosk,
Спасибо за ответ.
Я вроде тоже не с секундомером сидел . Конечно, вывод в лог. И для сравнения подобных операций задержки на работу с логами не имеют значения.

Клясться не буду, но если мне не изменяет память, то не количество операций IO файла бд существенно уменьшает время исполнения транзакции, а работа с лог файлом, локи и количество подключений к бд.

На каких объемах ты использовал applyBatch?

Idol

У меня число операций не статично, так что я не могу точно сказать, в некоторых 50, а в других 1500.

П.С. При замере времени работы цикла, если вы будите ориентироваться на время появления записи лога, то данные будут неверны. Нужно засекать в самом цикле и полученный результат уже выводить в лог.

Idol, причем тут applybatch если там главное использовать транзакцию? Если ты ее используешь, то время сокращается. У меня 90 тыс записей каждый день скачивается в одной из таблиц, не считая других. Занимает сносное время, точно уже не помню. Но эксперименты с транзакцией и без нее делала - в логи выкладывала время, без использования транзакций - это нереально ждать.

rezak90 писал(а):Та просто как то сразу негативное мнение о ContentProvider'e возникло, своего мало что напишешь, только нужно в рамки втиснуться... не люблю когда ущемляют в правах

ну вот, а вы смеялись, когда я долго с ними разбиралась. У меня нужно было в эти три метода впихнуть своих 60. Причем некоторые содержали транзакцию например, по добавлению строк в несколько таблиц. Я была в шоке. Тем более что в интернете все примеры содержат работу только с 1 таблицей - 99.9%. Разработчики на стеке вообще отвечали расплывчато "it depends" на вопрос как работать хотя бы с двумя таблицами. Андроид вообще не предназначен, я так поняла, для сколько нибудь серьезной работы с данными.

Это еще что, неудобно так же , что эти методы возвращают (например query) только курсор. А если нужно сразу целое число вернуть? или строчку? сумму? раньше это компактно было в одном методе, а сейчас приходится возвращать курсор, а обработку сделать уже в коде. Таким образом, нужно делать действительно еще одну надстройку по-хорошему над ним, чтобы логично использовать данные в основном коде программы, а не заниматься перебором и разбором курсоров.

Foenix писал(а):ну вот, а вы смеялись, когда я долго с ними разбиралась.

я и до сих пор смеюсь
У меня не возникает трудностей с ним и не понимания. Просто мне не понятна сама архитектура, ведь в таком чистом виде ContentProvider нужен только на примитивном банальном и скучном уровне. Ведь для 99% проектов он тогда не логичен. А писать кучу настроек под него ну это лишнее время и велосипеды, уж проще тогда тупо все методы реализовывать в SQLiteOpenHelper'e и делать его синглтоном. Да криво, но не более чем ContentProvider, зато гибко и легко использовать.

Foenix писал(а):У меня нужно было в эти три метода впихнуть своих 60. Причем некоторые содержали транзакцию например, по добавлению строк в несколько таблиц. Я была в шоке. Тем более что в интернете все примеры содержат работу только с 1 таблицей - 99.9%. Разработчики на стеке вообще отвечали расплывчато "it depends" на вопрос как работать хотя бы с двумя таблицами. Андроид вообще не предназначен, я так поняла, для сколько нибудь серьезной работы с данными.

а никто не запрещает тебе писать обычный sql запрос, в нём хоть 10 таблиц связывай.

ну с себя посмейся, я тебе ту же проблему описываю - нелогично и негибко в коде.

Причем тут связывание 10 таблиц? дело не в связывании а в том, что если подходить к проблеме прямо, то в каждом из трех даденых гуглом методов нужно делать свитч на 40 позиций, в каждом из которых связывать по 10 таблиц? красота неописуемая.
поэтому я придумывала способ, чтоб все это было не в 1 методе длиной 100 км, а так, чтоб потом через год в этом разобраться можно было.

что же касается хэлпера - я уже говорила о к.л.-ах, с которым нужен к.п.

ты сам посмотри, делаешь кучу пакетов в 1 проекте - и смеешься, если у меня всего 1 пакет. Но запихивать в 1 свитч 100500 методов обработки базы в 10 таблиц - это то же самое, что делать проект без пакетов внутри где 100500 классов в куче.

Foenix писал(а):что же касается хэлпера - я уже говорила о к.л.-ах, с которым нужен к.п.

вот здесь ты ошибаешься, никакой ContentProvider не обязателен...

Foenix писал(а):ты сам посмотри, делаешь кучу пакетов в 1 проекте - и смеешься, если у меня всего 1 пакет. Но запихивать в 1 свитч 100500 методов обработки базы в 10 таблиц - это то же самое, что делать проект без пакетов внутри где 100500 классов в куче.

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