Kênh Telegram "Мобильная разработка #1"

Мобильная разработка #1

Public

Chú ý : Điều quan trọng là phải tự nghiên cứu trước khi tin tưởng vào bất kỳ thông tin nào, đặc biệt nếu có yêu cầu liên quan đến tiền bạc.

Không thể tham gia? @developer_mobila

3.9k Thành viên

Cập nhật: March 11, 2026 at 9:52 AM

Мобильная разработка #1

Всё о создании приложений под Android и iOS в одном месте. 🔹 Инструменты, библиотеки и ресурсы для ускорения работы. 🔹 Статьи и гайды для разработчиков любого уровня. 🔹 Тренды мобильной разработки и новости индустрии. Реклама @evgenycarter

Join @developer_mobila for exclusive android and evgenycarter content and discussions in 12

Xếp hạng

Xếp hạng toàn cầu

#14456

-1

Xếp hạng ngôn ngữ

#10061

-1

Xếp hạng danh mục

#37Không thay đổi

Tăng trưởng người đăng ký (Trong 2 ngày qua)

Tổng cộng: 3.9K

Tăng trưởng 24 giờ: -4 0%

Bài đăng gần đây

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

💉 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

👉

622

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

🏎 Гонка потоков: Баг, который исчезает, когда вы пытаетесь его найти

Представьте ситуацию: у вас на банковском счете 100$. Вы и ваша жена одновременно (в одну миллисекунду) пытаетесь снять 10$ через разные банкоматы.
В теории должно остаться 80$.
На практике, из-за Race Condition, может остаться 90$. Банк потерял деньги. 💸

Почему так происходит?
Даже простая операция count++ (увеличение счетчика) для процессора - это три действия:

1. Считать текущее значение (100).
2. Прибавить единицу (101).
3. Записать новое значение (101).

Если два потока начнут выполнять шаг 1 одновременно, они оба "увидят" 100. Оба прибавят 1 и запишут 101. Одно действие потеряется навсегда.

🐛 Heisenbug (Гейзенбаг):
Самое страшное в гонках то, что они часто исчезают, когда вы начинаете дебажить (добавляете print или брейкпоинты), так как это меняет тайминги выполнения потоков.

🛡 Как защититься (Инструменты Мидла):

🤖 Android (Kotlin):

🔵Atomic-типы: Для простых счетчиков используйте AtomicInteger или AtomicBoolean. Они гарантируют атомарность операций.

🔵Mutex (для Coroutines): Это "светофор" для корутин.

val mutex = Mutex()
mutex.withLock {
// Код здесь выполняется только одним потоком за раз
count++
}

• StateFlow: Позволяет безопасно обновлять состояние UI, избегая гонок.

🍏 iOS (Swift):

• Actors (Swift 5.5+): В 2026 году это стандарт. Акторы автоматически защищают свое изменяемое состояние. Вам не нужны ручные блокировки.

actor BankAccount {
var balance = 100
func withdraw(amount: Int) { balance -= amount }
}

• Serial Queues (GCD): Старая добрая очередь, где задачи выполняются строго по одной.

💡 Совет: Если у вас в приложении есть переменная var, которую меняют из разных фоновых потоков, это бомба замедленного действия. Заверните её в Atomic, Mutex или Actor.

Сталкивались с багами, которые невозможно повторить на устройстве разработчика? 👇

#concurrency #multithreading #android #ios #kotlin #swift #bugs

👉

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

Холодный старт (Cold Start) и как не заставлять пользователя ждать.

🕓 Правило 3 секунд: Почему ваше приложение удаляют сразу после установки

Знаете ли вы, что 53% пользователей закрывают и удаляют приложение, если оно грузится дольше 3 секунд?

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

В итоге пользователь видит белый экран или зависшее лого на 5 секунд. Это Холодный старт (Cold Start) - момент, когда система создает процесс вашего приложения с нуля.

🛑 Главные убийцы скорости:

1. Тяжелый Application.onCreate (Android) / didFinishLaunching (iOS).
Если вы инициализируете 15 библиотек в главном потоке (Main Thread) до того, как покажется первый экран - вы тормозите запуск.

2. Фейковые Сплэш-экраны.
Никогда (слышите, никогда!) не делайте Thread.sleep(2000) или таймер на стартовом экране, «чтобы пользователь успел разглядеть логотип». Это бесит.

🚀 Как ускорить запуск (Чек-лист Мидла):

