jetc.dev Newsletter Issue #90
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.
Reviewing the release notes for the latest Jetpack Compose update!
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
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!
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!
derivedStateOf() lets you create a new
State from existing
However, depending on your use case, it may be overkill. See the alternatives
in this week’s highlighted Kotlinlang
#compose Slack thread!
Posts, videos, and other new information related to Jetpack Compose!
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.
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!
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.
Kristen Halper of Microsoft covers
NavigationRail(), designed as a replacement
for bottom navigation for large screens. Kristen shows how to use both
BottomNavigation() on foldables, based on the fold state.
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.
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
100% pure code!
…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.
- 2022-09-13: Compose updates! Tracking down and fixing recompositions! Maestro! Redwood! Molecule! And Twitter's rules for composables!
- 2022-09-06: Snapshots! A Glance support library! Measuring and drawing! Swipe-to-dismiss! Speed dials! And... a redwood sighting?!?
- 2022-08-30: Android 13 per-app language support! Performance optimizations! Expandable lists! MVI! Zooming! Steppers! And... another Compose beta? Already?!?