При конвертации android library module в pure kotlin отключается android lint (компонент, который занимает очень много времени). Добавляли ли вы его его обратно для pure-kotlin модулей или оставили как есть? И не думали вместо конвертации android library просто отключить какие-то его компоненты (типа того же линтера)?
Если нужно скрыть внутренние детали деления проекта на модули, при этом маппить только внутренние библиотеки проекта, которые никогда и нигде больше не используются, то такой вариант можно рассматривать.
Но если хочется замапить ещё и транзитивные внешние зависиости, то у такого варианта очень много недостатков:
Сложно следить за уязвимостями в забандленных транзитивных зависимостях с измененными пакетами. У пользователей библиотеки обычно нет никакой информации о том, что там внутри, а технологии типа SBOM в Android не приняты.
Сильно увеличивается размер APK и потребляемые приложением ресурсы. В APK оказываются несколько копий одних и тех же библиотек под разными именами.
Постоянно возникают конфликты у замапленных библиотек с основными. Нужно быть гуру R8, чтобы правильно настроить маппинг так, чтобы всё, что использует рефлексию, не задевало основной код. К тому же надо учитывать, что пользователи твоей библиотеки тоже используют R8, и им нужно предоставлять правила, которые покрывают все ваши зависимости с изменёнными пакетами. Обычно этим не занимаются и просто советуют делать 1 правило keep для всех классов библиотеки, что ещё больше увеличивает размер APK.
Это мы ещё не рассматриваем случаи, когда две разные версии вашей библиотеки подтягиваются в проект транзитивно разными зависимостями. Semantic versioning для нумерации версий библиотеки с зашейденными классами редко удаётся применить правильно.
Много раз видел жалобы на uber-jar в мире Java, сам сталкивался с этим и в Android, советовал бы избегать этот вариант.
Можно просто выложить снепшот maven-репозитория вместо одной aar и ничего не прятать.
Ещё практически любой мелкий статический сайт, задеплоенный на бесплатный тариф, например, с документацией. Я сейчас столкнулся с недоступностью docusaurus.io. Очевидно, что авторы этих сайтов ничего с этим делать не будут.
Пара моментов по convention-плагинам и kotlin-dsl, о которых мало кто говорит. 1. ID плагинов. Все обычно использут короткие ID, а-ля "android.base.config". Я считаю, что абсолютно у всех плагинов должен быть FQN, в том числе и у convention-плагинов. Т.е. "io.github.dmitriy1892.conventionplugins.android.base.config". Длиннее, но в таком виде плагины будет гораздо проще публиковать. А один из самых действенных способов борьбы со скоростью сборки — это публикация convention-плагинов во внутренний репозиторий. 2. Название и расположение файлов. Вы создаете файл "android.base.config.gradle.kts" в корне. Для плагина с FQN пришлось бы создавать файл с именем "io.github.dmitriy1892.conventionplugins.android.base.config.gradle.kts". Но это не единственный способ создания плагина. Другой способ — это создать этот файл в io/github/dmitriy1892/conventionplugins/android.base.config.gradle.kts и в него добавить строку package: `package io.github.dmitriy1892.conventionplugins` . Так имя файла будет короче, все классы будут в одном пакете, у плагина будет FQN ID и в нем можно будет использовать классы из того же пакета без использования `import`.
Подтверждаю сейчас старый аккаунт. На номер Мегафона СМС не отправляется, сбой отправки, но с номером Билайна всё прошло нормально. При отправке на номер МТС тоже не выдавал этой ошибки.
А где конкретно Google рекомендует Clean Architecture? Их гайды по архитектуре отличаются от принципов Clean Architecture. Ни Clean ни имя автора нигде не упоминается.
При конвертации android library module в pure kotlin отключается android lint (компонент, который занимает очень много времени). Добавляли ли вы его его обратно для pure-kotlin модулей или оставили как есть?
И не думали вместо конвертации android library просто отключить какие-то его компоненты (типа того же линтера)?
Если нужно скрыть внутренние детали деления проекта на модули, при этом маппить только внутренние библиотеки проекта, которые никогда и нигде больше не используются, то такой вариант можно рассматривать.
Но если хочется замапить ещё и транзитивные внешние зависиости, то у такого варианта очень много недостатков:
Сложно следить за уязвимостями в забандленных транзитивных зависимостях с измененными пакетами. У пользователей библиотеки обычно нет никакой информации о том, что там внутри, а технологии типа SBOM в Android не приняты.
Сильно увеличивается размер APK и потребляемые приложением ресурсы. В APK оказываются несколько копий одних и тех же библиотек под разными именами.
Постоянно возникают конфликты у замапленных библиотек с основными. Нужно быть гуру R8, чтобы правильно настроить маппинг так, чтобы всё, что использует рефлексию, не задевало основной код. К тому же надо учитывать, что пользователи твоей библиотеки тоже используют R8, и им нужно предоставлять правила, которые покрывают все ваши зависимости с изменёнными пакетами. Обычно этим не занимаются и просто советуют делать 1 правило keep для всех классов библиотеки, что ещё больше увеличивает размер APK.
Это мы ещё не рассматриваем случаи, когда две разные версии вашей библиотеки подтягиваются в проект транзитивно разными зависимостями. Semantic versioning для нумерации версий библиотеки с зашейденными классами редко удаётся применить правильно.
Много раз видел жалобы на uber-jar в мире Java, сам сталкивался с этим и в Android, советовал бы избегать этот вариант.
Можно просто выложить снепшот maven-репозитория вместо одной aar и ничего не прятать.
А кто X-Real-IP проставит в случае если "Даже если клиент за NAT'ом"?
А что будете делать, учитывая, что Java SecurityManager удален в новой версии Java?
Ещё практически любой мелкий статический сайт, задеплоенный на бесплатный тариф, например, с документацией. Я сейчас столкнулся с недоступностью docusaurus.io. Очевидно, что авторы этих сайтов ничего с этим делать не будут.
Пара моментов по convention-плагинам и kotlin-dsl, о которых мало кто говорит.
1. ID плагинов. Все обычно использут короткие ID, а-ля "
android.base.config". Я считаю, что абсолютно у всех плагинов должен быть FQN, в том числе и у convention-плагинов. Т.е. "io.github.dmitriy1892.conventionplugins.android.base.config". Длиннее, но в таком виде плагины будет гораздо проще публиковать. А один из самых действенных способов борьбы со скоростью сборки — это публикация convention-плагинов во внутренний репозиторий.2. Название и расположение файлов. Вы создаете файл "
android.base.config.gradle.kts" в корне. Для плагина с FQN пришлось бы создавать файл с именем "io.github.dmitriy1892.conventionplugins.android.base.config.gradle.kts". Но это не единственный способ создания плагина. Другой способ — это создать этот файл вio/github/dmitriy1892/conventionplugins/android.base.config.gradle.ktsи в него добавить строку package: `package io.github.dmitriy1892.conventionplugins` . Так имя файла будет короче, все классы будут в одном пакете, у плагина будет FQN ID и в нем можно будет использовать классы из того же пакета без использования `import`.Подтверждаю сейчас старый аккаунт. На номер Мегафона СМС не отправляется, сбой отправки, но с номером Билайна всё прошло нормально. При отправке на номер МТС тоже не выдавал этой ошибки.
Очень даже разумный подход
А где конкретно Google рекомендует Clean Architecture? Их гайды по архитектуре отличаются от принципов Clean Architecture. Ни Clean ни имя автора нигде не упоминается.