💉 Dependency Injection: Зачем усложнять, если можно просто написать new?

Когда новичок видит код с кучей аннотаций @Inject или модулей, у него возникает вопрос: "Зачем всё это? Я же могу просто создать объект внутри класса!"

❌ Код Джуна (Hard dependency):

class UserRepository {
    // Мы "приварили" конкретную базу данных к репозиторию
    private val database = SQLiteDatabase() 

    fun getUser() { ... }
}

В чем проблема?
Представьте, что вы строите дом. Этот код как если бы вы вмуровали кофемашину прямо в стену кухни.

1. Хотите заменить кофемашину на новую? Придется ломать стену (переписывать код класса).
2. Хотите протестировать кухню, не варя кофе? Не получится, машина там намертво.

✅ Код Мидла (Dependency Injection):

class UserRepository(private val database: Database) { 
    // Мы просим дать нам ЛЮБУЮ базу данных через конструктор
}

В чем суть?
Вы говорите: "Мне для работы нужна база данных. Дайте мне её, я не хочу сам её создавать".
Это как розетка. Вы не вмуровываете технику в стену, вы просто втыкаете вилку. Сегодня это дешевый чайник (тестовая база), завтра мощная кофемашина (реальный сервер).

🛠 Инструменты (Что учить):

🤖 Android:

• Hilt (Dagger): Стандарт от Google. Мощный, проверяет ошибки при компиляции, но сложный в настройке.

• Koin: Service Locator (технически не совсем DI, но решает те же задачи). Простой, пишется на чистом Kotlin, но ошибки могут вылезти в рантайме. Идеально для старта.

🍏 iOS:

• Swinject: Классика DI контейнеров.

• Swift Native: В современных проектах часто используют просто Factory Pattern или передачу зависимостей через init, без сторонних библиотек. Это самый чистый путь.

💡 Совет:
На собеседовании на вопрос "Что такое DI?" не начинайте рассказывать про даггер.
Скажите просто: "Это принцип, когда объекты не создают свои зависимости сами, а получают их извне. Это нужно для тестируемости и гибкости кода". Это ответ уровня Senior.

А что используете вы в своих проектах? 👇

#architecture #di #hilt #koin #ios #android #middle #patterns

👉 @developer_mobila

🎨 Почему простой список лагает: Скрытый враг FPS (Overdraw)

Бывало такое? Вы сверстали красивый экран, но при скролле он идет рывками, а телефон в руках начинает нагреваться. Вы смотрите в код адаптера, там всё чисто.

Проблема не в коде. Проблема в Overdraw (Перерисовке).

Это когда система вынуждена закрашивать один и тот же пиксель на экране 3-4 раза за один кадр.
Пример: У вас есть белый фон у Activity -> сверху белый фон у Fragment -> сверху белый фон у карточки товара -> сверху картинка.
GPU делает 4 лишних действия, хотя пользователь видит только картинку.

🛠 Как увидеть это своими глазами:

🤖 Android:
Это встроенная суперсила, о которой забывают.

1. Идем в Настройки разработчика (Developer Options).

2. Ищем пункт «Отладка наложения GPU» (Debug GPU overdraw).

3. Выбираем «Показывать зоны наложения».

Ваш экран станет психоделически цветным:

• 💙 Синий: 1 слой (Идеал).

• 💚 Зеленый: 2 слоя (Норма).

• 🩷 Розовый: 3 слоя (Стоит обратить внимание).

• ❤️ Красный: 4+ слоя (Плохо! Тут тормозит).

🍏 iOS: В Xcode:

1. Запустите приложение на устройстве.

2. В меню Xcode: Debug -> View Debugging -> Rendering -> Color Blended Layers.

3. Красные зоны покажут места, где смешиваются прозрачные слои (это самое дорогое для GPU).

🚀 Как лечить:

1. Удаляйте лишние фоны (background). Если у контейнера уже есть белый фон, не нужно ставить такой же белый фон вложенному TextView

2. Избегайте прозрачности (alpha). Для GPU просчитать полупрозрачность сложнее, чем просто сплошной цвет.

3. В списках (RecyclerView/LazyColumn) следите, чтобы элементы не рисовали фон там, где его перекрывает картинка.

💡 Задание: Включите этот режим на телефоне и зайдите в популярные приложения (Telegram, YouTube). Посмотрите, как качественно (или нет) они оптимизированы. А потом зайдите в своё. 😉

Знали про эту настройку или всё это время гадали, почему падает FPS? 👇

#performance #ui #fps #android #ios #optimization #middle

