View profile

jetc.dev Newsletter - Issue #40

alpha07 is out, and with it comes a bunch of API cleanup. In particular, renaming continues at a bris
jetc.dev Newsletter - Issue #40
By Mark Murphy, CommonsWare • Issue #40 • View online
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 roster.
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 puzzle.

One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
What's Our Configuration?
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…
Composable Commentary
Posts, videos, and other new information related to Jetpack Compose!
Compose Compiler Alpha 7 Release Notes
Compose Runtime Alpha 7 Release Notes
Compose Foundation Alpha 7 Release Notes
Compose Material Alpha 7 Release Notes
Video: Prototyping with Jetpack Compose
Video: Gaining Composure
Android Jetpack Compose: Navigation
Switching Locales with Jetpack Compose
Video: Let's Build with Compose!
Jetpack Compose: Intro & Basic Layouts
Resource Roundup
100% pure code!
GitHub - DevSrSouza / compose-icons
…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: Box(), Row(), Column(), LazyColumnFor(), etc. While a design system will use these composables, usually you do not need a CompanyBox() or 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 Basic as a prefix, so we get BasicText(), BasicTextField(), etc.
  • Composables that implement Material Design as a design system based on those Basic composables. So, Text() and TextField() are now material composables 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 org.awesome.compose.design.Text() that wraps the material edition of Text(), so you can still use Text() as 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 Text().
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 material 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.
Did you enjoy this issue?
Mark Murphy, CommonsWare

Jetpack Compose news and notes.

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue