Looking at <https://android.googlesource.com/platf...

# compose

[Kirill Grouchnikov]

Looking at https://android.googlesource.com/platform/frameworks/support/+/refs/heads/androidx-master-dev/compose/material/material/samples/src/main/java/androidx/compose/material/samples/SelectionControlsSamples.kt#117 it's not clear how can this scale to anything that requires internationalization. Eventually the selected option needs to be persisted for the next run, or be used to send some info to the server, or anything else that requires some sort of non-string data to be used to indicate the user selection in the group. Is there going to be some kind of a RadioGroup or ToggleGroup class in the core Compose for this? Same for segmented toggle buttons (like controlling text alignment, e.g.)

[jim]

What is it that concerns you? Is it just the radioValues on line 118? Because you could just load those as String resources and then they can be internationalized by the Android resources system before passing them to Text. Those values were just hard-coded strings for simplicity and easy of authorship.

[Kirill Grouchnikov]

Let's say this represents some choice that needs to be persisted on the server and made available across all user's devices (mobile or desktop). One device might be displaying string in english, and another device might be set to display the same strings in another language. Lines 127 and 134 update the selected state of the "control" on the specific device, but what do I send to the server for persisting my choice? Would that need a more complex data structure in line 118 that has a unique ID for each one of the choices, and then line 128 updates the selected ID?

[jim]

Ultimately engineers can make choices about how they want to write this, Compose is just Kotlin code, so you have some freedoms. But no, you don't need a complex data structure, although you certainly could use one.

If you wanted a minimally invasive diff, the only line that would change is 138 were it becomes something like text = internationalizeFromEnglish(text), assuming you use the english variant as your internationalization keys (which has benefits, like being able to search the codebase for english strings to locate the relevant pieces of code based on a UI). Of course, this has drawbacks too, so it is perfectly understandable if you wanted to replace 118 with an integer or enum, but either way, a complex data structure isn't necessary unless you want one.

[Kirill Grouchnikov]

I think I'd go with an enum-driven approach. Something like a payment screen wouldn't even have "simple" radio button rows. Each row might have a bit more info that just one text:

[jim]

Yup, depending on your use case, that makes sense. Kotlin is flexible in this way.