Ahmed Ibrahim
10/29/2020, 4:10 PMasCoroutineDispatcher()
but somehow things like debounce
in Flow
and delay
doesn't properly tell Espresso that it's not idle, and the UI matchers stuff still gets executed despite being in the debounce
period.Remy Benza
10/30/2020, 11:50 AMlifecycleScope.launch {
viewModel.playedTracks.collectLatest { pagingData: PagingData<TrackListItem> ->
playedTracksAdapter.submitData(pagingData)
}
}
Remy Benza
10/30/2020, 11:51 AMRemy Benza
10/30/2020, 11:51 AMRemy Benza
10/30/2020, 11:53 AMvar playedTracks: Flow<PagingData<TrackListItem>>
init {
playedTracks = Pager(PagingConfig(pageSize = 20)) { PlayedTracksPagingSource(playedTracksRepository, epochAsZonedDateTime.value!!) }.flow
}
Michal Klimczak
11/04/2020, 9:25 AMRobert Jaros
11/04/2020, 10:27 AMelizarov
11/04/2020, 11:20 AMkotlinx.coroutines
version 1.4.1
is released with an important fix to SharedFlow
implementation (for the case of concurrent emitters) https://github.com/Kotlin/kotlinx.coroutines/releases/tag/1.4.1rkeazor
11/06/2020, 6:51 AMNikky
11/13/2020, 2:44 PMNikky
11/13/2020, 7:19 PMMDCCOntext
or might know workarounds to update itdiesieben07
11/16/2020, 11:03 AMlaunch
inside flow {}
and using flowOn
it's still just one coroutine. I can't combine two `flow { }`s because the two use the same underlying resource.Uziel Sulkies
11/18/2020, 8:32 AMinit {
GlobalScope.launch (<http://Dispatchers.IO|Dispatchers.IO>) {
val logger = LoggerFactory.getLogger(javaClass)
var exceptionsCounter = 0
while (true) {
delay(DELAY_IN_MS_BETWEEN_FLAGS_CHECKS)
try {
getFlags()
.onEach {
featureFlagsStatusGauge.labels(it.key).set(if (it.value) 1.0 else 0.0)
}
exceptionsCounter = 0
} catch (e: Exception) {
exceptionsCounter++
if (exceptionsCounter > 6) logger.warn("Got exception while trying to update feature flags status for $exceptionsCounter times", e)
}
}
}
Tolriq
11/18/2020, 9:59 AMprivate val mutableEvents = MutableSharedFlow<Event>()
val events: SharedFlow<Event>
get() = mutableEvents.asSharedFlow().onSubscription {
if (something()) {
emit(Event())
}
}
an efficient way to generate a sharedflow that can produce something on subscribtion only to new subscribers? Or is there better way?df
11/18/2020, 8:43 PMdiesieben07
11/19/2020, 12:18 PMFlow
between n subscribers where all n must definitely receive all elements (but I don't want to keep a replay cache for all of the elements...). My solution works, but it seems strangely complex for a task that seems very common:
First I have a custom SharingStarted
implementation that ensures that the shared flow does not start collecting until all subscribers have either subscribed or have failed: https://pastebin.com/g6hsUQxg
Then it is used like this (sharing data
between all delegates
): https://pastebin.com/TzT9NnTy
Is this really the best solution? 🤔uli
11/19/2020, 10:21 PMrkeazor
11/20/2020, 2:54 AMKamilH
11/20/2020, 8:33 AMsuspend
to completionHandler
works under the hood in Kotlin-Native? On which dispatcher they are run? What about the scope in which they run? Is it possible to cancel this scope?Charlie Christensen
11/23/2020, 3:32 PMval viewState: Flow<iewState> = viewState()
.shareIn(viewModelScope, SharingStarted.Eagerly, 1)
.onSubscription {
optionallyTriggerActionAfterDelay()
}
private suspend fun optionallyTriggerActionAfterDelay() {
if (valueIsTrue) {
delay(5000)
triggerAction()
}
}
This suspends the flow and delays the initial emission until the delay is complete.
I’ve tried launching another coroutine in the same scope but it still seems to block
private suspend fun optionallyTriggerActionAfterDelay() = coroutineScope {
launch {
if (valueIsTrue) {
delay(5000)
triggerAction()
}
}
}
And just using a different scope but this doesnt cancel
viewModelScope.launch {
if (valueIsTrue) {
delay(5000)
triggerAction()
}
}
I could just create a separate variable that would still be tied to the view lifecycle but I am more just curious if something like this can/should be done?samuel
11/24/2020, 4:53 PM// Run multiple async tasks and combine them and enit as one flow
val finalFlow: Flow<SomeType> = flow{
supervisorScope {
val firstAsyncAction = async { firstAsyncActionFlow }
val secondAsyncAction = async { secondAsyncActionFlow }
val thirdAsyncAction = async { thirdAsyncActionFlow }
emitAll(
awaitAll(
firstAsyncAction,
secondAsyncAction,
thirdAsyncAction
).merge()
)
}
}
finalFlow.collect {
// This runs multiple times discarding the previously sent items from the flow
}
However, this emits as soon as any of the async tasks complete which is not the desired result. How would i handle such a use case?leandro
11/25/2020, 8:22 PMval now: Flow<ZonedDateTime> = MutableStateFlow(clock.now()).transform {
while (true) {
emit(clock.now())
delay(5.seconds)
}
}
Sadly transform()
breaks my StateFlow, converting it to just a Flow.ursus
11/25/2020, 8:24 PMleandro
11/25/2020, 8:28 PMMutableStateFlow
interface...leandro
11/25/2020, 8:30 PMAdam Powell
11/25/2020, 8:32 PMLulu
11/26/2020, 3:32 AMDispatchers.DEFAULT
dispatcher. Do threads work independently and pick up available coroutines by some atomic operation, or do they switch the context to a common thread to get available coroutines from? (I did my research but there was no clear answer)Vsevolod Tolstopyatov [JB]
11/26/2020, 5:39 PMDispatchers.Default
in a specific edge-cases
• Fixed StackOverflowError
in Job.toString
• SharingStarted
is now fun
interface
• Properly propagated cancellation between listenable futures and deferreds
• Minor bufgixes and improvements
Full changelog: https://github.com/Kotlin/kotlinx.coroutines/releases/tag/1.4.2df
11/26/2020, 6:44 PMFile(resource).useLines
(my example given) twice?!Vsevolod Tolstopyatov [JB]
11/27/2020, 1:56 PM1.4.2
with fixed StateFlow
and SharedFlow
K/N issues