https://kotlinlang.org logo
Join Slack
Powered by
Is there already an fix for the kotlinx serializat...
# multiplatform
f
Is there already an fix for the kotlinx serialization and kotlin native mpp incompatibility?
k
I'm not sure they're incompatible. Seem to work here: https://github.com/JetBrains/kotlinconf-app/blob/new-mpp/common/build.gradle
f
8 days ago there told me there are incompatible and there is an fix on the way.
k
The situation has been changing fast. I couldn't get mpp working for any of my libraries with native, but it looks like the kotlinconf app has things sorted out. If I get time before conf I'm going to try to update, but I have some kind of dependency resolution issue with k/n 0.9.2 that's still happening. Anyway, if you clone and build the kontlinconf app, it definitely works
f
there released an own version of coroutines to fix that with an kotlinconf postfix 0.26.1-rc-conf2
well im not getting the old incompatibility error at kotlin native compile anymore but an new error
Copy code
An operation is not implemented: enum and context serializer
k
Well, I guess my point is there is clearly some combination of versions and settings under which the library is functional. How they're incompatible with your project is a different discussion. As mentioned, I stopped mpp efforts because native wasn't resolving dependencies, but it's clearly working there, so the task is to figure out what's different.
f
im not sure how stable the dependencies that are build exclusively for the kotlinconf app are.
k
Not sure how stable any of them are, frankly. For the stuff I'm building I clone and deploy my own, to control for native version
I'm hoping how the dependencies are published and the form of gradle plugins stabilizes in Q4 so I can start not doing that, but that's where we're at.
Gradle module dependencies is in a non-final state, so gradle metadata deployments aren't compatible between 4.7 and 4.10. That's going to add another fun dimension to the issue.
f
im now using the same versions as in the repo but still the same error
was able to fix it. An kotlin native specific common module source class had an nested class of an serializable class which was missing the serializable annotation
the only change i had to do was to use the coroutine version of the kotlin conf app everything else worked without an change
and the nested class fix
k
Interesting. I think if I sort out whatever's wrong with my setup and native dependencies with gradle 4.7 I'll be able to put everything together, but config issues can be pretty time consuming to debug.
f
the error message wasn't very intuitive.
i like the
kotlin native version in the gradle.properties
0.30.0-eap13 for coroutines is working
looking forward to your talk at kotlinconf. After getting my internal sdk working i will start working on the multiplatform setup for https://github.com/mikepenz/FastAdapter to get it working on ios as well.
k
Interesting. I've never used FA, but is the idea to build something that would be used with UICollectionView on iOS?
The next concept I want to focus on is how everything pushes up towards the UI, without creating more work and/or confusion than it's worth. The common approach is to use interfaces and have a "UI contract" of sorts that shared code communicates with, but this becomes more problematic as the we get into the more platform specific UI components. By that I mean a text view is pretty simple, collection views seem doable but are more complex, view pager probably need entirely different UI components.
f
i already wrote an ios port to see the differences between the platforms in swift https://github.com/FabianTerhorst/FastAdapter-Swift
something like https://github.com/linkedin/LayoutKit could work very well as an multiplatform ui project.
and the same logic works very well in android https://github.com/FabianTerhorst/AndroidLayoutKit
fastadapter-swift works petty well already, but i would prefer an kotlin multiplatform project

https://cdn-images-1.medium.com/max/1600/1*6GZVNluJCV2Mz5ESYEzLew.gif▾

k
That's really interesting stuff. Putting those on the todo list. Not going to have much to say till after kontlinconf, though (working on slides and updating my repos right now. Slides take forever)
Shared UI is going to be challenging, but also something that would be great if implemented well. The next few years will be interesting, if nothing else.
s
Maybe I just remember too clearly how bad java's AWT was to like the idea of shared UI. It seems that most cross platform ui implementations mostly reimplement their own versions that attempt to look and feel native. Even ReactNative is somewhat a misnomer. For example they're not actually using real platform widgets but instead they're reimplementing a lot of the widgets in JS calling to native code.
k
Guess I should be more precise with terms. I wouldn't suggest attempting "shared UI' in that sense. I mean more like how far can you push shared (and tested) logic into the UI? In general, a text box is going to have very similar functionality between platforms, so it's easy to imagine a "TextView" type interface that is virtual (not 100% the point of Domic, but is defined there: https://github.com/lyft/domic). You could in theory define a UI contract which is generated in platform specific ways. Maybe.
Of course, not all situations need perfection. The Java UI is generally considered a failure, but only if you're building consumer apps. It was pretty successful in the enterprise. As for UI architecture, this past Droidcon NYC made it pretty clear that lots of different groups are pushing towards a "react-like" situation of immutable state and componentized UI. The common thread in these cases being that all the groups talking about that have large dev teams (which are generally overrepresented in conferences and in the definition of best practices). TL;DR, "shared UI" sucks and was a failure depending on the context.
Also, best practices can also be contextual. Anyway, slides...
s
Definitely the more logic you push out of the UI the more opportunities for sharing there are. I'm all for that but not as much for creating a common wrapper around common ui elements. I've gotten good results in my pure swift apps using view models and coordinators. Next time I work on an android app I want to see how a coordinator pattern would work there.
k
The common wrapper is speculative because beyond the basic components, and after the basic features, they stop being very similar. There's no "GONE" visibility in iOS for example (AFAIK). I get sort of excited about it conceptually till I try it a bit, then pretty quickly I'm less excited. Did something in the middle here. The logic around different UI states was (relatively for the app) complex, so there's an interface that is implemented on each platform that just manipulates the UI. The shared code does a bunch of check and calls the methods. If fully implemented there's be more going on (there's no "currently happening" state, for example, which existed in earlier version): https://github.com/touchlab/DroidconKotlin/blob/master/sessionize/src/main/kotlin/co/touchlab/sessionize/ScheduleModel.kt#L81
f
In ios there is an hidden attribute. But autolayout treats the view as visible when its setted true. Layoutkit also didn't added support for that because the layouts in layoutkit are immutable and don't react to view changes. You would have to fully redraw the layout tree after setting it to hidden and implement it inside the grouping layout structures in the library.
j
chiminig in here... my (ultimate) plan is to use kotlin mpp to construct e.g. a list of view models and let Android and the iOS counterpart do the UI based on the models I find https://github.com/airbnb/epoxy with databinding the most interesting solution for this and LayoutKit on iOS as they have similar concepts (and to avoid Autolayout hell for UICollectionViews)
exciting times ahead
k
Epoxy is definitely on the review list. I don’t understand the iOS ecosystem nearly as well. Lots of research coming
j
5 Views
Open in Slack
PreviousNext
Powered by