Pavel Korolev

Эффекты и Compose

В эфире регулярная рубрика "в интернете кто-то посрался". Сегодня на повестке дня вот этот обмен твитами. Там всё начинается с будничного хаяния Compose, а потом туда приходит один из разработчиков Compose и тут понеслась.

Ключевые тезисы:
- Эффекты использовать вообще плохая практика
- Наша же документация в этом смысле учит людей плохому, мы пытались донести это деврелам, они не слушают
- Функцию remember тоже лучше не использовать за исключением некоторых юзкейсов типа анимаций. ✏️

И это довольно забавные инсайты. Понятно откуда берётся это желание, чтобы Composable функции были (условно) чистыми, но в жизни по моему это не очень работает, учитывая горы нашего легаси за миром композа.

Плохо, что альтернативы не очень-то и раскрыты. Я покопался в нашей кодовой базе и попытался сформулировать наши юзейсы для эффектов.
- Во-первых они всё равно используются где-то под капотом collectAsState*. Считается ли это плохой практикой я не уверен. Но без этого, кажется, мы вообще не можем в том месте, где пытаемся связать Composable функцию с каким-то логическим компонентом, например вьюмоделькой, буквально по всех популярных подходах к архитектуре.
- Во-вторых это подписки на всякие Flow, т.к. только внутри эффектов у нас есть скоуп. И всё это можно было бы разрулить где-то в тех же логических компонентах, если бы не нужно было на эти события взаимодействовать с UI или платформенными штуками. Где-то у нас всратые Material апишки типа боттомшитов и снэкбаров, которые ни спрятать ни показать в m2 без корутин нельзя. Где-то нужен активити контекст, например, чтобы другую активити открыть. Где-то у нас под листвой вообще грабли в виде AndroidView, с которым нужно общаться императивно. Где-то приходится заворачивать в это всё пермишны и Result API. И как быть без эффектов то?
- В-третьих это часто используется как колбэк от UI, что он там начал рисоваться, типа "бизнес логика, запускайся". В этом кейсе я согласен, можно это на уровень Composable и не тянуть. С remember я тоже по большей части согласен в продуктовом коде, но когда пишем библиотеку уже не очень. Ребята в аккомпанисте соврать не дадут.

В общем типичный срач между тем, кто пишет инструмент и предполагает как его нужно использовать, и теми кто пытается применить его на практике и борется со всем миром лишь бы оно вообще завелось, и пофиг на то насколько это идеологически чисто. Можно понять обе стороны, но обе не сильно-то и правы. Мы понимаем, что это всё лучше не использовать, если можно обойтись. Нам тоже хотелось бы писать такие Composable функции, которые просто принимали бы уже готовый стейт. Но это невозможно, или с точки зрения существующих библиотек (от других отделов гугла же), или с точки зрения легаси, или с точки зрения перформанса, или просто альтернатива настолько бойлерплейтная, что всему комьюнити проще так.

Респект таким конфам, которые выкладывают записи не через полгода, а сразу, пока ещё не забыл, что хотел посмотреть. Да ещё чаще звук на видео лучше, чем в жизни был. Ставим лайк 👍

upd. меня поправляют, что видео доступны только купившим билеты, ну штош, такие тоже тут есть :)

Документация не для людей

Главная проблема любых LLM сейчас в том, что у нас человеков в голове с огромным трудом формируется связь между задачей и тем, что её можно делегировать нейронке. То есть они уже могут очень очень много всего делать как минимум нормально, но мы по старинке это делаем сами, т.к. не задумываемся об этом. А когда задумываемся, то удивляемся почему раньше не думали. 🤔

Довольно много в последнее время играюсь с Projects у Claude. Это примерно тоже самое что и кастомные GPTs у ChatGPT. То есть мы заранее можем начинать чат с определённым контекстом "проекта", причём в этот контекст мы можем накинуть и кучу файлов в качестве базы знаний и системные промпты.

У нас в репе проекта есть совсем небольшая маркдаун документация, которая писалась в первую очередь как материалы для онбординга. Или для новых разрабов, или для старых в новую технологию / новый подход, но всё таки для онбординга. Есть техрадар, где описана актуальность всех технологий, есть документация по подходу к модуляризации с типами модулей и правилами, есть документация по архитектуре конкретных фич, есть небольшой роадмап типа от чего избавляемся и куда хотим двигаться. А кроме документации, понятное дело, наш проект очень хорошо описывают файл Version Catalog и конфиг с detekt правилами. То есть всё то, от чего код сильно зависит.

