On Jan 7, 5:16 am, Mark Murphy <[email protected]> wrote: > On Fri, Jan 7, 2011 at 2:30 AM, Bob Kerns <[email protected]> wrote:
> You forgot the battery of permissions, one per email app, needed to > give users control over what app/spyware can receive these broadcasts. > Otherwise, though, you're probably on the right track tech-wise. I didn't forget, but I did omit the issue to focus on the main point. But you'll note that my suggested minimal protocol side-steps the issue by not exposing anything about the email other than its arrival, except via an optional content provider URL. That's where the permissions would hook in. > > This doesn't take a whole lot of design, or a whole lot of code. It > > simply involves having enough WILLPOWER to make a few decisions, and > > communicate them. > > IMHO, it's a bit more complex than that. You are correct that the tech > isn't the big problem. But anything that involves herding cats...er, I > mean, developers...can never be described as "simply". Actually, the cats in question here are already in a herd called the Google Android Team. The real herding operation comes in when you try to get developers of other applications to join in -- but it helps if you already have a herd! I've tried to do that herding on my own. From my perspective a lot of the problem is not having a good communications framework and context for proposing and discussing such proposals. OpenIntents.org is a good start on that. I just checked on them, and there's a lot more content and it's a lot easier to comment. It's really important that these discussions occur in a visible place. Email is NOT a good medium for this. What you propose below is another approach to this -- unifying applications in the face of non-standardization. It has its merits, especially as a transitional measure. It is also an opportunity to establish a defacto standard, especially if it publishes the best protocol as an OpenIntents.org interface, and supports that well. New apps (or old) which want to integrate well, could implement that protocol. But a bit of leadership from Google would really help here. For example -- one VERY easy thing that the Google team could do is to publicize OpenIntents.org here: http://developer.android.com/intl/de/resources/community-groups.html > IMHO, it starts with one developer/team with one implementation of an > API. From there, it is evangelism, to get other developers to use the > API and to get competitors to adopt the API as a > convention/protocol/standard/whatever. > > That's what really gets my goat with all of this. If somebody with the > itch to scratch would step up to the plate and decide to implement and > maintain a compatibility layer for all this stuff (e.g., accessing the > "SMS inbox"), everybody else could use that library. Then, some amount > of changes in Android would be insulated from most developers (e.g., > the change in the calendar content provider Uri), as it would require > just a change in the library. I and others could point people in the > direction of that library rather than being stuck merely parroting the > "it's not part of the SDK" line. And other products could see the > value in supporting that library (e.g., alternative SMS clients that > store their inboxes in some other fashion). Personally, I haven't had > an itch to scratch in these areas -- perhaps someday I will. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > _The Busy Coder's Guide to Android Development_ Version 3.4 Available! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
