jetc.dev Newsletter Issue #49
This week, we look at extending
Button() and the proper use of
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!
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.
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!
Posts, videos, and other new information related to Jetpack Compose!
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.
100% pure code!
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.
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.
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.
…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
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.
- 2022-05-17: Google I|O 2022 videos! Compose beta01! Layout()! State! drawBehind()! Credit cards! App intros! And... what's a horologist?!?
- 2022-05-10: StateFlow vs. State! Design systems! MotionLayout! Text editing problems and solutions! And... modal sheets that are actually modal?!?
- 2022-05-03: @aditlal and @JorgeCastilloPr on design systems! KMP + Compose + SwiftUI! Dropdowns! FABs! And, what does Google I|O 2022 have in store for Compose UI developers?