Как эффективнее всего передать объект из IntentService в Activity?

Question

[dimonkoz]

Реализую Web-клиент на Android. Http-запросы выполняются в IntentService. В результате в службе образуется объекты, которые имеют не только примитивные типы, но и, к примеру, Bitmap. Какой наилучший способ передачи объекта в Activity, или какой-то промежуточный класс.
Самый простой вариант использования ResultReceiver, как я понял, не проходит.
В методе обратного вызова

void onReceiveResult(int resultCode, Bundle resultData)

приходит Bundle-объект, который подходит только для хранения простых типов. Переводить Bitmap - объект в массив байтов не рекомендуется.
Второй вариант - упаковать объект в Parcel и засунуть вIntent. Затем отловить с помощью BroadcastReceiver. Рекомендовано ли отправлять весомые объекты?
Возможно можно просто сохранить картинку через OutputStream и передать путь? Или просто сохранить как статическую переменную где-нибудь? Я не знаток слабостей Android, хочу главное чтобы приложение оставалось шуcтрым. Заранее спасибо за ответы!

Comments

[Денис Загаевский]

Ivan Sokolov: и будет наиболее быстрым статическая переменная. И наиболее неправильным. И что?

[Денис Загаевский]

Ivan Sokolov: потому что это абсолютно неправильно с точки зрения архитектуры и поведения андроид-приложений.

[dimonkoz]

Попробовать можно все. Но не хочется тратить уйму времени. Хочется найти наиболее гибкий, элегантный и правильный с точки зрения специфики Android-системы вариант.

Answer 1

[MaxF]

Вообще уже наверное классика - это EventBus.
Однако, если вы не хотите подключать лишние библиотеки, то рекомендую вам посмотреть в сторону AsyncLoader вместо сервиса. Вам ведь не нужно чтобы запрос шел, если приложение убито. Зато взамен получите удобное получение результатов асинхронного запроса.

Comments

[dimonkoz]

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

[MaxF]

dimonkoz: на самом деле это спорный философский вопрос, но дело хозяйское. Тогда рекомендую EventBus или Otto

[nikitosgleb]

Если не стоит задача "Изобрести" - то бери библиотеку Universal Image Loader - и не парься. Так же на выбор аналоги - Fresco, Picasso, Glide

Answer 2

[lazard105]

Данные из сервиса всегда нужно передавать через Bundle.
Потому что: как только вы захотите отделить сервис от основного приложения android:process=":remote" то все упрощения (передача через static переменную, EventBus и т.д.) просто перестанут работать (из-за разных Application instance).

Что касается Bitmap - вы все правильно написали - их нужно сохранять на диск и передавать URI.
Потому что: часто бывает такая ситуация:
Сервис загрузил картинку -> отдал её в Activity по ссылке на объект -> после чего сервис завершил свою работу и уничтожился вместе со своим Context'ом -> соответственно картинка созданная в контексте Service тоже очистилась. Теперь Activity имеет ссылку на очищенный Bitmap -> как следствие

java.lang.RuntimeException: Canvas: trying to use a recycled bitmap

PS если приложение простое и вы хотите использовать простые методы взаимодействия с сервисом то напишите отдельный менеджер который будет отвечать за передачу данных (его потом проще переделать Bundle ;) )

Comments

[dimonkoz]

Я вот думаю как лучше сделать? Используя контекст, файл запишется в папку приложения?
FileOutputStream out= mContext.openFileOutput(filename, Context.MODE_PRIVATE);
bmp.compress(Bitmap.CompressFormat.PNG, 100, out);

А так какой путь может быть? Может ли быть такое, что прав на запись не будет у приложения?
FileOutputStream out = new FileOutputStream(filename);
bmp.compress(Bitmap.CompressFormat.PNG, 100, out);

Или вообще использовать MediaStorage?

[nikitosgleb]

Если картинка нужна только твоему приложению - сохраняй в internal storage(openFileOutput) - никто не запретит)) Но и другим апам - будет недоступна.

