Специалистам по надежности я прошу обратить внимание на Ada — язык специально для военных систем. И когда приводите примеры на Java всегда вспоминайте наш любимый NullPointerException. Также не хочется выслушивать лекции про оптимизацию приложения на предмет утечек памяти, хотя 20 лет назад нам пели песни о супер оптимизаторе памяти Java, который все делает за вас. Честно скажу г… а в Java Android полно. И если ваша задача — это максимум Галерея фоток со стандартным набором Dagger2 + Picasso), то некоторые разработчики пилят расширяемые системы на нескольких потоках.
EventBus служит просто транспортом для доставки сообщений и ничего больше. И ничем иным она (шина событий) не будет. Событие — это сущность, которая переносит только данные и ничего другого в них нет. Т.е. мы получаем систему, объединенную одной транспортной системой. По аналогии — мы имеем единую федеральную транспортную систему. Мы можем перемещать по ней что угодно — главная ее задача — это обеспечение своевременной ДОСТАВКИ и ничего более. Если вы живете в поселке — вы можете не видеть ее всю жизнь. Но любая транспортная система связывает что-то. В нашем случае модули (сервисы). Модулю (сервису — не путать с сервисом андроида) глубоко плевать — откуда/кто/как доставил данные/как доставит результат — он только производит специфичные ему преобразования. Причем их динамически можно подгружать/выгружать. Т.е. обеспечивать в приложении сервис в зависимости от требований. Поэтому на них и строят динамические системы. Т.е. если завтра потребуется дополнительно перенаправить поток сообщений с экрана смарта на удаленный сервер — никаких заминок не происходит — вы просто дополнительно перенаправляете поток событий в другой сервис. Т.е. Шина событий + сервисно-ориентированная архитектура обеспечивает максимальную гибкость в проектировании и эксплуатации приложения не ограничивая приложение ничем. Уберите шину событий и будете применять слушатели, callbacks, intents, broadcasts — все это уже давно проходили.
Если не использовали никогда EventBus зачем такие комментарии? Например завтра вам скажут пересылать все на сервер или запихивать все в БД, то каким способом вам поможет ActivityLifecycleEvents. В статических системах, в которых расписано все и на весь цикл разработки и жизни приложения не место событийно-ориентированным системам. Но в динамических системах, в которых вы не знаете, что от вас могут потребовать завтра (например — медицинские системы) — то используют вообще EventBus на каждый поток.
Перед тем как давать рекомендации — просто посмотрите процент использования EventBus. Я думаю также будет Вам полезно почитать о событийно-ориентированном программировании/clean architecture и прочих аналогичных штуках. И как их используют в крупных компаниях. habrahabr.ru/company/yamoney/blog/334500 habrahabr.ru/post/128772
Стандартный пример при плохой связи — получили отлуп и нужно вывести сообщение об этом. Но пользователь уже давно ушел из данного фрагмента и он уже давно уничтожен. В случае сервиса у вас есть список живых фрагментов/активити и вы выбираете один — текущий, тот который в состоянии на экране и спокойно передаете данные ему. Нет живых — приложение в фоне — положите в очередь в сервис мыла.
Я специально обратил внимание на Серьезность сообщения. В общем случае она не нужна — и в случае отсутствия слушателей оно теряется — закрыли фрагмент и нам не важно, что сообщение «Привет Вася» пропало. Но если приложение серьезно — и нам важен результат, то сервис обязан иметь зарегистрированных подписчиков(слушателей). Не важно какого типа они будут — важно, что они имеют нужный нам интерфейс. Нет живых подписчиков — бога ради используйте сервис по типу e-mail(т.е. появился слушатель — отправили ему мыло). Самое главное — нам не нужно никуда передавать ссылки на что-то — мы передаем только данные. А сервис сам решает — как поступить в каждом случае — отбросить событие/передать/переслать(положить в очередь/кэш). Я понимаю — а что делать, если зарегистрированного несколько слушателей? Добавьте текущего. Т.е. как с квартирой — хотите — сами ищите ее, а хотите — просто пишите объявление и ждете. Каждый выбирает свое.
Например есть задача вывода сообщений. Реализуйте все сервисом. И если завтра вас попросят выводить все через Toast, а послезавтра — через SnackBar — то вы просто меняете настройку прямо в приложении. Добавьте серьезность в сообщения. Вы поменяете только сервис, не трогая интерфейс взаимодействия. Интерфейс взаимодействия с сервисом един — через одно единственное событие. Тоже самое с диалогами — одно входящее событие и одно исходящее событие.
Диалог — это независимая визуальная сущность, создание единого интерфейса для взаимодействия с ним, независимого от порождающей и принимающей стороны — это задача, которая для реализации может использовать события. Т.е. создав сервис, который может порождать Диалоги и установив единый интерфейс получения результатов (например через событие) — вы просто забудете, что такое диалоги и их различные реализации (DialogFragment/AlertDialog). Умение проектировать независимыми сервисами — тоже умение. И единый транспорт (шина событий) в данной архитектуре — важнейшая часть.
Если не представляете, что такое сервис-ориентированная архитектура, то события Вам никогда не понадобятся. Я понимаю, что для приложения типа галерея — оно может и не нужно, но есть класс приложений, в которой использование сервис-ориентированной архитектуры важно.
Событие — по своему определению независимо от всех библиотек/компонентов/пр. Полностью согласен, что EventBus накладывает ответственность на разработчика. Так наша задача и состоит в том, что бы учиться правильно проектировать. И где нужна асинхронность + отвязка от ui/гибкая(меняющееся) бизнес логика/разделение приложения на слои — то лучше использовать события, а где можно использовать последовательности при неизменной бизнес логике — то лучший инструмент Rx и подобные инструменты. Поэтому выбранный Вами пример решается ну очень просто — генерацией события с данными — и всего одна строчка кода.
У MS изначально был подход — каждая новая версия не совместима с предыдущей. Сколько раз ее проклинали например за подход к доступу к данным (DAO/ADO/и пр). Начинал писать под Android с версии 2.1 — единственное работающее правило в ней — нет ничего гарантированного. Конечно с одной стороны плохо — с другой стороны учит писать совместимо, но «вероятностно».
Молодец!!! Все познается в сравнении. Когда у вас появится сразу несколько предложений развития одновременно внимательно всмотритесь в себя и в людей. Основная болезнь дельцов — «жадность» (может быть к Знаниям или Деньгам или к чему нибудь другому). И в этом они всегда всегда впереди. И это может заслонить у них все. Но слабы они во ВЛАСТИ — это уже прерогатива другого типажа.
Вы просто не видели и никогда не использовали крутые инструменты — и это не ваша беда. Например в свое время лучшим инструментом для 4G разработки SQL был PowerBuilder. Это просто небо и земля по сравнению с 1С — и мне удосужилось видеть разработки — копии по функциональности с 1С — но которые работают в десятки раз быстрее. Потому что и были правильно спроектированы и сам инструмент позволял в разы больше чем 1С. И писали его люди, которые не один год окучивали огород 1С
habrahabr.ru/company/yamoney/blog/334500
habrahabr.ru/post/128772
www.ibm.com/developerworks/ru/library/ws-eventprocessing/index.html