Just sharing this here for anyone who needs a hack...

# multiplatform

[Brendan Weinstein]

Just sharing this here for anyone who needs a hacky workaround to make network calls with multi-threaded coroutines until ktor resolves the mutability bugs.

[russhwolf]

Seems a little heavy to pull in alamofire for this on the iOS side. If you stick to platform APIs and keep things at the kotlin level you might be able to have your common interface be a suspend function. That would let you avoid the runBlocking on the Android side and keep your common API closer to what it will look like after ktor is ready.

[russhwolf]

But generally, the strategy of wrapping things at a higher level like this to work around limitations is a good one, and it doesn't get talked about enough

[Brendan Weinstein]

Agreed on alamofire being overkill -- I am overly avoiding objective-c to my own detriment. I have gradle setup now so I can access AFNetworking just fine from ios sourcesets within the common/shared module, so I'll get around to updating this.

Definitely wanted to share this because it's a bit different than using expect/actual and I've been kind of holding my breath on ktor. Now I feel like I have a recipe for quickly handling platform-specific dependencies. I've done this for wrapping a glide+nuke ImagePreloader dependency and workmanager+swiftqueuemanager WorkManager dependency.

[kpgalligan]

I’ve been on a deep dive on trying to get ktor to live in multi-threaded coroutines. I thought I’d be able to sort it out, but stuck on something that seemed minor. Thought I had another breakthrough this morning. Kind of did, but there’s something really odd happening. See how it goes…

[antrax]

It seems like 2 APIs are needed if we follow that suggested impl: 1) non-blocking that already works fine on both platforms if we run on main thread (even using ktor) 2) blocking one that we can use for background work