Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serialization support for FlowSettings #72

Open
xsveda opened this issue Dec 29, 2020 · 7 comments
Open

Serialization support for FlowSettings #72

xsveda opened this issue Dec 29, 2020 · 7 comments

Comments

@xsveda
Copy link

xsveda commented Dec 29, 2020

Are there any ideas or plans how to introduce kotlinx.serialization support also for FlowSettings?

As both multiplatform-settings-serialization and multiplatform-settings-coroutines are independent it might end up in a completely new module, actually maybe more than one as we have also native-mt and datastore variants.

Or is there any other option that would not lead to module number explosion?

@russhwolf
Copy link
Owner

I haven't given this much thought yet. I want to get a sense of what is and isn't working about each part separately first. Serialization, like the original Settings API, is by nature synchronous which complicates things. For now, you can probably do something like val settings = flowSettings.toBlockingSettings() and use the serialization extensions from there. This will wrap all suspend and flow calls in runBlocking.

@xsveda
Copy link
Author

xsveda commented Dec 30, 2020

My idea is to have serialization support when observing certain value using getXxxFlow(). So next to
fun <T> Settings.decodeValue(serializer, key, defaultValue: T, serializersModule): T
we would have
fun <T> FlowSettings.getDecodedValueFlow(serializer, key, defaultValue: T, serializersModule): Flow<T>

@russhwolf
Copy link
Owner

Oh I see. That's worth some thought but I still want to let everything settle a bit in it's current form first.

In the meantime it should be fairly easy to get something working by hand if you look at what the Flow extensions are doing currently. They're all powered by this one simple function which is private but you could copy it into your project and call it or modify as needed.

@kansson
Copy link

kansson commented Dec 28, 2022

Oh I see. That's worth some thought but I still want to let everything settle a bit in it's current form first.

In the meantime it should be fairly easy to get something working by hand if you look at what the Flow extensions are doing currently. They're all powered by this one simple function which is private but you could copy it into your project and call it or modify as needed.

Do you have an example of a working function that combines a serialized value with a flow? Thanks!

@russhwolf
Copy link
Owner

Oh, the original workaround I had in mind here breaks in 1.0 with the untyped addListener() no longer present. Will need to think about this some more. It's an awkward tradeoff between the needs of ObservableSettings, SuspendSettings/FlowSettings, and the serialization extensions.

@Giuliopime
Copy link

Wouldn't it be better to use kotlinx serialization to serialize and deserialize stuff, so implementing it on flows would be as simple as

@OptIn(ExperimentalSettingsApi::class)
inline fun <reified T> FlowSettings.getDecodeValueFlow(
    key: String,
    defaultValue: T
): Flow<T> =  getStringOrNullFlow(key).map {
    it?.let {
        Json.decodeFromString<T>(it)
    } ?: defaultValue
}

@OptIn(ExperimentalSettingsApi::class)
inline fun <reified T> Settings.encodeValue(
    key: String,
    value: T,
) = set(key, Json.encodeToString(value))

kotlinx serialization supports kotlin multiplatform so there should be no compatibility issues

@russhwolf
Copy link
Owner

@Giuliopime Something like that is easy to implement yourself if you want it. The purpose here is to use the settings store itself as the serialization format, rather than JSON.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants