jetc.dev Newsletter Issue #65
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!
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.
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
StateFlow, in this week’s highlighted Kotlinlang
#compose Slack thread.
Posts, videos, and other new information related to Jetpack Compose!
Francesc Vilarino Guell returns, this time looking at implementing a
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!
Rikin Marfatia delivered a presentation for Android Worldwide exploring the power
@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.
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.
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.
Joe Birch returns, this time looking at
ComposeView for adding composables to
an existing ordinary view hierarchy, whether at runtime (e.g., for
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.
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
100% pure code!
…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
a developer is using the MapBox SDK to display maps.
That SDK is not Compose-ready, so the developer is wrapping the MapBox
in a Compose
AndroidView — the standard approach for adding a
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
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.
- 2021-06-08: beta08! Effects! Compose for Desktop! Navigation! Progress indicators! @MarkIAllison on foldables! And... fruit?!?
- 2021-06-01: Inside the compiler plugin! @zachklipp on reactive state and snapshots! Lottie! Kotlin/Native! Internationalization! And... app widgets?!?
- 2021-05-25: Google IO 2021! beta07! Mixing text and composables! State holders! Staggered grids! Bazel! And... digital wellbeing?!?