jetc.dev Newsletter Issue #90

Published: 2021-11-09

1.0.5 and 1.1.0-beta02 are out, albeit with minimal changes — we look at what changes we got. We also look at derivedStateOf(), flowable grids, and navigation rails. And, I ponder what sort of tools we could create that would help us detect composables that run amok.

Beta Breakdown

Reviewing the release notes for the latest Jetpack Compose update!

A 1.0.5 patch release is out, with a derivedStateOf() tracking bug fix.

1.1.0-beta02 is also available, and it adds:

• The actual “bring into view” API, in the form of BringIntoViewRequester (teased but apparently unavailable in beta01)

• A fix to ripples and indications in general, to allow them to be more responsible to touch events when outside of scrollable containers

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

Are Navigation Resources Obsolete?

If you used Jetpack Navigation and its navigation XML resources in your fragment-based app, you will need to redo that navigation in Kotlin as part of employing Navigation for Compose. Learn more from Google’s Ian Lake in this week’s highlighted Stack Overflow question!

When Do We Use derivedStateOf()?

derivedStateOf() lets you create a new State from existing State objects. However, depending on your use case, it may be overkill. See the alternatives in this week’s highlighted Kotlinlang #compose Slack thread!

Composable Commentary

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

Compose for Wear OS: Navigation

Nikit Bhandari continues a tour of Compose for Wear OS, this time looking at how Navigation for Compose blends with Compose for Wear OS using SwipeDismissableNavHost, allowing users to go forwards and backwards within a Wear OS overlay.

Video: Migrating a Large-Scale Banking App to Compose

A few weeks ago, I posted a link to slides from Fatih Giriş’ presentation on using Compose in a large app. The 45-minute Android Worldwide conference video is now up!

Medium: Creating a Dynamic Grid in Jetpack Compose

Francesc Vilarino Guell returns, this time looking at creating a flowable grid: a grid that takes its child composables and their sizes and places them in the grid based on those sizes, one after the next, flowing onto subsequent rows as needed. Francesc implements this using Layout, a custom GridScope, and a lot of calculations.

A Closer Look at Modifier in Jetpack Compose

Jintin examines Modifier, peeking at the implementation (an interface and an object!), the impacts of Modifier order, and how to scope a Modifier to a particular composable.

Jetpack Compose Navigation Rail

Kristen Halper of Microsoft covers NavigationRail(), designed as a replacement for bottom navigation for large screens. Kristen shows how to use both NavigationRail() and BottomNavigation() on foldables, based on the fold state.

Multi-Theme Screenshot Tests in Jetpack Compose

Fábio Carballo demonstrates how to implement Shot-based screenshot tests that take into account design systems and multiple themes, such as light and dark themes. Fábio uses JUnit parameterized tests to allow you to write tests once and test them across the different themes.

Slides: Jetpack Compose - The New Way of Building Android UI

Umar Saidu Auna delivered a presentation to GDG-Kano with an overview of Compose UI, what it means for a UI to be “declarative”, and the basics of getting a Compose UI app up and running.

Medium: Figma2Android: How We Made a Figma Plugin to Speed Up UI Development in Jetpack Compose

Medium user Accessible co-created a Figma plugin that converts a Figma diagram to Compose UI code. Learn more about how they created the plugin and what it offers!

Other Interesting Links

• Jetpack Compose: Modifiers Fundamentals
• Streamlining Navigation in Jetpack Compose
• Responsive Layouts Using BoxWithConstraints in Jetpack Compose
• Multiplatform Compose and Gradle Module Metadata Abuse
• Video: Search Widget/App Bar with Jetpack Compose
• Medium: Login / Logout Flow: Android Jetpack Compose and CompositionLocal
• Awesome Dialog with Jetpack Compose
• Medium: Understanding Stateful & Stateless in Jetpack Compose
• Medium: Jetpack Compose Basics

Resource Roundup

100% pure code!

GitHub: jkuatdsc / form-builder

GitHub user jkuatdsc has started work on a form management composable, for declaring a series of input fields with validation rules, then applying those rules as needed across the entire form.

GitHub: atick-faisal / compose-material-color

Atick Faisal put together a small library that makes all of the Material Design colors available as constants.

…And One More Thing

Overcomposing — the act of recomposing a composable too many times — is going to be a problem until we create some tooling to help.

I profiled a Slack thread a couple of weeks ago where the developer was overcomposing. I and others helped someone on Twitter with an overcomposing problem. We had another overcomposing thread on Slack last week. And I guarantee that many more developers will encounter this sort of problem.

In many ways, overcomposing is a side effect of the compiler plugin magic that makes composables so svelte. We do not explicitly control when composables get recomposed. Rather, the Compose engine figures that out on its own, dutifully recomposing whenever we trigger it, even if that winds up being far too frequently.

I can see different types of tools that could help us identify and address overcomposing.

The “visually slick but probably complicated” solution would be the sorts of system overlays that we were given for seeing where overdraw occurs. Overdraw is redrawing the same pixel multiple times, usually because of overlapping views. While overdraw is less of a concern on modern hardware, in earlier Android times, overdraw could hammer performance, particularly in scrolling lists. To help us see where overdraw is occurring, Google added a developer option to tint the UI based on the amount of overdraw. I could see there being a similar mechanism for Compose UI, where something tints the UI based upon the number of times that particular branch of composables was recomposed. Of course, doing this without causing more recompositions might be tricky.

Another approach would be something akin to StrictMode, where something would log problems when they were detected. This might even offer crashing the app in debug builds, to make sure that developers see the problem (vs. the Choreographer messages that developers often miss). Since StrictMode itself is non-extensible (😞), we would need to do something outside of it.

Another way would be to handle this as a profiling problem, ensuring that method tracing adequately covers recomposition, and perhaps adding smarts to tracing tools to help indicate why a composable is being recomposed.

Most likely, there are many other possible tools besides those. But I feel that we are going to need something, as I fear that too many developers are going to run into too many problems by recomposing composables too many times.