Люди документацию редко читают превентивно. Для людей документация - это просто место куда можно сходить за дополнительной информацией в случае проблемы. А вот нейронка нет, это просто восхитительный материал для помощи ей. Закидываем это всё в кастомный Project, и любой чат сразу начинается без необходимости расписывать огромный промпт с деталями как делать, как не делать, что тебе надо, и так далее. Мы буквально онбордим нейронку заранее и один раз. И это у меня ещё где-то 15% от потенциального размера контекста, можно представить сколько туда ещё можно добавить всего.

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

В связи этим опытом у меня даже какой-то концептуальный сдвиг в голове произошёл. Всем понятно, что промпт инжинеринг невроятно важен и всем будет нужен, но эта мысль куда-то на шаг дальше ушла. А я теперь почти уверен, что документацию мы будем писать не людям, а нейронкам в первую очередь, потому что им она сильно нужнее и импакт от такой документации в разы больше. И финальная мысль - нам нужно инвестировать больше времени в то, чтобы в тексте формализовать все устные соглашения. То что разработчики будут их игнорить нас даже не волнует, потому что всё равно есть понятный юзкейс.

PS. GPTs у ChatGPT даже не близко в этом смысле, видимо из-за ограничений по размеру контекста он не воспринимает файлы из knowledge base как этот самый контекст. Ответить про содержимое этих файлов может, но когда просишь сделать фичу как принято по документации - он просто на это всё забивает и пишет максимально дженерик код в гугловом стиле и льёт кучу воды вместо того, чтобы почти молча написать код.

PPS. Купил стимдек, количество постов резко сократилось до тех пор, пока не пройдёт зависимость и снова не появится свободное время, сами понимаете. 👮

Clean / Rebuild Project

В новой канарейке студии удалили пункты меню Build - Clean и Build - Rebuild Project. Ага, две самые тыкаемые кнопки студии после Invalidate Caches and Restart удалили, вы правильно поняли. 💥

И узнаём мы об этом конечно из постов в r/mAndroidDev, потому что в ченджлоге студии изменения в меню Build упоминаются, но именно про это там нет. Там говорят, что в общем доработки скорее направлены на то, чтобы все эти задачи запускались только на выбранной конфигурации, а не на всём проекте целиком.

Мысль придумать с этим что-то довольно похвальная, т.к. мало кто из разработчиков вообще задумывается насколько ребилд всех source-сетов это оверкилл для проблемы, которую они пытаются решать. Но они удалили и не дали никакую замену. Через общий поиск найти всё ещё можно, но в менюшке больше нет.

Пункт Clean всегда делал gradle clean в корне, если не ошибаюсь, т.е. удаляла результаты сборки во всех подмодулях. Ну да, зацепит лишние модули, если в текущей конфигурации они не используются, но обычно это не настолько долго. А действия гугла сейчас явно направлены на то, чтобы не показывать нам что там вообще под капотом есть какой-то грэдл.

Моя претензия к этому пункту в таком случае заключалась бы только в том, что его бывает недостаточно. Хочется какой-то диалог с разными уровнями зачистки, от кэша конкретных модулей до кэша самого грэдла и на уровне проекта и на уровне GRADLE_HOME. Но теперь у нас даже этого нет.

Rebuild Project делал gradle clean build, в котором build это слииишком общая таска, объединяющая всё на свете. Это действительно пункт довольно бесполезный, но вместо него обывателю хотелось бы видеть что-то типа gradle clean + сборка только выбранной конфигурации, без пересборки тестов, всех билдвариантов и всего такого.

Если же мы пофантазируем про какие-то полезные юзкейсы, которых не хватает в смысле сокрытия от нас грэдла, то хочется какой-то быстрый способ флажок --rerun-tasks докинуть, или --refresh-dependencies. А такого тоже нет.

Сколько раз эти кнопки спасали нас от какой-то нестриггерившейся кодогенерации, от рандомных багов при переходе между ветками, от кучи других проблем. Да и не то чтобы оверхед настолько критичен на большинстве проектов. А теперь видимо всем учиться делать ctrl+ctrl+вручную вызывать грэдл таски или как взрослые через терминал. Удачи новичкам.

