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.

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.

However, 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 RemoteViews). However, Compose UI needs some lifecycle support, and Yannick ran into problems with that. Not only does InputMethodService not offer any Lifecycle-related APIs, but we cannot even use something like LifecycleService, as that is set to extend Service, not InputMethodService.

Yannick eventually figured out how to grab code from ComponentActivity to create an InputMethodService with support for LifecycleOwner, ViewModelStoreOwner, and 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 for 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.