✅ Ленивая загрузка (Lazy Init):
Инициализируйте тяжелые библиотеки (например, чаты поддержки или карты) только тогда, когда пользователь реально открывает нужный экран, а не при старте.

✅ Фоновые потоки:
Если библиотеку нужно загрузить сразу, делайте это в Coroutines (Dispatchers. IO) или DispatchQueue.global(). Главный поток должен заниматься только отрисовкой UI.

✅ Правильный Splash Screen:

🔵🤖 Android: Используйте официальный androidx.core:core-splashscreen. Он нативен, красив и работает мгновенно, пока грузится ваш процесс.

🔵🍎 iOS: Сделайте LaunchScreen.storyboard максимально легким. Никакого кода, только статика.

🛠 Как измерить:
Не считайте «на глаз»!

🔵Android: В логах (Logcat) ищите строку Displayed. Там система сама пишет: ActivityManager: Displayed com.app/. StartActivity: +850ms.

🔵iOS: В Xcode зайдите в Product -> Profile -> App Launch. Instruments покажут каждый миллисекунду задержки.

А вы следите за временем запуска или надеетесь на мощные смартфоны пользователей? 👇

#performance #optimization #android #ios #coldstart #middle

👉

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

🔐 Вы только что подарили хакерам доступ. Где НЕЛЬЗЯ хранить ключи

Классическая история: вы пишете пет-проект, используете API (например, ChatGPT или Firebase), и пишете прямо в коде:
val apiKey = "sk-proj-12345..."

Потом git push, и вы идете спать.
А утром ваш ключ заблокирован, или с карты списали деньги за чужой трафик.

🤖 Реальность: Боты сканируют публичные репозитории GitHub на наличие строк, похожих на ключи, за секунды после публикации. Удалить коммит не поможет, он уже в кеше у злоумышленников.

Как делать правильно (Middle Way):

Секреты никогда не должны попадать в систему контроля версий (Git). Они должны жить только локально на вашем компьютере.

🤖 Android:
Используйте файл local.properties. Он по умолчанию добавлен в .gitignore.

1. Откройте local.properties и добавьте: MY_API_KEY="ваш_ключ".

2. В build.gradle (app) считайте его и прокиньте в код:

defaultConfig {
buildConfigField("String", "API_KEY", gradleLocalProperties(rootDir).getProperty("MY_API_KEY"))
}

3. В коде используйте: BuildConfig. API_KEY.

🍏 iOS:
Вариантов много, но самый простой для старта:

1. Создайте файл Secrets.xcconfig (или .plist).
2. Сразу же добавьте его в .gitignore.
3. Запишите ключ туда.
4. В настройках проекта (Build Settings) подключите этот конфиг или считывайте файл программно.

🛡 Золотое правило:
Если вы клонируете свой проект на чистый ноутбук, он не должен собраться сразу. Он должен попросить вас создать локальный файл с ключами. Это не баг, это безопасность.

Признавайтесь, случалось случайно комитить пароли или токены? 👇

#security #android #ios #git #tips #middle #safety

👉

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

🧹 Убираем за собой: Как не опозориться при Code Review

Знакомая ситуация? Вы работали над фичей, сделали 10 коммитов с названиями:

🔵init
🔵wip
🔵fix crash
🔵fix typo
🔵aaaaa rabotay pls

А потом отправляете это в Pull Request. Тимлид открывает историю и… плачет кровавыми слезами. 🩸

Отличное правило хорошего тона: «Ветка может быть грязной, пока она локальна. Но в main должен уйти чистый и атомарный код».

Вам нужен Git Interactive Rebase. Это магия, которая позволяет переписать историю.

🛠 Как это сделать (Консоль / IDE):

Допустим, вы хотите объединить последние 5 мелких коммитов в один красивый.

1. Пишем в терминале: git rebase -i HEAD~5
2. Откроется редактор со списком ваших коммитов. Перед каждым стоит слово pick.
3. Меняем команды:
🔵Оставляем pick у самого первого (верхнего) коммита.
🔵У остальных меняем pick на squash (или s) - это значит «сплющить» этот коммит с предыдущим.
🔵Если хотите переименовать - используйте reword.


4. Сохраняем и закрываем. Git предложит написать одно общее сообщение для нового «супер-коммита».
5. Отправляем на сервер: git push --force (Осторожно! Делайте это только в своей ветке, пока никто другой в ней не работает).

💡 Результат:
Вместо 5 мусорных записей у вас одна красивая: Feature: Added dark mode implementation.