PS. Обновился на Ladybug через Toolbox, частично слетели настройки. Обычный день. 😷

Инициализация в ViewModel

Последний месяц в англоязычном сообществе в очередной раз перетирают тему как правильно триггерить инициализацию стейта в ViewModel. Сначала было обсуждение в твиттере, потом вот здесь по итогам появилась статья, на реддите и в комментариях автору закидали всю панамку, на ютубе ещё раз пережевали, и закончили всё тем, что автор вторую статью написал с ответами (оверинжинеринг лютый) на популярные вопросы. И это всё прям интересно так, показательно.

Задача такая: есть экран, у него есть какое-то состояние, на старте триггерится какой-то процесс, например запрос в интернет, который поменяет это состояние. Вопрос звучит так: где это всё делать? Сразу оговоримся, что речь идёт только про Compose, поэтому зумеры пытаются придумать решение проблеме, которую раньше даже не приходилось решать.

Первое решение, которым, по опросу от автора, пользуется примерно треть: LaunchedEffect(Unit) { viewModel.load() }. То есть Composable функция при первой рекомпозиции сама триггерит вызов какого-то метода. Плюсы: бизнес логика отвязана от создания объекта. Минусы: можно забыть; вьюшка командует вьюмоделью; при пересоздании вьюшки всё перезагрузится.

Второй вариант более популярный - использовать init секцию ViewModel. Плюсы: вызвать инит секцию ты никогда не забудешь. Минусы: бизнес логика (запуск корутины) формально является частью создания объекта и вытекающие из этого последствия.

На это всё пришёл чувак из гугла и говорит: вообще-то и то и это антипаттерны, у нас в документации даны все рекомендации Рекомендации заключаются в том, что состояние экрана должно быть холодным флоу, который запускает всю логику инициализации уже когда вьюшка на него подпишется. Ну и чтобы каждый раз флоу не пересоздавать, то обмазать StateFlow какой-то стратегией типа SharingStarted.WhileSubscribed(5_000). Так, говорят, ещё у наших дедов в LiveData было.

Плюсы: бизнес логика отвязана от создания объекта. Вручную дополнительно делать ничего не нужно. Переживёт смену конфигурации. Минусы: вообще нафиг всё остальное, но мы все вам об этом не расскажем. 🏥

Мне кажется эта строчка с 5 секундами это какой-то мем, потому что на полном серьёзе это в рекомендациях писать не стали бы. Идея заключается в том, что пересоздание вьюшки типа поворотов экрана стейт переживёт, а в случае если на него "долго" никто не подписан, то флоу можно прибить. Надёжная как швейцарские часы. Перешёл на другой экран, через 10 секунд вернулся - всё перезагружается. Аргументируют это тем, что импакт от перезагрузки обычно незначительный. Без комментариев. Даже если весь мир закэшировать, то это всё равно лишняя работа по восстановлению состояния убитого ни за что.

Стейт экрана это что-то более комплексное, чем единожды созданный дата класс. Для загрузки могут понадобиться параметры пришедшие из аргументов экрана или от UI. Возможно мы загрузку захотим зарефрешить каким-нибудь свайпом. Обычно ViewModel апдейтит его из кучи разных методов и это нормально. Возвращаться в 2017 комбинируя все эти потоки данных в одну огромную реактивную цепочку я не очень хочу, я уже привык, что можно вместо этого писать простой код. Как по мне это решение становится хуже и хуже с каждым маленьким усложнением.

Справедливости ради, если мы хотим что-то подобное без этих недостатков, то кроме WhileSubscribed есть стратегии SharingStarted.Lazily или Eagerly. К ним у меня вопросов уже сильно меньше, вот хорошая статья с похожими мыслями, они хотя бы UX не ломают. Да даже и в документации гугла по ссылкам выше это сказано, но почему-то на виду примеры кода только с первым. 😱

А вы как подобное пишете? Мне init + MutableStateFlow проще и понятнее вообще всегда. Стреляло в ногу один раз, но это уже отдельная история.

Podlodka Android Crew #12. День 5

Заключительный день тоже оказался тяжёлым, накопленное перенасыщение давало о себе знать, я вот только отошёл.

