Вы знаете, я люблю острые ощущения, поэтому решил попробовать встроить Jetpack Compose экран в приложение на React Native.
Так вот, это была ошибка, я по дороге несколько раз умер😵
Казалось бы, читаем документацию, как встроить AndroidView в RN, оборачиваем ComposeView во FrameLayout и готово, делов-то.
И всё хорошо, пока эта вьюшка отображается на первом экране, но из-за особенностей навигации в RN будем получать ошибку
AI-агенты впадают в экзистенциальный кризис при попытке решить эту задачу и зависают в бесконечном цикле правок, поэтому я начал шерстить интернет в поисках решения и нашёл доклад от Купера.
Исходников, конечно, я не нашёл, поэтому скормил скриншоты из доклада ChatGPT, чтобы она восстановила код, и это даже заработало🤯
🌐 Выкладываю gist для таких же искателей приключений, но полноценно я это ещё не протестировал, так что используйте аккуратно.
P.S. Слабонервным код лучше не смотреть
Так вот, это была ошибка, я по дороге несколько раз умер
Казалось бы, читаем документацию, как встроить AndroidView в RN, оборачиваем ComposeView во FrameLayout и готово, делов-то.
И всё хорошо, пока эта вьюшка отображается на первом экране, но из-за особенностей навигации в RN будем получать ошибку
cannot locate windowRecomposer.
AI-агенты впадают в экзистенциальный кризис при попытке решить эту задачу и зависают в бесконечном цикле правок, поэтому я начал шерстить интернет в поисках решения и нашёл доклад от Купера.
Исходников, конечно, я не нашёл, поэтому скормил скриншоты из доклада ChatGPT, чтобы она восстановила код, и это даже заработало
Please open Telegram to view this post
VIEW IN TELEGRAM
😁34🤡3🙏2
Разумеется, вы слышали о нашумевшем обновлении iOS с Liquid Glass: на картинках всё выглядит красиво, но как это будет выглядеть в вашем приложении, если все нативные компоненты разом поменяются? И как успеть всё исправить до релиза?
Мой коллега, Антон Долганов, написал классную статью о том, как мы готовимся к новым версиям iOS.
В статье, на примере подготовки к iOS 26, вы найдёте пошаговый процесс адаптации к обновлениям системы и узнаете, какие проблемы могут встретиться по пути.
🔖 Приятного чтения!
Мой коллега, Антон Долганов, написал классную статью о том, как мы готовимся к новым версиям iOS.
В статье, на примере подготовки к iOS 26, вы найдёте пошаговый процесс адаптации к обновлениям системы и узнаете, какие проблемы могут встретиться по пути.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11👍1🔥1
Двигаем списки оптимально
Представьте, что вам нужно реализовать drag&drop список, в котором можно менять элементы местами. Элементы списка хранятся в БД, и мы можем добавить туда поле priority, по которому будет выполняться сортировка.
Можно решить задачу в лоб и просто пересчитывать все приоритеты при перемещении карточки — на небольших списках это даже будет работать нормально.
Но представим, что у вас сотни таких элементов, и вы двигаете последнюю карточку в начало списка. Тогда придётся сделать 100 записей в БД — звучит не очень оптимально🤔
Как сделать лучше?
Можно заполнять поле priority не с шагом 1, а, например, с шагом 100.
🟢 Тогда при перестановке элемента в середину списка нам будет достаточно взять средний приоритет между соседними значениями и обновить только один элемент в БД.
🟢 Для крайних элементов тоже всё просто: либо вычитаем шаг приоритета, либо прибавляем.
🟢 Но может случиться так, что после многих перестановок разница между элементами станет равной 1, только тогда придётся перезаписать все приоритеты.
Итого: в первом варианте у нас всегда была бы сложность O(N), а во втором, в большинстве случаев O(1), и только в худшем сценарии мы получим линейное время.
❓ А вы бы стали заморачиваться с оптимизацией? Или сделали бы простой вариант?
Представьте, что вам нужно реализовать drag&drop список, в котором можно менять элементы местами. Элементы списка хранятся в БД, и мы можем добавить туда поле priority, по которому будет выполняться сортировка.
Можно решить задачу в лоб и просто пересчитывать все приоритеты при перемещении карточки — на небольших списках это даже будет работать нормально.
Но представим, что у вас сотни таких элементов, и вы двигаете последнюю карточку в начало списка. Тогда придётся сделать 100 записей в БД — звучит не очень оптимально
Как сделать лучше?
Можно заполнять поле priority не с шагом 1, а, например, с шагом 100.
Итого: в первом варианте у нас всегда была бы сложность O(N), а во втором, в большинстве случаев O(1), и только в худшем сценарии мы получим линейное время.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥26
Путеводитель по каналу
Спустя ровно год канал набрал ещё тысячу подписчиков, спасибо вам, что читаете🦞
Собрал для вас самые интересные посты по темам, вдруг найдёте что-то полезное для себя:
Compose
Что такое Compose Snapshot
Анимации по стейту в Compose
Проблемы Compose for WEB
Декларативный Bottom Sheet
Управляем курсором в TextField
Compose в React Native
SwiftUI в Compose Multiplatform
Отличия в модификаторах в SwiftUI и Compose
Must-have материалы для изучения Compose
iOS и KMP
iOS библиотеки в Kotlin коде
Собираем iOS приложения без macOS
Ставим iOS приложение из браузера
Как подключить KMP в iOS проект без CocoaPods
Фоновая работа в Android и iOS
Отличия при работе с БД на Android и iOS
Разное поведение Map на платформах
Интероп suspend и async функций
Зачем использовать новый Uuid
Android
Бессмертное приложение
Как сделать плитку в быстрых настройках
Шарим библиотеки между проектами
Корутины
Корутинные рецепты
Статья про нестандартное использование корутин
Библиотеки
Detekt правила для Decompose
Как зашифровать SharedPreferences
Библиотека для декларативного показа Snackbar
Разное
Об авторе канала
Мое первое мобильное приложение
Автоматизации в умном доме
Как опубликовать приложение с VPN в Google Play
#Навигация
Спустя ровно год канал набрал ещё тысячу подписчиков, спасибо вам, что читаете
Собрал для вас самые интересные посты по темам, вдруг найдёте что-то полезное для себя:
Compose
Что такое Compose Snapshot
Анимации по стейту в Compose
Проблемы Compose for WEB
Декларативный Bottom Sheet
Управляем курсором в TextField
Compose в React Native
SwiftUI в Compose Multiplatform
Отличия в модификаторах в SwiftUI и Compose
Must-have материалы для изучения Compose
iOS и KMP
iOS библиотеки в Kotlin коде
Собираем iOS приложения без macOS
Ставим iOS приложение из браузера
Как подключить KMP в iOS проект без CocoaPods
Фоновая работа в Android и iOS
Отличия при работе с БД на Android и iOS
Разное поведение Map на платформах
Интероп suspend и async функций
Зачем использовать новый Uuid
Android
Бессмертное приложение
Как сделать плитку в быстрых настройках
Шарим библиотеки между проектами
Корутины
Корутинные рецепты
Статья про нестандартное использование корутин
Библиотеки
Detekt правила для Decompose
Как зашифровать SharedPreferences
Библиотека для декларативного показа Snackbar
Разное
Об авторе канала
Мое первое мобильное приложение
Автоматизации в умном доме
Как опубликовать приложение с VPN в Google Play
#Навигация
Please open Telegram to view this post
VIEW IN TELEGRAM
7🎉34❤7🔥5👍2🤝1
Kotlin Adept Notes pinned «Путеводитель по каналу Спустя ровно год канал набрал ещё тысячу подписчиков, спасибо вам, что читаете 🦞 Собрал для вас самые интересные посты по темам, вдруг найдёте что-то полезное для себя: Compose Что такое Compose Snapshot Анимации по стейту в Compose…»
Kotlin Rich Errors
Вы, скорее всего, слышали про будущую фичу в Kotlin под названием Rich Errors, которая может кардинально изменить подход к обработке ошибок. Но многие не поняли: а в чём, собственно, отличия от sealed class или checked exceptions в Java?
Давайте разберёмся.
На мой взгляд, главная фича — это компактность и простота.
Например, если у нас есть такая функция:
Тогда можем написать выражение:
И мы не получим nullable-результат, метод charge выполнится только если fetchUser вернул успешный результат. И не нужно запоминать всякие операторы по типу fold в Result и так далее.
В отличие от sealed-классов, в Rich Errors ошибка и успешный результат не имеют общего родителя. При этом error class не является наследником Any, а наследуется от специального типа Error.
Также многих может ввести в заблуждение синтаксис, ведь это очень похоже на union-типы в других языках, но это не они.
Мы не можем использовать любой тип в правой части. Разрешается использовать только Error-классы, при этом их может быть больше одного. А основной тип может быть только один.
Подробнее узнать про Rich Errors можно в этом докладе.
А вы ждёте эту фичу или считаете, что это бесполезный сахар?
Вы, скорее всего, слышали про будущую фичу в Kotlin под названием Rich Errors, которая может кардинально изменить подход к обработке ошибок. Но многие не поняли: а в чём, собственно, отличия от sealed class или checked exceptions в Java?
Давайте разберёмся.
На мой взгляд, главная фича — это компактность и простота.
Например, если у нас есть такая функция:
fun fetchUser(): User | FetchingError
Тогда можем написать выражение:
fetchUser()?.charge(amount = 10.0)
И мы не получим nullable-результат, метод charge выполнится только если fetchUser вернул успешный результат. И не нужно запоминать всякие операторы по типу fold в Result и так далее.
В отличие от sealed-классов, в Rich Errors ошибка и успешный результат не имеют общего родителя. При этом error class не является наследником Any, а наследуется от специального типа Error.
Также многих может ввести в заблуждение синтаксис, ведь это очень похоже на union-типы в других языках, но это не они.
Мы не можем использовать любой тип в правой части. Разрешается использовать только Error-классы, при этом их может быть больше одного. А основной тип может быть только один.
Подробнее узнать про Rich Errors можно в этом докладе.
А вы ждёте эту фичу или считаете, что это бесполезный сахар?
👍20👾9🥱2❤1
Стадии принятия Compose Multiplatform
Отрицание🙅♂️
Вы не воспринимаете KMP всерьёз, пишете нативные приложения, этим занимаются разные люди, и всех в целом всё устраивает. Разве что страдают тестировщики из-за разного поведения на платформах и заказчики из-за двойного бюджета на разработку.
Гнев🐈
Начинаете адаптировать KMP, бомбите на кривой интероп, не видите какого-то значимого ускорения разработки, но продолжаете в надежде на лучшее.
Торг😒
Полноценно выносите всё, что можно, в общую логику, и пока вёрстку делают разные люди, вы уже настроены позитивно, так как это экономит вам около 60% времени разработки фичи, поведение остаётся консистентным, а также вы не теряете нативный look and feel.
Депрессия🤯
Со временем iOS-разработчику становится скучно делать только вёрстку, и он идёт делать фичи целиком с вёрсткой под обе платформы, уже начиная задаваться вопросом: «А какого фига мне приходится делать одно и то же дважды?» И с ужасом представляет, как раньше мы дублировали вообще всё.
Принятие🤩
Решаете избавиться от SwiftUI и перейти целиком на Compose Multiplatform.
Именно такой путь мы прошли в одном из наших проектов. И как вы думаете, сколько заняла миграция среднего приложения (40k LOC) со SwiftUI на Compose Multiplatform?Всего 3 часа 🤨 — чтобы запустить все экраны на iOS.
А на какой стадии принятия вы❓
#Compose #KMP #Multiplatform
Отрицание
Вы не воспринимаете KMP всерьёз, пишете нативные приложения, этим занимаются разные люди, и всех в целом всё устраивает. Разве что страдают тестировщики из-за разного поведения на платформах и заказчики из-за двойного бюджета на разработку.
Гнев
Начинаете адаптировать KMP, бомбите на кривой интероп, не видите какого-то значимого ускорения разработки, но продолжаете в надежде на лучшее.
Торг
Полноценно выносите всё, что можно, в общую логику, и пока вёрстку делают разные люди, вы уже настроены позитивно, так как это экономит вам около 60% времени разработки фичи, поведение остаётся консистентным, а также вы не теряете нативный look and feel.
Депрессия
Со временем iOS-разработчику становится скучно делать только вёрстку, и он идёт делать фичи целиком с вёрсткой под обе платформы, уже начиная задаваться вопросом: «А какого фига мне приходится делать одно и то же дважды?» И с ужасом представляет, как раньше мы дублировали вообще всё.
Принятие
Решаете избавиться от SwiftUI и перейти целиком на Compose Multiplatform.
Именно такой путь мы прошли в одном из наших проектов. И как вы думаете, сколько заняла миграция среднего приложения (40k LOC) со SwiftUI на Compose Multiplatform?
А на какой стадии принятия вы
#Compose #KMP #Multiplatform
Please open Telegram to view this post
VIEW IN TELEGRAM
👍30🔥12🤔4🤯2🤡2💯1
12 сентября в Москве пройдет big tech night — «ночь музеев» в мире IT
Редко можно увидеть мероприятия, в которых участвуют сразу несколько крупных IT-компаний. Когда еще можно будет за один вечер объехать несколько офисов, обменяться опытом со специалистами из разных бигтехов и посмотреть IT-стендап?
Формат простой: 5 офисов на один вечер станут фестивальными площадками для всех, кто любит технологии и хочет посмотреть на внутреннюю кухню компаний.
В каждом офисе будет своя уникальная программа. Все активности разделены на 3 трека:
— Обсуждение технологий и продуктов. Я для себя выделил доклад Александра Коротаева о будущем разработки, о том, как управлять сложностью и не писать лишнего, а также доклад Дмитрия Иванова о том, как инструменты и технологии трансформируют современные рабочие процессы.
— Управление командой и другие мягкие навыки. Например, можно послушать выступление Павла Федотовского о том, как инженерам адаптироваться к новой реальности ИИ.
— Интерактивы, где можно узнать что-то новое и отдохнуть. IT-кэмп, иммерсивные экскурсии и AI-слэм.
Весь вечер будет работать онлайн-студия с программой для тех, кто не сможет приехать в офлайн. Там можно послушать интервью с Маратом Мавлютовым из Яндекса про роботов-доставщиков или узнать, как юмор помогает бороться со стрессом.
Идею придумал Яндекс, а организовали мероприятие совместно со Сбером, X5, Т-Банком и Lamoda.
Зарегистрироваться можно тут
Редко можно увидеть мероприятия, в которых участвуют сразу несколько крупных IT-компаний. Когда еще можно будет за один вечер объехать несколько офисов, обменяться опытом со специалистами из разных бигтехов и посмотреть IT-стендап?
Формат простой: 5 офисов на один вечер станут фестивальными площадками для всех, кто любит технологии и хочет посмотреть на внутреннюю кухню компаний.
В каждом офисе будет своя уникальная программа. Все активности разделены на 3 трека:
— Обсуждение технологий и продуктов. Я для себя выделил доклад Александра Коротаева о будущем разработки, о том, как управлять сложностью и не писать лишнего, а также доклад Дмитрия Иванова о том, как инструменты и технологии трансформируют современные рабочие процессы.
— Управление командой и другие мягкие навыки. Например, можно послушать выступление Павла Федотовского о том, как инженерам адаптироваться к новой реальности ИИ.
— Интерактивы, где можно узнать что-то новое и отдохнуть. IT-кэмп, иммерсивные экскурсии и AI-слэм.
Весь вечер будет работать онлайн-студия с программой для тех, кто не сможет приехать в офлайн. Там можно послушать интервью с Маратом Мавлютовым из Яндекса про роботов-доставщиков или узнать, как юмор помогает бороться со стрессом.
Идею придумал Яндекс, а организовали мероприятие совместно со Сбером, X5, Т-Банком и Lamoda.
Зарегистрироваться можно тут
👍4🔥2
Розыгрыш билета на Подлодку
Мы с командой в очередной раз подготовили для вас новый сезон Podlodka Android Crew, который стартует уже 15 сентября.
В этот раз будем говорить про архитектуру, которая выходит за рамки экранов и навигации.
В программе:
🟢 Бинарная совместимость. Абакар Магомедов расскажет всё про бинарную совместимость: что это такое и как её соблюдать при разработке собственной библиотеки.
🟢 Интервью с мобильным архитектором. Вместе с Эдуардом Некрутовым узнаем, чем занимается архитектор мобильных приложений. Разберём реальные кейсы, типичные задачи и главные вызовы этой роли.
🟢 Архитектура Ktor для Android-разработчика. Разработчик библиотеки Ktor Осип Фаткуллин расскажет, как устроена библиотека под капотом, и покажет, как проектировать расширения для неё.
🟢 Что лежит под капотом удобного SDK? Игорь Рыбаков рассмотрит лучшие практики проектирования SDK для Android-приложений.
Это, разумеется, не все сессии, другие тоже определённо заслуживают вашего внимания!
🫴 Итак, давайте разыграем проходку. Для участия в розыгрыше нужно оставить комментарий под этим постом и написать про самую интересную архитектурную задачу в вашей практике. Итоги розыгрыша подведём ровно через неделю, удачи!
А те, кто не хочет участовать в розыгрыше, ловите промокод на скидку для покупки билета на сайте:android_crew_14_8RuHEz
Мы с командой в очередной раз подготовили для вас новый сезон Podlodka Android Crew, который стартует уже 15 сентября.
В этот раз будем говорить про архитектуру, которая выходит за рамки экранов и навигации.
В программе:
Это, разумеется, не все сессии, другие тоже определённо заслуживают вашего внимания!
А те, кто не хочет участовать в розыгрыше, ловите промокод на скидку для покупки билета на сайте:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6🔥3🥱3❤1
Мой архитектурный факап
Пока вы делитесь историями о самых интересных задачах, расскажу про ошибку проектирования, которая нам дорого обошлась.
Адаптируя Decompose в одно из наших приложений, мне пришла в голову гениальная идея: раз Decompose позволяет разом менять весь стек экранов, то почему бы не сделать навигацию по стейту из бизнес-логики?
Я слушал условно глобальный стейт и полностью заменял стек экранов. Поначалу это выглядело даже красиво, до появления в приложении диплинков...
В чём проблема? Если мы сразу обработаем диплинк и перейдём на нужный экран, то он тут же перетрётся изменением глобального стейта после загрузки данных.
Я не стал ничего менять и просто откладывал обработку диплинков до полной загрузки данных. Выглядело это уже не лучшим образом, а с ростом количества разных диплинков всё превратилось в полный хаос. Когда я передал проект другому разработчику, каждое новое изменение в этом коде ломало предыдущую функциональность, и поддерживать его стало невозможно.
Поэтому мы отрефакторили навигацию, отказались от подхода с навигацией по стейту, и жить стало гораздо проще.
А о каких решениях в архитектуре пожалели вы?
#Navigation #Decompose
Пока вы делитесь историями о самых интересных задачах, расскажу про ошибку проектирования, которая нам дорого обошлась.
Адаптируя Decompose в одно из наших приложений, мне пришла в голову гениальная идея: раз Decompose позволяет разом менять весь стек экранов, то почему бы не сделать навигацию по стейту из бизнес-логики?
Я слушал условно глобальный стейт и полностью заменял стек экранов. Поначалу это выглядело даже красиво, до появления в приложении диплинков...
В чём проблема? Если мы сразу обработаем диплинк и перейдём на нужный экран, то он тут же перетрётся изменением глобального стейта после загрузки данных.
Я не стал ничего менять и просто откладывал обработку диплинков до полной загрузки данных. Выглядело это уже не лучшим образом, а с ростом количества разных диплинков всё превратилось в полный хаос. Когда я передал проект другому разработчику, каждое новое изменение в этом коде ломало предыдущую функциональность, и поддерживать его стало невозможно.
Поэтому мы отрефакторили навигацию, отказались от подхода с навигацией по стейту, и жить стало гораздо проще.
А о каких решениях в архитектуре пожалели вы?
#Navigation #Decompose
👍24❤1
Как поменять ключ подписи приложения
Я удивился, что мало кто знает, и некоторые даже не верят, что возможно поменять сертификат для ключа подписи вашего приложения.
⚠️ Работает это только для App Bundle, и в случае Google Play придётся использовать Google Play App Signing.
При этом не стоит путать ключ загрузки и ключ подписи: иногда это один и тот же ключ, но по умолчанию Google предлагает сгенерировать свой ключ подписи, а ключ загрузки нужен, чтобы идентифицировать, что сборка подписана вами. Отсюда следует, что поменять ключ загрузки вообще не проблема, так как итоговый APK всё равно будет подписан другим ключом.
Но как изменить ключ подписи? Ведь система просто не даст установить приложение с одним package id и разными ключами🤔
На самом деле это возможно, начиная с Android N (API 24). Вы можете сделать это вручную с помощью apksigner, для этого вам потребуется доступ к старому и новому ключам:
Но в случае обновления приложения в Google Play нужно делать это через консоль. Переходим по ссылке и запрашиваем обновление ключа подписи, для этого придётся загрузить приватную часть сертификата в консоль. Сделать это можно только раз в год.
Как это работает?
Все существующие пользователи продолжат получать обновления со старым ключом, а для новых пользователей, у которых версия Android 13 и выше, подпись уже будет другая. Подробнее здесь.
Когда может понадобиться?
🔘 Если предыдущий ключ был скомпрометирован.
🔘 Вы выбрали автоматическое подписание в Google Play, а теперь хотите сделать одну подпись приложения для всех сторов.
🔘 Вы подписывали приложения разными ключами, но теперь хотите использовать один ключ для безопасного обмена данными между приложениями.
#GooglePlay #AppSigning
Я удивился, что мало кто знает, и некоторые даже не верят, что возможно поменять сертификат для ключа подписи вашего приложения.
При этом не стоит путать ключ загрузки и ключ подписи: иногда это один и тот же ключ, но по умолчанию Google предлагает сгенерировать свой ключ подписи, а ключ загрузки нужен, чтобы идентифицировать, что сборка подписана вами. Отсюда следует, что поменять ключ загрузки вообще не проблема, так как итоговый APK всё равно будет подписан другим ключом.
Но как изменить ключ подписи? Ведь система просто не даст установить приложение с одним package id и разными ключами
На самом деле это возможно, начиная с Android N (API 24). Вы можете сделать это вручную с помощью apksigner, для этого вам потребуется доступ к старому и новому ключам:
apksigner sign --in ${INPUT_APK} \
--out ${OUTPUT_APK} \
--ks ${ORIGINAL_KEYSTORE} \
--ks-key-alias ${ORIGINAL_KEY_ALIAS} \
--next-signer --ks ${UPGRADED_KEYSTORE} \
--ks-key-alias ${UPGRADED_KEY_ALIAS} \
--lineage ${LINEAGE}
Но в случае обновления приложения в Google Play нужно делать это через консоль. Переходим по ссылке и запрашиваем обновление ключа подписи, для этого придётся загрузить приватную часть сертификата в консоль. Сделать это можно только раз в год.
Как это работает?
Все существующие пользователи продолжат получать обновления со старым ключом, а для новых пользователей, у которых версия Android 13 и выше, подпись уже будет другая. Подробнее здесь.
Когда может понадобиться?
#GooglePlay #AppSigning
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥7❤1
Как с пользой провести День программиста?
Конечно, посмотреть доклад моего коллеги Евгения Мельцайкина о том, как мы делали медиаленту, решали проблемы синхронизации контента и как нам во всём этом помог Decompose🌳
Женя выступает на IT-фестивале KODE WAVES, доклад начнётся уже совсем скоро, в 11:30 МСК.
🔴 Ссылка на прямую трансляцию
Конечно, посмотреть доклад моего коллеги Евгения Мельцайкина о том, как мы делали медиаленту, решали проблемы синхронизации контента и как нам во всём этом помог Decompose
Женя выступает на IT-фестивале KODE WAVES, доклад начнётся уже совсем скоро, в 11:30 МСК.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14
Manual DI
DI-фреймворки продолжают появляться как грибы после дождя. Теперь рекомендуют использовать Metro, но всё чаще можно услышать, что люди принципиально отказываются от каких-либо библиотек для реализации DI. Так как в моей команде мы в основном делаем переиспользуемые общие модули, мы тоже давно отказались от DI-фреймворков. И знаете что? Мы вообще не испытываем из-за этого каких-либо проблем.
Тут я вспомнил про свой KMP-сэмпл и решил, что будет круто показать всё это на примере и заменить Koin в проекте. Но хорошо, что я не начал делать это раньше времени: буквально на докладе про сравнение DI-фреймворков с Podlodka Android Crew я узнал, что Александр Власюк уже всё сделал раньше и даже заслал pull request🌐
Примечательно, что Manual DI не только даёт compile-time safety по сравнению с Koin (без всяких плагинов), но даже количество строк кода в проекте сократилось😲
Понятно, что это всего лишь пример. Если использовать Koin глобально, то кода с Manual DI придётся писать больше. Однако я придерживаюсь подхода, при котором DI должен быть изолирован внутри модуля, а зависимости должны быть объявлены явно, чтобы можно было легко переиспользовать этот модуль где угодно.
А вы что думаете, стоят ли DI-фреймворки, чтобы их изучать и постоянно мигрировать проект на все более новые решения❓
#DI #Kotlin #KMP
DI-фреймворки продолжают появляться как грибы после дождя. Теперь рекомендуют использовать Metro, но всё чаще можно услышать, что люди принципиально отказываются от каких-либо библиотек для реализации DI. Так как в моей команде мы в основном делаем переиспользуемые общие модули, мы тоже давно отказались от DI-фреймворков. И знаете что? Мы вообще не испытываем из-за этого каких-либо проблем.
Тут я вспомнил про свой KMP-сэмпл и решил, что будет круто показать всё это на примере и заменить Koin в проекте. Но хорошо, что я не начал делать это раньше времени: буквально на докладе про сравнение DI-фреймворков с Podlodka Android Crew я узнал, что Александр Власюк уже всё сделал раньше и даже заслал pull request
Примечательно, что Manual DI не только даёт compile-time safety по сравнению с Koin (без всяких плагинов), но даже количество строк кода в проекте сократилось
Понятно, что это всего лишь пример. Если использовать Koin глобально, то кода с Manual DI придётся писать больше. Однако я придерживаюсь подхода, при котором DI должен быть изолирован внутри модуля, а зависимости должны быть объявлены явно, чтобы можно было легко переиспользовать этот модуль где угодно.
А вы что думаете, стоят ли DI-фреймворки, чтобы их изучать и постоянно мигрировать проект на все более новые решения
#DI #Kotlin #KMP
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍19🔥6🗿3
Как выстроить актуальную IT-инфраструктуру проекта в 2026?
Мнение экспертов и реальные кейсы на Selectel Tech Day
8 октября в Москве пройдет Selectel Tech Day — флагманская конференция одного из ведущих облачных провайдеров. В программе: доклады об актуальных технологиях, реальный опыт построения гибкой и устойчивой IT-инфраструктуры и нетворкинг.
Присоединяйтесь, чтобы узнать о главных технологических трендах и обменяться опытом с экспертами из крупных IT-компаний.
Место встречи — Москва, Цифровое деловое пространство. Участие в конференции бесплатное, нужно зарегистрироваться →
Реклама. АО "Селектел". erid:2W5zFJaTqC4
Мнение экспертов и реальные кейсы на Selectel Tech Day
8 октября в Москве пройдет Selectel Tech Day — флагманская конференция одного из ведущих облачных провайдеров. В программе: доклады об актуальных технологиях, реальный опыт построения гибкой и устойчивой IT-инфраструктуры и нетворкинг.
Присоединяйтесь, чтобы узнать о главных технологических трендах и обменяться опытом с экспертами из крупных IT-компаний.
Место встречи — Москва, Цифровое деловое пространство. Участие в конференции бесплатное, нужно зарегистрироваться →
Реклама. АО "Селектел". erid:2W5zFJaTqC4
👍2