我可以将“@ApplicationContext private val appContext: Context”用作将由 Android Studio 中的 Service() 调用的 class 的 DI 吗？

Question

. Answers to this question are eligible for a +50 reputation bounty. HelloCW is looking for an .

I am using Hilt as DI in my Android Studio project.

ServiceTranslate is a Service class that has a longer lifecycle than the app itself. The ServiceTranslate will invoke the TranslateIncompleted class to perform tasks in the background.

1: Currently, I am using @ApplicationContext private val appContext: Context in the TranslateIncompleted class. I believe appContext is an instance of the UIApp class, is that correct?

2: Will the app crash when the app is destroyed but ServiceTranslate continues to run in the background?

class TranslateIncompleted @Inject constructor(
   @ApplicationContext private val appContext: Context       //I'm afriad  that it maybe cause trouble.
): ITranslateIncompleted {

    override suspend fun translateIncompletedAndUpdate() {
        val myString = appContext.getString(R.string.translate_incompleted)        
    }
}


@AndroidEntryPoint
class ServiceTranslate: Service() {

    @Inject lateinit var translateIncompleted: ITranslateIncompleted
 
    inner class MyBinder : Binder() {
        val serviceTranslate: ServiceTranslate
            get() = this@ServiceTranslate
    }

    override fun onBind(intent: Intent): IBinder {
        return MyBinder()
    } 
}


@HiltAndroidApp
class UIApp : Application() {

}

Answer 1

ServiceTranslate is a Service class that has a longer lifecycle than the app itself

I don't think this statement is correct. An instance of Application should always exist if the process is running, which would be the case if the Service is active. Unless you are running your Service in it's own process, using AppContext should be entirely safe, as Service will always have an associated Application. You can validate this by putting a log statement in onDestroy of Application, and confirm that it's not called when the app get's backgrounded in the UI while the Service is still active. Related thread

Alternately, you could sidestep this concern entirely by exposing Service.getResources() on the Service's DI graph. That way, you wouldn't need to depend on the Application Context.