jetc.dev Newsletter Issue #41
This week, we look at lots of conference videos and screencasts on Compose, including a Googly panel discussion. We also explore units of state change, play more with Compose for Desktop, and look at a theme engine. Plus, we get just a bit more animated.
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
TextField() composable supports a
KeyboardOptions parameter where you can
specify what the action button of the input method editor should show (e.g., Done,
Next, 🔍, etc.). However, that just controls the action button caption. To do something
based on the user tapping that button, use the
TextField(), as we see in this week’s highlighted Stack Overflow question.
SnapshotStateList<T> seem similar: they offer Compose
state tracking for lists of some type
T. However, their change semantics are
significantly different, as we explore in this week’s
#compose Slack thread.
Posts, videos, and other new information related to Jetpack Compose!
Lottie is a powerful, cross-platform solution for encoding and rendering animations. Not surprisingly, there was a lot of interest in a version of Lottie for Compose, and in this Medium post, Gabriel Peal announces the first alpha of such a solution!
Vinay Gaba presented at the 2020 Android Summit and gives us a tour of the Compose
and Compose UI foundation, from basic UI elements to dialogs, recomposition, and
interoperability with existing
View-based Android code.
Another Compose UI presentation from the 2020 Android Summit comes from Wajahat Karim. In this case, he walks through his port of the Chrome T-Rex endless runner game that we mentioned here a few weeks ago.
Vinay Gaba is busy! He also moderated a panel discussion for droidcon Americas 2020, where Doris Liu, Ian Lake, Sean McQuillan, and Leland Richardson of Google weigh in on Compose and Compose UI concerns.
Jorge Castillo is back, with a post on effect handlers. Our composables can run at arbitrary times, as Compose determines what needs to be re-rendered based on state changes. Also, composables can get disposed at arbitrary times, such as when the user navigates to a completely different screen. This makes triggering work with side effects — such as I/O — a bit tricky in Compose. This post reviews how effect handlers can help us manage that work.
Joe Birch returns with a long post on steps that you can take now to help prepare your app for a Compose UI future, even if you will not be migrating to Compose for a few years. He covers concepts like state management, unidirectional data flow architectures, and business concerns (do we really need to support Android 4.x and older?).
Daniele Baroncelli brings us a three-part Medium post series on declarative UIs in the world of Kotlin/Multiplatform, looking at architecture, particularly MVI and how to apply it for both Compose, SwiftUI, and React.
A few months ago, we saw Arkadii Ivanov’s Decompose library, which offers its own take on navigation within a Compose app. He returns this week with an article exploring how Decompose can also work with Compose for Desktop, offering cross-platform navigation support.
All Techies returns with a pair of screencasts around applying Navigation for Compose. This one covers the basics, while the follow-on screencast explores passing arguments as part of navigation.
100% pure code!
Jonathan Lagneaux created a sample Kotlin/Multiplatform library module, with client apps for Android and the desktop using Compose UI (along with an iOS client app). The library is for sharing crepe recipes, which is a tasty subject! 😁
Ben Trengrove ported Nick Lockwood’s chess app for iOS to Android and Compose UI. An an extra benefit, the AI apparently needs work, so winning may be easy!
…And One More Thing
Jorge Castillo’s post on effect handlers is a nice introduction to the topic. It also scares the 💩 out of me, in terms of trying to train future generations of Android developers.
Effect handlers help to highlight how much Compose relies upon its Kotlin compiler plugin and the resulting “compiler magic”. Compiler magic is a double-edged sword:
Experts can get more done more quickly, by avoiding excess syntax
Complete newcomers can get up to speed more quickly, because there is less syntax to have to learn
Middle-tier developers who try to make sense of what is going on may become baffled, because they cannot see the missing syntax and cannot learn from it
Kotlin coroutines also relies upon compiler magic. However, that is limited to a
suspend. Everything else comes from a library and is fairly
visible. Developers learn by identifying patterns and seeing how to apply them in
new situations. With coroutines, much of what makes up those patterns is visible.
With Compose, much of what makes up those patterns is hidden:
Why do calls to composables actually affect the UI, despite their being bare functions decoupled from any specific classes? Magic!
rememberactually remember anything? Magic!
How can a function have a lifecycle? Magic!
And so on
You can try to explain the mechanics of that invisible stuff, in terms of slot tables and the other actual artifacts that make up a “composition”. But, they are largely hidden away, with good reason. The whole point of the compiler magic is to simplify Compose development. It just makes trying to explain to middle-tier developers that much harder.
That is not to say that the Compose team is making the wrong choice here. It does mean that I am scared for how this educational process will play out. As I described Kotlin when it gained popularity: there is a fine line between “concise” (little extraneous stuff) and “terse” (sub-standard intrinsic knowledge). Only time will tell whether we can categorize Compose as “concise” or “terse”.
If you encounter problems in subscribing, let us know!
- 2021-01-12: layout()! Navigation with Parcelables! Custom drawers! Compose for Desktop! And Compose... for iOS?!?
- 2021-01-05: Navigation arguments! ViewModel? Shapes! GraphQL and Compose! More shimmers! In-browser Compose! And the power of names!
- 2020-12-22: alpha09! @chrisbanes on how Compose impacts APK complexity and build times! Scaffold()! Staggered grids! Calendars! Design systems! And... mistakes were made!