https://kotlinlang.org logo
#oolong
Title
# oolong
p

pardom

05/24/2020, 6:41 PM
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
🎉 1
👌 1
m

Michal Harakal

06/01/2020, 4:34 PM
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 …
p

pardom

06/01/2020, 5:08 PM
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.
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
It takes a
Dispatch<A>
, a function
(B) -> A
, and returns a
Dispatch<B>
.
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
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. 😬
m

Michal Harakal

06/01/2020, 6:25 PM
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 … 🙂
p

pardom

06/01/2020, 6:54 PM
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.
6 Views