Первый доклад дня от Анны Жарковой про автоматизацию создания UI с помощью AI разочаровал. Всё тот же посыл как и днём ранее: из России эти ваши ChatGPT не работают, поэтому мы вынуждены плакать, колоться и тыкаться в GigaCode. Ну и в Gemini почему-то чуть чуть тоже будем тыкаться, хотя он тоже не особо доступен. И весь доклад как раз о том, что нифига они нормально не генерят и придумывают много всего несуществующего. Не знаю как для вас, для меня это новостью не стало, но было интересно посмотреть, что оно там вообще живое и даже какие-то плагины для студии есть. Claude и ChatGPT с последними обновлениями для меня сейчас безальтернативные фавориты и если и проверять что-то на прочность, то скорее их.

Более того, "создание UI" это не просто нагенерить пачку базовых Compose компонентов. Для меня нормальная вёрстка подразумевает переиспользование уже существующих в проекте концептов типа токенов и компонентов из дизайн-системы, иначе это код на выброс. А это вообще не затронули. Есть наитие, что для какого-нибудь клода переварить в контексте сигнатуры функций и токены из дс + json выгруженный из Figma API в терпимый код на композе это весьма даже посильная задача, хотя руки проверить пока у меня до этого не добрались, впрочем пометочку себе оставил. ✏️

Т.е. оба доклада об AI, и о тестах и о вёрстке, подразумевали какую-то специфику андроид разработки, но превратились в обзор плагинов и моделей не имеющих с ней ничего общего. Это не очень понравилось.

Заключительная сессия недели от Миши Левченко была про написание собственного сервиса автоматизации. Тоже довольно верхнеуровнево и поэтому просто для восприятия кому угодно, но пачку интересных мыслей на подумать оставляет. Если уложить посыл в несколько предложений, то там примерно так будет: пишите автоматизацию всего в виде кода, по аналогии с любым продуктовым, потому что разработчикам это привычнее и удобнее. Писать проще всего в виде бэкенда, без всяких пользовательских интерфейсов. Ну и технологии выбирать надо как по кайфу разработчикам, но немножко с оглядкой по сторонам что в компании принято. Это прям безоговорочно хедлайн выступление подлодки, потому что кроме интересной инфы формат с реальными бумажными "слайдами" вместо обычной презы выглядел супер оригинально. Сколько деревьев потрачено на подготовку неизвестно.

TIL что такое вообще где-то бывает. По умолчанию когда задумываешься об автоматизации на ум приходит скорее кастомизация CI и всякие существующие на уровне джиры или гитлаба инструменты. Хотя даже не совсем так, идея использовать апишки всех этих сервисов в воздухе витает и время от времени ты что-то такое вспомогательное пишешь, но прям взять это и всё вместев виде бэкенда с базой куда-то задеплоить я ещё не дошёл. И сейчас понятно, что это в какой-то степени решает много проблем. И создаёт, да.

Итого по всей неделе что можно сказать. Из-за тематики почти все доклады для меня получились довольно простые и часто повторяли мой собственный опыт. Это и плюс и минус, плюс в том, что прекрасно мои решения валидирует, минус в том, что нового я услышал не очень много. Но между строк иногда удавалось выцепить интересные детали. Как всегда больше пользы для себя вынес из чата зума, телеги и блока вопросов после сессий. Подготовка к докладу от некоторых ребят очень понравилась, явно буду пересматривать примерно треть из них именно с той точки зрения, чтобы свои доклады в будущем совершенствовать.

Программному комитету и спикерам спасибы, было интересно. 😑

Podlodka Android Crew #12. День 4

Как я уже и упомянул, день ооочень долгий. Три доклада и рандом кофе.

Первый доклад дня от Жени Мацюка это классическая для него база по UI тестам, такой мета-доклад по своим и чужим докладам с других конф. Я это все и так уже пересмотрел, поэтому ничего нового почти не вынес, к сожалению. Разве что было интересно послушать про всякие облачные сервисы, на которых эти тесты можно запускать не офигевая от строительства собственной инфры. Были отмечены emulator wtf, Firebase Test Lab и Marathon Cloud. Ну и две интересные мысли запомнил: восток в отличие от запада любит писать свои велосипеды, и в основном UI-тесты у всех пишут QA. Наверно свой стыд за то, что я никогда не писал нормальные UI тесты немножко можно сбавить, QA виноваты. 🤟

