Делаем Jetpack Navigation 3 удобнее

Согласен, метод then тут явно выигрывает по чистоте. DelegatedScreenStrategy я привёл скорее для наглядности — чтобы показать сам принцип выбора

Делаем Jetpack Navigation 3 удобнее

Что мешает передать его как MutableList во вью-модель?

Ничего не мешает, с этим просто неудобно работать

• необходимо создать список, прокинуть его в compose и di

• все еще нужно напрямую изменять список, что я лично для меня не является удобным

• навигация доступна не из одного места в приложении, а во многих, другими словами, требуется протаскивать список по многим местам

Лично для меня это вопрос удобства и снижения количества возможных ошибок и проблем

Делаем Jetpack Navigation 3 удобнее

Да, по сути взята архитектура из Cicerone и допилена для использования с Nav3

Делаем Jetpack Navigation 3 удобнее

1) в чем по-вашему выражается сильная связь?
2) чем может помочь path навигация? если это выглядит так, как в примере ниже, то в android от этого очень долго пытались уйти в навигации от гугл и наконец ушли тк типизированная в контексте android подходит гораздо больше

entry("/path/to/screen")

3) чем плох config based router в контексте android разработки?

Compose + Koin + Jetpack Navigation: что мы поняли за 2 года

Тоже реализовывал подобное некоторое время назад, статья есть здесь на habr
Возможно, что будет интересно: https://habr.com/ru/articles/881982/

Управление зависимостями: как работать с Koin scopes в Jetpack Compose Navigation

У вас есть 3 экрана под скоупом AuthGraph. нужно чтобы при попадании в AuthGraph (не важно, в какой экран) у вас отработал метод fetch() при старте. Можете, пожалуйста, написать небольшой пример, как вы сделаете вызов? Важно, чтобы вызов был один раз за все время жизни AuthGraph.

Например, создаю AuthFeatureViewModel

Скрытый текст

class AuthFeatureViewModel : ViewModel() {

    init {
        // do something
    }
}

Помещаю ее в скоуп фичи

Скрытый текст

val authModule = module {
    scope<Screen.AuthGraph> {
        viewModelOf(::AuthFeatureViewModel)
    }
}

Инициализирую AuthFeatureViewModel

Скрытый текст

@Composable
private fun Content() {

    val navController = rememberNavController()

    NavHost(
        navController = navController,
        startDestination = Screen.AuthGraph
    ) {

        navigation<Screen.AuthGraph>(
            startDestination = Screen.AuthGraph.EmailInput
        ) {
            composable<Screen.AuthGraph.EmailInput> { navBackStackEntry ->
                val parentNavBackStackEntry = rememberParentBackStackEntry(navController, navBackStackEntry)

                ParentScopeProvider<Screen.AuthGraph>(parentNavBackStackEntry) {

                    koinViewModel<AuthFeatureViewModel>()

                    ComposeScreenScopeProvider<Screen.AuthGraph.EmailInput> {
                        /* omitted code */
                    }
                }
            }

            // omitted code
        }
    }
}

AuthFeatureViewModel создается в скоупе фичи. Но есть минус с дублированием кода, потому что этот код

Скрытый текст

ParentScopeProvider<Screen.AuthGraph>(parentNavBackStackEntry) {

    koinViewModel<AuthFeatureViewModel>()

    // omitted code
}

Должен находиться в декларации каждого экрана, на который может быть совершен самый первый переход в рамках AuthGraph

Управление зависимостями: как работать с Koin scopes в Jetpack Compose Navigation

Подскажите, пожалуйста, думали ли в сторону того, чтобы создавать скоупы, не привязывая их к вьюмоделям? 

Да, изначально пробовал делать без них. Уперся в то, что без ViewModel не получалось понять, в какой момент закрыть скоуп фичи.

И второй вопрос касательно вашего подхода: как выполнять операции, которые должны совершаться единожды при создании родительского скоупа? 

Для такого я создаю ViewModel, в скоупе фичи и выполняю действие внутри нее

Мы у нас на проекте сделали немного вычурно – создаем composable с navHost`ом, где описываем дочерние экраны –порождает огромное кол-во контроллеров, но зато есть возможность описать родительский контекст в одном месте, а не в каждой функции

А вы уже обрабатывали кейс, когда нужно передавать параметры в объект, который живет в рамках скоупа фичи? Это отдельное приключение

Алло! Реализуем дисковый телефон с помощью Jetpack Compose(Обновлено)

Замечание справедливое, поэтому я доработал компонент и обновил статью. Спасибо!

Алло! Реализуем дисковый телефон с помощью Jetpack Compose(Обновлено)

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

Создание Custom Layout в Jetpack Compose

спасибо!

Насчет более сложный лейаутов пока что не знаю т.к. на данный момент нет идей как и о чем именно можно было бы рассказать