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 Intent actions (e.g., 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!