https://kotlinlang.org logo
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
benchmarks
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
confetti
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
lincheck
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by
Title
m

Martin Devillers

03/15/2019, 1:27 PM
Would it seem reasonable to add
object InactiveScope
the standard library, which would be a
CoroutineScope
instance with an job always in a cancelled state? I think this would be useful in cases when we have a scope var which isn’t initialized at object creation, so we could use this object as a placeholder rather than using a null value. I’m thinking about scopes tied to Android activity states, i.e.
activityCreatedScope
,
activityStartedScope
,
activityResumedScope
. Currently the solutions are to use
lateinit
or nullable
var
.
s

streetsofboston

03/15/2019, 1:56 PM
I think your Activity/Fragment, or even better your ViewModel should just implement CoroutineScope. Then you can assign a real or an ‘initially-cancelled’ Job to its
coroutineContext
.
m

Martin Devillers

03/15/2019, 1:58 PM
There’s more than one scope in this case, because different tasks are linked to different activity states
s

streetsofboston

03/15/2019, 2:01 PM
I see. Even in that case, I suggest not to use an already implemented scope, like InactiveScope. Instead, use ViewModel like object that get recreated each onCreate, onStart, onResume and cleared/destroyed/canceled each onPause, onStop, onDestroy and that object implements
CoroutineScope
. But, in a similar way, an
object CancelledJob : Job { ... }
could help here, that can be initially assigned to these objects’ `coroutineContext`s.
m

Martin Devillers

03/15/2019, 2:08 PM
The Android use-case is just an example. I’m suggesting a singleton scope which can be used as a placeholder in places where there’s a mutable scope instance which isn’t initialized immediately. I think that’s what you’re saying in your second paragraph, but I’m not sure. I also don’t see why you want to bring in
ViewModel
-like objects for tasks which are linked to the activity lifecycle, given that the
ViewModel
itself is precisely designed for taks which outlive the activity lifecycle. Maybe it’s clearer if I show a current implementation:
open class CoroutineActivity : AppCompatActivity() {

    private var _activityCreatedScope: CoroutineScope? = null
    val activityCreatedScope: CoroutineScope
        get() = _activityCreatedScope!!
    private var _activityStartedScope: CoroutineScope? = null
    val activityStartedScope: CoroutineScope
        get() = _activityStartedScope!!
    private var _activityResumedScope: CoroutineScope? = null
    val activityResumedScope: CoroutineScope
        get() = _activityResumedScope!!

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        _activityCreatedScope = MainScope()
    }

    override fun onStart() {
        super.onStart()
        _activityStartedScope = MainScope()
    }

    override fun onResume() {
        super.onResume()
        _activityResumedScope = MainScope()
    }

    override fun onPause() {
        super.onPause()
        activityResumedScope.cancel()
        _activityResumedScope = null
    }

    override fun onStop() {
        super.onStop()
        activityStartedScope.cancel()
        _activityStartedScope = null
    }

    override fun onDestroy() {
        super.onDestroy()
        activityCreatedScope.cancel()
        _activityCreatedScope = null
    }
}
This would be simpler if the `var`s for the scope could simply be initially assigned with a
InactiveScope
e

elizarov

03/15/2019, 2:16 PM
I fear that that would work to shuffle various bugs under the rug. You see, when you try to
launch
a coroutine in a scope that is not active it does not start silently. It is hard to notice. But when you try to read a
lateinit var
that was not initialized yet, then you get exception. Much better way to catch bugs.
2
s

streetsofboston

03/15/2019, 2:16 PM
My idea of bringing in ViewModel like object is to have those objects be responsible for launch tasks (
launch
,
async
) and never the Activity. The Activity then no longer has to worry about structured concurrency.
open class CoroutineActivity : AppCompatActivity() {

    private lateinit var _vmCreatedScope: MyViewModelWithScope
    private lateinit var _vmStartedScope: MyViewModelWithScope
    private lateinit var _vmResumedScope: MyViewModelWithScope

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        _vmCreatedScope = MyViewModelWithScope()
    }

    override fun onStart() {
        super.onStart()
        _vmStartedScope = MyViewModelWithScope()
    }

    override fun onResume() {
        super.onResume()
        _vmResumedScope = MyViewModelWithScope()
    }

    override fun onPause() {
        super.onPause()
        vmResumedScope.cancel()
    }

    override fun onStop() {
        super.onStop()
        vmStartedScope.cancel()
    }

    override fun onDestroy() {
        super.onDestroy()
        vmCreatedScope.cancel()
    }
}
And your logic is in your
MyViewModelWithScope
(they could be different classes for each state, if need be; in this example, they are the same instance type) and your
MyViewModelWithScope
implements
CoroutineScope
m

Martin Devillers

03/15/2019, 2:20 PM
@elizarov Ok so maybe a
CancelledScope
would be better, rather than inactive. This way the behavior is the same before the lifecycle reaches an “active” state and after it exits this “active” state.
e

elizarov

03/15/2019, 2:47 PM
Same problem, though. CancelledScope is just as tricky.
g

gildor

03/16/2019, 3:49 AM
Probably something like this would help in your case and avoid subtle bugs when you try to start coroutine in wrong state:
object UninitializedScope : CoroutineScope {
    override val coroutineContext: CoroutineContext
        get() = error("Scope is not initialized")
}
👍 1
I never tried this approach, just an idea
But this is better than lateinit only for components that may be destroyed and recreated again, like Android Fragment’s view, I prefer to use own scope for view because it has own lifecycle, different from parent Fragment one