With a Feed, What Could We Deliver?
AppBrain has a fairly slick site, as do some of their competitors. However, they collectively suffer from one fatal flaw: they rely upon the Android Market feed. And, since I and others have requested access to this feed and have been told it is not available, it is a reasonable assumption that AppBrain and kin are accessing this feed in an unauthorized fashion.
(If anyone has evidence that Google is indeed licensing the Android Market feed to third parties, please let me know!)
We, as developers, need a feed that is public, as a platform for innovation — not innovation of apps (necessarily), but innovation around the experience of finding, obtaining, using, and socializing apps.
Alas, the Android Market feed, today, is a poor foundation. Ignoring any moral or legal implications of using it in an unauthorized fashion, it could change at any time, or even be removed by technical means. Unsupported APIs are risky propositions, not the sort of thing you want to base an ecosystem around.
Hence, if we want such a feed, we are going to have to build it ourselves, and try to convince Android developers to make their app metadata available to the feed.
However, a feed is only as useful as are the products and services that leverage it. Just because we have a whole bunch of metadata out there does nobody any good, unless we put it to practical and effective use.
I can think of any number of things we could do given a robust and rich metadata feed:
Help users filter apps via advisory services, such as noting disturbing permission combinations or warning against apps that come from app spammers
Let users know about apps that arise that might interest them via notification services
Help developers make better apps — and help users get comfortable with those apps — via standardized about screens or help menus driven by an app’s own metadata
Help users discover apps that integrate with ones they already have, via generic
ACTION_SEND), such as offering an
Intent.createChooser()variant that not only lists apps they have, but gives them an option to search for apps they do not have that support a particular interface
But, having a rich roster of potential use cases will help us design proper metadata. Hence, we could really use your input.
If you can think of things that somebody could offer, given a rich set of freely-available, easy-to-consume app metadata, let us know!
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!