Очень вам благодарен за такой отзыв! Я как раз старался написать не просто сухую техническую инструкцию, а поделиться самой историей и подходом. Вдвойне приятно, что это было интересно читать даже за пределами Android-комьюнити. Спасибо!
Огромное спасибо за такой развернутый и очень вдумчивый комментарий! Это именно та техническая дискуссия, ради которой и пишутся статьи на Хабре. Вы подняли два абсолютно верных и важных вопроса.
1. По поводу toRoute<Class> и Serializable API.
Вы на 100% правы. Официальная библиотека сделала гигантский шаг вперед, и возможность навигироваться на Serializable/Parcelize класс — это фантастическое улучшение. Оно действительно решает проблему типобезопасной передачи данных.
Моя основная "боль", которую я пытался решить, лежит немного в другой плоскости — не в самой передаче данных, а в объявлении навигации и ее вызове. Даже с новым API, разработчику все еще нужно вручную:
Создавать composable блок в NavHost для каждого экрана.
Вручную прописывать arguments = listOf(...), если у аргументов есть значения по умолчанию.
Вручную настраивать enterTransition, exitTransition и другие анимации для каждого экрана, если они отличаются от стандартных.
Вручную реализовывать логику popUpTo.
Моя библиотека с помощью KSP берет на себя именно эту рутину, генерируя весь NavHost целиком на основе одной лишь аннотации над экраном. То есть, она является "надстройкой" над новым type-safety API, которая автоматизирует его настройку.
2. По поводу философии кодогенерации.
Насчет второго пункта — о "линейности" Compose и "размытии контекста" — это 100% валидный и, я бы сказал, философский вопрос. Я очень уважаю эту точку зрения, и для меня самого это был компромисс.
Мы действительно "платим" за магию кодогенерации небольшой потерей "прозрачности" (сгенерированный код не виден сразу), но взамен я старался получить другие преимущества:
Единый источник правды: Вся конфигурация экрана (его аргументы, анимация, DI-потребности) теперь находится в одной аннотации над Composable-функцией. Она не "размазана" по enum-классам, билдеру NavHost и ViewModel. На мой взгляд, это наоборот, концентрирует контекст в одном месте.
Сокращение рутины: В проектах с десятками экранов это экономит сотни, если не тысячи, строк повторяющегося кода, который нужно писать и поддерживать.
Но я абсолютно согласен, что это выбор. Кому-то комфортнее видеть весь код явно, даже если он повторяющийся. Моя библиотека — для тех, кто, как и я, готов немного "отпустить контроль" в обмен на автоматизацию этой конкретной рутины.
Еще раз огромное спасибо за такой качественный фидбэк! Это очень ценно.
Information
Rating
Does not participate
Registered
Activity
Specialization
Mobile Application Developer, Application Developer
Очень вам благодарен за такой отзыв! Я как раз старался написать не просто сухую техническую инструкцию, а поделиться самой историей и подходом. Вдвойне приятно, что это было интересно читать даже за пределами Android-комьюнити. Спасибо!
Огромное спасибо за такой развернутый и очень вдумчивый комментарий! Это именно та техническая дискуссия, ради которой и пишутся статьи на Хабре. Вы подняли два абсолютно верных и важных вопроса.
1. По поводу
toRoute<Class>иSerializableAPI.Вы на 100% правы. Официальная библиотека сделала гигантский шаг вперед, и возможность навигироваться на
Serializable/Parcelizeкласс — это фантастическое улучшение. Оно действительно решает проблему типобезопасной передачи данных.Моя основная "боль", которую я пытался решить, лежит немного в другой плоскости — не в самой передаче данных, а в объявлении навигации и ее вызове. Даже с новым API, разработчику все еще нужно вручную:
Создавать
composableблок вNavHostдля каждого экрана.Вручную прописывать
arguments = listOf(...), если у аргументов есть значения по умолчанию.Вручную настраивать
enterTransition,exitTransitionи другие анимации для каждого экрана, если они отличаются от стандартных.Вручную реализовывать логику
popUpTo.Моя библиотека с помощью KSP берет на себя именно эту рутину, генерируя весь
NavHostцеликом на основе одной лишь аннотации над экраном. То есть, она является "надстройкой" над новым type-safety API, которая автоматизирует его настройку.2. По поводу философии кодогенерации.
Насчет второго пункта — о "линейности" Compose и "размытии контекста" — это 100% валидный и, я бы сказал, философский вопрос. Я очень уважаю эту точку зрения, и для меня самого это был компромисс.
Мы действительно "платим" за магию кодогенерации небольшой потерей "прозрачности" (сгенерированный код не виден сразу), но взамен я старался получить другие преимущества:
Единый источник правды: Вся конфигурация экрана (его аргументы, анимация, DI-потребности) теперь находится в одной аннотации над Composable-функцией. Она не "размазана" по
enum-классам, билдеруNavHostи ViewModel. На мой взгляд, это наоборот, концентрирует контекст в одном месте.Сокращение рутины: В проектах с десятками экранов это экономит сотни, если не тысячи, строк повторяющегося кода, который нужно писать и поддерживать.
Но я абсолютно согласен, что это выбор. Кому-то комфортнее видеть весь код явно, даже если он повторяющийся. Моя библиотека — для тех, кто, как и я, готов немного "отпустить контроль" в обмен на автоматизацию этой конкретной рутины.
Еще раз огромное спасибо за такой качественный фидбэк! Это очень ценно.