Koin и Kodein сервис локаторы, а не DI, в отличии от dagger
Фреймворки - это инструменты, и следовать они могут разным паттернам.
Главное, что надо понимать про DI и Сервис локатор, это принцип. Знает ли ваш класс, что он сам запрашивает откуда-то зависимость? Или эту зависимость ему провайдит (в конструктор) кто-то извне, и ваш класс даже не знает кто именно и как.
Позволяет ли Kodein и Koin управлять зависимостями так, что ваши классы не знают откуда они берут зависимость? Позволяет. Все дерево зависимостей, кроме Активити могут получать зависимости через конструктор. Значит DI "как подход" здесь можно применять.
и следует JSP
Наверное вы имели ввиду JSR-330? Да, Dagger его поддерживает. Как, кстати, и Kodein.
Главная разница у вас будет в том, что вы написали аннотацию Inject (в случае Dagger 2 или другого фреймворка, который поддерживает JSR-330) или вы написали by instance, который является делегатом и можно за уши притянуть, что вы же здесь запрашиваете зависимость, а не внедряете. Но с семантической точки зрения Котлин это позволяет написать максимально не привязанно к подходу Сервис локатора.
Я бы сказал, что главное преимущество — простота использования. Я думаю, что возьми разработчика, который не работал с DI и дай документацию Dagger 2 и Kodein (или Koin) и засекай время, кто быстрее напишет работающий код. Другой вопрос "на столько ли оно велико" — ответ стандартный it depends... Надо смотреть. Например, если вас абсолютно всё устраивает во фреймворке и единственная претензия это целостность графа и больше нет претензий — то deploy time подход вполне себе норм.
Да, мы за основу взяли coil.compose.AsyncImage. Но сделали свою обертку, которая при фейле загрузки картинки делает ретраи, если появился интернет. Это для случаев, когда мы зашли на экран, и интернета нет, а потом интернет появляется. То в этом случае сами виджеты перезагрузили картинки.
Любопытно, что используют или KMP + Compose Multiplatform или Jetpack Сompose больше половины проголосовавших. Я думал сообществе более консервативно, а мы достаточно прогрессивны :)
аргумент фабрики – это аналог assisted inject в даггере?
Ну можно сказать, что да. Отличается API, что в даггере надо фабрику явную создавать. А здесь просто слово provider на factory меняется. Но по факту это сделано для одного и того же.
если нужно передать несколько параметров – нужно оборачивать их в класс?
@Lynnfieldспасибо за статью. Лично мне в ней не хватает решений проблем. Ты описал разные проблемы, но нет никаких решений. То есть я прочитал статью о том, как всё плохо, но так и не узнал, а как же хорошо. Либо прийти к выводу о том, что это и не проблемы вовсе, и это не дело MVx их решать.
Возможно, ты хотел описать решения в будущих статьях, но пока мы имеем эту статью, где расписана куча проблем и нет даже намека на решения.
@maxkachinkin Сколько в часах у вас заняло написание приложения с помощью ChatGP? Тут предлагаю условится, что вы не прибегали к помощи и не являетесь тематическим разработчиком. Так будет проще.
Я не смогу ответить, потому что я являюсь разработчиком. В моем случае, зная как надо писать, мне было интересно, а что будет предлагать чат-бот.
Если хочется проверить, как с этим справится неразработчик, то нужен новый эксперимент.
По времени у мены заняло это пару вечеров. Потому что я как бы имитировал, что я не разработчик, и любую ошибку спрашивал у него. Сам я написал бы, конечно, это гораздо быстрее. В данном случае эксперимент был не на время.
При выборе AsyncTask или Thread становится понятно, автор программист или работает с ментором. "Или" значит 50/50. Как робот решит задачу, если выбрать AsyncTask? Вот это сложнее и интереснее!
Было бы круче, если бы он ответил, что есть разные варианты для написания асинхронного кода в Андроиде, но я рекомендую такой-то по тому-то и тому-то. Как настоящий программист.
Единственное, перед этим, когда я игрался с ним, я позадавал пару рандомных вопросов по программированию. Просто было интересно, что он будет отвечать. И увидел, что он неплохо отвечает и даже сразу дает примеры кода. После этого решил, что давай сразу попробуем простенькое приложение. Раз ты сценарии к сериалам пишешь, чем список акций на андроиде хуже :)
Скажем так, имеется ввиду такой AI, который вы представляете/прогнозируете будет через 3-5 лет на основе текущих наработок и того, как он будет развиваться.
Для замены людей маловато, но уже можно круто прокачать поисковики и умные колонки
Но представь, ты сидишь, работаешь и спрашиваешь у умной колонки, как установить инсеты в Андроиде (поставь вместо этого то, что тебе сложнее запомнить). Прикольно же!
Нет, не 2-х недельным спринтам. Спринты у каждой команды любые на усмотрение команда. 2-х недельные именно релизные циклы приложения.
Смысл релиз трейна в том, чтобы отделить релиз билда от релиза фич. Релиз билдов идет строго по расписанию. Релиз фич идет так, как напланируют команды. Может быть так, что в новом релизе не будет ни одной новой фичи, а только фиксы какие-то. Хотя по факту, когда 6 команд работает параллельно, такого ни разу не было.
Правильно ли я понял, что на самом деле бизнесу просто был нужен график ввода в эксплуатацию
Бизнесу нужна прогнозируемость. Чтобы он мог четко понимать, когда та или иная фича окажется у клиентов. Когда приложение и команда были небольшими, то и график, который синхронизирует команды, никакой не нужен. Оценили фичу и делаем. Как сделали — покатили. А когда несколько команд работают параллельно так просто уже не получается. Нужен какой-то специальный процесс, который это всё синхронизирует.
Каков процент ручных тестов?
Сейчас 60% и 70% регресс кейсов автоматизировано на каждой платформе соответственно. Остальное пока ручное.
Фреймворки - это инструменты, и следовать они могут разным паттернам.
Главное, что надо понимать про DI и Сервис локатор, это принцип. Знает ли ваш класс, что он сам запрашивает откуда-то зависимость? Или эту зависимость ему провайдит (в конструктор) кто-то извне, и ваш класс даже не знает кто именно и как.
Позволяет ли Kodein и Koin управлять зависимостями так, что ваши классы не знают откуда они берут зависимость? Позволяет. Все дерево зависимостей, кроме Активити могут получать зависимости через конструктор. Значит DI "как подход" здесь можно применять.
Наверное вы имели ввиду JSR-330? Да, Dagger его поддерживает. Как, кстати, и Kodein.
Главная разница у вас будет в том, что вы написали аннотацию
Inject(в случае Dagger 2 или другого фреймворка, который поддерживает JSR-330) или вы написалиby instance, который является делегатом и можно за уши притянуть, что вы же здесь запрашиваете зависимость, а не внедряете. Но с семантической точки зрения Котлин это позволяет написать максимально не привязанно к подходу Сервис локатора.Я бы сказал, что главное преимущество — простота использования. Я думаю, что возьми разработчика, который не работал с DI и дай документацию Dagger 2 и Kodein (или Koin) и засекай время, кто быстрее напишет работающий код.
Другой вопрос "на столько ли оно велико" — ответ стандартный it depends... Надо смотреть. Например, если вас абсолютно всё устраивает во фреймворке и единственная претензия это целостность графа и больше нет претензий — то deploy time подход вполне себе норм.
А где Додо?)
Да, мы за основу взяли coil.compose.AsyncImage. Но сделали свою обертку, которая при фейле загрузки картинки делает ретраи, если появился интернет. Это для случаев, когда мы зашли на экран, и интернета нет, а потом интернет появляется. То в этом случае сами виджеты перезагрузили картинки.
�
Готовим статью про то как мы делали наш первый сложный экран на Copmose.
Не значительно да. Мы, если честно, больше страдает от времени загрузки Compose Runtime.
У нас мало было кастомных modifiers, написанных через composed. Мы пока не переписывали свои.
Любопытно, что используют или KMP + Compose Multiplatform или Jetpack Сompose больше половины проголосовавших. Я думал сообществе более консервативно, а мы достаточно прогрессивны :)
Ну можно сказать, что да. Отличается API, что в даггере надо фабрику явную создавать. А здесь просто слово provider на factory меняется. Но по факту это сделано для одного и того же.
Да, можно обернуть в data class например.
Спасибо
Отличная статья!
А зачем луперу File Descriptor? Что он с ним делает?
@Lynnfieldспасибо за статью. Лично мне в ней не хватает решений проблем. Ты описал разные проблемы, но нет никаких решений. То есть я прочитал статью о том, как всё плохо, но так и не узнал, а как же хорошо. Либо прийти к выводу о том, что это и не проблемы вовсе, и это не дело MVx их решать.
Возможно, ты хотел описать решения в будущих статьях, но пока мы имеем эту статью, где расписана куча проблем и нет даже намека на решения.
А так, молодец!
Касательно проекта релиз трейна - ни на сколько. Это всё было организовано техлидами и разработчиками. SRE мобильная команда возможно будет в будущем.
Я не смогу ответить, потому что я являюсь разработчиком. В моем случае, зная как надо писать, мне было интересно, а что будет предлагать чат-бот.
Если хочется проверить, как с этим справится неразработчик, то нужен новый эксперимент.
По времени у мены заняло это пару вечеров. Потому что я как бы имитировал, что я не разработчик, и любую ошибку спрашивал у него. Сам я написал бы, конечно, это гораздо быстрее. В данном случае эксперимент был не на время.
Было бы круче, если бы он ответил, что есть разные варианты для написания асинхронного кода в Андроиде, но я рекомендую такой-то по тому-то и тому-то. Как настоящий программист.
Сразу такое придумал. Не было "Hello, world!".
Единственное, перед этим, когда я игрался с ним, я позадавал пару рандомных вопросов по программированию. Просто было интересно, что он будет отвечать. И увидел, что он неплохо отвечает и даже сразу дает примеры кода. После этого решил, что давай сразу попробуем простенькое приложение. Раз ты сценарии к сериалам пишешь, чем список акций на андроиде хуже :)
Действительно :) Тоже подумываю завязывать пора :)
Скажем так, имеется ввиду такой AI, который вы представляете/прогнозируете будет через 3-5 лет на основе текущих наработок и того, как он будет развиваться.
Но представь, ты сидишь, работаешь и спрашиваешь у умной колонки, как установить инсеты в Андроиде (поставь вместо этого то, что тебе сложнее запомнить). Прикольно же!
Согласен! Хочу попросить жену (она продакт) сделать что-то похожее и посмотреть, на сколько это будет дольше и сложнее.
Нет, не 2-х недельным спринтам. Спринты у каждой команды любые на усмотрение команда. 2-х недельные именно релизные циклы приложения.
Смысл релиз трейна в том, чтобы отделить релиз билда от релиза фич. Релиз билдов идет строго по расписанию. Релиз фич идет так, как напланируют команды. Может быть так, что в новом релизе не будет ни одной новой фичи, а только фиксы какие-то. Хотя по факту, когда 6 команд работает параллельно, такого ни разу не было.
Бизнесу нужна прогнозируемость. Чтобы он мог четко понимать, когда та или иная фича окажется у клиентов. Когда приложение и команда были небольшими, то и график, который синхронизирует команды, никакой не нужен. Оценили фичу и делаем. Как сделали — покатили. А когда несколько команд работают параллельно так просто уже не получается. Нужен какой-то специальный процесс, который это всё синхронизирует.
Сейчас 60% и 70% регресс кейсов автоматизировано на каждой платформе соответственно. Остальное пока ручное.