jetc.dev Newsletter Issue #68
beta08 is out… with breaking changes! 😞
Beyond that, we see that Compose sometimes is black-and-white, explore more with navigation and custom progress indicators, get some custom views code-generated for our composables, and enjoy sliced fruit. Plus, with Compose for Desktop’s next update available, I look back to see how some earlier predictions of Compose targets are holding up.
Reviewing the release notes for the latest Jetpack Compose update!
This update had more changes than is desirable for a late beta release, let alone for a complex framework that is weeks away from a scheduled stable release, such as:
compose-uimoved a bunch of enums to
inline class, among other changes
Surface()now consume clicks, so you need to use new variants of those composables that accept
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
While some people want to add color to old black-and-white images, sometimes
developers need to go in the opposite direction. We can remove color via
ColorMatrix and the
colorFilter parameter on
Image(), as we see in this week’s
highlighted Stack Overflow question.
Posts, videos, and other new information related to Jetpack Compose!
JetBrains released an update for Compose for Desktop, complete with a new window API, better support for pointer events and tooltips, undo/redo support for text entry fields, and general rendering improvements.
Adam McNeilly is back, with a short screencast outlining a common question: why can I use a particular modifier in one place and not another? The answer is in the form of scopes: the objects that serve as the receivers for the content lambda expressions that we use with common composables.
Lachlan McKee wanted to use Navigation for Compose, but he grew concerned with
the potential for a
NavHost to become a “god object”, if it has to be able
to navigate everywhere. In this post, Lachlan explores using Hilt to decouple
route registration, such as having one route factory on a per-feature-module basis.
Waseef Akhtar continues an exploration of Compose, this time applying Navigation for Compose to get from a list of content to a detail screen for an individual item.
Abhishek Dewan offers a quick rundown of how
AnimatedVisibility works, to provide
a custom transition between two composables, such as a transition between showing
all content and the results of some sort of search or filter operation.
Andrey Molochko wanted a progress bar that used a gradient instead of a fixed
color to depict the amount of progress. Andrey’s approach uses a pair of
composables, one of which uses
Brush.horizontalGradient() for its background.
Continuing on the theme of progress indicators, Philipp Lackner returns with another
take on a progress bar, this one built using a
Canvas() and an animated effect to
show transitions to a particular progress level.
John Codeos brings us a tutorial for setting up a
Scaffold() with a top bar and
a bottom navigation bar. John then uses Navigation for Compose to navigate between
screens from that bottom navigation bar.
Mark Allison is back, continuing a look at the list/detail UI pattern. This time around, Mark looks at how to align the “split point” between the two patterns based on the hinge of a foldable, so the UI can transition between patterns based on fold/unfold actions.
Other Interesting Links
- Creating a Curved Scroll View with Jetpack Compose
- Kotlin Compiler Plugins and Binaries on Multiplatform
- Goodbye, RecyclerView Adapters — Hello, Lists in Jetpack Compose
100% pure code!
Tyler Wong is back, bringing us a KSP-based code generator! This one creates custom
View subclasses wrapping composables that you annotate with
@BridgeView. This can
help as part of a migration from a pre-Compose UI to a Compose-based one.
Not everyone is enamored with Material Design, and designers sometimes hop onto
other design trends, such as skeuomorphism or “neuomorphism”. Nikhil Chaudhari,
being curious, created a
neumorphic() modifier to adjust the shadows on existing
composables to apply a neumorphic look to them.
…And One More Thing
About seven months ago, I wrote a blog post about where Compose could go. This was written after the first milestone release of Compose for Desktop shipped, and I ran down some other possible Compose targets:
Web: I pointed out that JetBrains appeared to be working on this, and they did indeed release a Compose for Web recently. I had expected that it would take the Skia canvas approach; instead, they are focused more on composables manipulating the DOM. In other words, this is Compose, not Compose UI/Compose Material.
iOS: I was not expecting much here. As usual, Jake Wharton pushed the envelope, demonstrating composables driving a UIKit interface. Once again, this is Compose, not Compose UI/Compose Material.
Chrome OS: As I wrote then, we have both Android and Linux options, so we are in reasonable shape here. It will be interesting if somebody does create a Compose for Web variant that uses the Skia canvas, with an eye towards using it for Chrome OS, Chrome extensions, or other “installed” Web apps.
Fuchsia: Since I wrote that post, Fuchsia is slowly being rolled out to the Google Home Hub. However, there is still little sign of third-party apps, let alone ones that might be based on Compose.
The real fun is with “Platform X”. Here is what I wrote then:
If you were trying to create a new platform, to compete with the desktop, mobile, and Web options that we have today, your new platform will need apps. Adopting one of the cross-platform options (React, Flutter, Compose) would help a fair bit in getting developers interested in trying your platform, at least for conventional apps. For gaming-centric platforms, trying to adopt Unity 3D or similar cross-platform game engines would be the likely starting point.
If Google alone were pursing Compose, it would likely be an Android thing and that’s it. The fact that JetBrains has apparently decided to make Compose a focus area means that Compose is going to go further than just Android devices. We will have to see how well that turns out — after all, there is no guarantee that Compose will succeed beyond Android. But it has a lot of promise, and it will be interesting to see how the next 12 months or so play out!
To me the real power of Jake’s iOS demo, or Jake’s mosaic, or even Google’s likely forthcoming Compose for App Widgets, is to further demonstrate how we can drive UI with Compose without that UI being defined by Compose. Some Compose targets include Compose UI/Compose Material (Android, desktop). Some do not (iOS, terminal, app widgets). Some do not now but could, as an option, in the future (Web).
So, if you are creating Platform X, you can adopt Compose and decide the level of Compose support that you want:
- Composables, but to drive your own UI framework
- Composables, using a canvas to give you Compose UI/Compose Material support
- A “combo play”, where you offer your own UI composables but also support the canvas
These non-Material Compose targets demonstrate that the first option is viable and is not necessarily all that difficult. It is arcane — there are only a few people who know how to pull this off. But, given enough interest, the arcane can be codified, documented, and supported.
It will be interesting to see where else Compose goes and who might adopt it for some never-seen-before platform.
- 2021-09-07: 1.1.0-alpha03! Parcelable in Navigation... or not! SideEffect! Recomposition! Sharing KMP code! Grids! Timeline UIs, and timelines of stable releases!
- 2021-08-31: rememberUpdateState()! Paging! AndroidView()! @TouchlabHQ on animations and a composable KaMP Kit! Decompiled composables! And how sloppy use of custom views can hinder migration to Compose UI!
- 2021-08-24: 1.1.0-alpha02! Dependent modifiers! Input validation! Live text! Auto-sized text! And... performance anxiety?!?