Комментарии / Профиль infinity_coder

05.07.2025 10:48:53

Sat, 05 Jul 2025 10:48:53 GMT

Поправили опечатки
Спасибо за комментарий!

20.06.2025 20:40:11

Fri, 20 Jun 2025 20:40:11 GMT

Спасибо за комментарий!

К сожалению, я не понял как он относится к теме статьи. Попробуйте переформулировать его

20.06.2025 20:36:16

Fri, 20 Jun 2025 20:36:16 GMT

Спасибо за комментарий!
Действительно в некоторых местах я опирался на те материалы, которые я прикрепил в статье. Здорово, что вы заинтересовались темой, и прочли в том числе и прикрепленные к статье материалы!

Достойное применение контрактов можно посмотреть в стандартной библиотеке Kotlin. Именно отсюда я старался брать примеры для раздела "Contracts DSL".

Поломку неизменяемости я привел в пример, чтобы дать понять почему важно писать валидные контракты, и что произойдет если написать неправильный контракт. На практике, конечно, не рекомендуется использовать такие особенности Kotlin контрактов и специально ломать Kotlin компилятор :)

Если это отключение длинных проверок для увеличения производительности, хорошо

Контракты нельзя применять для таких кейсов. Они про другое: расширить знания компилятора, чтобы улучшить smart-cast'ы и убрать лишние проверки на null или типы.

Я специально привел в пример функцию, которая выглядит просто как обертка ради обетки, чтобы максимально упростить код.

Хорошие примеры функций, которые нужны в реальной жизни: `check(...)`, isNullOrEmpty(). Чтобы лучше понять зачем нужны контракты, попробуйте скопировать эти функции из стандартной библиотеки Kotlin и убрать оттуда контракты. После этого компилятор начнет ругаться, что переменные nullable типа, которые очевидно не могут быть null после вызова функции

24.10.2024 18:36:44

Thu, 24 Oct 2024 18:36:44 GMT

Классная поучительная статья с долей фана. То, что нужно после рабочего дня :) Спасибо!

17.03.2024 12:23:20

Sun, 17 Mar 2024 12:23:20 GMT

Для генерации кода в одномодульном проекте можно использовать встренную в Android Studio фичу "File and Code Templates". Она позволяет генерировать сразу серию файлов и пакетов без написания собственного плагина

17.03.2024 07:53:20

Sun, 17 Mar 2024 07:53:20 GMT

Спасибо за статью, Алексей! Тема достаточно полно и просто раскрыта для того, чтобы попробовать самому написать свой плагин.

Я бы только добавил, что по умолчанию в Intellij IDEA не будет доступен пункт "IDE Plugin" в Community Edition при создании проекта. Для добавления этого пункта нужно из Plugin Marketplace скачать плагин "Plugin Dev Kit".

28.10.2022 10:31:21

Fri, 28 Oct 2022 10:31:21 GMT

Топовая статья!
Когда я работал в Альфе, я наткнулся на тот же самый баг, пришлось его исследовать. Рад, что появилась статья, которую в случае чего можно скинуть, если кто-то захочет сохранять среднего/большого размера данные в fragments/activity. Особенно если fragments/activity много.

Спасибо за столь подробный разбор :)

20.05.2022 16:08:10

Fri, 20 May 2022 16:08:10 GMT

Удобный подход. Спасибо за статью!

05.03.2021 09:42:24

Fri, 05 Mar 2021 09:42:24 GMT

Оптимизацию в ~4% пользователи вряд ли заметят. А вот программисты будут тратить слишком много времени, чтобы обдумывать где нужен data класс, а где нет, а в дальнейшем будут проверять есть ли ключевое слово data у модели, с которой работает программист. В итоге, такое тщательное обдумывание может повлечь за собой больше багов, так как уменьшится предсказуемость кода.
Автору большое спасибо за статью! Отличная работа :)

20.10.2020 09:36:57

Tue, 20 Oct 2020 09:36:57 GMT

Спасибо за комментарий!

Я полностью разделяю Вашу точку зрения и придерживаюсь аналогичного подхода.
Я хотел добавить пункт «Повышение версии SDK», но я не мог найти весомого примера, который отображал бы потенциальную проблему. Я благодарен за аргументированный комментарий. Когда будет время, я постараюсь обновить статью, добавив туда мысли из Вашего комментария)

20.10.2020 09:22:54

Tue, 20 Oct 2020 09:22:54 GMT

