Я всегда стараюсь посещать митапы и слушать выступления вживую, но на выходные обычно есть более масштабные планы. На неделе запланировать двухчасовое мероприятие обычно проще.
Чрезвычайно интересная и полезная статья, поставлю +, когда хватит кармы. ArkadyGamza, Вы скорее всего не найдёте время, чтобы переработать код, но для читателей хочу подметить одну особенность: вызовы типа
doAfterSuccess() // и другие doЧтоТо
и уж тем более присвоения внешних переменных вроде
.doAfterSuccess(this::setupSurface) // инициализация переменной класса mSurface
не совсем в духе Rx. Это называется side effect, чего рекомендуется избегать (например, операторами map/flatMap). Если же применение операторов невозможно (из-за разнородности целевых данных, например), можно оформить обычную подписку.
Думаю, это не так. В графе навигации вместе неплохо уживаются и фрагменты и Activity. Более того, документация заявляет, что можно без особого труда реализовать свой узел навигации, хотя описано довольно скудно.
Это верно, но мне хотелось разделить логику просмотра и редактирования, чтобы не перегружать одну Activity элементами, которые нужны «не всем».
Рассмотрим, к примеру, toolbar — это общий компонент для всех фрагментов. Одни фрагменты
(фрагменты списков) захотят видеть в нём поиск, другим нужно будет показывать сжимающуюся картинку (инфо фрагменты), а третьим и вовсе захочется встроить в toolbar поле ввода (фрагменты редактирования). Реализовав всё это в одной activity, мы получим монстр-toolbar/actvity со всеми вытекающими последствиями.
Такой подход имеет право на жизнь, но мне привычнее жить с разделением ответственности.
ArkadyGamza, Вы скорее всего не найдёте время, чтобы переработать код, но для читателей хочу подметить одну особенность: вызовы типа
и уж тем более присвоения внешних переменных вроде
не совсем в духе Rx. Это называется side effect, чего рекомендуется избегать (например, операторами map/flatMap). Если же применение операторов невозможно (из-за разнородности целевых данных, например), можно оформить обычную подписку.
Рассмотрим, к примеру, toolbar — это общий компонент для всех фрагментов. Одни фрагменты
(фрагменты списков) захотят видеть в нём поиск, другим нужно будет показывать сжимающуюся картинку (инфо фрагменты), а третьим и вовсе захочется встроить в toolbar поле ввода (фрагменты редактирования). Реализовав всё это в одной activity, мы получим монстр-toolbar/actvity со всеми вытекающими последствиями.
Такой подход имеет право на жизнь, но мне привычнее жить с разделением ответственности.