On Aug 2, 1:18 pm, Mark Murphy <mmur...@commonsware.com> wrote: > 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.... > 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.
Yes, I didn't narrow my statement sufficiently, and taken to this extreme, it's preposterous. But documented intents (that behave, and continue to behave) as documented, are far more valuable than undocumented ones. The power of the intent mechanism really depends on being able to invoke it from anywhere -- otherwise, you could just do some "invoke activity" call. Which is what supplying a class name in an intent essentially is. For me, that's really the line of demarcation. Beyond that line, it ought to at least be documented who's allowed to call it! Further, there should be a registry for this information. Something like openintents.org, which I think has about 2/3 of the right idea. Unfortunately, I don't know the other third...but it's probably more sociopolitical than technical. One key component would be getting Google to particpate! This kind of openness enables a whole new CLASS of innovation. Yes the old style of innovation becomes more costly. But when you don't have to build in your own web browser because you can just send an intent -- well, we've seen that that can enable a whole lot of innovation right there. > >> 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 my considered opinion that, in the larger picture, this behavior is irrational. I can point to various industry parallels -- like how many device drivers PC vendors have have had to write and maintain, far exceeding the supply of competent device driver authors. The quest for competitive edge drives it into this corner, where it remains, but it is far from a cost-effective approach to the basic problem. And I think Apple's app store quite effectively sank the ship underneath that "controlled deck" idea. (Despite Apple then seizing control in turn). > 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. Obviously, I disagree. Developers have no control over the platform destiny. But a rich supply of tools that meet users needs does - regardless of whether that need is approved or not. A Very Direct Impact. Happy customers -- now there's something that will help the platform win! (Carriers still have the power to countermand that, I fear...) The situation would be different if developers had a real say in the platform directions. Then, absolutely I would agree. I think that would really help the platform win, in fact. > > 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. How are device manufacturers increasing their costs by NOT DELETING the core Google app? Is it a matter of license fees to Google? Even better would be to fold in their improvements into the original. This might seem like more work -- but not really, since they would forgo the work of creating all the improvements made by others. Which doesn't help as much as it might sound, but does make enough economic sense that I hear there's even companies selling commercial products based around open source code. Eh? What's that you said? Android is what? > 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. This is similar to the openintents.org idea, and equally good, IMHO. > 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. I don't think there is any such skill to be learned. At least, I've never seen evidence of it. Have you ever sat on a standard committee? If so, you'll understand what I mean. What there is, however, is dogged persistence. That, plus a matching degree of patience, and a armor-thick skin, are what a committee chair needs. Oh, and a full time paycheck from someone who doesn't expect any real work. > > And kudos for trying! > > Thanks. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://github.com/commonsguyhttp://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
