is it a good practice to have a state flow in a si...

# compose

[Pablo]

is it a good practice to have a state flow in a singleton and to access it in a viewmodel to make changes on a screen depending of the value of that state flow?

[Pablichjenkov]

Singleton is considered an antipattern

[Pablo]

well, in some circunstances is a good option, even in google android courses and codelab they are using it and recommending it

[Pablo]

maybe can someone tell me if is a good practice to use the state flow outside a composable and a viewmodel? in an external object like a singleton? thanks

[Rok Oblak]

there's no rules that say where a state flow should be.
It's up to you to determine and make sure you don't have memory leaks or components living past their intended lifecycle.

[Rok Oblak]

on Android, using the application reference or a singleton is very similar conceptually. And iOS makes extensive use of singletons too.

[Pablo]

thank you

[Alexandru Caraus]

You can have the stateflow as a global val, why bother adding it to a singleton (object)

[Alexandru Caraus]

I do that often, only in POCs

[Pablo]

well, it feels more confortable to have it on the singleton that manages sections

[Alexandru Caraus]

Okay

[Alexandru Caraus]

I wouldnt do it either way in a well designed app

[Alexandru Caraus]

Not sure abt your use case though, maybe it makes sense

[Pablo]

yes it does, is not a normal app, is a meta app that displays an app defined in a json, so is not a common way to do it

[Alexandru Caraus]

What does meta app mean?

[Rok Oblak]

in my opinion, it is good practice to manage the lifecycle of your "holders". Your singleton could instead be an instance that you instantiate yourself and make sure other child components get a reference to, if needed. If anything, it forces you to re-think and double check when and where something is needed. Otherwise you quickly end up with tons of singletons holding little pieces of state which is hard to reason about and as mentioned can lead to memory leaks.

[Pablo]

well, it's an app that can be infinite apps with the same source code, I mean, depending on the json received can generate a different app. So, one element can have an event with infinite actions, one of these actions can be a screen change with more following actions in the same event

[Pablo]

as you notice is not possible to change the current screen simply hoisting an "onscreenchanged" event with the current screen, there are infinite possibilities and chained actions/events

[Pablo]

so the only way I found to manage screen changes is with a "currentScreen" stateflow in a globally accesed class, in this case I'm using the screen manager class that does some other tasks

[Alexandru Caraus]

Probably you need to take a look at the compose navigation library

[Pablo]

I'm already using it