Для генерации кода в одномодульном проекте можно использовать встренную в Android Studio фичу "File and Code Templates". Она позволяет генерировать сразу серию файлов и пакетов без написания собственного плагина
Спасибо за статью, Алексей! Тема достаточно полно и просто раскрыта для того, чтобы попробовать самому написать свой плагин.
Я бы только добавил, что по умолчанию в Intellij IDEA не будет доступен пункт "IDE Plugin" в Community Edition при создании проекта. Для добавления этого пункта нужно из Plugin Marketplace скачать плагин "Plugin Dev Kit".
Топовая статья! Когда я работал в Альфе, я наткнулся на тот же самый баг, пришлось его исследовать. Рад, что появилась статья, которую в случае чего можно скинуть, если кто-то захочет сохранять среднего/большого размера данные в fragments/activity. Особенно если fragments/activity много.
Оптимизацию в ~4% пользователи вряд ли заметят. А вот программисты будут тратить слишком много времени, чтобы обдумывать где нужен data класс, а где нет, а в дальнейшем будут проверять есть ли ключевое слово data у модели, с которой работает программист. В итоге, такое тщательное обдумывание может повлечь за собой больше багов, так как уменьшится предсказуемость кода.
Автору большое спасибо за статью! Отличная работа :)
Я полностью разделяю Вашу точку зрения и придерживаюсь аналогичного подхода.
Я хотел добавить пункт «Повышение версии SDK», но я не мог найти весомого примера, который отображал бы потенциальную проблему. Я благодарен за аргументированный комментарий. Когда будет время, я постараюсь обновить статью, добавив туда мысли из Вашего комментария)
Прослушал Ваш доклад. Согласен с мыслью, изложенной в нем. Писать свои велосипеды для тех случаев, когда что-то уже хорошо реализовано и протестировано действительно не стоит. Например, я в своем проекте использую Room, Retrofit, ViewModel&LiveData и некоторые другие библиотеки, в которых я уверен. Но думаю, что важно убедиться, что данная библиотека действительно подходит вашему проекту (Порой библиотеки с кучей багов и без должной оптимизации могут вполне подходить Вашему проекту).
в Kotlin есть какая-то особая поддержка Builder'ов?
Да не, впринципе так же. Но некоторые разработчики считают, что в Kotlin лучше использовать строитель не через цепочку вызываемых методов, а через именованные параметры. Порой это выглядит читабельнее, но это спорный вопрос.
еще бы объяснялось в туториалах лучше, как именно они работают
Это точно. Сам как-то задавался таким вопросом. В итоге где-то на просторах YouTube нашел 2-х часовую лекцию, где в подробностях разбираются кишки корутин. Если не ошибаюсь канал называется ComputerScience. Но, к сожалению, понять как работают корутины внутри действительно непросто в связи с малым количеством годного материала на эту тему.
То, что Koin и Kodein не DI, а Service Locator — это не мешает им быть прекрасными инструментами для прокидывания зависимостей.
Да, я согласен, что у них есть свои минусы по сравнению с Dagger (как и свои плюсы). Но все же Dagger подходит для более узкого числа проектов, чем остальные либы. Если Dagger действительно подходит для проекта и упрощает жизнь, то заюзать можно. При этом важно, чтобы разработчик, использующий Dagger, использовал его правильно. Но когда Dagger используют таким образом:
— Нет Binds
— Для всего пишут Provides
— Все помечено аннотацией Singleton
— Скоупы нигде не хранятся
то проект превращается в кучу костылей, которые отовсюду летят в тебя.
На самом деле я и сам сторонник Dagger, в какое-то время я его достаточно глубоко изучал и использовал в проекте. А Koin, Kodein и Toothpick я изучал лишь в теории, но на практике не использовал.
В общем, хоть Dagger и классный, но в большинстве проектов он не подходит по большей части из-за своей сложности. Не многие джуны, мидлы и даже сеньоры находят силы его полноценно изучить, к сожалению.
С objectом нужно быть очень осторожным, иначе получите плохотестируемое нечто
Полностью согласен. Он заменяет, конечно, паттерн Singleton, но как и с паттерном с object надо быть аккуратным.
Можно еще примеров? Моя фантазия, к сожалению, ставит меня в тупик.
Паттерны — делегат, строитель. Работа с асинхронностью — корутины. Но мне кажется, что это уже не сильно связано с темой статьи)
Не она, случайно?
Не она. Тут видимо просто хотят скопировать Koin. Если Koin хорошо работает из коробки, то в таком коде мало смысла. Другим разработчикам будет лишь сложнее разобраться с кодом. ИМХО
В целом, моя статья предназначена для новичков, миддл разработчиков, которые любят внедрять в свой проект новые либы, не задумываясь о последствиях. Надеюсь, кому-то она действительно поможет)
Нужно внедрять библиотеку относительно требований проекта. Также существуют проверенные библиотеки, которые показали себя на практике и их можно использовать не боясь.
К таким библиотекам могу отнести:
— Room
— Retrofit
— Библиотеки для работы с Firebase
Думаю тут зависит от того какой бюджет закладывается в проект, есть ли время сделать качественный продукт или все таки нужно сделать кое-как, но по-быстрому
Я убежден в том, что если бездумно тащить в проект библиотеки, когда нужно внедрить какую-то новую фичу, написать качественный проект не получится.
Как показывает практика гораздо чаще приходишь в проект и видишь кучу лишних зависимостей, которые вдобавок ещё и некорректно используются. Например, многие используют Dagger даже не понимая как работают скоупы :)
Конечно же, везде есть золотая середина. Самое главное — думать головой что и когда использовать.
Язык может заменить многие инструменты. Например, те же паттерны проектирования в каждом языке видоизменяются. А в Kotlin паттерн Singleton пишется одним ключевым словом object. Аналогично работает и с другими инструментами.
Благодаря Kotlin делегатам, Kotlin DSL и некоторым другим фишечкам Kotlin появились такие библиотеки как Tootkpuck, Koin, Kodein. И как раз благодаря Kotlin мы можем прокидывать зависимости гораздо проще.
Помимо либ мы можем написать DI руками, используя делегаты, который внешне будет выглядеть гораздо проще, чем Dagger. К сожалению, я потерял статью, в которой было описано как красиво можно написать DI на Kotlin делегатах :(
По поводу DI в Kotlin я имел ввиду, что можно использовать Koin, Kodein, Toothpick или прокидывать зависимости руками. Каждый из этих вариантов добавляет меньше объема сгенерированного кода, проще отлаживается и внешне выглядит гораздо проще.
Для генерации кода в одномодульном проекте можно использовать встренную в Android Studio фичу "File and Code Templates". Она позволяет генерировать сразу серию файлов и пакетов без написания собственного плагина
Спасибо за статью, Алексей! Тема достаточно полно и просто раскрыта для того, чтобы попробовать самому написать свой плагин.
Я бы только добавил, что по умолчанию в Intellij IDEA не будет доступен пункт "IDE Plugin" в Community Edition при создании проекта. Для добавления этого пункта нужно из Plugin Marketplace скачать плагин "Plugin Dev Kit".
Топовая статья!
Когда я работал в Альфе, я наткнулся на тот же самый баг, пришлось его исследовать. Рад, что появилась статья, которую в случае чего можно скинуть, если кто-то захочет сохранять среднего/большого размера данные в fragments/activity. Особенно если fragments/activity много.
Спасибо за столь подробный разбор :)
Удобный подход. Спасибо за статью!
Автору большое спасибо за статью! Отличная работа :)
Я полностью разделяю Вашу точку зрения и придерживаюсь аналогичного подхода.
Я хотел добавить пункт «Повышение версии SDK», но я не мог найти весомого примера, который отображал бы потенциальную проблему. Я благодарен за аргументированный комментарий. Когда будет время, я постараюсь обновить статью, добавив туда мысли из Вашего комментария)
Да не, впринципе так же. Но некоторые разработчики считают, что в Kotlin лучше использовать строитель не через цепочку вызываемых методов, а через именованные параметры. Порой это выглядит читабельнее, но это спорный вопрос.
Это точно. Сам как-то задавался таким вопросом. В итоге где-то на просторах YouTube нашел 2-х часовую лекцию, где в подробностях разбираются кишки корутин. Если не ошибаюсь канал называется ComputerScience. Но, к сожалению, понять как работают корутины внутри действительно непросто в связи с малым количеством годного материала на эту тему.
Да, я согласен, что у них есть свои минусы по сравнению с Dagger (как и свои плюсы). Но все же Dagger подходит для более узкого числа проектов, чем остальные либы. Если Dagger действительно подходит для проекта и упрощает жизнь, то заюзать можно. При этом важно, чтобы разработчик, использующий Dagger, использовал его правильно. Но когда Dagger используют таким образом:
— Нет Binds
— Для всего пишут Provides
— Все помечено аннотацией Singleton
— Скоупы нигде не хранятся
то проект превращается в кучу костылей, которые отовсюду летят в тебя.
На самом деле я и сам сторонник Dagger, в какое-то время я его достаточно глубоко изучал и использовал в проекте. А Koin, Kodein и Toothpick я изучал лишь в теории, но на практике не использовал.
В общем, хоть Dagger и классный, но в большинстве проектов он не подходит по большей части из-за своей сложности. Не многие джуны, мидлы и даже сеньоры находят силы его полноценно изучить, к сожалению.
Полностью согласен. Он заменяет, конечно, паттерн Singleton, но как и с паттерном с object надо быть аккуратным.
Паттерны — делегат, строитель. Работа с асинхронностью — корутины. Но мне кажется, что это уже не сильно связано с темой статьи)
Не она. Тут видимо просто хотят скопировать Koin. Если Koin хорошо работает из коробки, то в таком коде мало смысла. Другим разработчикам будет лишь сложнее разобраться с кодом. ИМХО
В целом, моя статья предназначена для новичков, миддл разработчиков, которые любят внедрять в свой проект новые либы, не задумываясь о последствиях. Надеюсь, кому-то она действительно поможет)
Нужно внедрять библиотеку относительно требований проекта. Также существуют проверенные библиотеки, которые показали себя на практике и их можно использовать не боясь.
К таким библиотекам могу отнести:
— Room
— Retrofit
— Библиотеки для работы с Firebase
Я убежден в том, что если бездумно тащить в проект библиотеки, когда нужно внедрить какую-то новую фичу, написать качественный проект не получится.
Спасибо за комментарий!
Спасибо за комментарий!
Я очень рад разработчикам, которые осознанно внедряют библиотеки в свой проект :)
Как показывает практика гораздо чаще приходишь в проект и видишь кучу лишних зависимостей, которые вдобавок ещё и некорректно используются. Например, многие используют Dagger даже не понимая как работают скоупы :)
Конечно же, везде есть золотая середина. Самое главное — думать головой что и когда использовать.
Язык может заменить многие инструменты. Например, те же паттерны проектирования в каждом языке видоизменяются. А в Kotlin паттерн Singleton пишется одним ключевым словом object. Аналогично работает и с другими инструментами.
Благодаря Kotlin делегатам, Kotlin DSL и некоторым другим фишечкам Kotlin появились такие библиотеки как Tootkpuck, Koin, Kodein. И как раз благодаря Kotlin мы можем прокидывать зависимости гораздо проще.
Помимо либ мы можем написать DI руками, используя делегаты, который внешне будет выглядеть гораздо проще, чем Dagger. К сожалению, я потерял статью, в которой было описано как красиво можно написать DI на Kotlin делегатах :(
Поддерживаю каждое Ваше замечание.
По поводу DI в Kotlin я имел ввиду, что можно использовать Koin, Kodein, Toothpick или прокидывать зависимости руками. Каждый из этих вариантов добавляет меньше объема сгенерированного кода, проще отлаживается и внешне выглядит гораздо проще.