Sharing UIs

Over Android’s history, many developers have wanted to embed the UI of one app in another app. However, support for this pattern was lacking, in part due to the performance limitations of early-generation Android devices.

Android 11 seems to be unwrapping a new approach to this problem, one that may make cross-app UI embedding much more practical and powerful. In this chapter, we will explore how this mechanism works and what its current limitations are.

UI Embedding: The Classic Approaches

If you have ever created an app widget or a “custom view” for a Notification, you have worked with RemoteViews. This is the primary way for one app to provide a hunk of UI to be embedded into another app, such as the UI for an app widget to be embedded in a home screen of a launcher. RemoteViews, though, have not been significantly improved since API Level 11. You can use relatively few widgets with them, and the only real event that you can respond to is a click.

Technically speaking, RemoteViews is simply a data structure describing a UI. It is entirely possible to create your own replacement for RemoteViews that uses a different data structure, in an attempt to get past the limitations of RemoteViews. Android 9’s slices, for example, take this approach, even allowing it to be available via a Jetpack library for use with older devices. However, slices is more aimed at describing data to display, where some client code decides how to render that data. This adds flexibility at the cost of control — graphic designers, for example, cannot get “pixel perfect” UIs if the client can elect to render a slice differently than does another client.

As a result, most cross-app UI work has been handled simply between activities, with App A starting an activity of App B when needed. This certainly works, but it is very coarse-grained, usually with each app taking over the screen of the phone or tablet.