Гугл не так давно зарелизил артефакт fragment-compose с функцией AndroidFragment. Если коротко, то это первый first party способ завернуть Fragment в Composable функцию вместе с аргументами. Раньше можно было только вьюшку фрагмента нарисовать с помощью AndroidView или AndroidViewBinding, а всё остальное совсем не работало.
Я очень оптимистично настроен по отношению к этой штуке, потому что это, в моей голове, единственный способ не переписывая все сотни существующих экранов проекта перевести навигацию на Compose. А мы это хотим, потому что идея приложения состоящего из иерархии вложенных друг в друга Decompose компонентов выглядит ну очень уж красиво. ☀️
Так вот, я добрался поэкспериментировать. И я скорее разочарован. AndroidFragment написан таким образом, что он просто создаёт AndroidView с FragmentContainerView и выполняет транзакцию add во FragmentManager в DisposableEffect, что абсолютно логично, конечно. Но в его onDispose вызывается транзакция remove, что как будто бы делает эту историю вообще неюзабельной.
На практике это приводит к такой очевидной ситуации: мы просто навигируемся с AndroidFragment на другой, например чисто Composable экран, возвращаемся обратно, а фрагмент заново создаётся из нулевого состояния, и его ViewModel заново инициализируется. Да или поворачиваем экран, всё пересоздаётся.
С чистым композом такого не происходит за счёт механизма rememberSaveable. Т.е. даже если функция вышла из композиции, то память о ней жива. Впрочем, даже с чистым AndroidView такого не происходит, там нет FragmentManager из-за которого все беды.
Короче, это движение в правильную сторону (хвалю), но есть ощущение, что в таком виде это максимум для того, чтобы показывать из композа самые глубокие в иерархии фрагменты, да и то если нам пофиг на смену конфигурации. 😒
Возможно я делаю что-то не так, но вся документация пока сконцентрирована в ченджлогах и джавадоках. Даже гайды по использованию View в Compose не обновили.