https://kotlinlang.org
Join Slack
Hi guys, question... how to avoid the emission of the same item twice with `flows` :sweat_smile:? My...
# coroutines
c
Hi guys, question... how to avoid the emission of the same item twice with 
flows
😅? My scenario is the following... I'm implementing MVI with unidirectional data flow on an Android Project. When the user enters some screen an initial intent is emitted for load data. The user goes to another screen and when comebacks, the initial intent is triggered again, how can I avoid this? there is some operator? should I create a custom one (someone has a sample like that)?
r
haha lol! I just realised that.
🤣 1
can you please share the link once again? I’ll have a look
c
Probably the solution is to add a custom operator, like this therefore, if the initial intent is already added, then it wont be emitted again when the user comeback
r
when you say that you return to the screen, is a new instance created or does it load data for the same intance?
If it’s about the same state being emitted, you can potentially use ‘distinctUntilChanged’
c
Nono, that's not the problem (state) the problem is on the intents, when the fragment is created, an initial intent is emitted in order to load the data
There are also other intents that only emit on special user events like swipe refresh. but, when the fragment is replaced for any reason, and the user comeback, the view of the fragment gets created again and the method intents is triggered again firing the initial intent again
r
right. So, is the fragment’s viewmodel getting created again? Or is the load intent firing for the same instance?
oh right! that’s bound to happen. Because view will be re-created.
c
The viewmodel remain in memory, but the fragment view gets destroyed & then recreated(as it should be on a replace transaction)
Also, I have to mention that on that project this bug can't be reproduced due to the jetpack navigation library kill and create again the whole fragment and viewmodel (it doesn't add the fragments to the backstack as default). But I just upload an smaller project where that bug can be replayed. https://github.com/ChristopherME/counter-android-mvi
🗒️ 1
r
When the view will be recreated, load intent is ought to be fired, and that’s correct in a way. Probably the way out is to enforce fragment is to not destroy it’s view somehow. Not sure though how would that be done (but doesn’t seem ideal).
c
Nonono, I don't think that retain the fragment is optimus. Im following

this▾

approach of MVI and what he does is he creates some RxJava chains and avoids the re-emission of the initial intent
🗒️ 1
By the way, that is the most awsome talk about MVI I've ever saw.
🙏 1
r
Agreed. However, theoretically, if the view is being re-created, load intent should be called to setup the view for the first time. Alternatively, the code can be designed to handle the load intent call. What do you think?
c
Yeah, that's the goal. The initial intent should be emitted only the FIRST time the fragment is created. When the fragment view it's recreated it should not emitt that initial intent again. I have to go deep into flow operators... there have to be some way for accomplish that. I didn't understand the last part of your comment, what you mean with that? 🤔
r
I kind of disagree to the fact that it should be called only the first time when fragment is created. Fragment instances in android are meant to be reused (and system handles that internally), so our code should only care about view’s lifecycle (and not fragment’s lifecycle) and deal accordingly. For the second part, I meant we can have the initial intent to fire on view creation, but the code that gets executed can deal with that accordingly.
c
Uhmm, I'm probably not explaining the problem well that's why you disagree. I would really recommend to check the minute 26:00 of the video I sent before, what Im trying to do is the same implementation, but instead of RxJava, using Flows. 😊. I tried to go straight to the problem here, but probably is needed more context. In order to fully understand the problem, one must watch the presentation
And Im saying that because avoid the fire of the initial intent twice is something common in the MVI pattern applied in android apps, due to the lifecycle of our activities/fragment. Look at this other blog from Adam Bennet, he also finds a way for avoid the emision of the initial intent twice. https://adambennett.dev/2019/07/mvi-the-good-the-bad-and-the-ugly/
r
oh! I’ll have a look at them once, in that case. thanks for sharing.
9 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by