View profile

jetc.dev Newsletter - Issue #121

jetc.dev Newsletter - Issue #121
By Mark Murphy, CommonsWare • Issue #121 • View online
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?
Composable Commentary
Posts, videos, and other new information related to Jetpack Compose!
Medium: Fixing Font Padding in Compose Text
Animating visibility vs alpha in Compose
Medium: Spring & Fling Animations with Jetpack compose
Medium: Jetpack Compose bottom sheet over Android view using Kotlin extension
Medium: Custom layout designing in Jetpack Compose
Resource Roundup
100% pure code!
Other Interesting Links
…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.
Did you enjoy this issue?
Mark Murphy, CommonsWare

Jetpack Compose news and notes.

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue