Dealing with one-time effects

Here is a scenario:

Your screen supports rotation. A particular Action can generate an error which should display a Snackbar.

How do we deal with it? Emit the error State initially but not after rotation to avoid displaying the Snackbar twice? What should the State be after rotation then?

Should we introduce a concept of Effects (single event type States)?

In the spirit of Roxie’s lightweight way of doing things, it would be ideal to solve this with minimal code needed by the consumer apps.

[Ethan1983]

@Glurt Just FYI. Trying to relay navigation update as event/effect (SingleLiveEvent) fails in an edge case with lifecycle and fragment transactions.

https://github.com/kaushikgopal/movies-usf/issues/19

[ScottCooper92]

I’ve just run into the same problem when trying to use the Navigation Component. I was thinking along the same lines as you by introducing another emitter using SingleLiveEvent.

That way you have States which change the state of the UI and you have Events/Effects that trigger something like navigation, snackbars, dialogs, permission requests etc

The question is how to split Changes into either States or Events, an example would be the user pressing a “locate me” button, the Action triggers a Change that updates the State to show a progress spinner, whilst the Event needs to trigger a permission request. It gets trickier when we need to do something based on the results of the Event, did they accept it or did they reject it etc