Взаимод-ие фрагментов и активностей внутри системы (важно!)

[Mikhail_dev]

Тема важная думаю для многих будет. Предлагаю рассмотреть вопрос взаимодействия фрагментов внутри системы, а также (!) их взаимодействие с активностями.
Казалось бы, что тут сложного, следуй рекомендациям гугла и усё, но есть моменты, на которые я хотел бы найти ответ. Прошу всех, кто обладает какими-либо шишками, либо информацией, поделиться ею тут.

Общение фрагментов с фрагментами или активностями возможно через:
1. Слушатели (Listeners)
Это то, что советует гугл. Что в этом я вижу плохого:
1.1 Так это то, что если мы делаем один инфтерфейс (так сказать универсальный), к примеру на 30 методов, и если нам понадобилась активность новая, а в ней всего 5 методов надо, то либо новый интерфейс, либо реализовывать все 30 методов. Можно конечно помучиться с паттеранми, типа фабрики если не ошибаюсь, но это не то.
1.2 Слышал что слушатели регистрируются в очереди, либо в массиве и бывают проблемы в многопоточном приложении.
2. Прямая ссылка
Передавать прямую ссылку на активность очень удобно, но есть минусы:
2.1 привязка к одной активности
2.2 невозможность использования флага setRetainInstance (если правильно пишу - сохранение фрагмента). При сохранении фрагмента, ссылка на активность наверняка сохранится старая.
3. BroadcastReceiver.
И тут мы уже решаем первый минус слушателей. Шлем с нужного места бродкасты и ловим их в ПРОИЗВОЛЬНОМ количестве в ЛЮБЫХ местах приложения
Из минусов вижу только одно:
3.1 сообщения шлются во всю систему.
4. LocalBroadcastManager
И вот то, что по мне идеально. В документации сказано

Helper to register for and send broadcasts of Intents to local objects within your process.

Другими словами, у нас локальный бродкаст на наш процесс.
Мы наследуем все плюсы бродкастов, а при этом еще и лишаемся единственного минуса.

Вот такой расклад я вижу на данный момент. Просьба отписаться тех, кто что-либо знает по данному вопросу, а также пр грабли. И просьба по возможности прикладывать кусочки кода. И про нагрузку тоже можно пару слов чиркануть

[KamiSempai]

Лично я не вижу разницы в описании слушателя или LocalBroadcast.
Только в случае со слушателем сразу вызывается нужный метод, в то время как в Broadcast нужно еще с Intent провозиться.

[saabeilin]

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

Самое главное в этом подходе - независимость фрагмента от содержащей его активности. Мы можем внедрить фрагмент в любую активность, реализующую данный интерфейс. Ведь фрагмент, по идее, почти ничего не должен ничего знать о своей активности.

[rezak90]

1.2 Слышал что слушатели регистрируются в очереди, либо в массиве и бывают проблемы в многопоточном приложении.

Что бы не было проблем с многопоточностью юзай синхронизацию

привязка к одной активности

и что плохого то? у тебя всё равно на экране отображается максимум одна активити))

сообщения шлются во всю систему

и его не следует юзать только из-за этого... это мне сказал один сеньор, сказал что по рукам бы за такое дал бы

P.S. не понимаю что ты такого придумал что тебя гугловский гайд не устроил? никогда проблем не было между общениями, один интерфейс с одним методом = тунель между двумя сущностями

[rezak90]

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

Самое главное в этом подходе - независимость фрагмента от содержащей его активности. Мы можем внедрить фрагмент в любую активность, реализующую данный интерфейс. Ведь фрагмент, по идее, почти ничего не должен ничего знать о своей активности.

код после такого становится не читабелен, и если заказчик хоть чуть-чуть разбирается в коде то пошлёт его на переделкину мать.

[saabeilin]

привязка к одной активности

и что плохого то? у тебя всё равно на экране отображается максимум одна активити))

0. Отображается то может быть и одна, но вторая, вообще говоря, не факт что уже уничтожена как объект.
1. А если мне надо фрагмент вставлять в пять разных активностей, что, передавать во фрагмент все ПЯТЬ?

код после такого становится не читабелен, и если заказчик хоть чуть-чуть разбирается в коде то пошлёт его на переделкину мать.

0. /** @humor Код на Java вообще нечитабелен (после других языков) */
1. Грамотное проектирование интерфейсов, их минимизация как раз делает код читабельным, *особенно* на Java
(n+1) Заказчик тут как раз я

[Mikhail_dev]

Лично я не вижу разницы в описании слушателя или LocalBroadcast.
Только в случае со слушателем сразу вызывается нужный метод, в то время как в Broadcast нужно еще с Intent провозиться.

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

и что плохого то? у тебя всё равно на экране отображается максимум одна активити))

Ну как верно заметили, это сегодня, может быть, одна.

и его не следует юзать только из-за этого... это мне сказал один сеньор, сказал что по рукам бы за такое дал бы

Да фиг бы с ним, сеньером! Что ты скажешь про локальный бродкаст??

P.S. не понимаю что ты такого придумал что тебя гугловский гайд не устроил? никогда проблем не было между общениями, один интерфейс с одним методом = тунель между двумя сущностями

Слишком просто (Один интерфейс - один метод)
А теперь сложнее (Один интерфейс - много методов. Много интерфейсов - один метод. Много интерфейсов - много методов).
А теперь представь себе ситуацию, когда появилась новая активити, а в ней надо использовать всего пару методов. И в таком случае, придется реализовывать все методы интерфейса. Или же реализовывать к каждому фрагменту по одному методу работы с ним. И тогда активность будет выглядеть вот так
Class A implements Fragment_1, Fragment_2, ... Fragment_n

[KamiSempai]

Я сейчас заглянул под капот LocalBroadcastManager.
Ничего сверхъестественного. Работает по принципу слушателя.
Так-же как в слушателе есть массив, и при вызове sendBroadcast он пробегается по этому массиву и шлет указанное сообщение.
Представляет из себя ленивый синглтон. Естественно все там synchronized и за многопоточность можно не бояться.

Собственно говоря - это имитация броадкаста внутри приложения.

Единственный вопрос который меня сейчас мучает, на сколько это быстро, слать броадкасты.
Допустим, мне нужно каждый кадр передавать информацию в активити. Что быстрее, LocalBroadcastManager или слушатель на интерфейсах?

[saabeilin]

Class A implements Fragment_1, Fragment_2, ... Fragment_n

И это совсем не смущает меня, например. При этом какие-то "взаимозаменяемые" фрагменты могут использовать вообще один интерфейс, например.

[saabeilin]

Что быстрее, LocalBroadcastManager или слушатель на интерфейсах?

Боюсь, что ответ очевиден, если посмотреть исходники LocalBroadcastManager Там же фильтрация - по строкам. Понятно, что каждый раз разбор "мне/не мне" будет медленнее, чем.