Коллеги на ревью скажут спасибо:
✅ Проще читать изменения.
✅ Если баг - проще откатить один коммит, чем искать в куче мелких.

А вы используете Rebase или предпочитаете честную историю со всеми «фиксами»? 👇

#git #teamwork #middle #tips #tools #bestpractices

👉

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

🍝 Ваш код похож на спагетти? Синдром «Божественного объекта»

Знакомая картина: открываешь проект, заходишь в MainActivity или ProfileViewController, а там... 1500 строк кода. 😱

Там и работа с сетью, и валидация полей, и анимации, и сохранение в базу, и даже форматирование даты. В мире разработки это называется God Object (или Massive View Controller).

Почему это плохо?

1. Невозможно тестировать. Как написать юнит-тест на класс, который делает всё?
2. Сложно менять. Поправил верстку — сломалась база данных.
3. Конфликты при слиянии. В команде двое разработчиков полезли в этот файл — здравствуй, merge conflict на полдня.

🚀 Как лечить (Гайд для перехода в Middle):

Если видишь класс больше 300-400 строк, начинай «резню»:

1. ✂️ Всю логику сети - в Repository.
Во View/Activity не должно быть http-клиентов и JSON-парсинга. Она должна просто сказать: repository.getUsers() и показать спиннер.

2. ✂️ Всю бизнес-логику - в UseCases (Интеракторы).
Валидация пароля, подсчет корзины, фильтрация списков - это чистая логика. Выносите её в отдельные классы (PasswordValidator, CartCalculator).

3. ✂️ Сложный UI - в Custom Views / Child ViewControllers.
Если у вас в адаптере списка 500 строк кода настройки ячеек - вынесите ячейку в отдельный класс с методом bind(data).

💡 Правило одной ответственности (SRP):
Класс должен иметь только одну причину для изменения.

🔵Если дизайнер поменял цвет кнопок - меняем только View.
🔵Если бэкенд поменял формат JSON, меняем только DTO/Repository.
🔵Если эти изменения заставляют вас править один и тот же файл, у вас архитектурная проблема.

🏁 Задание на неделю:
Найдите самый «жирный» класс в своем проекте и попытайтесь вынести из него хотя бы одну функцию в отдельный вспомогательный класс. Ваш код скажет вам спасибо.

Сколько строк в самом большом файле вашего текущего проекта? Пишите честно 👇

#architecture #cleanCode #refactoring #middle #android #ios

👉

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

👆 Почему пользователи ненавидят ваши кнопки (даже если они красивые)

Знакомая ситуация: вы сверстали экран идеально по макету. Иконка «Закрыть» (крестик) - ровно 24x24, как нарисовал дизайнер.
Но пользователи бесятся, тыкая в нее по 5 раз, и не могут попасть.

Это классическая ошибка новичка: путать видимый размер и кликабельную область.

В гайдлайнах (HIG и Material Design) написано кровью:
🔴 Минимальная область нажатия:

🔵🍎 iOS: 44x44 pt
🔵🤖 Android: 48x48 dp

Если ваша иконка меньше (например, 24x24), вы обязаны искусственно увеличить область нажатия, не меняя визуал.

Как это сделать грамотно:

🤖 Android (Compose & XML):

🔵Compose: Используйте модификатор .minimumInteractiveComponentSize(). Он сам добавит невидимые отступы, чтобы дотянуть размер до 48dp.

🔵XML: Добавьте padding="12dp" к самому ImageView или оберните его в прозрачный контейнер, на который повесьте клик. Не используйте TouchDelegate без крайней нужды, это больно.

🍏 iOS (SwiftUI & UIKit):

🔵SwiftUI: Распространенная ошибка — вешать .onTapGesture на маленькую иконку.

🔵Плохо: Image("close").onTapGesture { ... }

🔵Хорошо: Image("close").frame(width: 44, height: 44).contentShape(Rectangle()).onTapGesture { ... } (мы делаем прозрачную рамку вокруг).

🔵UIKit: Переопределите метод point(inside:with:) в кнопке, чтобы она ловила касания за своими пределами.

💡 Лайфхак:
Включите в настройках разработчика на телефоне «Показывать границы элементов» (Show layout bounds). Если вы видите маленькие прямоугольники вокруг кнопок, это повод для рефакторинга.

Заботьтесь о пальцах своих пользователей! А вы спорите с дизайнерами, когда они рисуют слишком мелкие элементы? 👇

#ux #ui #android #ios #tips #mobile #design

👉

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

☠️ Баг, который вы не видите, а пользователи ненавидят

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

