Eeks, better not the Apollo 13 bit, Mark. I tried the "Houston, we have a problem" persiflage once before, and it was certainly not appreciated. :-)
By and large we agree, I think. I see the trade-offs that you mention. The one main opening that a constructive discussion could have created is that the Android team does not have to throw a "final" future-proof API over the wall as part of an official Android release. Their time and expertise is finite too, so yes, chances are that what they do would be flawed. The Java ME (dual) camera support with Nokia is actually rather messy too, riddled with ad hoc choices and a consequent legacy of device incompatibilities. > And you can see some places where they did try to future-proof things > better. Take sensors, for example. They took a stab at implementing a > future-proof sensor API, then had to deprecate *twice*. Locations are > another place, where they took a shot at future-proof, and sorta hit > it so far, if you ignore the whole mock location stuff popping in and > out of the SDK. They didn't totally ignore the issue -- they just > didn't do it everywhere. And, as the sensors API demonstrates, > "future-proof", like "past performance", is no guarantee of future > results. True. What the Android team could have initiated long ago is to publish draft API proposals, such that you and I and anyone else here can take a stab at them (review them and suggest improvements) and thus help improve quality before the result gets incorporated in an official Android release. Of course the future can still prove you wrong, but at least it ups the chances of getting it first time right. Such a way of working could save a lot of frustration on both sides, and help avoid later API deprecations. Regards On Sep 12, 3:58 pm, Mark Murphy <mmur...@commonsware.com> wrote: > On Sun, Sep 12, 2010 at 9:29 AM, blindfold <seeingwithso...@gmail.com> wrote: > > Therefore I felt that I am not just sketching some hypothetical > > situation that awaits concrete examples of devices that are being sold > > by the millions. > > Oh, in many of these cases, the hardware concept is certainly > foreseeable. However: > > -- all the details of the hardware, and the resulting impacts those > details may have on an API, are not always foreseeable > > -- the demand for such hardware is not uniform (e.g., dual cameras > would seem more likely than dual screens, which would seem more likely > than interfaces to Kenmore dishwashers) > > -- developing a truly future-proof API takes more engineering time > than creating an API that gets the job done, and engineering time is > not infinite > > At some point, they have to draw a line. I think you and I are in > agreement that where they drew the line is sometimes less-than-ideal > from the perspective of third-party developers. > > > Yes, I am aware of the organic growth option, but the zero-parameter > > getExternalStorageDirectory() would have been redundant if support for > > multiple devices had been foreseen and the parametrized method simply > > limited in value range by letting a "getExternalStorageCount()" return > > 1 (or zero) until manufacturers support higher counts. The third-party > > developer can then write code today that supports higher counts > > without having to wait for a future version of Android that specifies > > how getExternalStorageDirectory() gets an additional companion method > > or overloads one of the parameters. > > No arguments there. > > :: pause for laughter at the pun :: > > :: still waiting :: > > :: aw, c'mon, guys, it wasn't *that* bad... :: > > The case of external storage is probably the least defensible, even > looking at it at the time of original implementation. > > > For zero risk with supporting a second camera one could have looked at > > how Nokia supports additional cameras in Java ME using the capture:// > > locator, since the existing market has long given feedback on any > > issues with that (such that one can at the same time avoid making the > > same mistakes). > > I'd argue that the line they drew on camera support is more > defensible, because cameras are significantly more complex and in a > greater state of flux than is the concept of "external storage". > > > It largely boils down to the question what should come first, a > > general future-proof API or an actual implementation on a popular > > device that needs an existing API to be generalized for more > > widespread use. An actual implementation that is not supported by an > > API is typically a bit ugly, brings legacy code issues later on, and > > can discourage adoption of new features because third-party developers > > will be less inclined to write brand-specific code to exploit such > > features. > > And you can see some places where they did try to future-proof things > better. Take sensors, for example. They took a stab at implementing a > future-proof sensor API, then had to deprecate *twice*. Locations are > another place, where they took a shot at future-proof, and sorta hit > it so far, if you ignore the whole mock location stuff popping in and > out of the SDK. They didn't totally ignore the issue -- they just > didn't do it everywhere. And, as the sensors API demonstrates, > "future-proof", like "past performance", is no guarantee of future > results. > > In an ideal world, all APIs would be perfectly future proof. Major > engineering projects are rarely ideal. They tend to be more Apollo 13: > "We gotta find a way to make this...fit into the hole for this...usin' > nothin' but that." > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > Android Training...At Your Office:http://commonsware.com/training -- 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
