Hi <@U8NMFHUGJ> , do you know if it is possible to...

# kotlin-native

[louiscad]

Hi @kpgalligan , do you know if it is possible to make an equivalent of this awaitOneClick extension function for View on iOS? https://github.com/LouisCAD/Splitties/blob/8a38de6131b1b41d5404c8f236204cfa7becc3b8/sample/src/main/kotlin/com/louiscad/splittiessample/extensions/coroutines/View.kt#L9-L22

[kpgalligan]

On UIView? Not sure. Most ui I’ve done is in the visual editor. Could poke around if I get some time, although I’m currently re-releasing all libraries on 1.3.20

[louiscad]

Yup, on UIView (there's other clickable things on iOS?). If you have some time post re-releasing, yes, I'd be interested 🙂

[kpgalligan]

Cool. Working on some form of shared ui thing?

[louiscad]

Not just yet, but I was waiting for 1.3.20 with AAR publishing in MPP to consider starting it. I should have a new colleague next week: an experienced iOS developer! I don't know what to expect yet though, but we will discuss Kotlin/Multiplatform and coroutines for sure, I don't know if he will engage in open source library development, joining forces/giving back with/to the community as a result.
I'm still improving Splitties Views DSL (currently working on MaterialComponents first class support) as I enjoy using Kotlin to develop UIs, and I believe this will help tremendously when I'll start sharing code with iOS and maybe other targets.
I continued to use the UI contracts technique I told you about at KotlinConf and that we discussed in this channel a while ago, and I like it a lot when used with coroutines and their cancellation support plus try/finally. It also worked out for non Android apps, #tornadofx desktop apps fit with this UI contracts (`interface`s) approach.

I'm regularly thinking about the possible abstractions that could make it more capable with less code to write. Thinking about loading (and nested loading) with and without progress, showing errors, allowing retry, multiple actions in a single coroutine (that forks), and how to make it style/impl agnostic while still making impl/styling of the UI a piece of cake. There could be generic wrappers for boolean controls that can be modeled with switches, checkboxes, alert dialog, custom view, view group/tree, same for list controls (with list size indication/limits), selection, showing a value, etc. It turns out UI is finally just a structured I/O, that needs to be optimized for human interaction instead of optimized for raw performance when talking about storage/network/device I/O, so I think the key is finding the right levels of abstractions that can be used like lego blocks, leaving freedom for the design (hardcoding a FloatingActionButton that could become a simple Button later is not right IMHO, the classes are not compatible, and there's implementation details the non UI code doesn't need to know, it just cares about enabling, clicking and maybe showing/hiding).

TL;DR Thinking about it seriously, and working on it, but Android only for now, dogfooding the UI contracts approach and Splitties Views DSL.

[Sam]

Uiviews don’t have any interaction capabilities themselves. Typically a simple interactive view inherits from uicontrol which is a subclass of uiview. Other more complicated views like tables will use a combination of gesture recognizers. https://stackoverflow.com/a/32480721/2351 has a good explanation in Swift.

[louiscad]

Thanks for the link @Sam, very informative. I now see it would be possible, I just need to start doing it when I have some free time for iOS.