Add POC for swiftUI version of emoji-search #628
Conversation
skorulis-ap
force-pushed
the
skorulis/swift-ui
branch
from
e8c5de5 to
fc77738
Compare
Remove parent from SwiftUIChildren
skorulis-ap
force-pushed
the
skorulis/swift-ui
branch
from
fc77738 to
e588c93
Compare
| import SwiftUI | ||
|
|
||
| final class ColumnBinding: BaseWidget, WidgetColumn, SwiftUIViewBinding { | ||
| func height(height: Int32) { |
There was a problem hiding this comment.
Oof yeah Kotlin value classes don't interop well with Swift unfortunately. On the JVM (Android) these let us define 0 overhead enums.
There was a problem hiding this comment.
I think we might want to start considering using primitives and language features that do have better inter-opt, since the framework is meant to target both platforms. are there alternatives that could be considered for some of these?
There was a problem hiding this comment.
We could convert these properties to enums, though that has a small performance impact. Initially the plan was these interfaces would only be implemented in Kotlin.
|
|
||
| } | ||
|
|
||
| func horizontalAlignment(horizontalAlignment: Int32) { |
There was a problem hiding this comment.
@skorulis-ap The way we've been implementing these params to far is to pass them to a layout engine written in common Kotlin code. Basically it takes size constraints + views and returns positions for each of the children.
Is it possible to position children manually in a VStack or HStack? Else, we'll probably have to do something custom for Swift UI.
There was a problem hiding this comment.
Manual positioning is possible, but kind of fights the system. That I think is less of a worry than getting the sizes of each child. SwiftUI calculates the sizes during the layout pass so you would need to have some sort of side rendering happening to get these values.
iOS 16 adds a Layout object but that's not an option for a few years.
My plan was to use the SwiftUI layout system and respect the parameters that are passed in. wrapping likely being the hardest one to implement.
|
Haven't forgot about this! Going to try to get it (and a version for the Counter sample) landed first thing next year. |
This creates a version of emoji-search which is built on top of SwiftUI. It's currently as bare bones as possible to get something to render. The following have not been touched:
The code was based off the UIKit app with the rendering and binding parts replaced. Because SwiftUI isn't representable in Kotlin the implementations of common layout structures need to be done in Swift. This creates the biggest hurdle which is how to share this code between projects.
How this works
Each Binding is implemented as a class, which has a number of
@Publishedproperties. When one of these changes SwiftUI will compute which parts of the view tree need to be rendered. Each binding also has aviewparameter which defines how to render the binding. Classes get an automaticidproperty which allows swiftUI to understand the difference between an object being modified or added/removed.