В большинстве 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