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.
Or, you can subscribe to the Atom feed or follow Mark Murphy in the Fediverse.
Recent Issues:
- 2024-12-03: Rebecca Franks on clipping and masking! Stefano Natali on graphicsLayer()! FunkyMuse on type-safe nav results! And... if we have enough maps, do we need to store our maps in a Map?!?
- 2024-11-26: Math! Shared element transitions! Custom modifiers! Macrobenchmark! Adapting to platform-specific design systems! And... why does wrapContentSize() not wrap my content size?!?
- 2024-11-19: Compose alphas! Compose Multiplatform patch! PaddingValues! Graphics layers! Swiping! Heatmaps! Navigation! And... why did we get a new production Compose BOM?!?