⚙️ Почему я не использую *Screen и выбираю Pane подход

Когда речь заходит о создании UI на Jetpack Compose с поддержкой смартфонов, планшетов и десктопов, важно не привязываться к физическим размерам экрана.

❌ Чего я избегаю?
Я не использую именование Composable-экранов через *Screen, например:

// !!! не делайте так для экрана фичи
@Composable
fun HomeScreen() { /* UI */ }

Такой подход жестко связывает UI с понятием "экрана устройства", а это не всегда корректно, особенно в мире foldable-устройств и десктопов. UI каждой фичи должен уметь работать на всём пространстве что ему выделит контейнер, где будет показ UI фичи.

✅ Что я использую вместо этого?
Я применяю концепцию Pane – это независимые контейнеры UI, которые адаптируются под выделенное для них место и не должны понимать ничего о размерах экрана, ориентации, расположении. Контейнер, где встраивается UI, сам определит всё и настроит UI через Modifier.

@Composable
fun HomePane(modifier: Modifier = Modifier) {
    Column(modifier = modifier.fillMaxSize()) {
        Text("Welcome to Home")
        // Остальной UI
    }
}

Такой подход позволяет:
✔️ Легко компоновать UI для разных конфигураций (например, показывать две панели на планшете и одну на телефоне).
✔️ Избежать привязки к Screen, что делает код гибче.
✔️ Улучшить переиспользуемость UI-компонентов.

📌 Как применять Pane в адаптивном UI?

Простейший пример, где на планшетах и десктопе мы показываем две панели, а на телефонах – только одну:

// Рутовая Composable функция приложения, которая понимает про текущее состояние приложения 
// на экране и в зависимости от этого располагает контент
@Composable
fun RootScreen(windowSizeClass: WindowSizeClass) {
    if (windowSizeClass.widthSizeClass == WindowWidthSizeClass.Expanded) {
        // Большой экран
        Row(Modifier.fillMaxSize()) {
            HomePane(Modifier.weight(1f))
            DetailsPane(Modifier.weight(1f))
        }
    } else {
        // Маленький или средний
        HomePane()
    }
}

❗️ Также важной частью работы с Pane является передача в неё Modifier параметра, через который контейнер панели будет настраивать размещение и другие параметры Pane.

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

#compose #android #adaptive #material #советы

⚙️ В Compose появилось ограничение максимального состояния жизненного цикла

В следующей версии Jetpack Lifecycle добавили новую функцию, которая позволяет переопределить LifecycleOwner и задать максимальное состояние:

@Composable
fun LifecycleOwner(
    maxLifecycle: State = RESUMED,
    parentLifecycleOwner: LifecycleOwner = LocalLifecycleOwner.current,
    content: @Composable () -> Unit,
)

💡 Зачем это нужно?
Идея пришла из поддержки адаптивного UI в Jetpack Navigation 3. Теперь можно строить интерфейсы, которые одинаково хорошо работают и на смартфонах, и на больших экранах.

📌 Пример: многопанельный UI, где одна панель отображается, а вторая — скрыта, потому что не влезла на экран. Логично, что их Lifecycle будет разным. Но раньше стандартный LifecycleOwner был жёстко привязан к Activity или Fragment, без учета реальной видимости конкретного UI-компонента.

📹 Подробнее про возможности Navigation 3 я рассказал в отдельном видео.

А вы уже видите, где можно применить эту фичу в своем проекте? Делитесь идеями в комментариях 👇

#compose #adaptive #ui