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

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

The Busy Coder’s Guide to Android Development: the most Android knowledge by law! 🙂


Source link
thanks you RSS link


Please enter your comment!
Please enter your name here