DI фреймворки бывают двух видов: те, что строят свой граф зависимостей во время компиляции (compile time фреймворки), и те, которые делают это уже при выполнении кода (runtime фреймворки).

Kodein — типичный представитель runtime фреймворков. Это значит, что о пропущенной зависимости вы узнаете непосредственно в процессе работы приложения, что может стать неприятным сюрпризом. Только представьте себе: вы пропустили на регрессе какой-то кейс, и у вас краш в продакшене из-за DI! Это же настоящий кошмар!

Однако отказываться от Kodein ID и других runtime фреймворков не стоит. О том, почему мы продолжаем ими пользоваться, и как их сделать более надёжными, я расскажу в третьей статье из цикла материалов про Kodein DI для Android.

Погнали.

Быть в авангарде в разработке — жизненная необходимость. Поэтому многие проекты уже переходят на Jetpack Compose, а самые смелые и продвинутые даже выпускают приложения на KMP. Мы в проекте Дринкит тоже активно переходим на Jetpack Compose (с KMP пока не сделали подход).

Ну и как же жить со всем этим без DI? Правильно, никак. Поэтому в этой статье я расскажу, как применять DI Kodein в Kotlin Multiplatform и Jetpack Compose.

Это вторая статья из цикла статьей про Kodein DI для Android.

Погнали.

Android разработчики обожают DI. Куда ни посмотри, куча статей и выступлений про Dagger 2, Hilt или Koin, но очень мало про Kodein. Даже на Хабре всего пару неплохих статей, но и те от 2018 года. Но с тех пор Kodein бурно развивался, и вышло много мажорных версий, API значительно изменился.

Мы используем Kodein в приложении Drinkit и успели прочувствовать на себе плюсы и минусы этого инструмента. Я расскажу, как пользоваться Kodein, как у него дела со скоупами и многомодульностью.

Вчера чат-бот с искусственным интеллектом ChatGPT написал за меня Android-приложение! Это очень примитивное приложение, но оно компилируется, запускается и работает. Но как он это сделал? С первой попытки или пришлось долго сидеть и мучить его?

Сейчас расскажу!

Влияет ли размер приложения и команды на то, как мы его релизим? Давайте представим себе стартап. Проект и команда небольшие. В этом случае обычно не задумываешься о процессе релизов: сделал фичу — зарелизил.

А теперь представим большой проект, например, какое-нибудь банковское приложение, над которым работает много команд. Тут мы понимаем, что наверняка есть процесс, релизные циклы, «бюрократия». Без этого будет хаос. Но где то место, когда становится ясно, что пора такой процесс настраивать и у себя?

В этой статье расскажу, что при росте приложения Додо Пиццы стало для нас отправной точкой и заставило внедрить Release Train. В конце поделюсь результатами, помогло ли это.

Если ваш проект растёт, или вы по другим причинам часто спотыкаетесь в работе при релизе приложения, то надеюсь, что наш опыт пригодится и поможет эти проблемы решить.

Android-разработчиков часто спрашивают на технических собеседованиях, как запускать фрагменты, как передавать туда данные, почему нельзя класть много в аргументы, а много — это сколько, а что может пойти не так и т.д. Мы в Dodo тоже иногда такие вопросы задаём. Я думал, что понимал всё это, но оказалось, что довольно поверхностно. Всё изменилось, когда я столкнулся с частыми крашами TransactionTooLargeException в приложении Дринкит.

TransactionTooLargeException — это исключение из области IPC-вызовов (interprocess communication) и Android Binder. Но его можно получить в безобидной ситуации, когда, казалось бы, мы ничего такого не делали, и не пользовались IPC.

В этой статье предлагаю разобраться с этим крашем и поговорить про IPC-вызовы и Binder.

Представим простую историю. Вы заканчиваете делать рефакторинг, которым занимались последние 2 недели. Вы хорошо над ним поработали, сделали несколько ключевых изменений в проекте. Делаете долгожданный pull request, и ... 12 конфликтов.

Или другой вариант. Вы работали и постоянно подливали себе основную ветку, так чтобы код сильно не расходился. Делаете pull request, он висит несколько дней, после этого вы получаете approve и ... 15 конфликтов. Кто-то слил свой большой pull request раньше.

Но ведь вы всё делали правильно. Работали над рефакторингом в отдельной ветке. Почему вам надо разрешать эти конфликты и можно ли как-то попроще? Можно ли работать в какой-то особой ветке, которую потом легко сливать в главную ветку без конфликтов? Оказывается, можно.

В этой статье поговорим про технику Branch by Abstraction. Как она может помочь не копить большие изменения в нашей ветке, избегать merge hell и прокачать ваш CI.

Я буду описывать примеры из Android-разработки, но они также справедливы для большинства типов проектов и платформ.

Я Android-разработчик и хотел бы сам решать, какие задачи мне делать, а какие нет. У вас бывало такое желание? Можно ли так делать на работе? Мой краткий и возможно, интригующий ответ — можно. Ключ к этому — погружение в бизнес.

Разговоры о том, надо ли разработчикам погружаться в бизнес часто превращаются в холивар и километровые треды. Хочу порассуждать мозгами разработчика, зачем и стоит ли вообще, а если стоит, то насколько сильно надо «погружаться в бизнес», какие процессы в этом помогают, и какие вообще профиты для нас с вами с этого всего. Поехали.

Когда мы начинаем изучать корутины, то «идём» и пробуем что-то простое с билдером runBlocking, поэтому многим он хорошо знаком. runBlocking запускает новую корутину, блокирует текущий поток и ждёт, пока выполнится блок кода — кажется, всё просто и понятно. Но что, если я скажу, что в runBlocking есть одна любопытная вещь, которая может заблокировать не только текущий поток, а вообще всё ваше приложение навсегда?