Приемник трансляции и ResultReceiver в Android

В чем разница междуBroadcastReceiver а такжеResultReceiver в андроиде?

Ответы на вопрос(4)

принимающий трансляции. Они отправлены кем-то с намерением, что их может получить много получателей (например, радиопередачи).

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

 Rajesh Naddy18 июл. 2018 г., 07:43
пример рации хорош :)
 user167056401 нояб. 2012 г., 15:08
Спасибо за ответ! Хороший пример, чтобы понять ...

полностью разные. Это'S на самом деле совершенно такая же разница, как междуBroadcast а такжеРезультат.

что это трансляция? Простыми словами этоs какое-то сообщение, которое видно всей системе и может быть использовано каждой частью системы (которая знает контракт), это не былоt возник из-за кого-то Reuest;что такое результат? Это'что-то мыожидаете получить от другой части системы. Обычно тамs только один получатель для результата и обычно этот получатель запросил обработку для получения результата (почувствуйте разницу - для широковещательной передачи никому не нужно ничего делать »запрос' чтобы оно возникло);

Это было объяснение с логической точки зрения. С точки зрения кода, если бы вы сравнили BroadcastReceiver и ResultReceiver, вы могли бы наблюдать огромную разницу. В основном оба класса построены на основе IPC, но BroadcastReceiver намного сложнее из-за этого ».с другой природой (которую яЯ пытался объяснить в первой части).

 sandrstar01 нояб. 2012 г., 15:14
хм, я думаю нет, потому что оба не о HTTP-запросе. При необходимости Вы можете отправить результат из своей сервисной или асинхронной задачи с помощью любого из них. Но для AsyncTask Вы можете обычно использовать только Handler.
 user167056401 нояб. 2012 г., 14:54
Может ли оба получателя поддерживать асинхронный HTTP-запрос и ответ?

Приемник вещания

Приемник вещания - это компонент, который отвечает на общесистемные вещательные объявления. Например, трансляция, объявляющая, что экран выключен, батарея разряжена или был сделан снимок. Приложения также могут инициировать трансляции -например, чтобы сообщить другим приложениям, что некоторые данные были загружены на устройство и доступны для использования ими. Хотя вещательные приемники неДля отображения пользовательского интерфейса они могут создать уведомление в строке состояния, чтобы предупредить пользователя, когда происходит широковещательное событие. Более того, вещательный приемник - это простошлюз» к другим компонентам и предназначен для выполнения очень минимального объема работы. Например, он может инициировать службу для выполнения некоторой работы в зависимости от события.

Получатель результата

Если ваш сервис станет частью вашего приложения, то вы сделаете его более сложным, чем нужно. Поскольку у вас есть простой случай получения некоторых данных из Restful Web Service, вам следует изучитьResultReceiver а такжеIntentService.

Этот шаблон Service + ResultReceiver работает путем запуска или привязки к службе с помощью startService (), когда вы хотите выполнить какое-либо действие. Вы можете указать операцию, которую нужно выполнить, и передать ее в ResultReceiver (действие) через дополнительные функции в Intent.

 w3bshark28 сент. 2016 г., 16:32
Вы, вероятно, должны отдать должное словам, которые вы скопировали + вставили из Robby Pond здесь:stackoverflow.com/a/3197456/1738090
 user167056401 нояб. 2012 г., 14:57
Вместо AsyncTask я должен использовать этот вызов веб-службы Async?
Решение Вопроса

Generic interface for receiving a callback result from someone.

Приемник вещания:

Base class for code that will receive intents sent by sendBroadcast().

РЕДАКТИРОВАТЬ:

Справочная информация: Все сетевые операции / длительные операции должны выполняться вне основного потока. Два способа сделать это:

Асинхронная задача - для простых сетей, таких как, скажем, получение изображения / обработка БДСервис - для сложных длительных фоновых процессов

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

Допустим, вы выбрали 2. Теперь

Ваша деятельность отправляет веб-запрос к вашему сервисуВаш сервис выполняет это с помощью скажем DefaultHttpClient

