Persisting data in ViewModels with MutableState (Jetpack Compose ViewModel Example)

In this video I show you the best way (for most scenarios) to use an observable data structure in your viewmodels when using jetpack compose. There's lots of different options: LiveData, StateFlow, SharedFlow, MutableState. But in my opinion for simple scenarios you should be using MutableState. It's easy to use and is optimized for jetpack compose.

Follow me:
.
.

[debdutsaha]

Awsome mitch I have developed my skill quite a lot and now in 2.5 months in my job carrer I am a leading developer in my team and making awsome project.

[dennismozart]

That was the best tutorial I've found so far... Awesome video!

[ithebk]

I just hit a like button when you said submarine car joke. btw you're really great.

[staceyrichards]

Great teaching style. Keeping things simple and targeted to one key issue at a time. Makes learning Android programming so so much easier than trying to follow Googles own labs.

[s]

You are the one who let me know why X is preferred to y. Thanks

[YouGuto]

Engagement engaged!
Liked like a PRO!

[RaviTejagameboy]

Stateflow will be beneficial if we have separate network module following mvvm/mvi architecture and don't want to use any android ui related stuff(livedata, mutablestate) in the repository classes. Once we get the data from network layer it can be exposed to view as livedata or mutablestate from the viewmodel.

[viniciussantosguimares]

MutableStates looks a lot like reack hooks even the inital state, good to know they are actually starting with the right set of tools.

[frenzelts]

The best thing about flow is you can collect the data outside lifecycle. So they are great for repository to viewmodel communication, even more beneficial when the viewmodel needs to change or map the flow data from repository.

[speedboy]

Thanks, Mitch! This is great content :)

[MrAtrixsd]

ukrainian guy say thanks to u fot your videos

[quickmaths]

Idk if it's just me but the video title seems confusing for me as a beginner. Afaik ViewModels don't persist anything, the data goes away on shutdown. Afaik only SQLite & Room etc. really persist data.

I am not sure what this videos idea is, but maybe this is it: Mitch wants to store data temporarily in the UI when making request to a Backend. He stores that data there for convenience, but it doesn't get persisted, the only persistence that happens, happens in the backend.

Correct me if I am wrong

[Firespirit]

I was using the same approach for a big enterprise project as you showed at start for about 2 years, nothing wrong with that.

[armandoavila]

Great video! Here's some engagement 💪

[jayantkumar]

Thanks ! that's what i am looking for it :)

[hellespont]

I hope to be like @Debdut Saha and start my new career soon!! Android developer is my dream job, soon it will be a reality. Cheers from the UK Mitch!

[marksunghunpark]

Thanks for your awesome tutorials.

I am doing like this to hide implementation details:
class RecipeListViewModel ... {
private val recipes : MutableLiveData<List<Recipe>> = MutableLiveData ()

fun observe(owner: LifecycleOwner, onChange: (List<Recipe>) -> Unit) {
recipes.observe(owner, Observer(onChange))
}
}


class RecipeListFragment ... {
{

}
}

This way, RecipeListFragment doesn't care about implementation details .

[federicocreti]

I agree with you, BUT the real problem is to find a real scenario so simple to use this MutableState structure. I just wrote a real simple application I needed to manage the licenses of my users. And believe me, it is simple, but I had to use several structure types, like MutableStateFlow (to manage the persistent state of the app) and MutableSharedFlow(to emit a single event to the UI, like a toast to show a simple error). SO really I can't figure a situation so simple to simply use this MutableState structure.

[devgabriel]

Im having problems deleting an item of a list... I mean, it works, but the screen does not refresh, if i open a dialog or soething, then the list updates wihtout the deleted item, but i cat manage to have that refresh in the moment (locally, there is no API involved)

[cumpatomas]

that was a very good last comparison! :)