Вполне ожидаемо. AR/VR пик прошёл, попытки искусственного поддержания интереса пиаром и вливанием денег ни к чему не привели. Рынок всё расставил по местам.
Ну я больше к тому, что вкусы пиццы не просто разные. А можно сказать, что для меня в одном городе мне нравится, а в другом нет. Т.е. для меня уже не погрешность, так что даже перестал заказывать.
Верно, я бы сказал, что зависит не от проектов, а от их сменяемости. Если проектов сотни и каждый по месяцу, то наверное такая обёртка имеет смысл. А если один на пару лет…
Вброшу немного. Пробовал разные решения-обёртки над RecyclerView. Но это не таблетка счастья для меня. И вот почему:
1) Я не создаю по 5 экранов-списков на дню, чтобы меня это действительно мучало.
2) Я прекрасно знаю как заставить работать стандартный RecyclerView, а вот та обёртка которую использовал последний раз 2 месяца назад уже не помню… хочу ли вспоминать — не особо.
3) Бывает нужно сделать что-то хитрое, на что обёртка не способна… и вот ты либо выкидываешь полуготовый код и переходишь на обычный RecyclerView, или дорабатываешь обёртку(а тут уже п.2 снова)
Расскажу тоже немного о своём опыте. У нас было два Андроид приложения и 3 «библиотеки» для двух приложений
1) Вариант с мавен репозиторием считаю самым лучшим и правильным. НО только если у вас есть отдельная подкоманда, которая занимается либами, следит за версионностью и обновляет мавен. Типа «под ключ». У нас маленькая команда. У нас не получилось, отказались, перешли на submodules
2) Но от сабмодулей тоже отказались. Да, стало удобнее, но появилась некая проблема с версиями. Плюс проблема частых изменений никуда не ушла, на любое изменение и коммит в либе надо не забывать делать менять «указатель» на коммит в приложениях. Вообщем довольно много действий на каждое телодвижение.
3) Subtree не пробовал, но почитаю. Но мы перешли на простое монорепо, где каждая либа просто свой градл модуль, и все модули и оба приложения в одной кодовой базе. И пока в небольшой команде жизнь значительно проще
А вот такой вопрос. Предположим есть кнопка, к ней есть некая фича(логика). Результатом нажатия кнопки должна исполниться фича(логика) и в конце показаться фрагмент или диалог-фрагмент. Для его показа нужен либо фрагмент менеджер либо child фрагмент менеджер. В идеале такой компонент хочется максимально легко переиспользовать, а именно добавить в xml и всё. Возникает проблема передачи фрагмент менеджера. Тут либо во внешнем клиенте компонента создавать провайдера зависимости либо ручками добавлять его в компонент. Как вы решаете такую задачу?
1) У вас также будет проблема кто будет вызывать dispose() в RX
2)
View уже уничтожена, если бы вы напрямую из RX обновляли View
Тут не так, в этом случае есть другая прослойка в виде того же DataBinding. Поэтому RX меняет View не напрямую, а через DataBinding. В этом случае LiveData уже лишняя
rx никак не связан с MVVM. Как раз сейчас у меня в одном из проектов MVVM вместе с Rx. Rx всё таки обладает более полноценной поддержкой ReactiveStreams. Всякие zip, combineLatest и многие прочие другие операторы…
Почему не RX? LiveData это же не до RX.
Под требования «оповещает только активных подписчиков, в момент подписки не оповещает о предыдущих данных» в RX уже всё есть. PublishProcessor
Вкус бигмака одинаковый в Стокгольме, Москве и на острове Пхи-Пхи(Таиланд).
1) Я не создаю по 5 экранов-списков на дню, чтобы меня это действительно мучало.
2) Я прекрасно знаю как заставить работать стандартный RecyclerView, а вот та обёртка которую использовал последний раз 2 месяца назад уже не помню… хочу ли вспоминать — не особо.
3) Бывает нужно сделать что-то хитрое, на что обёртка не способна… и вот ты либо выкидываешь полуготовый код и переходишь на обычный RecyclerView, или дорабатываешь обёртку(а тут уже п.2 снова)
1) Вариант с мавен репозиторием считаю самым лучшим и правильным. НО только если у вас есть отдельная подкоманда, которая занимается либами, следит за версионностью и обновляет мавен. Типа «под ключ». У нас маленькая команда. У нас не получилось, отказались, перешли на submodules
2) Но от сабмодулей тоже отказались. Да, стало удобнее, но появилась некая проблема с версиями. Плюс проблема частых изменений никуда не ушла, на любое изменение и коммит в либе надо не забывать делать менять «указатель» на коммит в приложениях. Вообщем довольно много действий на каждое телодвижение.
3) Subtree не пробовал, но почитаю. Но мы перешли на простое монорепо, где каждая либа просто свой градл модуль, и все модули и оба приложения в одной кодовой базе. И пока в небольшой команде жизнь значительно проще
2)
Тут не так, в этом случае есть другая прослойка в виде того же DataBinding. Поэтому RX меняет View не напрямую, а через DataBinding. В этом случае LiveData уже лишняя
Под требования «оповещает только активных подписчиков, в момент подписки не оповещает о предыдущих данных» в RX уже всё есть. PublishProcessor