|Gmail, content providers, and formalising support..||Mark||6/26/11 3:42 PM|
Gmail functionality has been augmented for some time now by app
developers using the gmail-ls content provider.. now i know that the
default response in mentioning this is "it's not supported, not
intended to be used by 3rd parties, and is actively discouraged", but
nonetheless some developers have put it to good use providing
important features to users.
With honeycomb, something has changed with the provider, thus breaking
the functionality of these apps, and yes i realise again the response
will be "tough luck, thats what happens when you use unsupported apis
and functionality", and i *completely* appreciate that. What i'm
interested in is more if there will ever be concrete support for
developers to access the gmail content provider or some equivalent api
to provide the kind of functionality people actively require these
I don't know what has changed with the content provider exactly, it
could be something trivial, or perhaps its now locked down because of
concerns regarding applications accessing user emails for some reason,
but the reason i'm asking is primarily because, to developers that aim
to augment gmail usage for users on android, they face two ways of
achieving this: 1. use the gmail content provider, or 2. implement
their own binding to gmail to access the data they require, using
something heavyweight like javamail.
With option 1. users are informed via manifest permissions that an
application will be accessing their gmail data (and informed whether
it's just read, or r/w access), and the overhead of potential apps can
be minimised thanks to relying on the existing db, and the presumably
fairly well designed and efficient background services for maintaining
said db and communicating with the gmail servers.
With option 2. users won't necessarily have that obvious flag that the
app is using the gmail data (albeit at some point they will have to
authenticate via the app), and the developer will have to implement a
custom solution for monitoring changes to mail, leading to more
background services, with potentially multiple solutions polling the
imap servers indiscriminately or worse, periodically hitting up the
atom feeds, duplicating functionality and eating up cpu time, battery
life, and network bandwidth.
I realise this probably isn't the best mailing list to try, and that
the google apps are maintained as a separate project from android as
such, but i'm hoping someone on the gmail team sees this and some
thought can be put into supporting developers here. Perhaps it's a
trivial change that some enterprising soul will figure out, but
regardless i think formalising support for things like this would be
of benefit to everyone, rather than the current "don't ask, don't
tell" policy of using unsupported content providers like this.
|Re: [android-developers] Gmail, content providers, and formalising support..||Mark Murphy||6/27/11 3:58 AM|
On Sun, Jun 26, 2011 at 6:42 PM, Mark <mmc...@gmail.com> wrote:
I inquired about formalizing support for these undocumented content
Of all of them, Gmail would seem to be the least likely to be
Android Training in NYC: http://marakana.com/training/android/
|Re: [android-developers] Gmail, content providers, and formalising support..||Dianne Hackborn||6/27/11 5:08 PM|
This is purely an issue for Google with their gmail application.
I don't know that much about what goes on with the Google apps, but I suspect it is very unlikely for there to be an API like this. At the very least, I would say giving the user access to read all of your e-mails is *way* more serious than just throwing it behind an install-time permission. Consider other things that need more than that: IMEs, device admins, etc.
So I would not hold my breath for this.
Android framework engineer
Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.