Hi, I'm new to the compose. Actually I'm migrating...

# compose

[Abdul Hafeez Sajid]

Hi, I'm new to the compose. Actually I'm migrating my application to compose. I have custom widgets in my project which use properties in a map written in room database. When activity is created, I fetch properties of a widget from database and I pass properties in a map to widget and widget is created. Everything works.

Now, I have converted my custom widget to composable and I'm must use same old properties technique. But I'm stuck like how should I handle properties for a composeable. Should I just pass entire map to composeable that could include more than 100 properties?? Also, how should I handle states or in other words how should I create states out of map and hoist them outside composeable because widget behavior is changeable from outside.

Any suggestions would be highly appreciated.

[Colton Idle]

Are you talking about android widgets? that go on your home screen? if so maybe you want #glance

[Zach Klippenstein (he/him) [MOD]]

You probably need at least one state somewhere, since presumably the database load happens asynchronously, and since your properties can presumably change in the future. You could start with the whole (immutable!) map in a mutable state, or a single mutable SnapshotStateMap. Then from there, eventually refactor to more states if you change individual properties more frequently than others.

[Abdul Hafeez Sajid]

Basically I want to know if Compose provides any framework to handle UI states like flutter does with Redux or Provider?

[Zach Klippenstein (he/him) [MOD]]

Yes

[Abdul Hafeez Sajid]

Which one? Can you guide me a little bit about this? I'm kinda stuck right now.

[Zach Klippenstein (he/him) [MOD]]

AFAIK, it’s a little different than most of them. All the rest of your questions in your original post should be addressed by the docs – can you elaborate on what doesn’t make sense?

[Abdul Hafeez Sajid]

Sure. Actually I'm new to the compose. Problem is i have made a widget or lets say a composeable named ImageWidget. This will be used anywhere in any fragment or activity. Fragment or activity gets views properties from Room database like text to show on view or image name or margin etc etc. These properties are in the form of map. Now, problem is how do I handle states for my composeable. Like these properties could be 50 or more. I can't parameterize a composeable with 50 properties, right?

I did make some progress but I'm not very sure of it. I made a handler class in which I pass view properties as a map and then I make a mutablestatemapof that map. Then I read or write the map and its working fine now. What do you think is this a good approach or do you suggest any other mechanism that I haven't heard of? I still haven't checked any performance measures on this approach yet.

[Zach Klippenstein (he/him) [MOD]]

I’m not sure exactly what the parameter count limit is on the jvm but 50 params definitely sounds like a headache to manage either way. A map, or a class with properties, definitely seems like a better approach.

[Zach Klippenstein (he/him) [MOD]]

As for whether a single immutable object stored in a mutable state object (i.e. mutableStateOf) or an object that is mutable itself (i.e. a mutableStateMapOf or a class with properties backed by mutableStateOf), that really depends on real-world performance measuring and how often properties are changed together or individually.

[Zach Klippenstein (he/him) [MOD]]

I don’t think Room can produce custom map types (??), so I would start with just putting the map Room gives you in a MutableState and going with that until the performance of your widget is bad enough that you profile it and see that the cause is the maps.

[Abdul Hafeez Sajid]

Thank you for these points. I'll check them now.