Upgrade to Pro — share decks privately, control downloads, hide ads and more …

What about a desktop app?

What about a desktop app?

As Android devs, we don't generally do desktop development. They might do some scripting, but as soon as you need a user interface and want to use Kotlin in your desktop app, things get quite desperate. Swing is an old tech that’s impervious to newcomers and full of gotchas; JavaFx and TornadoFX aren’t much better; and using frameworks like Qt from Kotlin is going to take a toll on your mental wellbeing.

Or at least, this used to be the case!

We’ll see how, with Compose for Desktop, you can take much of your existing UI skill set from Jetpack Compose and apply it to create tools that run on desktop computers. There are some gotchas and some differences to be aware of, and this talk will cover them pointing out what is and isn’t there yet in Compose for Desktop.


More info on the talk, and a list of all the links, can be found at: https://go.sebastiano.dev/desktop-app-2021

Sebastiano Poggi

October 28, 2021

More Decks by Sebastiano Poggi

Other Decks in Programming


  1. A guide to Compose on desktop for the curious Android

    dev Sebastiano Poggi What about... a desktop app? @seebrock3r
  2. Notable differences • Lifecycle is much easier • Window chrome,

    menu bars, tray icons • Less restrictions • E.g., full filesystem access, no permissions system • Some things require "going down" • Swing and/or P/Invoke via JNI
  3. IDE support • Compose Multiplatform plugin • Also supports web

    • Android Studio and IntelliJ IDEA • Tooling is lagging behind Jetpack Compose's • No interactive preview and animation inspector • Missing many quality-of-life tweaks
  4. Familiar faces • Core Compose libraries: runtime foundation ui material

    • Same packages and API names as Jetpack Compose • Compose compiler plugin • Requires Kotlin (duh)
  5. Android-only APIs • No access to anything outside: • androidx.compose.*

    • java.* • kotlin.* • No permissions • No Android-only dependencies • Architecture Components • Other Jetpack libraries • Firebase • etc What's different Old-school UI Resources a11y UI testing
  6. What's different • No Android Views • MapView, etc •

    No WebView equivalent • Interop with "classic" Java UI • Swing hosts Compose • Compose can wrap Swing • No activities and fragments • Different (easier) lifecycle • Swing windows Android-only APIs Old-school UI Resources a11y UI testing
  7. What's different • Java resources system • No buckets •

    No concept of configuration • No orientation, display size, etc • I18n support is not built in • No RTL support yet • No animated GIFs • No animated vector drawables • Non-animated are supported • Resource refs not resolved • Lottie not supported yet • Maybe Skottie in the future? Android-only APIs Old-school UI Resources a11y UI testing
  8. What's different • APIs are there, but not hooked up

    • semantics() • Work in progress • Should be there for 1.0.0 • Current state: • Mostly works on macOS • Other OSes done next • No clue about ETAs, sorry Android-only APIs Old-school UI Resources a11y UI testing
  9. What's different • Not entirely true, it's mostly the same

    • UI testing is the same as on Android • Except, of course, (much) faster • Use createComposeRule() • Additional API (e.g., mouse scroll) • Fun idea: run your UI tests on CfD • Screenshot testing is different • TestComposeWindow • WIP: APIs for animations Android-only APIs Old-school UI Resources a11y UI testing
  10. Unique features • Desktop is different from mobile • Unique

    needs == unique features • Windowing • Multiple windows at the same time • Compose handles JFrames for you
  11. Unique features • Enhanced keyboard support • Keyboard shortcuts •

    Tooltips • Menus, tray icons, desktop notifications • Native installers (msi/exe, dmg/pkg, deb/rpm) • Output size saving tips • Notarization for macOS
  12. Unique features • Scrollbars • Yes, Jetpack Compose still doesn't

    have those • Works with scroll modifiers and LazyColumn/LazyRow • Mouse events • Pointer movement (hover) • Modifier keys and mouse buttons
  13. Unique features • Desktop-only components & integrations • Split panel

    • Video player • CEF-based WebView (outdated) • LWJGL integration
  14. Unique features • Desktop-only components & integrations • Split panel

    • Video player • CEF-based WebView (outdated) • LWJGL integration EXPERIMENTAL
  15. Libraries • A lot of JVM-only libraries out there •

    Some direct replacements • Some Android libs make no sense on desktop • Well, most don't • Some Accompanist libs work on desktop • Pager, Placeholder, FlowLayout, Swipe-to-Refresh (?)
  16. Libraries • No Play Services • No Firebase • Java

    or REST APIs for some • No Architecture Components • No ViewModel, Navigation, Room, Hilt, etc
  17. Library alternatives Navigation Decompose Room SqlDelight Hilt Dagger Timber Arbor

    Coil/Glide/Picasso/... Hand-rolled ! ViewModel Essenty's InstanceKeeper (but it's not really the same)
  18. Theming • Material theme is fully supported • Material You

    will, as well • Material is not great on desktop • Huge touch targets for use with mouse • There is no "official" desktop-oriented UI framework
  19. Distribute your app • Gradle tasks to build installers •

    OS-specific outputs • macOS is different • Requires notarisation • Signing to make Gatekeeper happy • Only required to distribute, not to run locally
  20. Life outside app stores • No Play Store, Amazon Appstore,

    Samsung App Gallery • No auto-updates, built-in licensing and IAB • Some Java libs may help to compensate (e.g., update4j) • You may be able to publish on OS stores... • But mileage may vary • May be harder on macOS App Store
  21. Closing remarks • Kotlin Multiplatform support • Share business logic

    • Share some degree of UI code (Android and Desktop) • Web is totally different, hard to share • Check out Jake Wharton's Mosaic