jetc.dev Newsletter Issue #36
alpha05 shipped, bringing changes to
Scaffold(), coroutine integration, and the
roster of ambients.
Beyond that, in this week’s issue, we look at converting
ConstraintLayout (the composable). We also explore the semantics API,
infinite scrolling, and how Epoxy and Compose compare. Plus, we play some games, with
cards and falling blocks.
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
ConstraintLayout is available in Compose UI, there are some key differences
in how you use it. In the traditional
ConstraintLayout, they overloaded
a width or height to mean “fill to the anchor points defined by constraints”.
In Compose UI, that now is a
fillToConstraints dimension value, as we explore
in this week’s highlighted Stack Overflow question.
In the run-up to official Navigation support for Compose, how do we switch between screens efficiently? Do we just render what we need, or do we render everything and switch which portion is visible via changes in elevation? We’ll take a look at that issue in this week’s highlighted Slack thread.
Posts, videos, and other new information related to Jetpack Compose!
FLAG_SECURE changes mentioned in the last issue were released.
If you are using
Scaffold(), note that
drawerGesturesEnabled is now a parameter
Scaffold() itself, rather than being tied into
ScaffoldState. Also note that
some content lambda parameters no longer accept
null to indicate that there is no
content – use
Bryan Herbst explores Compose’s semantics API. Partly, this is used for things like accessibility. Partly, this is useful for testing, associating custom properties with nodes in the composable tree, so we can verify certain behaviors.
Elye is back with another few posts on Compose, this one focusing on comparing and contrasting Compose with classic Android app development. Elye also has a post exploring animations in Compose, using an analog clock with moving hands as an example. And, Elye also wrote about how to update your UI based on user input and Compose’s concept of state.
100% pure code!
…And One More Thing
One of the many things that hopefully will arise out of the drive towards Jetpack Compose is an increased focus on design systems.
A simplified description of a design system is: it is a library of reusable elements (e.g., composables) that represent the building blocks of the app’s UI.
Ideally, graphic designers create such a library in their favorite design tool. So, they define the basic button shapes, the common field layouts, the standard checkbox looks, and so forth. For some projects, those might simply be Material Design with specific colors and typography. For other projects, those might be more “from scratch”, perhaps in a drive to have a common design system between Android and iOS.
If graphic designers describe their UIs in terms of a design system, developers can create implementations of the design system, then build up the UIs from those individual elements. If the designers decide to change an element of the design system — perhaps tweaking the font sizes a bit — that change would not only ripple out through all the designs, but the corresponding tweak to the element’s implementation would ripple out through all of the screens.
Right now, design systems tend to be the the sort of thing that only large or sophisticated teams try to pull off:
Some of the popular design tools do not lend themselves towards the rigorous definition and application of a design system, leading designers to treat every screen as a “one-off” design
Implementing a design system in classic Android development requires a fair bit of work spread out over a lot of files (style/theme resources, dimension resources, color resources, layout resources, Java/Kotlin code, etc.).
Compose greatly simplifies the creation of a design system, as it mostly turns
into a series of custom composables. So, instead of using
straight from the Compose UI libraries, you use
from your design system, where you create those functions to embody the characteristics
that the designers call for.
Hopefully, design tools will evolve to help designers define and use a design system, one that developers can then implement in Compose UI. Alternatively, we might be able to create tools that live alongside Figma, InVision, etc., where the add-on tools define the design system and annotations in the design tie back to the design system elements.
Regardless, the fact that Compose puts everything in Kotlin will at least help on the development side of a design system, and that will be a benefit for long-term app maintenance.
If you encounter problems in subscribing, let us know!