On Fri, Jan 7, 2011 at 2:30 AM, Bob Kerns <r...@acm.org> wrote: > All of what you say here is true. But Android-the-platform (not > Android-the-OS) is really missing out here, failing to fully and > effectively leverage a KEY FEATURE of Android -- the use of intents > and content providers to integrate. > > The mechanism is there, to do whatever you want -- but you can't do > it, simply because there is NO STANDARD.
Agreed. > But all that's needed here is agreement as to how email notifications > are to be provided. The simplest way would be to broadcast an intent, > and document this intent. Then when I write my super-duper email > program -- I also send the same broadcast. 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. > 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". > Really, I think this sort of thing, across the board, is really the > missing Apple Killer. This is what makes the Android platform have so > much more potential, in my mind, than the iPhone -- and yet, it seems > to be SADLY neglected. Android-the-platform could be vastly more > powerful -- without a single line of platform code. Agreed. 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/commonsguy http://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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