Рандом кофе нас свёл с Лёшей Хайминовым, который на круглом столе отвечал за средние проекты, и совпадения получились довольно забавные. Он родом из Алматы, я волею судеб сейчас из Алматы, поэтому темы общие нашли. Обсудили и местные особенности, и кипрские, где зафиксировался он, и андроид и мультиплатформу. Вы догадываетесь какие разговоры у иммигрантов-андроид разрабов. Прикольно было обменяться мыслями.

Первая вечерняя сессия была про генерацию автотестов с помощью LLM. Плюс минус самый бесполезный для меня доклад на этой подлодке (кажется это участь всех докладов, где упоминается AI). Доклад в одном предложении: есть вот всякие ChatGPT и Copilot-ы, они нам недоступны, небезопасны, поэтому ими не пользуйтесь, пользуйтесь локальными моделями. Некоторые особенности, назовём их так, российского рынка сказываются и на докладах. А специфики тестов я практически и не услышал, за весь доклад показали пару тестов уровня калькулятора.

Наслушавшись это всё начинаешь ещё больше ценить места, где раздают энтерпрайз Copilot и ChatGPT. Немного флэшбэкнуло даже в мир, где ты с рабочего ноута не можешь в нормальный интернет выйти, брр.

Последняя сессия дня - воркшоп по Geminio. К инструменту вопросов ноль, хотя я, когда у меня возникла идея генерации feature и core модулей в проекте просто пошёл и свою Gradle-таску написал, мне от Geminio чего-то не хватило. Больше вопросов к генерации 10 классов для фичи на Decompose + MVIKotlin. Мне пока какие-то внутренние убеждения не позволяют такое спрятать за генератором. Кажется что это слишком неявный способ скрыть комплексность архитектуры вместо того, чтобы всякими проверками и кодом направить разработчика не написать фигню, что более важно. Модули создать – это ок, потому что в студии это довольно геморно сделать по какому-то паттерну без лишнего мусора, ну и в этом не так много разночтений.

Сегодня последний день, я уже устал, честно говоря 😄

Podlodka Android Crew #12. День 3

Долгий долгий четвёртый день закончился, но мы с вами не торопимся, поэтому обсудим третий.

Первый доклад дня про релизные поезда от Я.Диска. Убедился что наш додошный вариант вполне эффективен, мы не сильно жалуемся. Автоматизацию публикации в сторы мне пока так и не продали. Хотя если публиковать 6 разных сборок по разным магазинам раз в неделю, то я бы тоже призадумался. Когда релиз раз в 3 недели в полтора стора, то как будто и не стоит того.

Интересно было обсудить подход к наполнению Release Notes в этих релизных поездах. Предлагается автоматическое заведение тасков на продактов и, соответственно, на маркетинг, без которых поезд не уедет. Думаю по такому пути и пойдём, а то наши пользователи явно устали от "новых тарифов" больше полугода в каждом релизе. А по хорошему релиз ноуты писать никто не хочет 🙁

На этом фоне ещё порассуждали про упомянутый trunk based подход к гиту. Но я для себя пока так и не определил грань покрытия тестами, начиная с которой не страшно лить всё подряд без тестирования в общую ветку (реквестирую ваш любимый материал на эту тему, хочу вкатиться). Наш а-ля git flow подход явно со страшными оверхедами в области CI пайплайнов и тестирования на мёрж реквестах, но нам он пока даёт такие гарантии, с которыми QA на регрессах не приходится перепроверять все последние изменения. Там где trunk based, там и фичатогглы, поэтому унёс из чатов к себе на размышление то, как бы такую политику сформулировать, чтобы их число не разрасталось настолько неконтролируемо, как это происходит по умолчанию. ✏️

Вторая сессия была круглым столом, где обсуждалось как CI/CD процесс выглядит в маленьких, средних и больших компаниях. И естественно всё скатилось в обсуждение какой-то дичи большой компании, потому что всем интересно. С точки зрения развития кругозора и для того чтобы какой-то офигевший масштаб осознать это наверняка полезно, но на практике не очень. Даже "средний" описанный проект, с моей точки зрения, выглядит уже как суперпродвинутый, это не очень понравилось. По крупицам удалось насобирать идей с чем поиграться. Захотелось затащить к себе dependency-guard, поиграться с dependecy-analysis и talaiot, а до кучи ещё в какой-нибудь импакт анализ занырнуть. Не то чтобы это нам какие-то сумасшедшие профиты принесёт в краткосроке, но с целью собственного развития почему бы и нет.