👉 @developer_mobila

🧟‍♂️ Зомби в вашем коде: Почему приложение «пухнет» со временем

Бывало такое? Вы открыли экран, закрыли его, а память не освободилась. Сделали так 10 раз и приложение упало.
Поздравляю, у вас Memory Leak (Утечка памяти).

Это происходит, когда объект (например, тяжелая Activity или ViewController) уже не нужен пользователю, но сборщик мусора (GC) не может его удалить, потому что кто-то другой всё еще держит на него ссылку.

Главные причины утечек (Checklist):

🛑 Android:

1. Static Context: Никогда не сохраняйте Context или View в статические переменные!
• Плохо: companion object { var myView: TextView? = null } - это удержит всю Activity в памяти навсегда.


2. Забытые слушатели: Если вы подписались на синглтон (LocationManager.addListener(this)), но забыли отписаться в onDestroy - Activity останется жить вечно.
3. Внутренние классы: Анонимные классы (например, Handler или AsyncTask) неявно хранят ссылку на внешний класс.

🛑 iOS:

1. Retain Cycles (Циклы сильных ссылок):
Объект А держит Б, а Б держит А. Они никогда не удалятся.
• Классика: Вы передали self внутрь замыкания (closure), которое сохранено в свойстве этого же класса.
• Лечение: Всегда используйте [weak self] внутри клоужеров, если есть риск цикла.



🛠 Инструменты для поиска (Без них вы слепы):

🐤 Android - LeakCanary:
Библиотека от Square. Must-have в любом debug-билде.
Она автоматически следит за Activity/Fragment. Если происходит утечка, она присылает уведомление (буквально кричит), дампит память и показывает красивое дерево ссылок: кто именно держит ваш объект.

📊 iOS - Memory Graph Debugger:
В Xcode есть встроенная кнопка (три шарика, соединенных линиями) в нижней панели дебага.
Нажимаете её во время работы приложения - и Xcode показывает граф всех объектов в памяти. Ищите фиолетовые восклицательные знаки (⚠️) - это утечки.

💡 Совет: Утечки памяти коварны тем, что на мощном телефоне разработчика они незаметны. А у пользователя на старом Android с 3 ГБ RAM приложение вылетит через 5 минут. Проверяйте память хотя бы раз в спринт.

А вы используете [weak self] везде «на всякий случай» или только там, где нужно? 👇

#memory #performance #leaks #leakcanary #ios #android #middle #optimization

👉 @developer_mobila

🎭 Искусство обмана: Зачем нужны Mock-объекты (и почему без них тесты - мусор)

Представьте: вы пишете тест для экрана Логина.
Вы нажимаете «Войти» в коде теста -> идет запрос на реальный сервер -> сервер отвечает 200 OK -> тест проходит.

На следующий день у вас пропал интернет. Или бэкенд упал. Или Вася с бэкенда поменял JSON.
Ваш тест упал 🔴.
Но ваш код Логина не менялся и работает правильно!

Это Flaky Test (Хрупкий тест). Он проверяет не вашу логику, а погоду на Марсе (доступность сервера).

🛡 Решение: Mocking (Мокирование)

В Unit-тестах мы должны тестировать классы в изоляции.
Ваш ViewModel / Presenter не должен знать, что существует настоящий сервер или база данных. Ему нужно подсунуть «куклу» (Mock).

Как это работает (на пальцах):

1. У вас есть интерфейс AuthRepository.
2. В реальном приложении вы используете NetworkAuthRepository (который ходит в сеть).
3. В тесте вы создаете Mock этого репозитория.

Что умеет Mock:
Вы говорите ему: "Слушай, когда у тебя вызовут метод login("admin", "123"), не ходи ни в какую сеть. Просто верни мне Success мгновенно" (или Error, если хотите проверить обработку ошибок).

🛠 Инструменты Мидла:

🤖 Android (Kotlin):
Забудьте про Mockito (он из мира Java). Используйте MockK.

// Создаем мок
val repository = mockk<AuthRepository>()

// Обучаем его (Stubbing)
coEvery { repository.login(any(), any()) } returns Result.Success(User("Max"))

// Тестируем ViewModel
viewModel.onLoginClicked()

// Проверяем, что метод был вызван (Verification)
coVerify { repository.login("admin", "pass") }

🍏 iOS (Swift):
В Swift часто пишут моки вручную (создают класс MockAuthRepo, реализующий протокол), так как рефлексия ограничена.
Либо используют генераторы: Sourcery или Cuckoo.
Суть та же:

