jetc.dev Newsletter Issue #121

Published: 2022-06-21

1.2.0-rc01 shipped, which means a stable 1.2.0 can’t be too far away! 🎉

Beyond that, we spend a lot of time on animations, from MotionLayout() and AnimatedVisibility() to lower-level springs and flings, to flicking cards off of a stack. We look at Compose for Desktop windows and yet another take on navigation. And I worry a bit about people running away screaming from the Jetpack (Compose UI included).

RC Reflections

Reviewing the release notes for the latest Jetpack Compose update!

1.2.0-rc01 is now available! Of note:

  • If you happen to be using protobuf, those types are not automatically considered to be immutable

  • Similarly, the Compose compiler plugin now knows about Guava and kotlinx collections and their respective immutable types

  • Context receivers appear to be supported

  • Overscrolls can now be customized via an experimental OverscrollEffect

  • More support for meta keys was added, such as withKeysDown() and withKeysToggled() functions in KeyInjectionScope

Similarly, Wear Compose is up to 1.0.0-rc01, with a few fixes to ScalingLazyColumn() and the warned-about mandatory padding on CompactChip (so it has a height of at least 48dp).

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

How Can a Ripple Affect A Parent?

In the View system, widgets like Switch had associated text, and ripple effects would affect both the “real” UI and the text. In Compose UI, the corresponding composables (such as Switch()) do not have text, and you need to supply that yourself via a Text() composable. But… how do you get the ripple effect to cover both the Switch() and its Text()? Learn how in this week’s highlighted Stack Overflow question!

Do We Need State To Remember?

rememberSaveable() is almost always paired with mutableStateOf(). Is that a required combination? The answer is no, but it is probably the simplest solution, as we see in this week’s highlighted Kotlinlang #compose Slack thread.

Composable Commentary

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

Medium: Fixing Font Padding in Compose Text

Google’s Alejandra Stamato looks at recent changes to font padding, notably PlatformTextStyle and includeFontPadding from Compose 1.2.0. Alejandra compares and contrasts what Compose UI now offers with classic TextView options for font padding. Alejandra also show how Compose UI improves upon those platform approaches, such as supporting multiple fonts for font padding calculations.

Medium: MotionLayout AppBar in Jetpack Compose

One common aspect of the collapsing app bar pattern is for UI elements in the app bar to move as it is expanded and collapsed. Gideon Paul examines how to use MotionLayout() for this, to have the title and subtitle move as the app bar transitions between states.

Animating visibility vs alpha in Compose

We are used to animating the alpha of a View to animate the overall visibility, using the classic View system. James Shvarts explores AnimatedVisibility() in Compose UI and shows how it also removes the composable once it is invisible, akin to making a View be GONE at the end of an animation. James also looks at using animateFloatAsState() on the alpha of a composable to animate visibility while still having the composable take up space on the screen.

Spring & Fling Animations with Jetpack compose

Radhika S looks at animating the positions of composables, including adding bounce effects and animating a chain of connected composables.

Medium: Jetpack Compose bottom sheet over Android view using Kotlin extension

Ziv Kesten wanted an easy way to add modal bottom sheets to existing activities that are not yet fully implemented in Compose UI. In this post, Ziv shows how to create an Activity.showAsBottomSheet() extension function that does just that, using ComposeView to attach it to an existing activity without having to completely rewrite the activity’s layout.

Medium: Custom layout designing in Jetpack Compose

Saurabh Pant explores creating layouts with complex shapes, such as ones with rounded diagonal cuts. Saurabh creates a CurvedShape to describe the layout’s shape and creates a custom modifier to allow two diagonal-cut layouts to fit together.

Resource Roundup

100% pure code!

GitHub: X1nto / Taxi

GitHub user X1nto offers another option for lightweight Compose UI navigation. Taxi uses a sealed interface for destinations and a basic pop() function for navigating back.

GitHub: MayakaApps / ComposeWindowStyler

GitHub user MayakaApps created a library for Compose for Desktop to allow you to style the window your app runs in, from the backdrop to the corner shape.

Gist: c5inco / SwipeableCards.kt

Google’s Chris Sinco created a sample of flicking cards off of a stack, where a flicked card spins around several times as it heads to the back of the stack. See a video of the effect in Chris’ tweet about this work.

…And One More Thing

Last week, I wondered where are the other Google Play composable SDKs. That was with an eye towards Compose UI eventually “eating the world” — if Compose UI will become dominant in Android app development, then you will want your UI SDKs to be Compose-friendly.

The countervailing pressure comes from Android retroprogramming.

For the past several years, numerous developers have complained about the pace of change within Google’s recommendations and libraries. A subset of those developers have taken to abandoning much of the Jetpack outright, which presumably includes ignoring Compose UI. Their argument is that the quality of the Jetpack libraries is not great — combine that with forever chasing Google’s changes, and there is too much churn for too little value.

I appreciate their position. For years, I was anti-AppCompat, as it added a ton of bloat to solve a problem (“Material all the things!”) that Google itself invented. My concern was with low-end devices and the practical impacts of AppCompat on users. Eventually, AppCompat became all but mandatory, and I wound up moving through the “N stages of grief” (for some value of N) and reaching “acceptance”.

Saying that you don’t want to use Compose UI today is reasonable. It still has plenty of issues, and it has been stable for less than a year at this point. While Compose UI is gaining popularity, it has not yet “eaten the world”, and so there is plenty of time before adopting it becomes more pressing. And, even if Compose UI becomes dominant, if you want to ignore it for your own personal projects, that is your choice.

My concern is more in the commercial realm and development teams.

Some teams are big on creating their own app development frameworks that bear little resemblance to conventional Android app development. From a technical standpoint, that may make sense. However, if you wind up with staff who are expert in your custom framework and not so much in conventional Android app development, those developers will have difficulty working for other firms in the future. Some companies no doubt view that as a feature, not a bug: if developers have difficulty switching jobs, that can help reduce staff churn. However, it also may impede your ability to hire developers. Plus, from an ethical standpoint, companies have a responsibility for developing the skills of their employees, despite the risks of those employees leaving. After all, companies might shed those employees for any number of reasons, including layoffs and closures, and companies should not be leaving those employees worse off from a skills standpoint than when those employees started.

Similarly, saying “not yet” for Compose UI is reasonable, but “not ever” probably is not. You may think Compose UI is a buggy bloated bombastic bundle of bits. However, it is becoming a popular bundle of bits, regardless of bugs or bloat. Eventually, it is likely that developers who do not know Compose UI will have trouble getting jobs, just as Java-only developers do today. Conversely, your ability to recruit and retain talent may be curtailed if you are off on your own technology tangent. Some firms can get away with that, but not all.

Make sure that as you make technical decisions (“down with Jetpack! up with, um, ListView!”), that you take into account the flow of time and the flow of talent. In other words, technical decisions have ramifications beyond the technology itself.