Can this be simplified?

Yes, no code is shorter. Sorry for the unhelpful response, but I fail to see any clue on what you want to achieve, and

foo

and

bar

are not helping much. Some observations regarding your snippet still: It seems there's no reason

Bar

should implement

CoroutineScope

. The

async

block in

getAThing

is code smell. It breaks structured concurrency as it doesn't use a local scope and its result is not used. Please, read

async

doc and understand that you rarely need it.

Ok, to give some context,

Foo

is a presenter-type object and it needs to invoke view actions on the main thread.

Bar

is a repository-type object. It needs to make network requests and db queries via the appropriate interfaces. Those kinds of transactions have to happen off the main thread. Some network objects need additional network requests made in order coalesce multiple data sources. I need the original result immediately displayed to the screen and continue to resolve the extra requests in the background, invoking view updates using

action

. I’m using

async

to force the extra calls to be made asynchronously.

Why not rename Foo and Bar too to something more meaningful?

Renamed. Hopefully that helps

What is

action

supposed to do?

I pass it in in the

doWork

fun in

Presenter

You can just drop that lambda and update the view after calling the suspending function

I won’t have the reference to the new

Thing

type object

I'd probably recommend

val thing = db.getThing() ?: network.getThing()

instead of

var thing ...

The

network.getThing()

portion is vastly over simplified in this example. I was hoping to get more input on the way I've organized coroutines in this example.

Can you just return the updated thing? Then just use the return value instead of a call back?

@uli

Thing

is a list that can have hundreds of entries and

updateThing

has to do a network call for each thing. I want the view to be updated as each entry is resolved, rather than wait for potentially hundreds of network calls to resolve.

But this is not what your code does. It calculates the full update and only then passes it as parameter to

action

@uli You’re right, I changed it to reflect what the codebase actually performs. Do you recommend that I pass the channel in that I would publish to?

You could, but why do you return

thing

from all methods. In the end the return value seem unused. Instead you could return a freshly created channel.

Or return a Flow

unfortunately this is a production application and I can’t risk implementing preview features in it