Ещё одна прозвучавшая за круглым столом мысль, которая пока мне покоя не даёт: зелёный девелоп гарантируется только очередями из мёржреквестов на мёрж при условии того, что на них ещё и все проверки запускаются. А если тебе хочется чтобы мры ещё и быстро от пуша до мёржа продвигались, то это вообще утопия скорее. Отсюда сделал вывод, что процессы выхода из нехороших ситуаций наверно в большинстве кейсов даже важнее, чем защита от попадения в эти нехорошие ситуации. Что впрочем не новость, но именно в смысле работы с гитом и тикетами я об этом видимо ещё не задумывался. Поэтому лучше раз в несколько месяцев сломать общую ветку или пустить проблему в релиз, но иметь процесс это быстро поправить и при этом всегда стабильно быстро работать, без фанатизма в надёжности.

Podlodka Android Crew #12. День 2

Утренний доклад второго дня подлодки от Григория Шимичева про кастомные detekt правила. Тоже самое. У меня опыт есть, я их уже писал, поэтому половину доклада для чего это и как завести можно было спокойно проскипать. Интересно только про type resolution послушать. Мы прогоняем детект только на CI до сборки и без type resolution, чтобы лишнее время не тратить, и нет ощущения что мы сильно недополучаем чего-то. Ну и от докладчика тоже самое услышал. Кажется, что тема type resolution у detekt это примерно как тесты, все говорят, но нормально начать использовать все только собираются.

Поймал себя на мысли, что моя любимая формулировка вопросов в последнее время это "где грань между тем и этим?". Я очень часто пытаюсь её нащупать, но не всегда получается. Вот например где грань между тем, что должен проверять Android Lint, что должен проверять detekt, а что какой-нибудь Konsist? Они даже на первый взгляд в чём-то пересекаются несмотря на свои разные, казалось бы, цели, не говоря уж о том что там можно кастомное написать.

Контента ради, накидаю рандомных идей для правил из нашего проекта: Запрещены LiveData и MutableLiveData, Запрещены android.* импорты в ViewModel, Запрещены публичные поля в конструкторах ViewModel, запрещены названия классов типа Base*, Проверка на максимальное число классов в одном файле. Написаны кровью, впрочем до конца так и непонятно насколько это вообще задача детекта.

Вечерний доклад Паши Стрельченко про плагины для IntelliJ пока лучший по наполнению. Супер насыщенно и с практикой, максимально классное и интересное повествование, как и всегда. Но это во многом как раз потому, что в кроличью нору написания плагинов я пока не погружался. Да и не очень то и хочу, честно говоря, т.к. наслышан про боль и страдания, особенно в смысле поддержки новых версий IDE, зачем мне это? Если говорить про какие-то грани, то я тоже явно пока не перешёл ту, где у меня появилась явная необходимость плагин для IDE написать вместо какой-то Gradle-таски или standalone утилитки. Это или какой-то прикол масштаба, которого я пока не видел, или оставшиеся 80% усилий ради 20% результата.

Podlodka Android Crew #12. День 1

Взял отпуск, чтобы с полными силами смотреть новый сезон подлодки (на самом деле нет, совпало). Неделя автоматизации прям в меня попадает пока, поэтому много мыслей по каждому докладу, попробую каждый день что-то фиксировать для себя.

Первый доклад дня от Никиты Куликова был про Github Actions. И он довольно грустный на самом деле. Потому что у меня и так тревожность от того, насколько моя жизнь завязана на гитхаб, так ещё и Actions слишком хорош, чтобы почти в любой ситуации выбирать не его, а остальные популярные CI. И дешевле, иногда бесплатно даже, и маркетплейс экшнов есть, которых всегда не хватает во всяких гитлабах. Слишком просто становится писать сами ямлы, засчёт чего ты всё сильнее в это болото зависимости утопаешь. Мне всегда казалось, что правило хорошего тона для CI это максимально всю комплексность настройки переносить от CI решения в сторону проекта, в нашем случае грэдл таски писать и всё такое. Но если комплексности настройки вообще практически нет, то может и не так страшно это всё. Ну и остался при мнении, что CI конфиги писать не сложно, сложно собрать такую модель поведения, которая будет эффективно работать на конкретном проекте.

