I just made this project public. It's far from fin...

# oolong

[pardom]

I just made this project public. It's far from finished, but already implements basic functionality using Oolong and Compose.

https://github.com/pardom/lambda-news

[Michal Harakal]

First things first. Just kudos to your work. After playing a little bit with the news app and oolong samples my mind just got blow away 🤯. Beeing noob in FP area and just started with Jetpack Compose I can see that your are using contramap for binding MVU model to Jeppack’s model. But I don’t get it about lifecycle, who is reposnsible for that? I’ve seen in other sample use of Android’s ViewModel bound with using observeAsState to Jetpack. Also you are using `@Model`which is already deprecated with dev12.
Also looking forward to see iOS part …

[pardom]

Thanks for checking it out! So let’s first address the question about activity lifecycle. The Oolong runtime is hosted in the Application process and is therefore independent of any Activity. When an Activity (in this case there is only one) has a configuration change (e.g. orientation change), it will first remove its render function from the runtime here: https://github.com/pardom/lambda-news/blob/master/lambda-news/android-compose/src/main/java/news/lambda/android/AppActivity.kt#L46. Then when the new activity is created, it will provide its render function to the runtime here: https://github.com/pardom/lambda-news/blob/master/lambda-news/android-compose/src/main/java/news/lambda/android/AppActivity.kt#L42. That is all that is needed handle configuration change because the runtime is not part of the activity.

An Oolong user may not like this approach, in which case you can host the runtime in a ViewModel. The UI state is managed by the runtime and job of Android/Compose is to simply provide dependencies and render UI.

[pardom]

As for contramap, this has nothing to do with the lifecycle, but rather delegation to child components (i.e. screens). The root component of the app delegates to child components by wrapping their model/msg/props. contramap is a function that allows you to easily map from a child Dispatch<ChildMsg> to the root `Dispatch<AppMsg>`: https://github.com/pardom/lambda-news/blob/master/lambda-news/view/src/main/kotlin/news/lambda/app/component/AppComponent.kt#L45

[pardom]

Looking at the source of contramap should help in understanding it: https://github.com/oolong-kt/oolong/blob/master/oolong/src/commonMain/kotlin/oolong/dispatch/util.kt#L36

[pardom]

It takes a Dispatch<A>, a function (B) -> A, and returns a Dispatch<B>.

[pardom]

Similarly, there is a function contramap which helps in delegating from a parent Next to a child Next. https://github.com/oolong-kt/oolong/blob/master/oolong/src/commonMain/kotlin/oolong/next/util.kt#L50

[pardom]

As for your last comment about @Model I plan to migrate soon, but I’m waiting for the next version of AS Preview. Canary 10 is pretty laggy. 😬

[Michal Harakal]

Thank you for your answer, for me is important to know, that ModelView is not necessary and we can have perfectly multiplatform sharable code with MVU (stiil keeping iOS in mind), just reimplementing the render function. Which is a really good news. I expect some good news regarding Jetpack Compose this week … 🙂

[pardom]

for me is important to know, that ModelView is not necessary and we can have perfectly multiplatform sharable code with MVU (stiil keeping iOS in mind), just reimplementing the render function.

That was one of the primary goals with Oolong. The platform is not the problem domain, so it shouldn't be coupled to your domain logic. Nor should it concern itself with what to render, but rather how.