WorkManager не работает в библиотеке, когда клиент вызывает WorkManager.initialize () - PullRequest
1 голос
/ 11 октября 2019

Я пишу библиотеку Android, которая использует WorkManager. Где-то в коде я называю что-то вроде этого:

val uploadTripRequest = OneTimeWorkRequest.Builder(UploadTripWorker::class.java)
    .setConstraints(someConstraints)
    .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, OneTimeWorkRequest.MIN_BACKOFF_MILLIS, TimeUnit.MILLISECONDS)
    .build()

WorkManager.getInstance(context)
    .enqueueUniqueWork(WORKER_NAME, ExistingWorkPolicy.REPLACE, uploadTripRequest)

В моем build.gradle у меня есть: implementation 'androidx.work:work-runtime:2.2.0'

Обычно все работает отлично. Проблемы возникают, когда клиентское приложение вызывает https://developer.android.com/reference/kotlin/androidx/work/WorkManager.html#initialize,, например:

WorkManager.initialize(context, Configuration.Builder().setWorkerFactory(myWorkerFactory).build())

Когда это вызывается, WorkManager из моей библиотеки не работает должным образом. doWork метод не вызывается на моем UploadTripWorker, но он выполняется на рабочем, предоставленном клиентом myWorkerFactory.

С моей точки зрения, WorkManager непригоден для использования в библиотеке, поскольку он является одноэлементным, и кто-то может изменить его поведение с помощью метода initialize. Но я надеюсь, что ошибаюсь.

Можно ли как-нибудь решить эту проблему? Конечно, я не могу сказать всем своим клиентам не использовать метод WorkManager.initialize().

1 Ответ

1 голос
/ 11 октября 2019

WorkManager v2.1 представил класс DelegatingWorkerFactory, который может помочь в этих случаях.

Требуется, чтобы разработчик приложения реализовал его правильно, как вы сказали, WorkManagerявляется одноэлементным.

Ключевым моментом является то, что, если приложение требует пользовательской инициализации и пользовательского WorkerFactory, оно должно использовать DelegatingWorkerFactory, а затем добавить свой собственный WorkerFactory.

Ключевым моментом здесь является то, что WorkerFactory приложения должен проверить имя рабочего класса, чтобы убедиться, что оно правильное (обычно вставляя некоторые параметры в конструктор). Если имя класса не соответствует ожидаемому приложением, оно может просто возвратить ноль, и DelegatingWorkerFactory позаботится о том, чтобы найти правильный рабочий класс для создания экземпляра.

Что-то вроде (в коде приложения):

class MyWorkerFactory(
    private val myInjectedParam: InjectedParam
) : WorkerFactory() {

    override fun createWorker(
        appContext: Context,
        workerClassName: String,
        workerParameters: WorkerParameters
    ): ListenableWorker? {

        return when (workerClassName) {
            MyWorker::class.java.name ->
                MyWorker(appContext, workerParameters, myInjectedParam)
            else ->
                // Return null, so that the base class can delegate to the default WorkerFactory.
                null
        }
    }
}

Затем приложению необходимо добавить этот WorkerFactory в DelegatingWorkerFactory, который он настроил как пользовательский WorkerFactory, используя:

private fun initializeWorkManager (myInjectedParam: MyInjectedParam): WorkManager
{ 
    val appContext = getApplication<MyApplication>()
    val factory = appContext.workManagerConfiguration.workerFactory
            as DelegatingWorkerFactory
    factory.addFactory(MyWorkerFactory(myInjectedParam))

    return WorkManager.getInstance(appContext)
}

В то время как в классе приложения у вас есть:

class MainApplication : Application(), Configuration.Provider {

    val delegatingWorkerFactory: DelegatingWorkerFactory

    // Setup custom configuration for WorkManager with a DelegatingWorkerFactory
    override fun getWorkManagerConfiguration(): Configuration {
        return Configuration.Builder()
            .setMinimumLoggingLevel(android.util.Log.INFO)
            .setWorkerFactory(delegatingWorkerFactory)
            .build()
    }
}
...