Если нужно "поделится" картинкой с кем-то, напрем с почтовым аппом который ты откроешь для отправки почты - тут два пути - либо external storage(плохо - потому что надо будет за собой её оттуда у бирать - и всем она будет доступна, и через total comander - зайдут еще и удалят)
Либо - более правильный путь - как в первый раз - internal storage - но дописываешь к этому свой ContentProvider - для предоставления доступа внешним апам к твоему файлику

[MaxF]

Насчет EventBus (Otto) вы не совсем правы (https://github.com/square/otto/issues/38)
И в любом случае ваш совет не соотносится с "если приложение простое и вы хотите использовать простые методы взаимодействия с сервисом" - bundle vs otto в простоте явно не выигрывает.

[lazard105]

MaxF: Вы путает понятия Thread и Process. В ссылке которую вы привели обсуждают взаимодействие между потоками а не процессами.
Кстати в топике по вашей ссылке, сам автор библиотеки, пишет что Otto работает только в одном Process.
https://github.com/square/otto/issues/38#issuecomm...

Еще вот ссылка на stackoverflow где написано что не только Otto, но и Greenrobot's и EventBus тоже работают только в одном процессе:
stackoverflow.com/questions/25568181/otto-eventbus...

P.S. Либо вы не знаете что делают параметры android:process=":remote" и android:process=":sync" :)

[MaxF]

lazard105: Обсуждение stackoverflow.com/questions/25568181/otto-eventbus... я также видел, и там есть ответ (второй по счету) в котором приводится вариант решения и на случай когда сервис в отдельном процессе. Так что работать заставить его все равно можно, просто это костыли.

P.S. я знаю что делают параметры android:process=":remote" и android:process=":sync" :)
И Thread и Process я не путаю. Просто не считаю что если приложение простое как вы написали, то есть действительно необходимость выносить сервис в отдельный процесс и иметь всевозможные грабли с этим связанные. Не знаю почему вы с этим не согласны.

[MaxF]

lazard105: вопрос стоял как эффективнее.
И я не спорю, что Bundle - правильно. Но назвать это простым не могу. Собственно, библиотеки типа Otto потому и появились.

[lazard105]

MaxF: Вы сами ответили на свой вопрос :
Вариант с использованием BroadcastReceiver выглядит так : Data -> Otto -> Bundle -> Otto -> Data. И именно на случай таких костылей я посоветовал сделать отдельный менеджер. Ведь вопрос стоял - как правильнее.

PS я не писал что использовать EventBus - плохо. Наоборот он очень удобен в своей нише (слабые связи внутри приложения) но для сервиса он не всегда удобен.

[MaxF]

lazard105: согласен.

Оффтопик: Странное поведение - при редактировании вами комментария, они поменяли ему время и теперь он висит позже чем мой ответ на него. Выглядит сомнительно.

[dimonkoz]

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

[lazard105]

dimonkoz: Всё что связано с Application Instance.
Накидаю несколько вариантов :
1) Состояние приложения: При старте вы инициализировали Singletone (например ACRA.init(), Factbook.init(), итд ) в UI он работает нормально - а в Service он null.
2) Callback : Вы отправили в сервис запрос и ждете ответа. Тут Android решает завершить тот процесс, в котором работает сервис и убивает его, но процесс с UI остается работать и жать ответа вечно. Эту ситуацию нужно обрабатывать отдельно.
3) Доступ к файловой системе (file locks) : если вы находитесь в одном процессе то легко сделать ThreadSafe менеджер для работы с файлами, который будет разрешать коллизии доступа на логическом уровне. Если процессы разные, то блокировка доступа к файлам будет возникать на уровне файловой системы и их разрешать гораздо сложнее. Особенно это касается SQLite - когда сервис и UI одновременно пытаются писать в базу, то возникает SQLiteDatabaseLockedException.

Это проблемы "на вскидку", есть еще проблемы с тем что данные хранятся дважды (в сервисе и в UI) и нужно их постоянно как-то синхронизировать и т.д.

Но это очевидные проблемы, а настоящие грабли обычно неожиданны и не предсказуемы :)