Jake Wharton
Jake Wharton
The listed types are optional for conditional Kotlin support. You can safely tell GraalVM to ignore them, assuming that's a possibility.
I'm personally not interested in maintaining a KSP version right now. Perhaps once it moves into the Kotlin repo and KSP2 is stable we can reconsider.
The logic is really simple. Someone can maintain a KSP version outside the Retrofit repo until KSP is stable enough to move it in.
Separating your network layer into its on module will allow reducing that time to effectively 0, since it will always reuse the cached output rather than running on every change.
Sorry I haven't forgotten about this. I was waffling on what I wanted to do based on this comment: https://github.com/Kotlin/kotlinx.serialization/issues/253#issuecomment-2158956453. Specifically, > So the only option I see here is...
I guess in that case we can simply deprecate this converter and add the streaming to the normal one, assuming the APIs make themselves available on the high-level "format"-suffixed types...
Yep I'll get it in here soon. Probably Monday
Streaming is always slower than buffered, yes. The point of using the streaming APIs is that you get to amortize the cost of serialization and deserialization across the cost of...
Okio costs less than `InputStream` when streaming as there are no array copies across layers.
I'm out for a week. Will try to look next week when I return.