Pinch me, I'm dreaming :star-struck: <https://andr...
# multiplatform
m
๐ŸŽ‰ 14
๐Ÿ˜ฏ 9
p
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
j
I already knew this was ongoing ๐Ÿ˜ Very nice being able use lifecycle things easier in KMP. Very interesting direction from Google.
d
This is cool but I got so used to using decompose now as its replacement that I would think viewModel will go deprecated
๐Ÿ‘ 1
m
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.
๐Ÿ‘Œ 1
๐Ÿ‘ 1
d
well said ๐Ÿ˜„
j
@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.
๐Ÿ˜ฎ 1
m
I thought so too, but I had no proof to confirm my suspicions. Glad to hear it from someone else.
j
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
๐ŸŽ‰ 2
p
Did you try it already?
j
Just added dependency, but havent evaluated all yet.
๐Ÿ†’ 1
https://android-review.googlesource.com/c/platform/frameworks/support/+/2965063 Hehe ViewModel is in the works as well I just found out ๐Ÿ™‚
And iOS lifecycle is here it turns out for CMP: https://github.com/JetBrains/compose-multiplatform-core/pull/1043
p
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.
๐Ÿ’ฏ 1
m
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.
j
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.
I have expect/actual with collectStateWithlifecycle on Android and regular collect on iOS ๐Ÿ˜„
Also not sure how this will work in desktop and wasm targets ๐Ÿ™‚
Like whats the lifecycle of the browser ๐Ÿ˜„
Browser going into task manager/background onPause vs onResume?
p
Looking at Elijah's diagram, it kinda reminds me that onResume/onStart should be the same thing. Old Android made things complex.
m
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. ๐Ÿ˜„
yes black 1
j
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 ๐Ÿ™‚
๐Ÿ˜ธ 1
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 ๐Ÿ™‚
๐Ÿ’ฏ 1
p
Is a good opportunity to simplify stuff, let's see how it rolls
j
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 ๐Ÿ˜„
But indeed, will be interesting about this direction how impacts libraries in general. Like things didnt shift fast as it was ๐Ÿ˜„
androidx -> googlex ๐Ÿ˜„
p
Right! Lifecycle is always trouble
j
This reminds me of auto thing in RxJava for Android ๐Ÿ˜„
๐Ÿ˜ 1