# Reactive Apps with Model-View-Intent - Part 7: Timing (SingleLiveEvent problem)

DevFeed: [Reactive Apps with Model-View-Intent - Part 7: Timing (SingleLiveEvent problem)](<https://devfeed.tech/articles/reactive-apps-with-model-view-intent-part-7-timing-singleliveevent-problem-25460.md>)

Original publisher: [Read original article](<https://hannesdorfmann.com/android/mosby3-mvi-7/>)

Author: Hannes Dorfmann

Published: 2017-09-13T09:00:00Z

Content type: tutorial

Language: en

Sources: [Hannes Dorfmann](<https://devfeed.tech/sources/hannes-dorfmann.md>)

Topics: [reactive](<https://devfeed.tech/topics/reactive.md>), [App](<https://devfeed.tech/topics/app.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [display](<https://devfeed.tech/tags/display.md>), [livedata](<https://devfeed.tech/tags/livedata.md>), [mvi](<https://devfeed.tech/tags/mvi.md>), [reactive](<https://devfeed.tech/tags/reactive.md>), [screen](<https://devfeed.tech/tags/screen.md>), [state](<https://devfeed.tech/tags/state.md>), [state-management](<https://devfeed.tech/tags/state-management.md>), [viewmodel](<https://devfeed.tech/tags/viewmodel.md>)

## AI overview

This article explains how Model-View-Intent and proper state management can address the recurring Snackbar problem associated with SingleLiveEvent when Android views are recreated or revisited. It presents immutable view state and unidirectional data flow as the proposed approach.

## Source excerpt

In my previous blog post we discussed the importance of proper state management and why I think introducing a SingleLiveEvent as discussed in Google's Architecture Components GitHub repo is not a good idea because it just hides the real underlying problem: state management. In this blog post I would like to discuss how the problem SingleLiveEvent claims to solve can be solved with Model-View-Intent and proper state management.