Метод вызова для запуска кода или использования шины событий

Я использую широковещательные приемники для отправки данных в действия и фрагменты. Эти данные предназначены либо в первую очередь для информации/отображения, либо для активации некоторого кода во фрагменте/действии.

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

Это автобус без событий....

 public class loqooBroadcast extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) {
           if (intent.getAction().equals("tv.SCENE")) {
             try {
                message = (JSONObject) 
                   new JSONTokener(intent.getStringExtra("message")).nextValue();
                sceneId = message.getString("scene_sceneid");
                if (sceneId == lastSceneId){
                    return;
                }
                channel = message.getString("channel");
                args.putString("json", message.toString());
            } catch (JSONException e) {

            }
            lastSceneId = sceneId;
            pushToFeedFromActivity(message);
      }

намерение поступает от службы, которая представляет собой просто сообщение json, поступающее извне.

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


person sirvon    schedule 13.01.2015    source источник
comment
Некоторый пример кода был бы полезен здесь   -  person fge    schedule 13.01.2015
comment
с шиной событий издатель освобождается от таких обязанностей, и эта независимость помогает, потому что издателю и подписчику не нужно иметь закодированную в них логику, которая устанавливает зависимости между ними. - nerds.weddingpartyapp. com/tech/2014/12/24/   -  person sirvon    schedule 13.01.2015


Ответы (3)


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

Это огромный плюс для использования событий/шины событий.

С другой стороны, все довольно развязано. Хотя это может звучать как аргумент в пользу шины событий, на самом деле это не всегда так. Довольно легко заставить поток программы прыгать, казалось бы, случайным образом, а отладка может стать настоящей головной болью. Рефакторинг — это еще одна проблема — потенциально это не так просто, как было бы без плавающих вокруг событий.

Мой совет: Используйте, но не злоупотребляйте. Если есть прямой способ общения двух сотрудников, предпочитайте его. Но не разделяйте вещи, которые на самом деле принадлежат друг другу.

person jan groth    schedule 13.01.2015
comment
спс за ваши мысли. сложность событий мне по нраву. все мои приложения в значительной степени сосредоточены на нескольких фрагментах с несколькими вариантами. добавление концепции шины событий в мою настройку - это ответ! - person sirvon; 13.01.2015

Я бы рекомендовал использовать шину событий. Это значительно упрощает работу, если вам позже понадобятся эти данные в другом фрагменте/действии, вы можете просто подписаться на событие. Он также позаботится о многих раздражающих вещах, например, о том, что ваш фрагмент уже был собран. Делает код чище и легче для понимания.

person pat    schedule 13.01.2015

этот пост в значительной степени отвечает на мой вопрос и направляет меня на будущее.

http://nerds.weddingpartyapp.com/tech/2014/12/24/implementing-an-event-bus-with-rxjava-rxbus/

почти каждый вопрос, который у меня есть в эти дни, сводится к одному слову... разъединение!

person sirvon    schedule 13.01.2015