Am I right that using `runBlocking { }` in a `Sync...

# android

[dave08]

Am I right that using runBlocking { } in a `SyncAdapter`'s onPerformSync or in a Service will crash the application with an InterruptedException (as in https://github.com/Kotlin/kotlinx.coroutines/blob/9be85a44f157cea6bf14b685a87c6709ebd9664b/kotlinx-coroutines-core/jvm/src/Builders.kt#L27 )? What does everyone do about this? Surround it with a runCatching { runBlocking { } } 🙈?

[satyan]

#coroutines + runBlocking means:

Runs a new coroutine and **blocks** the current thread _interruptibly_ until its completion.

Do you really need to block the current thread for your operation ?

Can’t you use a coroutine scope (scoped to service lifecycle) to run your job ?

[satyan]

+ SyncAdapter seems to be deprecated.
You should use a WorkManager instead (A CoroutineWorkManager even 😏 )

[dave08]

How does the sync adapter know that I finished? I really do need the sync adapter's UI that links the process to a custom Android Account...

[dave08]

But I do the actual process in a WorkManager Worker...

[dave08]

I just need the sync adapter not to schedule a new work until the previous one is finished:

override fun onPerformSync(
			account: Account,
			bundle: Bundle,
			s: String,
			contentProviderClient: ContentProviderClient,
			syncResult: SyncResult
	) = runBlocking {
		i { "Running sync..." }

		val workManager = WorkManager.getInstance(context)

		val syncRequest = OneTimeWorkRequestBuilder<SyncWork>()
				.build()

		workManager.enqueueUniqueWork(
				SYNC_WORK_UNIQUE_NAME, ExistingWorkPolicy.APPEND, syncRequest
		).await()

		syncResult += workManager.getWorkInfosByTagLiveData(SYNC_WORK_UNIQUE_NAME)
				.asFlow().onEach {
					d { "WorkInfo (${syncRequest.id}): $it" }
				}.singleOrNull()?.firstOrNull { it.state.isFinished }?.outputData

		Unit
	}

[dave08]

But if it gets interrupted... it seems to crash.

[louiscad]

It seems? Or it does?

[dave08]

Crashylitics is a bit funny, in this case, I have seen crashes myself, but there are certain crash reports, that I really don't see how it could have crashed there since I used catch all over in those places @louiscad. That's why I said that it seems to crash = according to crashylitics.