Maybe just changing the libraries imports? :sweat_...

# orbit-mvi

[Guilherme Delgado]

Maybe just changing the libraries imports? 😅 it would be awesome

[Mikolaj Leszczynski]

Thanks for pinging us about this!

I will need to make the module multiplatform - and there is some Espresso idling resource code I need to figure out what to do with.

Other than that it should be a straight swap I think 🤞

[Mikolaj Leszczynski]

awesome news!

[Mikolaj Leszczynski]

PS I wonder how LifecycleOwner is implemented on the iOS side 😄

[Guilherme Delgado]

https://androidx.tech/artifacts/lifecycle/lifecycle-common-iosarm64/2.8.0-rc01

[Guilherme Delgado]

😇

[appmattus]

I’m currently going through all my personal open source projects about to look at all this stuff while I have the motivation (and more importantly time)

[Guilherme Delgado]

did a first try and it seams the KMP libs are:

androidx.lifecycle:lifecycle-runtime-compose
androidx.lifecycle:lifecycle-viewmodel

but Orbit also relies on:

androidx.lifecycle:lifecycle-viewmodel-ktx
androidx.lifecycle:lifecycle-runtime-ktx
androidx.lifecycle:lifecycle-viewmodel-savedstate

which i believe were not ported.

:orbit-compose:iosArm64Main: Could not resolve androidx.lifecycle:lifecycle-runtime-ktx:2.8.0-rc01.
Required by:
    project :orbit-compose

Possible solution:
 - Declare repository providing the artifact, see the documentation at <https://docs.gradle.org/current/userguide/declaring_repositories.html>

So maybe some refactor its going to be needed, but I might be wrong.

[appmattus]

lifecycle-runtime-ktx should be changed to lifecycle-runtime as the -ktx variants have been merged in and no longer provided separately

[appmattus]

doesn’t look like savedstate has been ported so that would have to be extracted out no doubt

[appmattus]

as a starting point to better prepare the project i’ve started updating all dependencies to the latest

[Guilherme Delgado]

I was using Kotlin-2.0.0-RC1 because of the new compose compiler simplifications, building smooth except for some non-kmp dependencies like savedstate

[Guilherme Delgado]

also updated the build.gradle files to become multiplaform, was ok

[Guilherme Delgado]

only “hack” I had to do was disable the jacoco by commenting the file, it was failing and I have no experience with it to understand why

[appmattus]

regarding savedstate myself and @Mikolaj Leszczynski had previously discussed pulling out into a separate module to help with multiplatform support anyway so perhaps this accelerates that plan. we were never quite sure how to support state saving for iOS anyway

[Guilherme Delgado]

In my POCs I always endup implementing that by hand, is not that hard too, of course we don’t have the same nice features but we can live without them too.

[Guilherme Delgado]

for google not porting that, either is WIP or the same philosophy

[Guilherme Delgado]

although DataStore is KMP ready so they could implement it in theory (and leave it “blank” for iOS for instance)

[Guilherme Delgado]

I never saw iOS deal with background restore and config. changes like Android

[Guilherme Delgado]

but I’m not that experienced in that platform

[appmattus]

the mechanism is just a little different and it doesn’t occur at quite the same frequency as on Android

[appmattus]

https://developer.apple.com/documentation/uikit/view_controllers/preserving_your_app_s_ui_across_launches

[Guilherme Delgado]

I would say that a barebones “saved state” implementation would be creating a proxy for the state, collecting all its emission and store them in the DataStore.

[appmattus]

theres a mechanism in swift too from what i remember; been a while since i’ve looked at it though

[Guilherme Delgado]

and then check cache uppong containerhost creation (VM init)

[Guilherme Delgado]

https://developer.apple.com/documentation/swiftui/restoring_your_app_s_state_with_swiftui/

[appmattus]

the problem i was struggling with using that approach was knowing the difference between something being created , i.e. new and not using saved data vs recreated and using saved data

[Mikolaj Leszczynski]

I think we need an abstraction layer that does not rely on platform semantics

[Mikolaj Leszczynski]

and then we'll figure out how to solve this per platform

[Mikolaj Leszczynski]

Not done any research on this, so forgive me if I'm stating the obvious XD

[appmattus]

yes which is what we’d previously discussed doing to pull it out from the main module 🙂

[appmattus]

(just been a while)

[appmattus]

😄

[Mikolaj Leszczynski]

haha yes

[Guilherme Delgado]

What I did was uppon “SavedStateContainer” creation check for cached state, but I feel the struggle, sometimes is just coming back again to the screen (in my POC I do want to preserve the state so i guess it’s a biased implementation). I believe this delegation depends on “app logic” so I guess the user would be responsible to activate the restore in the VM init? 😅

[Mikolaj Leszczynski]

maybe it's a good idea to just give the restored state to the user and go here, this is what I remembered, do what you will with it

[Guilherme Delgado]

yup i think is best too

[Guilherme Delgado]

that’s how savedstate works btw

[Guilherme Delgado]

we have to check if it has data to emit

[Guilherme Delgado]

But recently using orbit i don’t have to think much about it 😛 only in the past when using “live data” i was creating them by checking the savedState instance

[Mikolaj Leszczynski]

uh we'd have to migrate to kotlinx.serialization too

[Mikolaj Leszczynski]

currently we rely on Parcelable 😞

[Guilherme Delgado]

tadaaaaa: https://issuetracker.google.com/issues/334076622

[Guilherme Delgado]

just a matter of time until androidx.savedstate becomes available 😎