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.
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.