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/commonsguy http://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
