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
ContentProvider subclass, and it will use the
content scheme, and I
content was the only option.
When I rummaged through the source code for slices themselves (e.g., the
artifact), I did not see any signs of
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)
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
SliceProvidercome in the form of
PendingIntentobjects. A Web slice might use URLs instead. Those with
schemes would be wrapped in
Intentobjects; those with
intentscheme would be used verbatim with
Or, perhaps there might be an encoding that triggers simple Web service
GETrequests 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
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 allowed by law! 🙂
thanks you RSS link