Он отправляет данные обратно вашей активности.

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

1.) Вещательный приемник: несколько приемников могут получать ваши данные. Используется, если вы хотите отправлять данные / уведомления через приложения (например, вы также взаимодействуете с fb и twitter, несколькими получателями для вашей веб-трансляции), когда вы отправляете широковещательную рассылку по всей системе.

2.) Получатель результатов: Ваше приложение является единственным получателем данных. Это интерфейс, который вы реализуете и передаете его intentService через putExtra. IntentService затем извлечет этот объект и вызовет его функцию receive.send для отправки чего-либо (в комплекте) на вызывающую активность. Получатель результатов имеет преимущество перед приемниками вещания, если все ваше общение является внутренним для вашего приложения

РЕДАКТИРОВАТЬ: я должен также упомянуть эту осторожность

предосторожность: Служба работает в главном потоке своего хостингаслужба не создает свой собственный поток и не запускается в отдельном процессе (если не указано иное). Это означает, что, если ваша служба будет выполнять какие-либо работы с ЦП или блокировать операции (такие как воспроизведение MP3 или работа в сети), вы должны создать новую нить внутри службы для выполнения этой работы. Используя отдельный поток, вы снизите риск ошибок приложения не отвечает (ANR) и приложения ».Основной поток может оставаться посвященным взаимодействию пользователя с вашими действиями.

 user167056401 нояб. 2012 г., 15:38
Спасибо за твою помощь
 Micro23 февр. 2016 г., 05:22
И каждый, кто читает этот пост, должен увидеть IntentService (поскольку я считаю, что это лучший выбор по сравнению с Service):stackoverflow.com/questions/15524280/service-vs-intentservice
 Micro23 февр. 2016 г., 05:20
Есть ли разница в производительности при получении данных в BroadcastReceiver и ResultReceiver?
 Vrashabh Irde01 нояб. 2012 г., 15:09
Проверьте мой отредактированный раздел
 Andy Res21 янв. 2013 г., 13:12
Не могли бы вы ответить на вопрос. Если мне нужно показать ход процесса загрузки в панели уведомлений, скажем, и обновлять его каждую 1 секунду, чтобы я мог видеть его текущий прогресс. Тогда можно ли использовать ResultReceiver для отправки прогресса в уведомление каждую 1 секунду? Или я должен использовать в этом случае BroadcastReceiver, или он 'так же?
 user167056401 нояб. 2012 г., 14:53
Какой из них лучше всего подходит для длительного сетевого процесса? Например: загрузка файлов, JSON parsing.etc
 user167056401 нояб. 2012 г., 15:02
Спасибо за ответ. Я прошел по ссылке. Однажды пересек ссылку, у меня есть сомнения в обоих получателях. Оба приемника поддерживают длительные задачи. В какой ситуации мне нужно использовать Broadcast и результат.
 Vrashabh Irde01 нояб. 2012 г., 14:58
Посмотрите на верхний ответ здесь:stackoverflow.com/questions/3197335/restful-api-service чтобы понять результат получатель + шаблон обслуживания. Это дает действительно хороший пример применения
 Arun C28 июн. 2015 г., 10:18
ИНФОРМАЦИЯ: Если вы хотите избежать накладных расходов на управление потоком в сервисе, вы можете использовать IntentService, который управлял этим для вас.
 Vrashabh Irde01 нояб. 2012 г., 15:30
Все службы выполняются в основном потоке приложения, поэтому в вашем коде должна быть логика для создания новых потоков в службах. Пока это верно, несколько сервисов не должны влиять на удобство использования
 user167056401 нояб. 2012 г., 15:16
Большое спасибо .. Но я уже использую Сервис с Broadcast Receiver для какой-то другой логики. Опять же, у меня та же логическая ситуация, чтобы использовать сервис внутри сервиса. Если я использую больше, чем сервис, будет ли приложение работать медленнее?

Ваш ответ на вопрос