Это System-initiated process death. Самая частая причина удаления приложения у пользователей и головная боль разработчиков.

Почему это происходит?
ОС (Android или iOS) всегда не хватает оперативной памяти. Когда ваше приложение уходит в фон, система может «тихо» убить его процесс, чтобы освободить ресурсы для активного окна (например, Камеры).

❌ Ошибка новичка:
«Я храню данные в ViewModel (Android) или в переменной контроллера (iOS), они же живут долго!»
Реальность: ViewModel переживает поворот экрана, но умирает вместе с процессом. Синглтоны тоже сбрасываются.

✅ Как делать правильно (Level Up):

🤖 Android:
Перестаньте полагаться только на поля класса. Используйте SavedStateHandle.
Это специальный механизм внутри ViewModel, который сохраняет небольшие кусочки данных (ID, поисковый запрос, ввод пользователя) в системный бандл. Система бережно восстановит его даже после смерти процесса.
Гуглить: SavedStateHandle, Parcelable.

🍏 iOS (SwiftUI/UIKit):
В SwiftUI для простых данных (например, выбранная вкладка или текст) используйте обертку @SceneStorage. Она автоматически сохраняет и восстанавливает состояние.
Для сложных данных — сохраняйте их в локальную БД (CoreData/Realm/SwiftData) при каждом изменении, а не при закрытии экрана.

🛠 Как проверить себя (Челлендж на 5 минут):
Не верьте эмулятору. Проверьте свой текущий проект прямо сейчас:

1. Запустите приложение и введите данные в любое поле.
2. Сверните приложение (Home).
3. Android: В настройках разработчика включите опцию «Don't keep activities» (Не сохранять действия).
4. iOS: В Xcode нажмите Debug -> Simulate Memory Warning или остановите дебаг и запустите другое тяжелое приложение.
5. Вернитесь в свое приложение.

Если данные исчезли или случился краш, поздравляю, вы нашли критический баг. Время фиксить!

Знали про SavedStateHandle или по старинке сохраняли всё в базу данных? 👇

#android #ios #bugs #middle #architecture #обучение

👉

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

🛑 Хватит спамить принтами! Дебажим как профи

Признавайтесь, делали так?
У вас есть цикл на 100 элементов, и ошибка вылетает только на 87-м. Вы ставите обычный брейкпоинт и 86 раз яростно жмете «Resume Program» (▶️), проклиная всё на свете, пока не дойдете до нужного состояния.

Или еще хуже:
Log.d("TAG", "Я тут")
Log.d("TAG", "А теперь тут, значение i = $i")

Есть способ элегантнее, который отличает опытного разработчика от новичка - Conditional Breakpoints (Условные точки останова).

Они останавливают выполнение программы только тогда, когда выполняется определенное условие.

Как это сделать за 5 секунд:

🤖 Android Studio (IntelliJ IDEA):

1. Поставьте обычный красный брейкпоинт.
2. Нажмите на него правой кнопкой мыши.
3. В поле "Condition" напишите условие на языке Kotlin/Java.
Пример: item.id == 87 или user.name.contains("Test") && i > 50
4. Готово! Студия проигнорирует первые 86 итераций и остановится точно там, где нужно.

🍎 Xcode:

1. Поставьте синий брейкпоинт.
2. Нажмите на него правой кнопкой (или двойной клик) -> "Edit Breakpoint".
3. В поле "Condition" пишите условие на Swift.
Пример: indexPath.row == 87

💡 Бонус-фича для тех, кто не любит останавливаться:
В настройках брейкпоинта уберите галочку Suspend (Остановить) и поставьте галочку Log Message (Evaluate and log).
Теперь IDE будет сама писать в консоль значения переменных при прохождении этой точки, не останавливая приложение. Это те же принты, только вам не нужно пачкать ими код и пересобирать проект!

Какая ваша любимая фишка дебаггера, о которой мало кто знает? Делитесь в комментариях 👇

#productivity #androidstudio #xcode #debug #tips #middle

👉

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

🛠 Хватит писать To-Do листы! Топ бесплатных API для твоего портфолио

Рекрутеры видят сотни «списков задач» и «калькуляторов». Чтобы выделиться, нужно показать работу с сетью, сложным UI, кэшированием и картинками.

Лучший способ это сделать - написать клиент для реального API. Вот подборка бесплатных, стабильных и открытых API, на которых можно построить крутой проект:

🎬 1. The Movie DB (TMDB)

