tiwiz
10/10/2018, 10:04 AMrunBlocking
behaviour happens even with a possible delay. In the following gist (https://gist.github.com/tiwiz/b85c72fb77148e6cc12aa378b762e94b) there is the code (the delay
is only to test if the test waits or not). So far, we couldn't have it to wait, so we must be doing something wrong... does anyone have a clue about it?Jonathan
10/10/2018, 10:08 AMselectById
suspend? It would be much simpler then.gildor
10/10/2018, 10:09 AMtiwiz
10/10/2018, 10:09 AMJonathan
10/10/2018, 10:10 AMwithContext
gildor
10/10/2018, 10:10 AMwithContext(IO) {}
insteadJonathan
10/10/2018, 10:10 AMtiwiz
10/10/2018, 10:10 AMgildor
10/10/2018, 10:11 AMtiwiz
10/10/2018, 10:12 AMonCleared
method, so that it can be canceled based on Android's lifecycle... is that wrong?Jonathan
10/10/2018, 10:12 AMtiwiz
10/10/2018, 10:12 AMgildor
10/10/2018, 10:13 AMtiwiz
10/10/2018, 10:14 AMIO + job
is wrong, then?ViewModel
?ViewModel
invoke the Selector
and clear the job?gildor
10/10/2018, 10:14 AMtiwiz
10/10/2018, 10:16 AMfabiocollini
10/10/2018, 10:16 AMsuspend
method approach but here the job must be saved in the ViewModelgildor
10/10/2018, 10:16 AMfabiocollini
10/10/2018, 10:16 AMgildor
10/10/2018, 10:18 AMfabiocollini
10/10/2018, 10:19 AMTrampolineScheduler
to wait the end of the computation, is there something similar on the coroutines?gildor
10/10/2018, 10:20 AMfabiocollini
10/10/2018, 10:21 AMgildor
10/10/2018, 10:21 AMthe Unconfined context works only if there aren’t any nested async/launch callit’s not true anymore, coroutine builders now use coroutineScope context by default
val selector = Selector(dao)
selector.selectById(1)
selector.coroutineContext[Job]!!.join()
tiwiz
10/10/2018, 10:32 AMgildor
10/10/2018, 10:34 AMtiwiz
10/10/2018, 10:54 AM