Второй доклад от Никиты Яцкивского был про автоматизацию экспорта токенов из Figma. Я буквально этим прямо сейчас занимаюсь и было интересно сравнить опыт, хотя от оригинальной статьи на хабре ушло не далеко. У меня не пропало ощущение, что все такие решения делаются из говна и палок без возможности нормально переиспользовать между проектами. Автоматизация состоит из двух частей: выгрузить из апи фигмы в какой-то промежуточный формат и сгенерить из этого формата код. И проблема в том, что в фигме структура нод у всех разная и код всем нужен разный, отсюда и not invented here синдром. Поэтому про теорию послушать интересно, но на практике всё самому всё равно делать, благо это максимально прямолинейная активность. Жаль, что самое интересное для меня осталось скрыто за словами "фигма не дала нам энтерпрайз, т.к. мы российская компания", а variables это как раз то, что потенциально может защитить нас от разной структуры фигмы, облегчить переиспользуемость и спастись от шаловливых ручек дизайнеров.

Надеюсь дальше чуть больше каких-то инсайтов и кишочков. Пока всё довольно верхнеуровнево и помогает разве что провалидировать свою адекватность или триггернуть размышления по всем этим темам. Но если опыт есть, то мало что нового узнаёшь, хотя ребята объективно в теме очень хорошо поварились. В чате больше интересностей, как всегда)

WebView и Compose

У нас в приложении достаточно много фич открываются просто как WebView с кучей разных настроек, хуков, переопределением логики загрузки урлов, множеством параметров в кукисах, и так далее, не говоря уж о всяких браузерных приколах типа пермишнов и файл пикеров. И вот уже несколько месяцев как мы подкрались к идее взять вот всю эту логику из фрагмента и засунуть в голый композ, чтобы спокойно его встраивать в декомпоз иерархию. И вот уже несколько недель я в фоновом режиме всё пытаюсь переварить. Мысли.

Задача по сути делится на две. Первая - дженерик обёртка WebView в AndroidView. Т.е. буквально "замена" классическому WebView для композа. Состояние индустрии такое, что официальной обёртки от гугла не существует. Ну то есть как не существует, есть Deprecated реализация в Accompanist, которую самим же гуглом и предлагается форкать, потому что они сдались её поддерживать. И не то чтобы она плохая, на первый взгляд даже решает тривиальные кейсы типа загрузки урла без лишних настроек, но к ней прям привыкнуть надо. Как и многое у гугла оно как-то очень некрасиво наружу высовывает андроид зависимости типа клиентов, битмапов и так далее. Оно слишком в лоб реализовано. Поэтому первым делом хочется написать обёртку на обёртку, ага. 👌

Если копнуть глубже, то любая какая-то очевидная фича типа пулл-ту-рефреша делается в таком сетапе с болью и страданиями. Серьёзно, там на стэковерфлоу единственный рабочий ответ походу подразумевает использовать вьюшный SwipeRefreshLayout внутри того же AndroidView с WebView. Но это даже не проблема конкретно этого решения, это в принципе проблема AndroidView в композе. Слава богу, у нас эту фичу пока никто не придумал.

Вторая часть задачи, на самом деле, учитывая первую сильно сложнее. Нужно написать такой декомпоз компонент (ну или ViewModel), который будет описывать сам "экран" фичи с этим WebView и всю логику его держать. И вот тут начинается приключение на 20 минут. Тебе с одной стороны удобно работать с ней прям из композа раз уж там инкапсулированы все вот эти стейты-навигаторы-клиенты, с другой стейт то ты хочешь держать снаружи от композа, для клиентов зависимости существуют вне композа, и так далее. И тут ты второй раз понимаешь, что большая часть кода из аккомпаниста такое вообще не подразумевала и ловишь себя на том, что всё сам императивно через их навигатор начинаешь гонять, отказываясь от декларативных опций.

Продолжаем наблюдение, возможно через неделю у меня всё поменяется.