jetc.dev Newsletter Issue #17
In this issue, we look at states and threads, Joe Birch’s latest work, and
what properties you can add to a
@Preview. Plus, I look at a likely Compose
casualty: data binding.
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
This was not a good week for Compose questions in Stack Overflow. If you have questions, don’t be afraid to ask!
Posts, videos, and other new information related to Jetpack Compose!
100% pure code!
…And One More Thing
Jetpack Compose is likely to be real, and it is likely to be spectacular. While it is possible it could go the way of past promoted technologies (slices, I’m looking at you), that seems unlikely. There is too much engineering effort going into Compose, and the competitive pressure of Swift UI should prevent Compose from getting sent to the dustbin. On the contrary, I expect Google to be promoting Compose extensively, with a campaign reminiscent of how they promoted Kotlin, once they elected to support it.
A theme that I will be returning to from time to time, such as in an upcoming presentation, is how we can be preparing our apps to be ready for Compose, once Compose becomes stable.
One of the likely casualties of Compose is data binding. Data binding is based on binding expressions in layout resources, and Compose largely does away with layout resources. Instead of a mix of layout resource XML, binding expression syntax, and the Java/Kotlin in your activities/fragments/presenters/etc., Compose lets it all just be in Kotlin.
This does not mean that you need to be ripping out your data binding today, if you adopted it. However, projects that had been considering a move to data binding might want to reconsider. Perhaps more so than any other single bit of existing Android technology, data binding feels like something that will become “tech debt” rapidly once Compose ships in stable form.
If you encounter problems in subscribing, let us know!