Has anyone come across a usecase where the actual ...

# multiplatform

[saket]

Has anyone come across a usecase where the actual declarations have to be of different types on different platforms?

// Kotlin Native
expect class Feature

// Android
actual typealias Feature = AndroidFeature
where AndroidFeature is a class

// iOS
actual typealias Feature = iOSFeature
where iOSFeature is an interface

[jw]

inline class works well here because you can provide an abstraction the encapsulates the original different types without paying the overhead of traditional interface/class encapsulation at runtime.

[jw]

I've definitely designed APIs such that one platform could typealias and another would have to define a wrapper. It's hard to build something that typealiases on every platform though

[saket]

Ooh that is a clever solution. I'll try this, thanks jake!

[jw]

I don't think I have any examples anywhere. I think when I tried this I was doing a typealias to an inline class on a single platform? I would have to try it again. It was for experimenting with making a multiplatform data/time library.

[jw]

Well you deleted your reply but perhaps mine is still useful simple smile

[saket]

Yea… I thought I had a eureka moment but that didn't work out :p

It's late night here so my brain is working a bit slow.

[saket]

Typealiasing on the same platform was my eureka but it doesn't work either. I will play a bit more and report back.

[jw]

Maybe I ran into the same thing an gave up. If it doesn't work, we should file a bug. This has the potential to unlock a lot of power and it needs to work.

[saket]

I fell asleep while trying to make it work yesterday :D. Drafting a bug right now.

[saket]

Let me know if you think the wording can be improved.

[kpgalligan]

I recently did the firestore sdk, which is frustratingly sameish-but-not-the-same on iOS/android. Voting for your issue. What I did was a little more of a hack. Expect classes, but leave them empty, and use extensions for functionality

[kpgalligan]

[kpgalligan]

[kpgalligan]

[kpgalligan]

Warning. If call signature is the same but return value is different, Intellij won’t complain but it’ll fail compile (notice “get_” above. Not pretty, but works)

[saket]

Interesting. Is this repository public so that I can take a better look?

[kpgalligan]

No, but I can give you access. May open it later this year in relation to a talk https://oredev.org/sessions?tags=Polyglot-Fringe&day=day3. Send your github username

[saket]

That will be great! I'm saket on github.

[kpgalligan]

Cool. Obviously ignore the readme, etc.

[kpgalligan]

Also, no guarantee that the sample app runs.

[kpgalligan]

Droidcon Sponsor page is now being driven from it, if you want to see a sample in action: https://github.com/touchlab/DroidconKotlin/pull/123

[kpgalligan]

The dependency is only published locally, so that won’t compile out of the box unless you run publishToMavenLocal on the firestore project.

[kpgalligan]

Ah, also, this branch kpg/cleaning_api_2

[kpgalligan]

It’s like having guests show up when you haven’t cleaned the place

[kpgalligan]

More thoughts. In some places, rather than the ugly underscore thing, I’m renaming the functions if it makes sense. For example, in DocumentReference, I’ve renamed get to getDocument. https://github.com/touchlab/FirestoreKMP/blob/kpg/cleaning_api_2/firestore/src/commonMain/kotlin/co/touchlab/firebase/firestore/DocumentReference.kt#L14

[kpgalligan]

The whole api could kind of use a few more passes to make it more “Kotlin-like”. For example, I’ve added Flow from a document listener, and it actually works in native (everything happens on the main thread). Currently going through similar for java.time, although order(s) of magnitude more difficult. Reassessing life/career goals at the moment.

[saket]

It’s like having guests show up when you haven’t cleaned the place

Hahah no worries. This looks like a good reference project for beginners like me. Thanks Kevin!