tgoop.com/kotlin_lib/556
Last Update:
Как мы «убили» Application Context, и проект стал чище
В большинстве Android-проектов Application и его Context используются как "корзина" для синглтонов, сервисов, preferences и всего подряд. Это удобно, но быстро превращает код в неуправляемую помойку. В одном из проектов мы решили отказаться от хранения зависимостей в Application, и вот что получилось.
🧩 Проблема
В проекте Application класс использовался для:
* инициализации SDK,
* предоставления доступа к SharedPreferences,
* доступа к репозиториям,
* передачи контекста в ViewModel и утилиты.
Со временем этот "божественный" объект стал точкой ошибок и зависимостей, которые тяжело мокать, тестировать и отслеживать.
✅ Что сделали
1. DI в Application только для инициализации
Application остался, но теперь он инициализирует Dagger/Hilt-модули, не предоставляя никаких данных напрямую.
2. Всё через DI
* Репозитории, UseCase’ы, утилиты — больше не держатся в Application, а инжектятся через Hilt.
* SharedPreferences теперь обёрнуты в провайдер, который зависит от @ApplicationContext и инициализируется DI.
3. ViewModel не знает про контекст
Никаких передач context в конструктор ViewModel. Всё, что нужно, приходит через зависимости. Даже WorkManager задачи создаются через HiltWorkerFactory.
4. Утилиты без статиков
Вынесли "утильные" классы в сервисы или обёртки. Например, AnalyticsTracker стал интерфейсом, имплементация которого инжектится в нужные классы.
🚀 Результат
* Код стал легче тестировать — особенно ViewModel и UseCase.
* Снизили количество «странных» багов, где терялся или менялся context.
* Избавились от синглтонов, создающих утечки памяти.
📌 Вывод
Контекст приложения не должен быть мусорной корзиной. Если у вас в проекте Application весит больше 100 строк — это красный флаг. Попробуйте вынести оттуда всё, что можно заменить инжекцией зависимостей.
✍️ @kotlin_lib
BY Kotlin
Share with your friend now:
tgoop.com/kotlin_lib/556