jetc.dev Newsletter Issue #65

Published: 2021-05-18

Google I|O is here! I outlined a bunch of Compose-related sessions last week.

While we wait for the Googly goodness to be presented, we explore architectural concerns, such as sources of truth. We also look at pagers and previews, KMM and daggers, and themes and… more themes. We also see a number picker, and I explain why Compose UI will not eliminate our per-platform compatibility problems (though it will help).

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

Single Source of Truth

With screens being implemented by composables, it sometimes becomes confusing to determine how to get data from Screen One to Screen Two. Google’s Ian Lake emphasizes establishing a single source of truth, such as a repository, in this week’s highlighted Stack Overflow answer.

MutableState or StateFlow?

A related problem is in making sense of what to use out of the sea of reactive solutions. Here, we look at Compose’s own MutableState when compared to Kotlin’s StateFlow, in this week’s highlighted Kotlinlang #compose Slack thread.

Composable Commentary

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

Creating a ViewPager in Jetpack Compose

Francesc Vilarino Guell returns, this time looking at implementing a ViewPager page-at-a-time swipe solution in Compose UI. Accompanist offers paging composables in a library, but here Francesc dives deep into the details of how to implement this sort of pager yourself, including swipe inputs, animations, and more!

Video: Preview Driven Development

Rikin Marfatia delivered a presentation for Android Worldwide exploring the power of the @Preview annotation. The subtitle is “Avoid build times at all cost!”, and Rikin looks at how to to use multiple modules to allow your composables to be previewed quickly.

Video: Recomposition - Jetpack Compose

Stevdza-San gives us a brief walkthrough of what compositions and recomposition means in Compose, how State drives recomposition, and what impacts recomposition has on the way we write our composables.

Video: KMM with Jetpack Compose and SwiftUI

Karan Dhillon gave a presentation for the Chicago Kotlin Users Group exploring using reactive UI frameworks on Kotlin/Multiplatform using the KMM framework. The slides are available as well.

Jetpack Compose: Styles and Themes

Waseef Akhtar continues an exploration of Compose UI, this time looking at applying custom colors, including dark/light themes, to a Compose-based app.

Extending Material Theme in Jetpack Compose

The Xmartlabs team continues on the theme of themes, and looks at what role a theme plays in Compose Material and how to extend it for app-specific themeable properties.

Migrating to Compose - ComposeView

Joe Birch returns, this time looking at ComposeView for adding composables to an existing ordinary view hierarchy, whether at runtime (e.g., for RecyclerView rows) or in a layout resource. Joe also looks at AbstractComposeView and using that for creating custom views that happen to be implemented in the form of composables.

Dagger 2 and Jetpack Compose Integration

Alexey Glukharev looks at how dependency inversion frameworks integrate with Navigation for Compose. In particular, Alexey explores using plain Dagger 2, without Hilt, for this integration.

Make an Awesome Bottom Navigation using Jetpack Compose

Sourabh Mandal dives into Navigation for Compose and how to integrate it with Scaffold() and BottomAppBar() composables for implementing the popular bottom-nav UI pattern.

Other Interesting Links

• Video: Android Jetpack Compose Networking with Ktor Client
• Infinite auto-scrolling lists with RecyclerView & LazyLists in Compose
• Jetpack Compose : State & Constraint Layout
• Kotlin and Compose for Desktop - The Balloon Years
• Cartographing Jetpack Compose: compiler and runtime
• Slides: Clean Architecture with Jetpack Compose

Resource Roundup

100% pure code!

GitHub: marcauberer / compose-number-picker

Marc Auberer published a library with HorizontalNumberPicker() and VerticalNumberPicker() composables, for incrementing and decrementing a value via buttons.

GitHub: timeline-notes / Composables

This repository contains a few standalone composables for common UI patterns: chips, expandable containers, “message box”-style dialogs, and a seek bar.

…And One More Thing

One of the cited advantages of Compose UI is that it is a library, distributed independently from the framework classes distributed in Android firmware. The primary touted benefit of this is the ability to control updates: you decide when to switch to a new version of Compose UI. With framework classes, you get whatever the device offers you, for the devices that your app runs on.

The primary reason why those framework classes may differ is Android OS version — widgets occasionally get new methods or XML attributes. However, in addition to that, device manufacturers have an annoying history of tinkering with widget implementations, sometimes resulting in incompatibilities. By contrast, a device manufacturer has no ability to modify how your copy of the Compose UI library renders its composables.

However, you will still encounter some problems, at the points where you need to integrate with existing framework classes.

For example, in this Kotlinlang Slack #compose thread, a developer is using the MapBox SDK to display maps. That SDK is not Compose-ready, so the developer is wrapping the MapBox MapView in a Compose AndroidView — the standard approach for adding a View to a composable hierarchy. In particular, the developer is then trying to layer a composable on top of the MapView on the Z axis.

This appears to work on some devices but not others, particularly not on a certain Huawei device.

Presumably, there is some compatibility hiccup between Huawei and MapBox that is causing problems for the composables. It is unlikely that the problem is Compose’s fault directly — if it were, you would expect the buggy behavior to exist across devices, and apparently it does not. It is possible that the bug is more on MapBox’s side, or it might be on Huawei’s side. I suggested in that thread that the developer might want to test the framework widgets that MapBox uses, such as a SurfaceView or TextureView. If a framework class exhibits the same problem, then the issue is more specific to Huawei; if the problem can only be reproduced using MapBox itself, then perhaps MapBox is more to blame.

Over time, this situation should improve. More and more SDK developers will offer Compose-based SDKs and reducing their reliance on framework classes, particularly if they want to offer their SDK on other supported Compose platforms, like Compose for Desktop. Also, we will start developing guidelines for debugging these sorts of problems — in this case, is Huawei doing something that affects the elevation of the MapView, such that it is being drawn over the composable instead of under it?

But, just bear in mind that while Compose UI helps apps be less dependent on things that manufacturers might modify, Compose UI is not a complete insulation layer. There is a chance that you will still run into device- or manufacturer-specific problems, even with Compose UI. This is just “one of those things” that make Android app development more challenging, and that is not changing any time soon, with or without Compose.