Использование Отто вместо всего

Я уже некоторое время пользуюсь автобусом для мероприятий Otto, и это здорово. Можете ли вы назвать какие-либо недостатки его использования поверх реализации BroadcastReceiver внутри пакета или поверх более традиционного шаблона прослушивателя интерфейса?

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


person SIr Codealot    schedule 17.02.2015    source источник
comment
Что ж, для Отто есть альтернативы, но помимо этого я не вижу причин не использовать его, если он вам подходит.   -  person harism    schedule 17.02.2015


Ответы (1)


Google предлагает это, потому что они не могут просто предлагать людям использовать другие библиотеки. Их предложения всегда основаны на том, как это можно сделать внутри ОС Android без каких-либо дополнительных библиотек (кроме вспомогательных библиотек).

Есть небольшая потеря производительности (действительно небольшая), потому что otto использует отражение вместо скомпилированного кода, но Otto также кэширует отраженные «вещи», поэтому это небольшое снижение производительности применяется только к первому запуску определенного класса событий.

Как вы упомянули, в интерфейсе есть принудительное исполнение контракта, но, учитывая простоту использования Otto, стоит просто кодировать немного осторожнее.

LocalBroadcastReceivers может быть альтернативой, но, учитывая весь код для создания намерений, фильтров намерений и т. д., оно того не стоит.

Так что, ИМХО, да, идите вперед и используйте Otto везде (мы делаем это в приложении, над которым я сейчас работаю, у которого в среднем 920 тысяч активных пользователей в месяц).

person Budius    schedule 17.02.2015