Skip to content

Add more custom serializers for kotlinx serialization#2978

Open
Luna712 wants to merge 3 commits into
recloudstream:masterfrom
Luna712:add-serializers
Open

Add more custom serializers for kotlinx serialization#2978
Luna712 wants to merge 3 commits into
recloudstream:masterfrom
Luna712:add-serializers

Conversation

@Luna712

@Luna712 Luna712 commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

This also seperates the tests, and test serializers that are in library, using commonMain tests rather than testing library serializers in androidTest also. The tests in androidTest have been changed to just test UriSerializer, which is the only one actually there.

This adds numerous other serializers to replicate Jackson mapper configuration behavior, that some extensions will need (such as InternetArchiveProvider) This adds support for replicating the following behaviors:

jacksonObjectMapper().apply {
    configure(DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY, true)
    configure(DeserializationFeature.ACCEPT_EMPTY_ARRAY_AS_NULL_OBJECT, true)
    configure(DeserializationFeature.ACCEPT_EMPTY_STRING_AS_NULL_OBJECT, true)
    configure(DeserializationFeature.ACCEPT_FLOAT_AS_INT, true)
}

For DeserializationFeature.ACCEPT_FLOAT_AS_INT, which allows converting both Int or Long to a Float, it was split into two separate serializers, FloatAsIntSerializer and FloatAsLongSerializer, as it was complex to do both at once and I also figured it would be nice to allow splitting this before for more explicit control.

Another difference is that unlike custom mappers that can be applied to the whole thing, when migrated from Jackson to Kotlinx, it would have to drop custom mappers entirely, use the normal parseJson/tryParseJson/etc... and be explicit about what classes need this, which in my personal opinion is better to be more explicit and allows us to be more unified in how the AppUtils methods are used more accept under some way more rare circumstances where you may need a custom Json instance.

I also explained how to use all the serializers in doc comments. We could also later add more serializers if necessary.

Luna712 added 3 commits June 29, 2026 13:59
This also seperates the tests, and test serializers that are in library, using commonMain tests rather than testing library serializers in androidTest also. The tests in androidTest have been changed to just test UriSerializer, which is the only one actually there.

This adds numerous other serializers to replicate Jackson mapper configuration behavior, that some extensions will need (such as [InternetArchiveProvider](https://github.com/recloudstream/extensions/blob/cf16b3b45cda911a36ddca69f9acbe4763c6a4b1/InternetArchiveProvider/src/main/kotlin/recloudstream/InternetArchiveProvider.kt#L47-L56)) This adds support for replicating the following behaviors:
```kt
jacksonObjectMapper().apply {
    configure(DeserializationFeature.ACCEPT_SINGLE_VALUE_AS_ARRAY, true)
    configure(DeserializationFeature.ACCEPT_EMPTY_ARRAY_AS_NULL_OBJECT, true)
    configure(DeserializationFeature.ACCEPT_EMPTY_STRING_AS_NULL_OBJECT, true)
    configure(DeserializationFeature.ACCEPT_FLOAT_AS_INT, true)
}
```
For `DeserializationFeature.ACCEPT_FLOAT_AS_INT`, which allows converting both Int or Long to a Float, it was split into two separate serializers, `FloatAsIntSerializer` and `FloatAsLongSerializer`, as it was complex to do both at once and I also figured it would be nice to allow splitting this before for more explicit control.

Another difference is that unlike custom mappers that can be applied to the whole thing, when migrated from Jackson to Kotlinx, it would have to drop custom mappers entirely, use the normal `parseJson`/`tryParseJson`/etc... and be explicit about what classes need this, which in my personal opinion is better to be more explicit and allows us to be more unified in how the `AppUtils` methods are used more accept under some way more rare circumstances where you may need a custom `Json` instance.

I also explained how to use all the serializers in doc comments. We could also later add more serializers if necessary.
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

Successfully merging this pull request may close these issues.

1 participant