1) Посмотрел видео, по диагонали почитал книгу.
Моя статья мало имеет отношения к тому, о чём говорит профессор Шалыто =)
Он рассказывает о построении логики программ на основе стейт-машин / конечных автоматов (или об «автоматной парадигме программирования», если в терминах профессора). Стейт-машины — полезный инструмент, который Android-разработчики давно взяли на вооружение. Мы в hh практически каждую фичу описываем именно с их помощью.
Но писать абсолютно на каждый чих стейт-машины — это, во-первых, лишнее усложнение программ, во-вторых — не всегда возможно. Вот перед вами задача: в зависимости от объекта, пришедшего от сервера, покрасить кнопку в зелёный или синий цвет. Здесь стейт-машина не нужна, тут нужен простой boolean-флаг.
По сути, о таких простых флагах и идёт речь в статье.
Иногда флаги появляются и для описания переходов внутри стейт-машин, кстати. Немного странно делать 2 стейт-машины в этом случае, гораздо проще описать дополнительный if для одного перехода.
P.S. Лично мне показалось, что структура тех стейт-машин (автоматов), о которых рассказывает профессор, недостаточно гибкая. В частности, не увидел в структуре способе отдать единичное событие из машины наружу. А такое иногда требуется — например, показать снекбар при переходе в состояние ошибки. Каким-то полем внутри State-а это делать неудобно.
2) «Надо не собирать, надо не разбрасывать.»
Недостаточно понятная для зумера сентенция =) Уточните, что имеете в виду, как именно надо было «не разбрасывать»?
Вот есть проблема: если «не разбрасывать» и помещать код в один-единственный файл (неважно, в виде enum-а, в виде отдельных функций или ещё как-нибудь) — появятся merge-конфликты, от которых мы хотели уйти.
Если размещать в разных файлах (то бишь, «разбрасывать»), merge-конфликты уходят, но надо будет собирать всё обратно в единый список.
Хочется увидеть конкретное решение, которое вы предлагаете, реализацию в коде. Необязательно на Java, но тогда есть шанс, что вы используете какую-то специфичную для определённого языка конструкцию, которой просто не существует для Android-разработки.
1. На сайте случилась ошибка
Если вы отправите нашей службе поддержки как можно больше данных об инциденте, мы получим шанс это исправить.
2. Решают сложность увеличением сложности
Укажите, где именно случилось «увеличение сложности»? Мы столкнулись с проблемой merge-конфликтов, довольно дешёвым способом её решили. Захотели собрать разбросанные по кодовой базе флаги — и тоже сделали это довольно простым способом.
3. Проблемы с флагами давно уже решил Шалыто Анатолий Абрамович
Пробовал нагуглить его статьи про merge-конфликты, feature toggles, feature flags, не нашёл. На сайте, который вы указали, тоже не нашёл в публикациях подобных статей. Укажите конкретную статью, чтобы и другие читатели могли с ней ознакомиться.
Спасибо большое за такой подробный комментарий. Я очень рад, что наше решение пригодилось вашей команде!
По пунктам:
1. Забыл упомянуть в статье, что мы всё тестировали только на MacOs, на других системах не пробовали даже. Похоже, что нужно дописать в инструкцию шаги, что делать, если у вас другая операционная система, спасибо.
2. Globals специально не переносили. Всегда раздражало переключаться постоянно между template и global-ом. Но сейчас их стало не хватать самим, не очень удобным кажется добавление таких «переменных» через stringParameter. Возможно, добавлю секцию globals с возможностью туда внедрять нужные переменные с expression-ами.
3. Да, оператора отрицания тоже стало не хватать, добавлю в ближайшее время.
4. А вы это использовали для создания новых модулей? У нас есть планы докрутить функционал Geminio для похожих целей, тоже планировали заняться этим в ближайшее время)
Нет, видимо я недостаточно точно выразился.
Я имел в виду Git submodule.
В нашем основном репозитории хранится указание на нужный коммит репозитория с шаблонами. Когда мы скачиваем проект из github-а, мы выполняем команды
git submodule init
git submodule update
И код из репозитория добавляется внутрь нашего основного проекта. Из IDE это выглядит так, будто код шаблонов лежит прямо в нашей кодовой базе, вы даже можете менять текст шаблонов в своём проекте, но это не повлияет на код шаблонов в отдельном репозитории.
По поводу MVI и навигации — мы в hh так и делаем. У нас в основном проекте нет никакого Navigation Component, и навигация построена на Cicerone. То, что описано в статье — это большой тестовый пример, который был сделан в рамках ресёрча.
Не очень понял про состояние экрана, Navigation Component же не связан с ним (разве что в очень широком смысле). Navigation Component осуществляет навигацию, переключение между экранами, у которых могут быть свои состояния.
Если вы спрашиваете про сегодняшний день, то — Cicerone, который, всё-таки, решает гораздо больше проблем, чем добавляет)
Если про недалёкое будущее, то, может быть в Jetpack Compose будет уже меньше проблем с этим. Не помню уже где, но видел там какие-то конструкции вида:
Crossfade(navigationViewModel.currentScreen) { screen ->
when (screen) {
is Screen.Home -> HomeScreenComponent()
is Screen.Articles -> ArticlesScreenComponent()
}
}
Я согласен с тем, что для реального проекта передавать результаты зачастую проще через какие-то общие шины данных. А ещё это позволит описать бизнес-логику не во View-части =)
В статье мне хотелось показать то, как нам предлагают работать с Navigation Component и его сущностями. Я бы точно не рекомендовал делать так, как показано в статье, потому что это больно и костыльно.
Привет!
Вторая часть — на следующей неделе, и третья — через неделю после второй.
В качестве альтернативы предлагаю посмотреть видео. Там, по сути, тоже самое. Разве что я в статью мелкие добавления вставляю, которые не поместились в доклад.
Привет!
Могу только посоветовать дождаться продолжения статьи, или скинуть коллегам посмотреть её видео-вариант — очень может быть, что появятся новые аргументы за / против =)
Привет!
Почему же не в тему, вполне в тему. Каких-то исследований сходу не могу привести, не натыкался, кажется.
Но отдельный back stack нужен, если вы хотите:
а) по кнопке назад возвращаться на предыдущий экран в той же самой вкладке даже после переключения между вкладками. Например, в соискательском приложении hh.ru вы можете открыть вкладку «Профиль», там открыть своё резюме, потом переключиться на вкладку «Избранное», там открыть какую-то вакансию. Если вы после этого переключитесь на «Профиль» и нажмёте кнопку Back, вас перебросит на предыдущий экран именно во вкладке «Профиль», а не на экран во вкладке «Избранное».
б) Если хотите сохранять пройденный пользователем путь в отдельной вкладке — опять же, вы можете в соискательском приложении hh.ru открыть какую-то вакансию на первой вкладке, открыть из неё ещё кучу других вакансий, потом переключиться на вкладку «Избранное» и сделать там тоже самое. Когда вы переключитесь обратно на первую вкладку, вы сможете повторить весь путь обратно до стартового экрана вкладки.
Имхо, это улучшает UX, я был бы недоволен приложением, если бы информация, которую я так долго искал внутри вкладки, куда-то пропала.
Привет!
Если кратко — мне НЕ нравится Navigation Component =)
Для мелких приложений, где у вас не будет никаких сложных вложенных навигационных графов, где не будет нижней навигации, дип линков, а будет просто переход с одного экранчика на другой — Navigation Component не так уж плох. Работать с графическим редактором, в котором можно мышкой добавлять экраны, и создавать для него переходы очень даже удобно. И это точно удобнее ручной работы с FragmentManager.
Но для больших приложений — лучше выбрать другую библиотеку или самому что-то сделать.
Окей. Могу только согласиться, что официальной документации по плагинам решительно не хватает для создания чего-то по-настоящему классного, остается изучать чужие плагины и исходники самой IDEA.
Привет! К сожалению, готового ответа, как это сделать, у меня нет. Мы в hh.ru такого еще не делали. Но я бы предложил начал свой ресерч с исходников плагина Database Navigator (исходники).
Я могу попробовать изучить вопрос, когда выдастся свободное время, вдруг что-то накопаю.
1) Посмотрел видео, по диагонали почитал книгу.
Моя статья мало имеет отношения к тому, о чём говорит профессор Шалыто =)
Он рассказывает о построении логики программ на основе стейт-машин / конечных автоматов (или об «автоматной парадигме программирования», если в терминах профессора). Стейт-машины — полезный инструмент, который Android-разработчики давно взяли на вооружение. Мы в hh практически каждую фичу описываем именно с их помощью.
Но писать абсолютно на каждый чих стейт-машины — это, во-первых, лишнее усложнение программ, во-вторых — не всегда возможно. Вот перед вами задача: в зависимости от объекта, пришедшего от сервера, покрасить кнопку в зелёный или синий цвет. Здесь стейт-машина не нужна, тут нужен простой boolean-флаг.
По сути, о таких простых флагах и идёт речь в статье.
Иногда флаги появляются и для описания переходов внутри стейт-машин, кстати. Немного странно делать 2 стейт-машины в этом случае, гораздо проще описать дополнительный if для одного перехода.
P.S. Лично мне показалось, что структура тех стейт-машин (автоматов), о которых рассказывает профессор, недостаточно гибкая. В частности, не увидел в структуре способе отдать единичное событие из машины наружу. А такое иногда требуется — например, показать снекбар при переходе в состояние ошибки. Каким-то полем внутри State-а это делать неудобно.
2) «Надо не собирать, надо не разбрасывать.»
Недостаточно понятная для зумера сентенция =) Уточните, что имеете в виду, как именно надо было «не разбрасывать»?
Вот есть проблема: если «не разбрасывать» и помещать код в один-единственный файл (неважно, в виде enum-а, в виде отдельных функций или ещё как-нибудь) — появятся merge-конфликты, от которых мы хотели уйти.
Если размещать в разных файлах (то бишь, «разбрасывать»), merge-конфликты уходят, но надо будет собирать всё обратно в единый список.
Хочется увидеть конкретное решение, которое вы предлагаете, реализацию в коде. Необязательно на Java, но тогда есть шанс, что вы используете какую-то специфичную для определённого языка конструкцию, которой просто не существует для Android-разработки.
Давайте разберём всё по-порядку.
1. На сайте случилась ошибка
Если вы отправите нашей службе поддержки как можно больше данных об инциденте, мы получим шанс это исправить.
2. Решают сложность увеличением сложности
Укажите, где именно случилось «увеличение сложности»? Мы столкнулись с проблемой merge-конфликтов, довольно дешёвым способом её решили. Захотели собрать разбросанные по кодовой базе флаги — и тоже сделали это довольно простым способом.
3. Проблемы с флагами давно уже решил Шалыто Анатолий Абрамович
Пробовал нагуглить его статьи про merge-конфликты, feature toggles, feature flags, не нашёл. На сайте, который вы указали, тоже не нашёл в публикациях подобных статей. Укажите конкретную статью, чтобы и другие читатели могли с ней ознакомиться.
4. Ошибка исчезла, отклик исправился
Рад слышать.
По пунктам:
1. Забыл упомянуть в статье, что мы всё тестировали только на MacOs, на других системах не пробовали даже. Похоже, что нужно дописать в инструкцию шаги, что делать, если у вас другая операционная система, спасибо.
2. Globals специально не переносили. Всегда раздражало переключаться постоянно между template и global-ом. Но сейчас их стало не хватать самим, не очень удобным кажется добавление таких «переменных» через stringParameter. Возможно, добавлю секцию globals с возможностью туда внедрять нужные переменные с expression-ами.
3. Да, оператора отрицания тоже стало не хватать, добавлю в ближайшее время.
4. А вы это использовали для создания новых модулей? У нас есть планы докрутить функционал Geminio для похожих целей, тоже планировали заняться этим в ближайшее время)
Ещё раз спасибо за подробный фидбек!
Я имел в виду Git submodule.
В нашем основном репозитории хранится указание на нужный коммит репозитория с шаблонами. Когда мы скачиваем проект из github-а, мы выполняем команды
git submodule init
git submodule update
И код из репозитория добавляется внутрь нашего основного проекта. Из IDE это выглядит так, будто код шаблонов лежит прямо в нашей кодовой базе, вы даже можете менять текст шаблонов в своём проекте, но это не повлияет на код шаблонов в отдельном репозитории.
Свои шаблоны мы храним в отдельном, открытом репозитории — github.com/hhru/android-style-guide/tree/master/tools/geminio
Этот репозиторий мы подключаем в качестве submodule-я к нашему основному репозиторию, так что, по сути, всё хранится в отдельном месте.
По поводу MVI и навигации — мы в hh так и делаем. У нас в основном проекте нет никакого Navigation Component, и навигация построена на Cicerone. То, что описано в статье — это большой тестовый пример, который был сделан в рамках ресёрча.
Не очень понял про состояние экрана, Navigation Component же не связан с ним (разве что в очень широком смысле). Navigation Component осуществляет навигацию, переключение между экранами, у которых могут быть свои состояния.
Если про недалёкое будущее, то, может быть в Jetpack Compose будет уже меньше проблем с этим. Не помню уже где, но видел там какие-то конструкции вида:
Выглядит неплохо =)
Я согласен с тем, что для реального проекта передавать результаты зачастую проще через какие-то общие шины данных. А ещё это позволит описать бизнес-логику не во View-части =)
В статье мне хотелось показать то, как нам предлагают работать с Navigation Component и его сущностями. Я бы точно не рекомендовал делать так, как показано в статье, потому что это больно и костыльно.
Вторая часть — на следующей неделе, и третья — через неделю после второй.
В качестве альтернативы предлагаю посмотреть видео. Там, по сути, тоже самое. Разве что я в статью мелкие добавления вставляю, которые не поместились в доклад.
Могу только посоветовать дождаться продолжения статьи, или скинуть коллегам посмотреть её видео-вариант — очень может быть, что появятся новые аргументы за / против =)
Почему же не в тему, вполне в тему. Каких-то исследований сходу не могу привести, не натыкался, кажется.
Но отдельный back stack нужен, если вы хотите:
а) по кнопке назад возвращаться на предыдущий экран в той же самой вкладке даже после переключения между вкладками. Например, в соискательском приложении hh.ru вы можете открыть вкладку «Профиль», там открыть своё резюме, потом переключиться на вкладку «Избранное», там открыть какую-то вакансию. Если вы после этого переключитесь на «Профиль» и нажмёте кнопку Back, вас перебросит на предыдущий экран именно во вкладке «Профиль», а не на экран во вкладке «Избранное».
б) Если хотите сохранять пройденный пользователем путь в отдельной вкладке — опять же, вы можете в соискательском приложении hh.ru открыть какую-то вакансию на первой вкладке, открыть из неё ещё кучу других вакансий, потом переключиться на вкладку «Избранное» и сделать там тоже самое. Когда вы переключитесь обратно на первую вкладку, вы сможете повторить весь путь обратно до стартового экрана вкладки.
Имхо, это улучшает UX, я был бы недоволен приложением, если бы информация, которую я так долго искал внутри вкладки, куда-то пропала.
Если кратко — мне НЕ нравится Navigation Component =)
Для мелких приложений, где у вас не будет никаких сложных вложенных навигационных графов, где не будет нижней навигации, дип линков, а будет просто переход с одного экранчика на другой — Navigation Component не так уж плох. Работать с графическим редактором, в котором можно мышкой добавлять экраны, и создавать для него переходы очень даже удобно. И это точно удобнее ручной работы с FragmentManager.
Но для больших приложений — лучше выбрать другую библиотеку или самому что-то сделать.
Я могу попробовать изучить вопрос, когда выдастся свободное время, вдруг что-то накопаю.