There is something I don't get about the Jetpack M...

# multiplatform

[Daniele B]

There is something I don't get about the Jetpack Multiplatform libraries:
If DataStore depends on Java IO and Android platform APIs, how can it be multiplatform?
https://android-developers.googleblog.com/2022/10/announcing-experimental-preview-of-jetpack-multiplatform-libraries.html?m=1

[Tijl]

seems to have an OKIO implementation now, and that is multiplatform

[Tijl]

https://androidx.github.io/kmp-eap-docs/libs/androidx.datastore/datastore-core-okio/androidx.datastore.core.okio/index.html

[Vitor Hugo Schwaab]

It uses Java IO and Android platform APIs for the current Android implementation.

Márton says these libs were chosen because of the current implementation, not that the multiplatform implementation are using these:

These were chosen as they evaluate several important aspects of converting an existing library to multiplatform:

• Collections is an example of a library written in the Java programming language that has no Android-specific dependencies, but implements Java collection APIs.

• DataStore is written entirely in Kotlin, and it uses coroutines in both its implementation and APIs. It also depends on Java IO and Android platform APIs.

For iOS, and even JVM, it is using Okio to access the file system and persist preferences.
You can download the sources jar and see how it's implemented for each platform by clicking on Artifact(s) -> source.

Okio is a multiplaform library for IO by the way.

[zsmb]

Explanation above is correct! For the time being, the normal releases of these libraries are still dependent on Java/Android APIs for their normal releases.

The multiplatform previews are published alongside those versions, and those had these dependencies removed so that they can be used outside the JVM and Android.

[Landry Norris]

Is there a timeline on when these might be stable (just looking for a ballpark: days, weeks, months, etc)? I’m working on a KMM app and one of the tasks I need to do in the near future would greatly benefit from datastore. I’d hate to implement it with some other library, then have datastore multiplatform become stable right after, or to wait too long to implement this.

[zsmb]

From the blog post:

Keep in mind that these dev builds are experimental and should not be used in production. They are published outside the regular release cycle of these libraries, and they are not guaranteed to graduate to stable.

There is not even a ballpark estimate, we don’t even know if these multiplatform builds will become a stable release or not. This will depend on many things, among others, your feedback about them.

If you have a use case for it, please try DataStore and tell us how it went, but please do not use these preview builds in production for now, as we do not support them like regular builds.

[dewildte]

I was told to come here to express interest in Jetpack Libraries going Multiplatform.
So here I am expressing interest.
I am interested.
This is one of the best ideas I have heard in a long time.

[Landry Norris]

Also expressing interest. I’ve been using the Compose experimental release for a bit, and been happy.

[dewildte]

Compose UI should be Mutliplatform so I can reuse UI everywhere.
I am imagining a fully multiplatform ecosystem all the way down to abstracting
File IO and the like.

[Landry Norris]

There’s already a lot of good libraries
File IO: okio
HTTP/WebSocket: ktor
Settings: multiplatform-settings (possibly datastore in the future)
Serialization of any kind: kotlinx.serialization

Way too many state management libraries. The main thing we’re missing right now is UI.

[Landry Norris]

It would be cool to see more androidx libraries become multiplatform. I’d like to especially see androidx.startup make its way to iOS somehow.

[yigit]

wrt java io vs okio;
DataStore has public APIs that depend on Java IO (serializer, File etc) that were impossible to make multiplatform (and we cannot break API).

So we had to come up with a new Storage / StorageConnection abstraction at a lower level and have 2 implementations of Storage w/ Okio and Java IO.

If you just use the android version, it still uses file io.
So if you want to use datastore on iOS or in common code, you’ll need to use the OkioStorage implementation.
If you are using it just for android, you can use it w/o okio (but can also use w/ okio).

A primary goal in Jetpack Multiplatform is to not impact Android developers which creates this kind of interesting API challanges. (also datastore being full in corouitnes is another set of challanges for KMP which are not too bad anymore thanks to the new memory model)

[dewildte]

corouitnes is another set of challanges for KMP which are not too bad anymore thanks to the new memory model

I am so happy they are addressing that.

[agrosner]

same, the memory management model on kotlin native was a strong blocker until now 🙂

[Landry Norris]

I’ve been using the new mm since the first dev preview in January. The old mm made what I needed to do at the time basically impossible.