On Mon, Aug 2, 2010 at 3:21 PM, Bob Kerns <r...@acm.org> wrote: > Unpublished, undocumented, unsupported intents are part of the sin.
The more you nail down an API, the more expensive innovation becomes, because the legacy API becomes an albatross over time. It's one of the reasons why APIs are slow to be promoted out of AOSP into the SDK. In an ideal world, we would not be burdened by such issues, but in an ideal world, I'd have more hair. Again, I would agree that there should be more published, documented, supported Intents for the core applications. Expecting there to be no unpublished, undocumented, unsupported Intents is preposterous. >> Actually, by my interpretation of the CDD, that's not allowed, unless >> they are going to have both apps (the original and their replacement). > > Yes, that's exactly what they should be doing. Personally, I have no problem with this. Carriers would definitely have a problem with this, based on conversations I've had -- they've triggered SDK violations over more minor issues than this. Remember that we're not all that far removed from a world where carriers dictated everything about what was on the "deck" of a device. It is one of the reasons I hope that those rumors from earlier this year are true, and that the core applications will be unbundled from the OS and available for update via the Market. At that point, the CDD would need to be adjusted to prohibit replacement-in-place by OEMs, and things will stabilize more. It might even help with the goal of having more published, documented, supported Intents for the core applications. > I do not believe the developers have the same responsibility to the > platform -- but they DO have a responsibility to the users. And if that attitude is prevalent, in the end, Android will fail. > So I don't buy your "pissing-in-the-pool" analogy -- and I think you > should be able to turn this to your advantage in your efforts to > convince hardware manufacturers to behave more sanely. I don't see how. You are asking for device manufacturers to increase their development costs, to support things they're not obligated to support, because third-party developers are doing things they're told by Google not to do. What would help third-party developers in this area is if they'd get organized. At minimum, there should be a community-developed library with a common implementation of these sorts of SDK breaches (e.g., startCalendarAgendaActivity()), with some sort of published roster of all the apps that are using said library. In one fell swoop, you'd simplify maintenance in light of Android and OEM shifts in the ways these things work, you'd supply evidence to Google of the importance of standardizing some of these things, and you'd supply evidence to OEMs about the importance of not mucking this stuff up. However, organizing Android developers appears to be in the "herding cats" category, and it's something I don't feel I have any particular skill in doing. > And kudos for trying! Thanks. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _Android Programming Tutorials_ Version 2.9 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
