ടെലിഗ്രാം ചാനൽ "Мобильная разработка #1"

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

Public

ശ്രദ്ധിക്കുക : ഏതെങ്കിലും വിവരങ്ങളിൽ, പ്രത്യേകിച്ച് പണം ആവശ്യപ്പെടുന്ന സന്ദർഭങ്ങളിൽ, വിശ്വസിക്കുന്നതിനുമുമ്പ് സ്വന്തം നിലയ്ക്ക് ഗവേഷണം നടത്തുന്നത് പ്രധാനമാണ്.

ചേരാൻ കഴിയുന്നില്ലേ? @developer_mobila

3.9k അംഗങ്ങൾ

അപ്ഡേറ്റ് ചെയ്തത്: March 11, 2026 at 9:52 AM

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

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

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

റാങ്കിംഗ്

ഗ്ലോബൽ റാങ്കിംഗ്

#14456

-1

ഭാഷാ റാങ്കിംഗ്

#10061

-1

വിഭാഗ റാങ്കിംഗ്

#37മാറ്റമില്ല

വരിക്കാരുടെ വളർച്ച (കഴിഞ്ഞ 2 ദിവസങ്ങൾ)

ആകെ: 3.9K

24h വളർച്ച: -4 0%

ഏറ്റവും പുതിയ പോസ്റ്റുകൾ

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

११ मार्च, २०२६, ०५:३२ PM

📷 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

११ मार्च, २०२६, ०५:३२ PM

📷 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

११ मार्च, २०२६, ०५:३२ PM

📷 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

११ मार्च, २०२६, ०५:३२ PM

📷 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

११ मार्च, २०२६, ०५:३२ PM

📷 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

११ मार्च, २०२६, ०५:३२ PM

📷 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

११ मार्च, २०२६, ०५:३२ PM

📷 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

११ मार्च, २०२६, ०५:३२ PM

📷 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

११ मार्च, २०२६, ०५:३२ PM

📷 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

११ मार्च, २०२६, ०५:३२ PM

📷 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

१० मार्च, २०२६, ११:४६ AM

📷 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...

റേറ്റിംഗ്

ലോഗിൻ ആവശ്യമാണ്

ഉപയോക്തൃ അവലോകനങ്ങൾ (0)

അവലോകനങ്ങൾ ഒന്നും ലഭ്യമല്ല. നിങ്ങളുടെ അനുഭവം പങ്കുവെക്കുന്ന ആദ്യത്തെയാളാകൂ!

Loading reviews...

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

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

റാങ്കിംഗ്

ഗ്ലോബൽ റാങ്കിംഗ്

#14456

-1

ഭാഷാ റാങ്കിംഗ്

#10061

-1

വിഭാഗ റാങ്കിംഗ്

#37മാറ്റമില്ല

വരിക്കാരുടെ വളർച്ച (കഴിഞ്ഞ 2 ദിവസങ്ങൾ)

ആകെ: 3.9K

24h വളർച്ച: -4 0%

ഏറ്റവും പുതിയ പോസ്റ്റുകൾ

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

११ मार्च, २०२६, ०५:३२ PM

📷 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...