jetc.dev Newsletter Issue #31
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!
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() implements a Material Design text-entry field.
an ordinary text-entry field. The relationship between these composables causes
some confusion, as we see in this week’s highlighted Slack thread.
Posts, videos, and other new information related to Jetpack Compose!
A lot of focus on Markdown with Compose UI is converting the Markdown source
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.
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.
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?
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.
100% pure code!
…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.
- 2021-07-20: rc02! Preview and ViewModel, together again! Coil supports Compose! MVI! @dequesystems on accessibility! Screenshots of composables! D-pad support! And... Context code smells?!?
- 2021-07-13: Focus! Viewports! Navigation! @divyajain2405 talks about architecture! Screenshot testing! Sliders! Reorderable lists!
- 2021-07-06: RC01! Navigation! Phones *and* tablets! Cards! Timers! Barcodes! And... the