correct way of using coroutines in kotlin 1.3
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I started using corotuines when it was still in experimental. With anko, I had something like
async(UI) {
val request = bg { sendRequest() }
val result = request.await()
// UI work
}
I really like how it is structured and it does provide cleaner code vs callback hell imo. I just realized coroutines is now in stable channel and couldn't wait to try it out. I updated my kotlin and anko and now I have this
doAsync {
val result = sendRequest()
uiThread {
// ui work
}
}
Am I doing it correctly? This structure seems ugly to me. Although it might be more readable but I still like the old way of calling await(). Or maybe I miss something here? I remember one of the selling points when coroutines was introduced is less curly braces.
kotlin kotlinx.coroutines anko
asked Nov 24 '18 at 1:32
user1865027user1865027
83521635
add a comment |
I started using corotuines when it was still in experimental. With anko, I had something like
async(UI) {
val request = bg { sendRequest() }
val result = request.await()
// UI work
}
I really like how it is structured and it does provide cleaner code vs callback hell imo. I just realized coroutines is now in stable channel and couldn't wait to try it out. I updated my kotlin and anko and now I have this
doAsync {
val result = sendRequest()
uiThread {
// ui work
}
}
Am I doing it correctly? This structure seems ugly to me. Although it might be more readable but I still like the old way of calling await(). Or maybe I miss something here? I remember one of the selling points when coroutines was introduced is less curly braces.
kotlin kotlinx.coroutines anko
asked Nov 24 '18 at 1:32
user1865027user1865027
83521635
add a comment |
I started using corotuines when it was still in experimental. With anko, I had something like
async(UI) {
val request = bg { sendRequest() }
val result = request.await()
// UI work
}
I really like how it is structured and it does provide cleaner code vs callback hell imo. I just realized coroutines is now in stable channel and couldn't wait to try it out. I updated my kotlin and anko and now I have this
doAsync {
val result = sendRequest()
uiThread {
// ui work
}
}
Am I doing it correctly? This structure seems ugly to me. Although it might be more readable but I still like the old way of calling await(). Or maybe I miss something here? I remember one of the selling points when coroutines was introduced is less curly braces.
kotlin kotlinx.coroutines anko
asked Nov 24 '18 at 1:32
user1865027user1865027
83521635
I started using corotuines when it was still in experimental. With anko, I had something like
async(UI) {
val request = bg { sendRequest() }
val result = request.await()
// UI work
}
I really like how it is structured and it does provide cleaner code vs callback hell imo. I just realized coroutines is now in stable channel and couldn't wait to try it out. I updated my kotlin and anko and now I have this
doAsync {
val result = sendRequest()
uiThread {
// ui work
}
}
Am I doing it correctly? This structure seems ugly to me. Although it might be more readable but I still like the old way of calling await(). Or maybe I miss something here? I remember one of the selling points when coroutines was introduced is less curly braces.
kotlin kotlinx.coroutines anko
kotlin kotlinx.coroutines anko
asked Nov 24 '18 at 1:32
user1865027user1865027
83521635
asked Nov 24 '18 at 1:32
user1865027user1865027
83521635
edited Nov 24 '18 at 3:03
user1865027
asked Nov 24 '18 at 1:32
user1865027user1865027
83521635
asked Nov 24 '18 at 1:32
user1865027user1865027
83521635
asked Nov 24 '18 at 1:32
user1865027user1865027
83521635
83521635
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You don't need Anko to get good code with coroutines. Also, you don't need async and in fact you should avoid it for cases like yours, where you just want to make a non-blocking call and don't want to launch several such calls concurrently. Your basic idiom should be
myScope.launch {
val result = sendRequest()
// UI work
}
where sendRequest() is
suspend fun sendRequest() = withContext(Dispatchers.IO) { ... body ... }
If you are calling this from an Android Activity, then myScope can be just the implicit this, and your activity must implement CoroutineScope:
class MyActivity : AppCompatActivity, CoroutineScope {
override val coroutineContext = SupervisorJob() + Dispatchers.Main
...
}
To get more insights, Explicit Concurrency by Roman Elizarov is highly recommended reading.
answered Nov 24 '18 at 7:50
Marko TopolnikMarko Topolnik
149k19200330
Thanks for your suggestion. This sounds like a good idea but I still like the old way of using coroutines. That way I don't need to go back and modify all my request methods to suspend.
– user1865027
Nov 25 '18 at 1:59
If your request method isn't suspendable, then you must wrap calling it into awithContext. In its basic effect this is the same as wrapping inasyncand immediatelyawaiting on it, but behaves correctly in the face of failures. So in any case you should avoidasync-await, which you should use strictly when you want to achieve concurrency (as opposed to merely avoiding blocking the UI thread).
– Marko Topolnik
Nov 25 '18 at 9:06
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53454433%2fcorrect-way-of-using-coroutines-in-kotlin-1-3%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You don't need Anko to get good code with coroutines. Also, you don't need async and in fact you should avoid it for cases like yours, where you just want to make a non-blocking call and don't want to launch several such calls concurrently. Your basic idiom should be
myScope.launch {
val result = sendRequest()
// UI work
}
where sendRequest() is
suspend fun sendRequest() = withContext(Dispatchers.IO) { ... body ... }
If you are calling this from an Android Activity, then myScope can be just the implicit this, and your activity must implement CoroutineScope:
class MyActivity : AppCompatActivity, CoroutineScope {
override val coroutineContext = SupervisorJob() + Dispatchers.Main
...
}
To get more insights, Explicit Concurrency by Roman Elizarov is highly recommended reading.
answered Nov 24 '18 at 7:50
Marko TopolnikMarko Topolnik
149k19200330
Thanks for your suggestion. This sounds like a good idea but I still like the old way of using coroutines. That way I don't need to go back and modify all my request methods to suspend.
– user1865027
Nov 25 '18 at 1:59
If your request method isn't suspendable, then you must wrap calling it into awithContext. In its basic effect this is the same as wrapping inasyncand immediatelyawaiting on it, but behaves correctly in the face of failures. So in any case you should avoidasync-await, which you should use strictly when you want to achieve concurrency (as opposed to merely avoiding blocking the UI thread).
– Marko Topolnik
Nov 25 '18 at 9:06
add a comment |
You don't need Anko to get good code with coroutines. Also, you don't need async and in fact you should avoid it for cases like yours, where you just want to make a non-blocking call and don't want to launch several such calls concurrently. Your basic idiom should be
myScope.launch {
val result = sendRequest()
// UI work
}
where sendRequest() is
suspend fun sendRequest() = withContext(Dispatchers.IO) { ... body ... }
If you are calling this from an Android Activity, then myScope can be just the implicit this, and your activity must implement CoroutineScope:
class MyActivity : AppCompatActivity, CoroutineScope {
override val coroutineContext = SupervisorJob() + Dispatchers.Main
...
}
To get more insights, Explicit Concurrency by Roman Elizarov is highly recommended reading.
answered Nov 24 '18 at 7:50
Marko TopolnikMarko Topolnik
149k19200330
Thanks for your suggestion. This sounds like a good idea but I still like the old way of using coroutines. That way I don't need to go back and modify all my request methods to suspend.
– user1865027
Nov 25 '18 at 1:59
If your request method isn't suspendable, then you must wrap calling it into awithContext. In its basic effect this is the same as wrapping inasyncand immediatelyawaiting on it, but behaves correctly in the face of failures. So in any case you should avoidasync-await, which you should use strictly when you want to achieve concurrency (as opposed to merely avoiding blocking the UI thread).
– Marko Topolnik
Nov 25 '18 at 9:06
add a comment |
You don't need Anko to get good code with coroutines. Also, you don't need async and in fact you should avoid it for cases like yours, where you just want to make a non-blocking call and don't want to launch several such calls concurrently. Your basic idiom should be
myScope.launch {
val result = sendRequest()
// UI work
}
where sendRequest() is
suspend fun sendRequest() = withContext(Dispatchers.IO) { ... body ... }
If you are calling this from an Android Activity, then myScope can be just the implicit this, and your activity must implement CoroutineScope:
class MyActivity : AppCompatActivity, CoroutineScope {
override val coroutineContext = SupervisorJob() + Dispatchers.Main
...
}
To get more insights, Explicit Concurrency by Roman Elizarov is highly recommended reading.
answered Nov 24 '18 at 7:50
Marko TopolnikMarko Topolnik
149k19200330
You don't need Anko to get good code with coroutines. Also, you don't need async and in fact you should avoid it for cases like yours, where you just want to make a non-blocking call and don't want to launch several such calls concurrently. Your basic idiom should be
myScope.launch {
val result = sendRequest()
// UI work
}
where sendRequest() is
suspend fun sendRequest() = withContext(Dispatchers.IO) { ... body ... }
If you are calling this from an Android Activity, then myScope can be just the implicit this, and your activity must implement CoroutineScope:
class MyActivity : AppCompatActivity, CoroutineScope {
override val coroutineContext = SupervisorJob() + Dispatchers.Main
...
}
To get more insights, Explicit Concurrency by Roman Elizarov is highly recommended reading.
answered Nov 24 '18 at 7:50
Marko TopolnikMarko Topolnik
149k19200330
edited Nov 24 '18 at 9:04
answered Nov 24 '18 at 7:50
Marko TopolnikMarko Topolnik
149k19200330
answered Nov 24 '18 at 7:50
Marko TopolnikMarko Topolnik
149k19200330
answered Nov 24 '18 at 7:50
Marko TopolnikMarko Topolnik
149k19200330
149k19200330
Thanks for your suggestion. This sounds like a good idea but I still like the old way of using coroutines. That way I don't need to go back and modify all my request methods to suspend.
– user1865027
Nov 25 '18 at 1:59
If your request method isn't suspendable, then you must wrap calling it into awithContext. In its basic effect this is the same as wrapping inasyncand immediatelyawaiting on it, but behaves correctly in the face of failures. So in any case you should avoidasync-await, which you should use strictly when you want to achieve concurrency (as opposed to merely avoiding blocking the UI thread).
– Marko Topolnik
Nov 25 '18 at 9:06
add a comment |
Thanks for your suggestion. This sounds like a good idea but I still like the old way of using coroutines. That way I don't need to go back and modify all my request methods to suspend.
– user1865027
Nov 25 '18 at 1:59
If your request method isn't suspendable, then you must wrap calling it into awithContext. In its basic effect this is the same as wrapping inasyncand immediatelyawaiting on it, but behaves correctly in the face of failures. So in any case you should avoidasync-await, which you should use strictly when you want to achieve concurrency (as opposed to merely avoiding blocking the UI thread).
– Marko Topolnik
Nov 25 '18 at 9:06
Thanks for your suggestion. This sounds like a good idea but I still like the old way of using coroutines. That way I don't need to go back and modify all my request methods to suspend.
– user1865027
Nov 25 '18 at 1:59
Thanks for your suggestion. This sounds like a good idea but I still like the old way of using coroutines. That way I don't need to go back and modify all my request methods to suspend.
– user1865027
Nov 25 '18 at 1:59
If your request method isn't suspendable, then you must wrap calling it into a
withContext. In its basic effect this is the same as wrapping in async and immediately awaiting on it, but behaves correctly in the face of failures. So in any case you should avoid async-await, which you should use strictly when you want to achieve concurrency (as opposed to merely avoiding blocking the UI thread).– Marko Topolnik
Nov 25 '18 at 9:06
If your request method isn't suspendable, then you must wrap calling it into a
withContext. In its basic effect this is the same as wrapping in async and immediately awaiting on it, but behaves correctly in the face of failures. So in any case you should avoid async-await, which you should use strictly when you want to achieve concurrency (as opposed to merely avoiding blocking the UI thread).– Marko Topolnik
Nov 25 '18 at 9:06
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53454433%2fcorrect-way-of-using-coroutines-in-kotlin-1-3%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
