workflow-kotlin
workflow-kotlin copied to clipboard
Kotlin Multiplatform support
trafficstars
This is a loose rundown of the state of the kmp branch, which contains the kotlin multiplatform conversion that @brady-aiello and myself began prototyping earlier this summer.
Things that exist in that branch include:
- multiplatform conversion of
workflow-core,workflow-runtime, and thecore-common,backstack-common, andmodal-commonsubmodules ofworkflow-ui - Two new samples
hello-workflow-multiplatformandtictactoe-multiplatformbased on the existinghello-workflowandtictactoesamples. These mostly just exercise the multiplatformworkflow-core.
Some design decisions we made that are worth highlighting
- Some things that previously references java
Classnow instead useKClass. This has a slightly differenttoString()format, which impacts some things likeWorkflowIdentifiertests. - We added a string-based
WorkflowIdentifierimplementation for iOS, since theKAnnotatedElementlogic that exists in the current version mostly only works on JVM. - Some extensions in
Snapshot.ktdepend on theenumConstantsfield which doesn't have an equivalent onKClass, so these extensions were left as JVM-only. - The
Workerclass includes aTYPE_OF_NOTHINGconstant which istypeOf<Void>()on JVM. We added anexpect class Voidwith an arbitraryactual class Voidon native, but there may be other ways to handle this. - We had difficulty migrating the existing
--friend-pathsconfiguration that allowsworkflow-testingto read internal classes ofworkflow-core. We opted to introduce an opt-in annotationInternalWorkflowApiinstead, to mark library API that consumers shouldn't depend on. Note that opt-in annotations are not yet stable as a language feature (but will be soon). - JMH performance testing configuration in workflow-runtime is currently disabled in the branch since it doesn't migrate naturally to the multiplatform plugin
TODOs and future work.
- [ ] Multiplatform publishing configuration. We haven't touched publish scripts yet.
- [ ] More targets. Current prototype uses only
iosX64for simulator builds on Intel mac hosts. At a minimum we'll want to also enableiosArm64andiosSimulatorArm64, but it probably makes sense to do all darwin targets, and consider whether any Windows/Linux targets are worthwhile. - [ ] Reexamine native
WorkflowIdentifier. If this is largely only needed for snapshots, which are largely only needed for Android, then maybe there's a better solution whereWorkflowIdentifiermoves to being JVM-only instead of having a native implementation that rarely get used. - [ ] Reexamine the
workflow-runtimeconversion. A bunch of functionality and tests were left JVM-only. Is the stuff in common useful? - [ ] Re-enable JMH tests in
workflow-runtime, possibly by moving to an separate module - [ ] Add dependency on multiplatform
kotlinx-coroutines-testwhen available, and move jvm-only tests to common where possible. - [ ] Try moving workflow-testing to common once multiplatform
kotlinx-coroutines-testis available. - [ ] Demonstrate interop with a
Workerinvolved, since this API is not exercised by the current multiplatform samples. - [ ] Figure out strategy for workflow-swift interop. There's some code in the samples that might be useful as library-level interop helpers, but we need to refine that API and figure out what's useful, as well as come up with a publishing strategy.
- [ ] Explore ways to delegate between render methods of
workflow-kotlinandworkflow-swift, in order to avoid reimplementing this logic. There are probably adapters here that could live in an interop library. - [ ] Explore calling into
renderWorkflowIn()from Swift in order to facilitate interop. This might need some helper code on the Kotlin and/or Swift side that could live in an interop library - [ ] Determine if multiplatform
workflow-uimodules are useful. What sort of interop is needed to make these natural to call into from Swift?
There are probably other TODOs worth considering as well, and some of these might not be necessary for a first release, but hopefully this can start the ball rolling.