jetc.dev Newsletter Issue #31

Published: 2020-09-15

This week, we look at the difference between types of text fields, get a double dose of Sean McQuillan, and see a bunch of sample apps blending Compose UI with other other technologies, like Hilt and ExoPlayer. Plus, we see that not everybody likes Compose.

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

Applying Multiple Styles to Text

With Modifier, we can chain one after the next, to describe a sequence of effects that we wish to apply to a composable. TextStyle takes a slightly different approach, with a merge() function to combine individual styles, as we see in this week’s highlighted Stack Overflow question.

TextField and Names

TextField() implements a Material Design text-entry field. BaseTextField() implements an ordinary text-entry field. The relationship between these composables causes some confusion, as we see in this week’s highlighted Slack thread.

Composable Commentary

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

Video: On the Road to Jetpack Compose

In this 360|AnDev conference video, Google’s Sean McQuillan and Tiem Song review Compose UI and popular related topics, such as architecture and state management.

Podcast: Talking Jetpack Compose in Alpha with Sean McQuillan

Sean McQuillan also appeared on an episode of the Talking with Apples podcast, reviewing the state of Compose, its toolchain, themes, and more.

Rendering Markdown with Jetpack Compose

A lot of focus on Markdown with Compose UI is converting the Markdown source into an AnnotatedString to render using Text(). In this blog post, Erik Hellman expands upon that, using AnnotatedString for inline formatting and using other composable functions for blocks, such as headers and lists.

Video: Scrollable List with Jetpack Compose

All Techies offers up a screencast-style video showing how use LazyColumnFor() and related composables for setting up a simple vertically-scrolling list.

Exploring Jetpack Compose: Padding Modifier

Joe Birch returns with a deeper dive into the various types of padding that you can add in Compose UI via Modifier functions. Remember: in Compose UI, “padding” handles both padding and margins in classic View system, so we spend a lot more time thinking through padding structures in Compose UI projects than we might have done for views.

Jetpack Compose Quick Bytes

Vinay Gaba is starting in on a series of Twitter threads with “quick bites” of Jetpack Compose knowledge. The first one focuses on the term “declarative UI”. We use this to describe things like Compose and Flutter, but what does it really mean? What are we declaring?

Android Jetpack Compose Is Welcome, But What About The Churn?

Not everyone is super-happy about Compose. Nikos Vaggalis outlines a contrarian view of Compose, one that points out some of its downsides. Simply put: big changes like Compose cause some developers to abandon Android app development, as they lack the time or desire to learn Yet Another New Technology, let alone rewrite everything to accommodate that new technology. Compose, like Kotlin and the Architecture Components, represents progress, but it is unrealistic to assume that there are no casualties caused by that progress.

Resource Roundup

100% pure code!

GitHub: tylerbwong / stack

Tyler Wong has released a Stack Overflow client that is being slowly migrated to using Compose UI, alongside other new technologies like Hilt and Kotlin Gradle scripts.

GitHub: Sh4dowSoul / Compose-Scrobbler

Niklas Schnettler offers up a “scrobbler” (music tracking app), one that also blends Compose UI and Hilt.

GitHub: vipulasri / JetInstagram

Vipul Asri brings us an Instagram lookalike app, built using Compose UI and Exoplayer.

Gist: ExpandCollapseButton

Prat Tana offers a small composable for rendering and animating a caret, such as you might use to show an expand or collapse of a panel.

…And One More Thing

The “what about the churn?” post demonstrates a not-too-surprising reaction to Compose.

New Android development technologies get hyped relentlessly, from Gradle to the Architecture Components to Kotlin to MotionLayout and now to Compose. This very newsletter contributes to that hype. Usually, the technologies being hyped are positive developments, solving key problems in Android app development. Many thought leaders in Android rapidly latch onto how these technologies solve problems and, as a result of their enthusiasm, feed the hype engine.

The problem is that hype is not always a positive thing, even if what is being hyped is positive.

Not every developer is in position to drop everything, learn the new technology, and apply it. Worse, developers deal with wave after wave of hype in different ways, including “tuning out” the hype or simply getting out of Android app development. Developers who think they can never catch up may simply drop out.

The “drop out” approach gets exacerbated when hyped technologies get forced onto developers. Gradle is a vast improvement over prior Android build systems, such as Ant and the one intrinsic to the Eclipse IDE. However, Google went from “we will continue to support Eclipse indefinitely” to “we are not supporting Eclipse” in little over a year, effectively forcing the hands of developers to switch to Gradle whether they were ready to or not. Similarly, Google has stated that they will continue to support Java indefinitely… but technologies like Compose will be awkward fits at best with existing Java-centric code bases.

To counteract this, we need to ensure that we provide lots of levels for adopting Compose, beyond a “smash cut” rewrite of an entire app. To date, and to some level, we have this: key Compose developers have pointed out that incremental adoption of Compose is possible, with a smattering of examples.

By the time Compose ships its first stable release, we will need a lot more of this, from Google and from the community. We need developers to feel confident that they can migrate to Compose, and do so on their own timetable. Developers need to believe that Compose can be added incrementally to an app, without a full app rewrite. It is insufficient for this ability to merely exist — developers need to believe in it, which means that they need to find out about progressive Compose adoption and how to implement it.

I hope to be able to do what I can to help with this. And if you are writing a lot about Compose, it would be good if you could focus a portion of your time on the progressive-adoption problem. Let’s not lose Android developers who get overwhelmed with the technology churn — let’s instead help them not only learn how to use Compose, but how it can work alongside what they already have built.