class MockAuthRepo: AuthRepository {
    var loginResult: Result<User, Error>?
    
    func login(...) {
        return loginResult! // Возвращаем то, что настроили заранее
    }
}

💡 Главная мысль:
Unit-тесты должны работать без интернета, без эмулятора и выполняться за миллисекунды. Если ваш тест идет 5 секунд - это не Unit-тест.

А какой процент покрытия кода тестами (Code Coverage) в вашем проекте? (Если 0% - не стесняйтесь, ставьте 🌚) 👇

#testing #unit #mockk #android #ios #quality #middle

👉 @developer_mobila

⚡️ Kotlin — современный мощный инструмент с простым синтаксисом. Он подходит как для бэкенд, так и фронтенд-разработки, к тому же на нем разрабатывают приложения под Android. Присматриваетесь к Kotlin, но еще нет навыков программирования? В OTUS стартовал набор на онлайн-курс «Kotlin Developer. Basic».

Всего через 4 месяца вы:
✔Освоите принципы программирования и алгоритмов
✔Узнаете о возможностях языка Kotlin на практике
✔Научитесь использовать популярные структуры данных
✔Опробуете Kotlin в качестве языка бэкенд- и фронтенд-разработки

И все это на живых вебинарах с ведущими разработчиками и на практике, где вы разработаете собственный проект для портфолио. Пройдите вступительный тест и успейте занять место со скидкой:

https://vk.cc/cUxQm5

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Подводные камни миграции на Swift 6, о которых стоит знать

Swift 6 вводит более строгие проверки изоляции конкурентности и поддерживает поэтапную миграцию, модуль за модулем. Хотя рекомендуемая Apple стратегия выглядит мягкой, на практике вы можете столкнуться со скрытыми сбоями во время выполнения, особенно когда в проекте одновременно сосуществуют модули на Swift 5 и Swift 6.

В этой статье разберем два реальных кейса, на которых команды регулярно спотыкаются при поэтапной миграции на Swift 6. Мы свяжем их с исходниками Swift Runtime, объясним задумку и триггеры падений, и завершим практическими мерами по снижению рисков и рекомендациями по обновлению.

https://www.hughlee.page/en/posts/swift-6-migration-pitfalls/

#ios

👉 @developer_mobila

🚀 Хватит собирать билды руками: Введение в CI/CD

Знакомая боль: вы закончили крутую фичу, и QA просит тестовую сборку. Вы переключаете ветку, жмете "Build APK" (или "Archive" в Xcode) и... идете гулять на 20 минут. Ноутбук гудит как турбина самолета, интерфейс тормозит, работать невозможно.
А потом тестировщик пишет: "Слушай, а ты версию (versionCode) забыл поднять, оно не ставится поверх старого". 🤦‍♂️

Сборка релизов руками со своего компьютера - это огромная трата времени и источник человеческих ошибок (забыли сменить конфиг с Debug на Release, выбрали не тот сертификат).

Взрослые команды используют CI/CD (Continuous Integration / Continuous Deployment).

⚙️ Как это выглядит у Мидлов:
Вы просто делаете git push или сливаете Pull Request в ветку develop. ВСЁ. Ваша работа закончена.
Дальше начинается магия:

1. В облаке просыпается виртуальный сервер.
2. Он скачивает свежий код.
3. Запускает линтеры и Unit-тесты (о которых мы говорили раньше). Если они упали - сборка отменяется, а вам в Slack/Telegram прилетает по шапке.
4. Если всё зелено — сервер сам увеличивает номер версии, собирает приложение и подписывает его нужным ключом.
5. Готовый файл (APK/IPA) автоматически улетает в Firebase App Distribution, TestFlight или прямо в чатик QA.

🛠 Что нужно знать мобильному разработчику (Инструменты):

• Fastlane: Это абсолютный мастхэв индустрии (работает и для iOS, и для Android). Это инструмент, который превращает клики мышкой по настройкам в простой код. Он умеет всё: от сборки до автоматического создания скриншотов для App Store / Google Play.

• GitHub Actions / GitLab CI / Bitrise: Это те самые «облачные серверы» (Runner'ы), которые будут выполнять ваши команды из Fastlane каждый раз, когда вы пушите код.

💡 Правило чистой среды:
Главный плюс CI/CD - код собирается на «чистой» машине. Это навсегда убивает отмазку -А у меня локально всё собирается и работает!". Если код не собрался на CI - значит, он сломан.


#cicd #automation #fastlane #android #ios #middle #githubactions

👉 @developer_mobila