> 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.
I have only just recently started reading through the aosp source from git with hopes of understanding the level of exposure the google team provides towards future updates. is this a hopeless effort? i just really hate the idea of working so hard towards a goal that has its support changed, dropped or is natively integrated into the next release. (e.g. froyo's anti-task manager functions recently sent me for a spin). does anyone know of a google group where this kind of stuff is discussed? its not that I disagree with ANY of google's decisions towards the API, its just it would be nice to know what's going to happen before it becomes written law (and weeks/months of coding become useless). thanks, s. "Live as if you were to die tomorrow. Learn as if you were to live forever." -- On Sun, Sep 12, 2010 at 11:42 AM, blindfold <[email protected]>wrote: > 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 <[email protected]> wrote: > > On Sun, Sep 12, 2010 at 9:29 AM, blindfold <[email protected]> > 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<http://github.com/commonsguyhttp://commonsware.com/blog%7Chttp://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 [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
