Pinch me, I'm dreaming :star-struck: <https://android-review.googlesource.com/c/platform/frameworks/...

# multiplatform

[Mofe Ejegi]

Pinch me, I'm dreaming 🤩
https://android-review.googlesource.com/c/platform/frameworks/support/+/2965063

[Pablichjenkov]

ViewModel is fine but the recovery from process death API not good IMO. Hopefully they don't bring that one in. Doesn't play well with asynchronous dependency injection.
*Update: Single Activity is ok though

[Joel Denke]

I already knew this was ongoing 😁 Very nice being able use lifecycle things easier in KMP. Very interesting direction from Google.

[Djuro]

This is cool but I got so used to using decompose now as its replacement that I would think viewModel will go deprecated

[Mofe Ejegi]

Yeah, I know AndroidX VM had some challenges but the main point for me is similarity in development between KMP and basic Android development. Personally, I’ll be more excited to see an official Nav library from Compose MP that works well with its own VM.

The other thing I’d like to point out is the support Google is giving towards KMP. I find it pretty interesting, especially as Google have their own cross platform solution.

[Djuro]

well said 😄

[Joel Denke]

@Mofe Ejegi Yeah I think it was the core reason they rewrite the lifecycle library, so they can do that in androidx navigation if I recall correct. But I am not sure. Dont quote me on that though 😄 I would presume Jetbrains and Google co-op on this one.
I looking forward get androidx security and androidx credential as well as Firebase KMP supported more 😄 The other existing navigation libs is already good imo.

[Mofe Ejegi]

I thought so too, but I had no proof to confirm my suspicions. Glad to hear it from someone else.

[Joel Denke]

Plus the core Lifecycle APIs in 2.8.0-alpha02 are now compatible with Kotlin Multiplatform!
Sweet Google published it yesterday 🙂
See https://developer.android.com/jetpack/androidx/releases/lifecycle#2.8.0-alpha02

[Pablichjenkov]

Did you try it already?

[Joel Denke]

Just added dependency, but havent evaluated all yet.

[Joel Denke]

https://android-review.googlesource.com/c/platform/frameworks/support/+/2965063
Hehe ViewModel is in the works as well I just found out 🙂

[Joel Denke]

And iOS lifecycle is here it turns out for CMP: https://github.com/JetBrains/compose-multiplatform-core/pull/1043

[Pablichjenkov]

Well ViewModel by itself does not do much, it needs a lifecycle owner to be a thing. Most common lifecycle owners in Android are Activity, Fragment and NavBackstackEntry. Since Fragments won't make it to KMP, then I guess we will have to wait for the NavComponent too.

[Mofe Ejegi]

That really sums it up for me. The NavComponent would truly be a game changer.
Also, there was this new LifecycleEventEffect that got added to Lifecycle a few versions ago, I hope it’s still gonna be part compose multiplatform. Using it would be quite helpful for tracking iOS lifecycles without having to worry about implementing it myself.

[Joel Denke]

ViewModelFactory and such doing A LOT, ViewModel itself yes not much 😛 But its not the viewmodel itself thats imo interesting, more how to deal with the system around it.

[Joel Denke]

I have expect/actual with collectStateWithlifecycle on Android and regular collect on iOS 😄

[Joel Denke]

Also not sure how this will work in desktop and wasm targets 🙂

[Joel Denke]

Like whats the lifecycle of the browser 😄

[Joel Denke]

Browser going into task manager/background onPause vs onResume?

[Pablichjenkov]

Looking at Elijah's diagram, it kinda reminds me that onResume/onStart should be the same thing. Old Android made things complex.

[Mofe Ejegi]

Yeah, on iOS there is a clear distinction between when you enter the first time and when you exit and renter the foreground. In Android, it’s a bit jumbled up… but we’re pretty much used to it that way. 😄

[Joel Denke]

Hehe yeah mix of https://developer.android.com/reference/android/arch/lifecycle/ProcessLifecycleOwner and LifecycleOwner needed in Android to align to that it looks like 🙂

[Joel Denke]

But from end perspective, do we really need all these lifecycle things? Feels like only need enter and exit from user perspective?
Given that you have single Activity/View that is, and not care about deal with things shifting between each Activity/Screen, rather care about when user goes away from your UI 🙂

[Pablichjenkov]

Is a good opportunity to simplify stuff, let's see how it rolls

[Joel Denke]

Ideally feels like would be possible to auto decouple things in Kotlin Coroutines level, like attach lifecycle to that and auto kill/cancel collects and jobs automatic in background.
So dont need to care about this at all in Compose UI 🙂 Like introduce a new or existing Coroutine Dispatchers, UiLifecycleDispatcher 😄

[Joel Denke]

But indeed, will be interesting about this direction how impacts libraries in general. Like things didnt shift fast as it was 😄

[Joel Denke]

androidx -> googlex 😄

[Pablichjenkov]

Right! Lifecycle is always trouble

[Joel Denke]

This reminds me of auto thing in RxJava for Android 😄