An introduction to Compose Multiplatform

The talk was an introduction to Compose Multiplatform for Java and Kotlin Developers. I focused on Jetpack Compose, Compose Desktop and Jetpack Compose - Java Swing interop. The attendees saw a lot of code, learned about the differences between imperative and declarative UI toolkits, unidirectional data flow and state hoisting. I also introduced ComposePanel and SwingPanel as a means for two-way-interop. The talk was presented in German.

Transcript

1. An introduction to Compose Multiplatform Thomas Künneth
3. Because the Browser and Web technology have won But why do we put so much effort in wrapping Web Apps in native containers? That’s quite a user base. Why don’t we write apps for the Desktop anymore?
4. • Browsers (and Web Apps) achieved a lot in the last 15 years, but a few things remain cumbersome ◦ Local storage ◦ Background activities • Leaving the confinements of the Browser allows for an better platform integration ◦ File associations ◦ Local search ◦ Multiple windows
5. So, writing native apps for the Desktop may be a good idea But how do we write apps for the Desktop these days?
6. Writing apps for the Desktop • Native frameworks and tools ◦ Make use of all platform features ◦ Each platform has its own programming languages, tools, best practices • Cross platform frameworks ◦ Significant code sharing ◦ Less platform-specific knowledge needed ◦ Satisfactory platform integration possible (depending on the framework)
7. • Cross platform vs. native debate started many years ago • Both approaches have distinct advantages and shortcomings • On the Desktop, Cross platform frameworks are a good idea because writing truly native apps for all ecosystems likely isn’t feasible today
8. Noteworthy Cross Platform frameworks • Electron • Qt • Flutter • Compose Multiplatform What about Java?
9. • Is Java a Cross Platform Framework or a platform? • General consensus: Java is a platform, like the Browser • In the end, it doesn’t matter, because either way ◦ Apps run on multiple operating systems ◦ One programming language is used ◦ One tool chain is used
10. • Java feels like having been around forever • Used to be a pain to get the JRE onto a machine • Most users hated it (sorry!) A lot has changed since then
11. • No Java plugin for the Browser • No local JRE installation • No Java Web Start OK, so let’s use Java and just don’t tell our users the JVM
12. Compose Desktop • Framework for building Desktop apps using Kotlin and Jetpack Compose • Targets macOS, Linux and Windows • Utilizies significant parts of the Java toolchain (jpackage) • Apps run inside the JVM • Part of a bigger picture: Compose Multiplatform
13. Compose Multiplatform • UIs are built using Jetpack Compose and shared across supported platforms ◦ Android ◦ iOS ◦ Desktop (Linux, macOS, Windows) ◦ Web • Based on Kotlin Multiplatform
14. Kotlin Multiplatform • Share Kotlin code across platforms ◦ Compiler output depends on the target ◦ Common libraries available on all platforms • Part of Kotlin Multiplatform (KMP): ◦ Project templates ◦ Project structure ◦ Gradle plugins ◦ Language constructs ◦ Libraries
15. Jetpack Compose • (Started as) Androids new declarative UI framework • UI is built by nesting composable functions ◦ Kotlin top-level functions ◦ Annotated with @Composable ◦ Usually return Unit • Compose hierarchies are hosted in native containers
17. Define a component tree Add it to the main window Make it visible Wire up behavior Changes to the UI are made by modifying the component tree
18. Define a hierarchy of composable functions Main window is a composable, too Make it visible Wire up behavior Changes to the UI are based on state
19. • Declarative UI frameworks don’t expose component trees ◦ No references (pointers) to leaves or branches of the UI tree ◦ No runtime exceptions due to outdated references • The UI is declared based on state • State changes trigger UI updates • State relies on the Observer/Observable pattern
20. Observable mutable value holder Remember something upon invocations
21. property delegation using by
22. • Stateless composables ◦ only depend on their input parameters (for the same set of parameters the same output is created) ◦ are composed when they enter the composition ◦ are recomposed when their input parameters change • Stateful composables ◦ hold state ◦ depend on their input parameters and state associated with them ◦ are composed when they enter the composition ◦ are recomposed when their input parameters or the state associated with them change
23. There’s more… • Composition over inheritance • Unidirectional data flow and state hoisting • Animation • Side effects • …
26. Java Beans specification
31. • ComposePanel allows replacing parts of a Swing UI with a Compose hierarchy • Should be used for branches of the component tree, not on a component level
34. Returns java.awt.Component or derived classes Called when related state changes (isImageSizeDisplayed) Size of the composable is controlled by the size of the (Swing) component
35. Webcam Capture API by Bartosz Firyn https://github.com/sarxos/webcam-capture
36. • SwingPanel helps adding Swing components to a Compose hierarchy • Should be used when… ◦ composables providing a similar functionality are not available ◦ the existing components hold considerable value (roi)
37. Things we saw • Jetpack Compose isn’t deeply integrated into a platform ◦ A root composable is placed inside a native container ◦ It has its own (highly customizable look) ◦ Two-way interop is provided on all supported platforms • Compose Desktop benefits from a rock-solid foundation: the JVM ◦ Everything possible on the JVM can be leveraged in a Compose Desktop app ◦ To access truly native libraries, for now we need JNI
38. Things we couldn’t cover • Enjoying the multiplatform benefits • Preconditions imposed by the framework ◦ Heavy focus on Gradle and related plugins ◦ Project structure • Functionality and features of the UI elements provided by Jetpack Compose
39. Should I use it? (Checklist) • Write a new app for the Desktop • Update an existing AWT/Swing app ◦ Evaluate converting the project to a structure defined by Compose Desktop or integrating the sources into a newly setup one ◦ Evaluate general fitness/stability of the app ◦ Evaluate the general code structure; is replacing individual parts possible or is everything intertwined? Go It depends
40. https://github.com/tkuenneth/compose-swing-interop Thank You!