https://kotlinlang.org logo
#coroutines
Title
# coroutines
j

Jacques Smuts

04/03/2019, 8:25 AM
I just want to say thank you to whomever thought of this warning.
g

gildor

04/03/2019, 8:26 AM
This is recommended convention for Kotlinx.corotuines
Just curious, what is yiour use case for returning UUID in Deferred
j

Jacques Smuts

04/03/2019, 8:28 AM
that’s an api call to get the UUID from an endpoint. Converted the api calls to use coroutines by wrapping them in Deferred<>
this is part of Kotlinx.coroutines doc about this convention
that’s an api call to get the UUID from an endpoint. Converted the api calls to use coroutines by wrapping them in Deferred<>
Why do you need Deferred in this case instead of suspend function?
I’m using that
g

gildor

04/03/2019, 8:30 AM
Soon retrofit will support suspend functions
j

Jacques Smuts

04/03/2019, 8:31 AM
I’m looking forward to that, but for now I’m happy with this pattern
not the point I was trying to make when I uploaded that image
g

gildor

04/03/2019, 8:31 AM
for now I would just suppress this warning for retrofit interfaces and refactor Deferred to suspend functions later
j

Jacques Smuts

04/03/2019, 8:31 AM
but I appreciate the input
I just like it that the IDE picks up on naming conventions because I know it’s easy to miss those.
g

gildor

04/03/2019, 8:33 AM
Yeah, but I wouldn’t use this convention for retrofit services if you use them directly, without wrapper, because soon you will probably refactor it
but it just my IMO
j

Jacques Smuts

04/03/2019, 8:33 AM
hmmm
g

ghedeon

04/03/2019, 8:34 AM
Well, ironically, as @gildor mentioned, this is the exact case where it's better to ignore this warning and not follow the convetion. Because you'll replace it soon, the
suspend
support is already in the retrofit snapshot
j

Jacques Smuts

04/03/2019, 8:34 AM
lol
Thanks for the advice 🙂
😉 1
though they way I did it, once the suspend function is supported, it’ll be really easy to just remove the Deferred<> wrapper and still make the call through the same coroutinescope and things I set up 🤔
g

gildor

04/03/2019, 8:40 AM
if you use them always as
api.getUuid().await()
that it will be easy and exactly the same in terms of scopes, lifecycle, dispatchers etc, just remove
Deferred<>
, remove `.await()`and add
suspend
👌 1
g

ghedeon

04/03/2019, 8:45 AM
True, but the
Async
in the name will be redundant and that was the premise of this thread.
1
g

gildor

04/03/2019, 8:46 AM
yeah, just one more unnecessary change
s

Sam

04/04/2019, 5:30 PM
I found using async named functions make sense only when it launches multiple tasks concurrently over one after the other.
g

gildor

04/05/2019, 3:22 AM
@Sam Hm, what do you mean? Async named functions make sense only if it returns Deferred, if it suspend function and under the hood it launches multiple tasks (you can do this using coroutineScope/withContext functions), than no need to use Asyn in name, because it’s just an implementation detail
s

Sam

04/05/2019, 4:37 PM
@gildor Yeah, i meant the ones that return Deferred. Caller can leverage concurrency by fun downloadImageAsync : Deferred<T> vs suspend fun downloadImage
g

gildor

04/05/2019, 11:59 PM
Yeah, correct, for such case. But I usually don't see a reason for such functions in public API, more flexible provide suspend function and a user of this API easily can wrap it to Deferred on call site if some concurrency is required
s

Sam

04/06/2019, 12:43 AM
Okay, yeah that works as well
2 Views