Прослушал Ваш доклад. Согласен с мыслью, изложенной в нем. Писать свои велосипеды для тех случаев, когда что-то уже хорошо реализовано и протестировано действительно не стоит. Например, я в своем проекте использую Room, Retrofit, ViewModel&LiveData и некоторые другие библиотеки, в которых я уверен. Но думаю, что важно убедиться, что данная библиотека действительно подходит вашему проекту (Порой библиотеки с кучей багов и без должной оптимизации могут вполне подходить Вашему проекту).

19.10.2020 09:41:03

Mon, 19 Oct 2020 09:41:03 GMT

Ничем :) Я форкнул библиотеку, исправив некоторые баги.

15.10.2020 07:52:35

Thu, 15 Oct 2020 07:52:35 GMT

в Kotlin есть какая-то особая поддержка Builder'ов?

Да не, впринципе так же. Но некоторые разработчики считают, что в Kotlin лучше использовать строитель не через цепочку вызываемых методов, а через именованные параметры. Порой это выглядит читабельнее, но это спорный вопрос.

еще бы объяснялось в туториалах лучше, как именно они работают

Это точно. Сам как-то задавался таким вопросом. В итоге где-то на просторах YouTube нашел 2-х часовую лекцию, где в подробностях разбираются кишки корутин. Если не ошибаюсь канал называется ComputerScience. Но, к сожалению, понять как работают корутины внутри действительно непросто в связи с малым количеством годного материала на эту тему.

15.10.2020 07:28:01

Thu, 15 Oct 2020 07:28:01 GMT

Вот вот! :)

15.10.2020 06:28:49

Thu, 15 Oct 2020 06:28:49 GMT

То, что Koin и Kodein не DI, а Service Locator — это не мешает им быть прекрасными инструментами для прокидывания зависимостей.
Да, я согласен, что у них есть свои минусы по сравнению с Dagger (как и свои плюсы). Но все же Dagger подходит для более узкого числа проектов, чем остальные либы. Если Dagger действительно подходит для проекта и упрощает жизнь, то заюзать можно. При этом важно, чтобы разработчик, использующий Dagger, использовал его правильно. Но когда Dagger используют таким образом:
— Нет Binds
— Для всего пишут Provides
— Все помечено аннотацией Singleton
— Скоупы нигде не хранятся
то проект превращается в кучу костылей, которые отовсюду летят в тебя.
На самом деле я и сам сторонник Dagger, в какое-то время я его достаточно глубоко изучал и использовал в проекте. А Koin, Kodein и Toothpick я изучал лишь в теории, но на практике не использовал.
В общем, хоть Dagger и классный, но в большинстве проектов он не подходит по большей части из-за своей сложности. Не многие джуны, мидлы и даже сеньоры находят силы его полноценно изучить, к сожалению.

С objectом нужно быть очень осторожным, иначе получите плохотестируемое нечто

Полностью согласен. Он заменяет, конечно, паттерн Singleton, но как и с паттерном с object надо быть аккуратным.

Можно еще примеров? Моя фантазия, к сожалению, ставит меня в тупик.

Паттерны — делегат, строитель. Работа с асинхронностью — корутины. Но мне кажется, что это уже не сильно связано с темой статьи)

Не она, случайно?

Не она. Тут видимо просто хотят скопировать Koin. Если Koin хорошо работает из коробки, то в таком коде мало смысла. Другим разработчикам будет лишь сложнее разобраться с кодом. ИМХО

В целом, моя статья предназначена для новичков, миддл разработчиков, которые любят внедрять в свой проект новые либы, не задумываясь о последствиях. Надеюсь, кому-то она действительно поможет)

15.10.2020 05:49:43

Thu, 15 Oct 2020 05:49:43 GMT

Спасибо за комментарий!

14.10.2020 17:04:14

Wed, 14 Oct 2020 17:04:14 GMT

Полностью с Вами согласен

Нужно внедрять библиотеку относительно требований проекта. Также существуют проверенные библиотеки, которые показали себя на практике и их можно использовать не боясь.
К таким библиотекам могу отнести:
— Room
— Retrofit
— Библиотеки для работы с Firebase

14.10.2020 17:00:48

Wed, 14 Oct 2020 17:00:48 GMT

Думаю тут зависит от того какой бюджет закладывается в проект, есть ли время сделать качественный продукт или все таки нужно сделать кое-как, но по-быстрому

Я убежден в том, что если бездумно тащить в проект библиотеки, когда нужно внедрить какую-то новую фичу, написать качественный проект не получится.

14.10.2020 14:20:27

Wed, 14 Oct 2020 14:20:27 GMT

Согласен

Спасибо за комментарий!

14.10.2020 14:19:57

Wed, 14 Oct 2020 14:19:57 GMT

Полностью с Вами согласен. Жаль, что понимание баланса приходит с годами.

Спасибо за комментарий!