Slices From Afar

From the “Things That Make You Go ‘Hmmmmm’” Department…

Recently, I was puttering through the source code to Google’s Slice Viewer app. This app can be used by developers to test their slices, since we, um, don’t have many (any?) real places to use slices right now. I was double-checking to see if my own implementation of a slice host was missing anything of note that Slice Viewer used from the slice APIs.

As I was wandering through the code, I noticed something very curious: Slice Viewer supports slices coming from three Uri schemes. A SliceProvider is a ContentProvider subclass, and it will use the content scheme, and I thought that content was the only option.

But Slice Viewer also has code that specifically shows support for http and https, such as here and here.

When I rummaged through the source code for slices themselves (e.g., the slice-core artifact), I did not see any signs of http/https support, though my search was fairly cursory. It is entirely possible that the Slice Viewer code was for some experiment and never got cleaned up, or perhaps it is for some internal implementation of the slice API that has not been released yet.

But, it’s worth considering the possibilities here.

Most of what makes up a slice is a snapshot of static data: text, images, and metadata about how those should be rendered (lists, grids, etc.). That could easily be obtained from a Web site. If you wanted to minimize the round trips to the server, you might package the whole slice up in single payload, using protobuf to blend text and binary content in a single blob. AFAICT, slice data is already being published as a stream (versus a database structure) from a SliceProvider — a stream from a Web server is just another stream, perhaps with a distinctive MIME type.

This would allow Web sites to surface content directly in arbitrary slice-enabled Android apps, without custom code in those apps. Just by hosting and rendering slices, you would be able to support slices from both local providers and Web sites. Interested brands could publish Web slices with an eye towards having them lead users either back to the Web site or to use the brands’ Android apps, perhaps even including Instant Apps.

This is not a perfect solution. Some functionality of local slices would be lost:

• Unless they decided to bring websockets into the mix, there would be no good way to push slice data updates from the Web server to the client. Polling would be an option, of course, based on a supplied expiry time, but… ew.

• Slices can have actions, which for a SliceProvider come in the form of PendingIntent objects. A Web slice might use URLs instead. Those with https schemes would be wrapped in ACTION_VIEW Intent objects; those with the ill-used intent scheme would be used verbatim with startActivity(). Or, perhaps there might be an encoding that triggers simple Web service GET requests back to the server. Still, those are less flexible than the options available to local slices.

• Local slice providers — at least those implemented using official code — are secured. The user has to agree to allow the slice host to have access to slices from the slice provider. It is unclear how that sort of permission grant would be mapped to Web slices.

Discovery of Web slices is as big of an issue as is discovery of locally-available SliceProviders. How does a host know the Uri to use? Obviously, Google could do stuff through their own search engine, but what about the rest of the Android ecosystem?

So, I don’t know if there is anything to the http/https code that exists in Slice Viewer. But it is something that I will be watching for, as it could really change the way that we think about slices.