Комментарии 7
Совершенно согласен. Как-то раз попытался сделать черновики неотправленных сообщений на контент-провайдерах. Убил сутки и ничего хорошего в итоге не получил.
Опять же, в документации написано, что бэкэнд может быть совершенно любым, хотя ничего кроме бд использовать не представляется возможным — придется парсить query запросы вручную.
Сделал для себя вывод, что контент-провайдеры слишком сложны и неповоротливы для применении в пределах одного приложения.
Опять же, в документации написано, что бэкэнд может быть совершенно любым, хотя ничего кроме бд использовать не представляется возможным — придется парсить query запросы вручную.
Сделал для себя вывод, что контент-провайдеры слишком сложны и неповоротливы для применении в пределах одного приложения.
не соглашусь с вами
использовать ContentProvider'ы можно и внутри приложения.
Есть же приложения которые используют успешно ContentProvider'ы внутри приложения. И эти приложения ставят в пример разработчикам — Twitter, контакты, календарь. Подозреваю, что и facebook
относительно ваших замечаний:
1) Обработка исключений — более чем уверен, что это ошибка архитектуры у вас.
2) мета данные — не вижу проблем получать их отдельным запросом. Хотя тут все зависит от приложения и требований, но в примере который вы привели, думаю, так можно.
3) прогресс выполнения — думаю основная ошибка в том, что вы хотите передать файл через контент провайдер. передавайте адрес этого файла или URL. Пусть тот кому нужен этот файл сам его обрабатывает и показывает прогресс обработки.
4) Остановка выполнения. Подозреваю что это следует из предыдущего замечания про прогресс выполнения. Спроектируйте так, чтобы контент провайдеры отдавали вам данные быстро, уберите все, что долго работает в сервис.
использовать ContentProvider'ы можно и внутри приложения.
Есть же приложения которые используют успешно ContentProvider'ы внутри приложения. И эти приложения ставят в пример разработчикам — Twitter, контакты, календарь. Подозреваю, что и facebook
относительно ваших замечаний:
1) Обработка исключений — более чем уверен, что это ошибка архитектуры у вас.
2) мета данные — не вижу проблем получать их отдельным запросом. Хотя тут все зависит от приложения и требований, но в примере который вы привели, думаю, так можно.
3) прогресс выполнения — думаю основная ошибка в том, что вы хотите передать файл через контент провайдер. передавайте адрес этого файла или URL. Пусть тот кому нужен этот файл сам его обрабатывает и показывает прогресс обработки.
4) Остановка выполнения. Подозреваю что это следует из предыдущего замечания про прогресс выполнения. Спроектируйте так, чтобы контент провайдеры отдавали вам данные быстро, уберите все, что долго работает в сервис.
Вот давайте про обработку исключений например.
В контент-провайдере делаем запрос к вес-сервису «список документов для внутреннего пользования». Возможные исходы: 1) нет инета, 2) сервис вернул ответ отличный от 200, 3) юзер не авторизован (устарели куки например), 4) у юзера нет прав, 5) возвращён список содержащий от 0 до N элементов.
Как вы это спроектируете с использованием провайдеров?
В контент-провайдере делаем запрос к вес-сервису «список документов для внутреннего пользования». Возможные исходы: 1) нет инета, 2) сервис вернул ответ отличный от 200, 3) юзер не авторизован (устарели куки например), 4) у юзера нет прав, 5) возвращён список содержащий от 0 до N элементов.
Как вы это спроектируете с использованием провайдеров?
Неправильно делать запрос к веб-сервису в ContentProvider'е
Запрос и парсинг ответа от веб-сервиса должен делаться на стороне Service (в термина Андроид). И если произошла какая-либо ошибка, то уже сервис сделает callback на активити, которая запросила данные.
Запрос и парсинг ответа от веб-сервиса должен делаться на стороне Service (в термина Андроид). И если произошла какая-либо ошибка, то уже сервис сделает callback на активити, которая запросила данные.
кстати да.
посмотрите лекцию с Google IO. Там описывают несколько моделей взаимодействия Service-ContentProvider-RESTfull web-service
посмотрите лекцию с Google IO. Там описывают несколько моделей взаимодействия Service-ContentProvider-RESTfull web-service
Много воды, смотрите Google i/o, там все рассказано. Вы не первый кто делает сложные клиенты, Google все решил уже давно.
>>Если исключение появится внутри ContentProvider'а, вызывающий код никак об этом не узнает
Абсолютно не соглсен. Если так рассуждать, то можно и от потоков совсем отказаться. Если в каком-то(не UI) потоке произойдет Exctption, то приложение об этом, без дополнительных настроек, тоже ничего не узнает.
Для того, чтобы знать обо всех фейлах приложения нужно использовать Crash reports или хотя-бы писать их в лог и самому мониторить.
Абсолютно не соглсен. Если так рассуждать, то можно и от потоков совсем отказаться. Если в каком-то(не UI) потоке произойдет Exctption, то приложение об этом, без дополнительных настроек, тоже ничего не узнает.
Для того, чтобы знать обо всех фейлах приложения нужно использовать Crash reports или хотя-бы писать их в лог и самому мониторить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тёмная сторона ContentProvider'ов