jetc.dev Newsletter Issue #49

Published: 2021-01-26

This week, we look at extending Button() and the proper use of AndroidView(). We continue examining Navigation for Compose (and an alternative) and learn more about Compose for Desktop. We also get a peek at how to put composables in a system overlay view. And, I start to beat the drum on expectation management, as what you get out of a Compose migration may not exactly match what you put in.

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

Long Press on a Button()

Composables supplied in Compose UI, particularly in Compose Material, may not offer all the features that you want. A Material Button(), for example, does not support long-press or double-click support. However, as part of your own design system, you may be able add in the missing event handlers, as we see in this week’s highlighted Stack Overflow question.

The Role of AndroidView()

AndroidView() offers a very convenient way to get a classic View into a composable hierarchy. Some worry that it may be a little too convenient, as it is being used in unexpected ways, as we see in this week’s highlighted Kotlinlang Slack thread!

Composable Commentary

Posts, videos, and other new information related to Jetpack Compose!

Navigating with Jetpack Compose

Francisco Barrios walks us through the use of Navigation for Compose to navigate between four different composables, with a FAB to rotate between those composables.

Podcast: Jetpack Compose Desktop with Sebastian Aigner

JetBrains’ Sebastian Aigner recorded a podcast with The Developer’s Bakery, exploring Compose for Desktop, how it relates to the main Compose and Compose UI projects, and how you can get started with it.

Resource Roundup

100% pure code!

GitHub: mallumoSK / navigation

GitHub user mallumo created a navigation library for Compose. This library uses annotations to identify composables that serve as destinations, with a KSP-based compiler plugin to generate code for navigating to those destinations.

GitHub: JetBrains / compose-jb intelliJPlugin

JetBrains continuously updates the examples in the Compose for Desktop repo. One new one demonstrates how to create an IntelliJ IDEA plugin using Compose for Desktop. The demo just launches a window with some sample composables, but it hints at how JetBrains is looking to apply Compose for Desktop for helping us extend their IDE.

Gist: handstandsam / MyLifecycleOwner.kt

In last week’s issue, we explored how to apply Compose UI in unusual situations, specifically for an input method editor (a.k.a., soft keyboard). Sam Edwards pushed Compose UI into another unconventional area: system overlays. The code in this gist demonstrates how to have a floating window that is populated by a composable.

GitHub: vipulasri / ComposeSlackDesktop

Vipul Asri used Compose for Desktop to create a demo of a Slack-style chat client.

…And One More Thing

Compose UI is different.

Not only is it radically different in terms of how we write it, but the resulting UI is not necessarily going to match any specific existing UI. The more complex the UI, the more likely it is that the Compose UI implementation will differ in some ways from what you would make using the classic View system.

For example, in a Kotlinlang Slack thread, a developer pointed out that the behavior of ViewPager, with respect to things like page snapping, looks a bit different than existing composable equivalents.

This is going to be unavoidable.

Even when Compose reaches its first stable release, there may be differences between a Compose-based UI and any View-based predecessor. The objective of the Compose team is to create a powerful, flexible, and forward-thinking UI toolkit. It is not to offer pixel-perfect (and gesture-perfect, animation-perfect, etc.) equivalents of our existing UI toolkit.

For new apps, this is not a problem, as there is no history to compare against. For existing apps migrating to Compose, though, this may be an occasional issue. Designers, managers, and users may get a bit of an “uncanny valley” sensation as a seemingly-unchanged UI exhibits subtle changes.

One way to try to address this is to couple migrating to Compose with other substantial UI changes in the screen. Compose will be blamed less if there is a more significant break with the visual history of the screen, as you add, remove, or otherwise modify what that screen offered.

In the end, migrating to Compose will involve a level of “expectation management”. Ideally, designers and managers judge the results of the migration on its own merits, rather than considering differences to be “wrong” by definition. How development teams manage those expectations will depend a lot on the team, the app, and the people whose expectations matter.

But if you are assuming that your Compose-based UI will be completely identical to what you have today… that is not out of the question, but it may be a lot of work to achieve.