jetc.dev Newsletter Issue #37

Published: 2020-10-27

The Compose community contributions continue to climb!

In this issue, we will look at an exception handling hiccup with Compose, see a growing catalog of composable libraries, learn how to translate React-isms into Compose constructs, and examine how to tailor the status and nav bar colors from your composables. Plus, I’ll rant a bit on how Compose does not want you to use dp for your text size, even though that’s what your designs (unfortunately) probably call for.

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

Center Composable

While there used to be a dedicated Center() composable, that has since been removed. If you need to center something, you need a container in which to center it, as we see in this week’s highlighted Stack Overflow question.

Compose and try/catch

You might think that calling a composable from within a try block would not present a problem. As it turns out, it does, as we see in this week’s highlighted Slack thread.

Composable Commentary

Posts, videos, and other new information related to Jetpack Compose!

Jetpack Compose Catalog

Vinay Gaba’s site has expanded to include a roster of Compose-related libraries, organized by category.

Video: Ask Googlers About Jetpack Compose

This Droidcon EMEA video is of a panel of numerous Google engineers and GDEs, answering questions about Compose and Compose UI.

Compose Insights

Bruno Aybar is doing something akin to the “One Off the Slack” posts on this site, trying to capture knowledge from Slack threads and expose them to a wider audience. Bruno’s is set up in a FAQ style, covering a lot of ground from the role of ambients to the timing of recompositions.

React to Jetpack Compose Dictionary

React and Jetpack Compose share common objectives and some of the same concepts, though those concepts often appear with different names and different approaches. Tiger Oakes is maintaining a site to help React developers understand the Compose equivalents of various React constructs.

Video: Converting an existing app screen to Jetpack Compose (Part 1)

Google’s Material Design team is starting to run some screencasts related to revamping an existing app to use Compose UI.

Jetpack Compose Interop Part 1: Using Traditional Views and Layouts in Compose with AndroidView

Dai has two posts up on integrating Compose with legacy code that uses the classic View system. This one focuses on using AndroidView to show a View as a composable. Part 2 explores the inverse scenario, using ComposeView to render a composable as a View for embedding a layout.

Exploring Jetpack Compose: Card

Joe Birch returns, with a quick rundown of how the Card() composable works for rendering a CardView-style rounded-rectangle-with-drop-shadow UI element.

Android: Utilizing Jetpack Navigation With Jetpack Compose

As we continue to wait very very patiently for the Compose-ready edition of the Jetpack Navigation component to ship… Trevor Holliday has a post on using the existing fragment-centric Navigation component for Compose, powered by fragments and ComposeView.

Choosing the right architecture for a new Kotlin Multiplatform, Jetpack Compose and SwiftUI app

Marco Gomiero wrote a post describing some work to create a Kotlin Mulitplatform Mobile (KMM) app, with Compose for the Android UI and Swift UI for iOS. In particular, this post focuses on how to set up an architecture that can work across the two platforms.

Create Art Using Jetpack Compose

Akash Kamble wrote up his experiences with using Compose’s Canvas() for rendering arbitrary content, in this case some animated artwork.

Jetpack Compose Layouts

Spikey Sanju has a brief post reviewing the usage of Column() and Row() composables.

Resource Roundup

100% pure code!

Gist: chrisbanes/SystemUi.kt

This gist contains code for a SystemUiControllerAmbient that lets you attempt to set the status bar and navigation bar colors from your Compose UI code.

GitHub: alorma / ComposeDrawer

Bernat Borrás Paronella has implemented a debug drawer in Compose, with build and device details, along with the possibility of custom modules for your own debug items.

Gist: AdrianoCelentano/SimpleSlider.kt

GitHub user Adrian has posted a pair of slider gists. This one is a conventional linear slider, while this one is circular.

…And One More Thing

Another Slack thread that caught my attention this week had to do with text sizing. Note that the link requires you to be a member of Kotlinlang Slack, and if you are not, consider signing up at https://slack.kotlinlang.org.

Basically, courtesy of some fun approaches to data types, the fontSize argument on Text() will not work with a Dp value, such as you might get from 16.dp. It requires a TextUnit.Sp (e.g., 16.sp) or TextUnit.Em value.

This is a nudge from the Compose developers. We should be using sp for text sizes, so that not only are the sizes independent of density but also scale based on the user’s font size selection in Settings. The equivalent nudge in the classic View system comes in the form of a Lint warning, complaining about using dp for text sizes.

And, in the end, developers are going to work around it, because they have to, just as they have ignored the Lint warning.

In an ideal world, designers would design UIs that take font scaling and other accessibility concerns into account. No doubt some designers do that… but not all do and not all do consistently. Even Google doesn’t do it consistently – try the YouTube app at maximum font scale sometime, and you will see that the bottom nav does not adapt. Plenty of other major tech brands, such as Adobe and Apple, do not consistently support font scaling. And as you head to smaller or less-technical firms, handling font scaling becomes less and less likely.

I would love it if this nudge would cause designers and management to adopt robust support for font scaling. That is ludicrous.

As a result, developers will apply hacks, rather than lose their jobs.

The Slack thread points out one workaround: with(DensityAmbient.current) { size.dp.toSp() } will convert a size number (Int, Float, etc.) into a TextUnit.Sp value based on the current font scale. It seems to be slightly inaccurate, in that the resulting font size is not completely independent of font scale, but it is close. Most likely the details of any such workaround will change between now and a stable Compose release, but some workaround will exist. We need to know the density and font scale for other reasons, and after that, it’s just math.

Frankly, I’d be happier if Google applied a Lint warning, rather than forcing screwy code, to pester developers about addressing font scaling. The existence of Compose is not going to cause designers to take font scaling into account, as if by magic.