By Mark Murphy, CommonsWare Newsletter - Issue #50





Subscribe to our newsletter

By subscribing, you agree with Revue’s Terms of Service and Privacy Policy and understand that Newsletter will receive your email address. Newsletter - Issue #50
By Mark Murphy, CommonsWare • Issue #50 • View online
alpha11 is out, so we take a tour of the release notes! There were a lot of changes this time around!
Beyond that, we look at View interoperability and testing, integrating Compose UI with ActivityResult APIs, and a piano-style keyboard composable. Plus, I fret about collisions between app-specific design systems and third-party composable libraries.

One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
Arctic Foxes and Clickables
Alpha Analysis
Reviewing the release notes for the latest Jetpack Compose update!
Compose Runtime Alpha 11 Release Notes
Compose Foundation Alpha 11 Release Notes
Compose UI Alpha 11 Release Notes
Compose Material Alpha 11 Release Notes
Composable Commentary
Posts, videos, and other new information related to Jetpack Compose!
Jetpack Compose Components (Part 3)
Video: Display Photo from Gallery with Jetpack Compose
Navigating in a pure jetpack compose project — part #1
Jetpack Compose: Custom List? Such ez, much wow. | by MJ Manaog | Jan, 2021 | Medium
Resource Roundup
100% pure code!
GitHub - fluxtah / pianoroll
GitHub - Veriqus / goldpare
…And One More Thing
There are design systems, and then there are design systems.
The argument that Google has made on a few occasions is that Compose Material is just one design system. Development teams are welcome to:
  • Just use Compose Material directly
  • Create their own design system that layers atop Compose Material
  • Create their own design system that avoids Compose Material and works with lower-level composables, the same way that Compose Material does
This is fine if we only think about the app’s code in conjunction with the various Compose libraries. The development team can aim to stick with their own design system’s functions when writing their own code.
The problem comes with third-party libraries.
These abound in classic View-based Android development. The expectation is that there will be many more for Compose, as creating a custom composable is so much easier than is creating a custom View.
The question then becomes: how does the third-party composable integrate with an app-specific design system?
For example, suppose that the library needs to render some text. The options are:
  • Use BasicText() from the Compose Foundation library
  • Use Text() from the Compose Material library
  • Somehow use the desired function from the app’s design system… except that the library does not know what that function is
I opened a Kotlinlang Slack thread on this. Google’s Adam Powell chimed in on it, and we had a fairly extensive discussion.
For lower-level composables — a date picker was the example we used — either:
  • The composable will need to expose a bespoke API for configuration details like fonts and colors, even if those might be available in some theme mechanism; or
  • The composable will assume MaterialTheme and use it, making Compose Material be part of the API
Perhaps some third-party independent theme engine will gain prominence and that will become a popular option.
Composables will exist at various levels though. An about screen will be a composable, for example. Ideally, there would be some relatively easy way to teach an about screen composable about how to blend into the app’s design system.
Regardless, I still have concerns about the intersection of app-specific design systems and third-party composable libraries. I guess we will learn over time how well these will integrate.
Did you enjoy this issue?
Mark Murphy, CommonsWare

Jetpack Compose news and notes.

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue