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