Как правильно работать с Context в зависимостях - принимать извне или создавать внутри класса

Правильная работа с Context в Android-зависимостях

Работа с Context в Android — один из фундаментальных аспектов разработки, от которого зависит стабильность, производительность и тестируемость приложения. Выбор между принятием Context извне и созданием внутри класса имеет серьезные архитектурные последствия.

Основной принцип: всегда принимать Context извне

Контекст должен передаваться в зависимости как внешний параметр, а не создаваться или храниться внутри класса. Это следует принципу Dependency Injection (внедрение зависимостей) и обеспечивает:

1. Тестируемость — можно передавать тестовые реализации Context (например, ApplicationContext для тестов)
2. Контроль жизненного цикла — предотвращение утечек памяти
3. Гибкость — класс не зависит от конкретного типа Context
4. Чистую архитектуру — соблюдение принципа инверсии зависимостей (DIP)

Почему НЕЛЬЗЯ создавать Context внутри класса

Создание или получение Context внутри класса через getApplicationContext(), getContext() или статические методы приводит к проблемам:

// ПЛОХОЙ ПРИМЕР - Context создается внутри класса
class UserRepository {
    private val context: Context = MyApplication.applicationContext
    
    fun saveUser(user: User) {
        val prefs = context.getSharedPreferences("app", Context.MODE_PRIVATE)
        // ... использование prefs
    }
}

Проблемы такого подхода: -android

1. Утечки памяти — если сохраняется Activity Context вместо Application Context
2. Сложность тестирования — класс жестко завязан на глобальное состояние
3. Нарушение принципа единственной ответственности — класс занимается получением зависимостей
4. Проблемы с жизненным циклом — Context может быть уничтожен раньше класса

Правильный подход: внедрение Context через конструктор или метод

// ХОРОШИЙ ПРИМЕР - Context передается извне
class UserRepository(private val appContext: Context) {
    
    init {
        // Валидация типа Context
        require(appContext.applicationContext != null) {
            "Expected Application Context"
        }
    }
    
    fun saveUser(user: User) {
        val prefs = appContext.getSharedPreferences("app", Context.MODE_PRIVATE)
        // ... использование prefs
    }
}

// Использование с Dependency Injection (например, Dagger/Hilt)
@Module
@InstallIn(SingletonComponent::class)
object AppModule {
    
    @Provides
    @Singleton
    fun provideUserRepository(
        @ApplicationContext appContext: Context
    ): UserRepository {
        return UserRepository(appContext)
    }
}

Ключевые рекомендации по работе с Context

1. Выбор правильного типа Context

• Для долгоживущих компонентов (репозитории, сервисы) используйте Application Context
• Для UI-компонентов с коротким жизненным циклом можно использовать Activity Context, но с осторожностью

class SoundPlayer(
    // Всегда использовать Application Context для долгоживущих компонентов
    @ApplicationContext private val appContext: Context
) {
    fun playSound(resId: Int) {
        MediaPlayer.create(appContext, resId).start()
    }
}

2. Использование DI-Backbone с учетом жизненного цикла

При использовании Dagger/Hilt или Koin:

// Hilt пример с разными скоупами Context
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    
    // Для Activity скоупа
    @ActivityContext
    @Inject lateinit var activityContext: Context
    
    // Для Application скоупа  
    @ApplicationContext
    @Inject lateinit var appContext: Context
}

// ViewModel с SavedStateHandle
class MyViewModel(
    private val savedStateHandle: SavedStateHandle,
    private val userRepository: UserRepository // с внедренным Context
) : ViewModel()

3. Паттерны для безопасной работы с Context

// Обертка для безопасного доступа к Resources
class ResourceProvider(private val appContext: Context) {
    fun getString(@StringRes resId: Int): String {
        return appContext.getString(resId)
    }
    
    fun getColor(@ColorRes resId: Int): Int {
        return ContextCompat.getColor(appContext, resId)
    }
}

// Использование WeakReference для временного хранения Context
class ContextAwareComponent(context: Context) {
    private val weakContext = WeakReference(context)
    
    fun doWork() {
        val context = weakContext.get() ?: return
        // безопасная работа с Context
    }
}

4. Архитектурные подходы

• Clean Architecture: Context остается во внешних слоях (Data, Presentation)
• MVVM/MVI: ViewModel не должна содержать Context, используйте UseCase/Repository
• Compose: предпочитайте LocalContext.current с учетом recomposition

Исключения из правила

Бывают случаи, когда получение Context внутри класса допустимо:

1. View и кастомные UI-компоненты — имеют доступ к Context через getContext()
2. BroadcastReceiver — Context передается в onReceive()
3. Service — имеют собственный Context
4. ContentProvider — доступ через getContext()

// Допустимое получение Context внутри View
class CustomView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null
) : View(context, attrs) {
    
    // Можно использовать переданный context
    private val typedArray = context.obtainStyledAttributes(attrs, R.styleable.CustomView)
}

Заключение

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

• Предсказуемое поведение компонентов
• Легкость тестирования и замены зависимостей
• Отсутствие утечек памяти
• Соблюдение современных архитектурных принципов

Для Android-приложений используйте Dagger Hilt или Koin для автоматического управления Context с правильными скоупами. Помните: Context — это системный ресурс с жизненным циклом, и неправильное обращение с ним является одной из самых частых причин проблем в Android – приложениях.