🔵 Что там: Огромная база фильмов, актеров, рейтингов и постеров.
🔵 Чему научишься: Работать со сложными списками (RecyclerView/LazyColumn), пагинацией, поиском и загрузкой изображений (Glide/Coil/Kingfisher).
🔵 Идея: Клон Netflix или «Кинопоиска».

🚀 2. NASA Open APIs

🔵 Что там: Фото дня (APOD), данные о Марсе, астероидах.
🔵 Чему научишься: Работать с красивым медиа-контентом и датами.
🔵 Идея: Приложение «Космос сегодня» с ежедневными уведомлениями.

3. PokéAPI

🔵 Что там: Всё о покемонах. Полностью открытое, не требует ключа (Auth Key).
🔵 Чему научишься: Архитектуре. Данные хорошо структурированы, идеально для тренировки Clean Architecture и маппинга JSON в модели.
🔵 Идея: «Покедекс» с детальной информацией и статами.

📈 4. CoinGecko API

🔵 Что там: Курсы криптовалют в реальном времени.
🔵 Чему научишься: Работать с Websockets (если найдешь) или частым обновлением данных, рисовать графики.
🔵 Идея: Трекер портфеля крипты.

💡 Совет ментора: Не пытайтесь сделать всё сразу. Возьмите один экран (например, список популярных фильмов) и сделайте его идеально: с обработкой ошибок («нет интернета»), скелетоном при загрузке и красивой анимацией. Это ценнее, чем кривое, но большое приложение.

Сохраняй подборку, чтобы не потерять! А какое API вы использовали в своем последнем проекте? 👇

#ресурсы #api #петпроект #ideas #android #ios

👉

Мобильная разработка #1

11:46 10 thg 3, 2026

📷 Photo

🤖 Хватит быть «человеком-компилятором» на Code Review

Вам знакомо это чувство, когда вы открываете Pull Request коллеги, и вместо того, чтобы проверять логику, пишете:

🔵«Тут лишний пробел»
🔵«Название функции с большой буквы?»
🔵«Удали неиспользуемый импорт»

Это трата дорогого времени разработчика. Эти споры (Tab vs Space, где ставить фигурную скобку) должны решать роботы, а не люди.

В 2026 году стыдно не иметь настроенный Linter (Линтер) в проекте.

🛠 Что подключить прямо сейчас:

🤖 Android (Kotlin):

1. Ktlint: Следит за стилем кода (официальный Kotlin Style Guide). Умеет сам форматировать файл по команде (./gradlew ktlintFormat). Больше никаких споров о пробелах.

2. Detekt: Это уже тяжелая артиллерия. Он ищет не просто кривые отступы, а потенциальные баги: слишком сложные функции, магические числа, пустые блоки catch.

🍏 iOS (Swift):

1. SwiftLint: Стандарт индустрии. Настраивается через .swiftlint.yml. Может кидать Warning (желтое) или Error (красное), если код не соответствует правилам команды.
🔵Пример правила: force_cast (запрет на использование as!), line_length (длина строки).

🚀 Уровень Pro (Git Hooks):
Настройте Pre-commit hook.
Это скрипт, который запускает линтер до того, как коммит вообще создастся.
Если линтер найдет ошибку - Git просто не даст сделать коммит.
Итог: В репозиторий физически невозможно запушить «грязный» код.

💡Договоритесь с командой о правилах один раз, запишите их в конфиг линтера и забудьте. Code Review должен быть про архитектуру и надежность, а не про красоту текста.

У вас в проекте стоит жесткий запрет на варнинги (Treat warnings as errors) или «пусть висят»? 👇

#ci #quality #detekt #swiftlint #ktlint #automation #middle

👉

Showing 11 of 11 posts

No more posts

Loading posts...

Xếp hạng

Yêu cầu đăng nhập

Đánh giá của người dùng (0)

Chưa có đánh giá nào. Hãy là người đầu tiên chia sẻ trải nghiệm của bạn!

Loading reviews...

Мобильная разработка #1

Join @developer_mobila for exclusive android and evgenycarter content and discussions in 12

Xếp hạng

Xếp hạng toàn cầu

#14456

-1

Xếp hạng ngôn ngữ

#10061

-1

Xếp hạng danh mục

#37Không thay đổi

Tăng trưởng người đăng ký (Trong 2 ngày qua)

Tổng cộng: 3.9K

Tăng trưởng 24 giờ: -4 0%

Bài đăng gần đây

Мобильная разработка #1

17:32 11 thg 3, 2026

📷 Photo

💉 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

👉

Loading posts...