WorkManager init conflict error

[mmw-andreig]

After implementing ExponeaSDK there is an error with initialisation of ContentWorker that was used in the app, before the SDK implementation.
From what I see, SDK also uses the WorkManager dependency..
In case I comment Exponea.init(context, configuration), there is no issue at all.

From what I see, it's not recommended to use WorkManager.initialize(context, configuration) directly, and that was found in the source code.

What do you think? Is this something that you can fix on your end?

Could not instantiate com.myapp.app.content_synchronizer.ContentWorker
                                                                                                    java.lang.NoSuchMethodException: com.myapp.app.content_synchronizer.ContentWorker.<init> [class android.content.Context, class androidx.work.WorkerParameters]
                                                                                                    	at java.lang.Class.getConstructor0(Class.java:3395)
                                                                                                    	at java.lang.Class.getDeclaredConstructor(Class.java:3077)
                                                                                                    	at androidx.work.WorkerFactory.createWorkerWithDefaultFallback(WorkerFactory.java:94)
                                                                                                    	at androidx.work.impl.WorkerWrapper.runWorker(WorkerWrapper.java:243)
                                                                                                    	at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:144)
                                                                                                    	at androidx.work.impl.utils.SerialExecutorImpl$Task.run(SerialExecutorImpl.java:96)
                                                                                                    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
                                                                                                    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
                                                                                                    	at java.lang.Thread.run(Thread.java:1012)
WM-WorkerWrapper        com.myapp.app.sandbox        E  Could not create Worker com.myapp.app.content_synchronizer.ContentWorker

[adam1929]

Hi @mmw-andreig thanks for report.
This issue is 99% caused by different WorkManager version. What is yours please?
After that info from you, we are able to tell more.
Thank you

[mmw-andreig]

Hi @adam1929
WorkManager version is "androidx.work:work-runtime-ktx:2.9.0", but I tried to downgrade to 2.7.1 and still issue is the same
Thank you

[adam1929]

Hi @mmw-andreig thanks.
Unfortunatelly, I was able to run application with Workmanager of version 2.9.0 and also 2.10.0 without problem. With and without auto-init.
That WorkManager.initialize method is effectively used only if your app turned off auto-init for WorkManager. If you allow auto-init (default behaviour), that method returns error that WorkManager is already initialized. That error is catched by SDK.

Anyway, could you please share your implementation of ContentWorker ? Class structure is enough, implementation of doWork method is not required for analysis.
As stacktrace wrotes, class loader was unable to find constructor of ContentWorker class for context and WorkerParameters.
You may validate it against our implementation of ExponeaSessionEndWorker. It is working normally for all version of WorkManager.

Thanks

[mmw-andreig]

@adam1929
Hey, sure, here the ContentWorker implementation

@HiltWorker
class ContentWorker @AssistedInject constructor(
    @Assisted val appContext: Context,
    @Assisted val workerParams: WorkerParameters,
    private val contentSynchronizer: ContentSynchronizer
) : CoroutineWorker(appContext, workerParams) {

    override suspend fun doWork(): Result {
        contentSynchronizer.syncContent()
        return Result.success()
    }
}

[adam1929]

Great @mmw-andreig
I was able to use your class definition except ContentSynchronizer. I assume that this is your class. Anyway, how do you initialize WorkManager in your app?
I think that there is no problem with version of WorkManager but incompatibility how is it initialized.

[mmw-andreig]

But I don't get, why its initialised fine without Exponea SDK usage, but when I init SDK the WorkManager is giving an error.
We use hilt, so its not initialised manually.
Here the providing methods:

    @Provides
    fun provideContentWorkerUtil(workManager: WorkManager) = ContentWorkerUtil(workManager)

class ContentWorkerUtil(private val workManager: WorkManager) {

    fun startWork() {
        workManager.beginUniqueWork(
            "contentWorkerJobId",
            ExistingWorkPolicy.KEEP,
            OneTimeWorkRequest
                .Builder(ContentWorker::class.java)
                .build()
        ).enqueue()
    }
}

[adam1929]

We have no deep experiences with Hilt; plus as it is 'dependency injection' library it may generate some source code on its own. I believe that Exponea SDK init runs sooner than WorkManager is initialised by your app (and your configuration, Hilt env, etc.).
Could you turn off automatic WorkManager initialisation, invoke manual one, and then run SDK init?
This could help you: https://medium.com/@santimattius/workmanager-with-hilt-and-app-startup-80b34062e144
As you already saw, SDK is trying to init WorkManager with default (empty) configuration. Therefore I think that Hilt requires some non-default configuration and it has to be configured before SDK init.

[mmw-alex]

Hi @adam1929
I've added a basic implementation of Hilt and WorkManager without introducing anything complex.
You can check it out here: exponea-android-sdk PR #82 – it's based on my fork of your demo app and SDK usage.

In AuthenticationActivity, if you comment out the call to initSdk(), the Worker initializes without any issues.
Similarly, if you remove private val testRepo: TestRepo from the constructor of TestWorker, everything still works fine.

This suggests that the SDK might be doing something with WorkManager internally, which could be affecting dependency injection behavior.

[adam1929]

Thank you @mmw-andreig and @mmw-alex for reporting and light example. We need do more deep hilt-compatibility-investigation to bring solution or guidance for this case.
Please report this issue to Bloomreach support or via your CMS. We'll ask more details.
Thank you.