jetc.dev Newsletter Issue #48
alpha10 is out! So, this week, we look at the release notes and see what changes
are in store (focus, animation, and more). We also look at floating action menus,
charts, and the Surface Duo. Plus, we look at the challenges we face when applying
Compose UI in unusual situations, such as for implementing an input method.
…and we see how to ellipsize text.
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
With the classic
TextView, we have ways to control how many lines are used
for our text and what to do when we run out of room (e.g., append an ellipsis).
BasicText() offers similar
overflow properties to control
this behavior, as we see in this week’s highlighted Stack Overflow thread.
Box() has some convenient modifiers in its
BoxScope, such as
to cause a child to size itself based on the parent’s size. Those modifiers
are only available on
Box(), though. However, there are more flexible alternative
solutions for the same problem, as we see in this week’s highlighted kotlinlang
Reviewing the release notes for the latest Jetpack Compose update!
If you have written utilities or similar code that work at a low level with
nodes, you may run into a breaking change in
alpha10. There is a new batch API
for applying changes to nodes, and apparently you do not have access to nodes
until those changes get applied. The release notes mention a workaround using
SideEffect to defer execution of your code until the proper time.
Some focus-related improvements were released, including a
modifier to let you control focus traversal.
animate() is now
with a corresponding change in the return type to be a
State rather than just
the underlying type being animated. And there is a new
Posts, videos, and other new information related to Jetpack Compose!
Thomas Kuenneth continues documenting his Compose for Desktop experiences, this
time with a look at showing desktop dialogs and shows how
AlertDialog() gives you
a lot of control… which you need to get the dialog to look and work correctly.
Thomas also has another post up this
week, continuing his examination of the
Canvas() API in Compose UI.
100% pure code!
In 2020, Microsoft released the Surface Duo, an Android-powered dual-screen device. Microsoft has been pretty good about making code samples available to show how to work with those dual screens, and this repo contains Compose UI-specific examples.
…And One More Thing
Right now, the focus is on using Compose UI for traditional activity/fragment-style Android app screens. This is perfectly reasonable, as those screens are the backbone of most apps.
View gets used in a number of other places and other ways. Over time,
we will need to identify which of those can be adapted to work with Compose UI.
For example, GitHub/Stack Overflow user Yannick has been experimenting with
Compose UI… for an
InputMethodService. We should be perfectly capable of
creating soft keyboards using Compose UI, as that is all in-process UI
rendering (as opposed to app widgets or other use cases for
However, Compose UI needs some lifecycle support, and Yannick
ran into problems with that.
Not only does
InputMethodService not offer any
but we cannot even use something like
LifecycleService, as that is set to
Yannick eventually figured out how to grab code from
to create an
InputMethodService with support for
SavedStateRegistryOwner. This GitHub repo
contains Yannick’s results.
Other areas will need similar treatment. In the “Resource Roundup” section,
I pointed out Microsoft demonstrating using Compose UI for the Surface Duo’s dual screens.
I expect to do some work tying Compose UI into
Presentation for external display
support (monitors, projectors, etc.). And, undoubtedly, there will be other
use cases for this sort of solution.
We might get official support for these atypical
View consumers from Google.
But, in many cases, I suspect that we will not. For example, I will be surprised
(but pleased) if Google offered an official rendition of Yannick’s solution
InputMethodService. Google does not have infinite amount of development
time, and so the “long tail” of
View consumers may get neglected. It will
be up to the Yannicks of the world — the Android developer ecosystem —
to fill in the gaps.
What I do hope for is some official guidance for the general approach to take for filling in those gaps. While Yannick’s approach looks reasonable, there may be some subtle API nuances that Yannick and I are missing, ones that may prove important over time.
- 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