jetc.dev Newsletter Issue #40
alpha07 is out, and with it comes a bunch of API cleanup. In particular,
renaming continues at a brisk pace, as Google starts organizing their composable
This week, we look at
alpha07, along with the broader issues around design systems
in the Compose UI world. We also peek at testing, locale-switching, server-driven
theming, and a bunch of composable icons! And, we try our hands at creating a crossword
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
This week’s Stack Overflow question asks about finding out whether the UI is portrait
or landscape. Probably that is the wrong question — it is better to focus on
available height and width, to take into account a wider range of scenarios, such
as split-screen and multi-window. But, sometimes you need to know the orientation
for other reasons, or you need other elements of the configuration. For that, use
As it did a couple of months ago, the
question of composable names came up. This sort of thing usually comes in the form
of: “Why is
TextField() using Material Design? Shouldn’t that be
In this week’s highlighted Slack thread, we explore more about Google’s thinking
in this area and how some developers are trying to use base names, like
for their own custom design systems.
Also, due to a screwup on my part, those of you who got the newsletter via email received a broken link to last week’s “One Off the Slack” entry. I apologize for my mistake. Note to self: do not put apostrophes in URLs…
Posts, videos, and other new information related to Jetpack Compose!
Due to a change in metadata, “composable functions compiled with the alpha07 compiler will not be binary compatible with composable functions compiled with any earlier compiler version”. Be careful with third-party libraries and make sure they get updated!
Text() is now
BasicText(), and the new
Text() is a
composable. Also, if you were using
CoreText(), switch to
BaseTextField() is now
CoreTextField() is now
considered to be an internal API. A bunch of ambients (e.g.,
AmbientContentColor) were moved to
material; if you are not using Material Design,
you will need to create your own theming ambients. There were a lot of changes in
this library — see the release notes for more!
Localazy is a service for helping translate and localize your app. Their Android SDK includes being able to switch locales on the fly within your app. Václav Hodek of Localazy wrote up a post showing how to integrate their SDK into your Compose UI app.
100% pure code!
Gabriel Souza used his
code to bulk-convert a few free icon packs into composables, akin to how we have
the Material Design icon set available to us as composables.
…And One More Thing
Google is continuing to clean up the Compose UI API to center around design systems.
As I covered previously, a Compose design system is basically a set of composables that implement the core building blocks of your designers’ desired aesthetics. If your designers want buttons with a particular background color, shape, and border, you create a composable that defines such a button, so the rest of your code can then just use that composable. If the designers change their minds and tweak what that button should look like, you change the button composable in your design system, and everything else automatically adopts the change.
In the end, it appears that we will be getting roughly three categories of composables in Compose UI:
Composables that do not draw anything themselves. Key examples of this are your containers:
LazyColumnFor(), etc. While a design system will use these composables, usually you do not need a
DesignRow()that somehow embodies design rules.
Composables that handle basic operations and are unopinionated (and perhaps are a bit plain as a result). It appears that Google is standardizing on
Basicas a prefix, so we get
Composables that implement Material Design as a design system based on those
materialcomposables and adhere to Material Design aesthetics. These offer limited flexibility, specifically because they are supposed to adhere to Material Design rules.
If your designers are sticking pretty close to Material Design, your project’s
design system can be based on the
material composables, wrapping them to configure
them for project design standards. If your designers are ignoring Material Design,
your project’s design system will be based on the
Basic family of composables,
wrapping them to apply your desired aesthetic.
Google’s apparent objective is for teams to use package names to distinguish composables
from different design systems. For example, you might have
that wraps the
material edition of
Text(), so you can still use
the composable name. That, in turn, will drive the creation of Lint rules to help
ensure that only the design system uses the
material edition of
Text(), as auto-complete
may cause developers to accidentally use that instead of the design system’s
Personally, unless we get some really good tutorials or other solutions for creating
and maintaining those Lint rules, my guess is that projects will lean towards
AwesomeText(), with a prefix denoting the design system, to better distinguish
the design system’s composables from those supplied by Compose UI. There is a bit
more discussion of this point in this week’s “One Off the Slack” entry.
Regardless, I think the
Basic cleanup is a good move. The more that
can be a true design system atop of
Basic, the more likely it is that teams will
have success creating their own similar design systems.
- 2021-10-12: Overscroll! Responsive layouts! Accessibility! Reorderable lists! Foldables! Testing with an Espresso wrapper! And... testing with robots?!?
- 2021-10-05: 1.0.3! 1.1.0-alpha05! Scopes! Compose in production! rememberUpdatedState()! And... particles of Compose?!?
- 2021-09-28: @androidamanda on declarative UIs! Keyboard handling! Swapping themes! Pickers, pickers, and more pickers! And... LED matrix displays?