Hi Mark, I appreciate your thoughtful comments. Some things are fairly trivial at API level, but hard at implementation level. Sometimes it is also at API level not immediately clear which choices are most elegant and future proof. I also realize that the Android team has been exceedingly busy first realizing the core of what is currently needed on most mobile devices, for the time being skipping certain generalized features that have been available for quite some time on other popular platforms, and that do have merit beyond the time to market consideration. Ms. Hackborn's emotional and rather rude response cut this discussion short, despite concrete examples of existing implementations from Samsung as mentioned by Kostya and Indicator. For cameras there exists the two-camera HTC Evo 4G, and outside Android there exist two-camera phones from Nokia (I even have an old Nokia 6680 with two cameras) and from Apple (iPhone 4G). 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.
> -- New versions of the same methods are added to Environment that take > some sort of identifier as a parameter, with some sort of > getExternalStorageDevices() method to list them 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. 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). 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. > No, she has made it quite clear now that she has little interest in > doing any of that until there are concrete implementations ready to > be, um, implemented. OK, good to know. I guess I was hoping for the type of leadership that Chris just mentioned. Regards On Sep 12, 12:43 pm, Mark Murphy <[email protected]> wrote: > On Sun, Sep 12, 2010 at 2:59 AM, blindfold <[email protected]> wrote: > > I hope your colleagues will consider device enumeration as being > > important for limiting future fragmentation of a supposedly open > > platform and for encouraging new application areas, going well beyond > > "nice". > > I imagine that they will add support for multiple forms of "external > storage" as manufacturers request it (or, perhaps, where manufacturers > contribute back code). As Ms. Hackborn indicated, an API for things > like this is the tip of the iceberg. It's not also terribly relevant > until the rest of the iceberg exists, and there's no sense in them > spending time trying to design an API until they know what that API is > going to need to contain. > > With respect to "future fragmentation", the pattern for handling this > is rather obvious. Let's take external storage: > > -- The zero-parameter getExternalStorageDirectory() and kin do what > they do today, reporting on the default external storage > > -- New versions of the same methods are added to Environment that take > some sort of identifier as a parameter, with some sort of > getExternalStorageDevices() method to list them > > However, there are plenty of "unknowns": what the identifier is > (string or more complex object), what getExternalStorageDevices() > returns (ArrayList or some Environment.DeviceRoster object), etc. > Those details are impractical to design ahead of the full > implementation. So they didn't try. This is not terribly surprising -- > in fact, it would have been more surprising had they spent a lot of > time on it and skipped other functionality as a result. > > I am not aware of any compatible Android devices with multiple forms > of external storage back in, say, January. There were some (e.g., > ARCHOS 5 Android tablet) that had multiple forms of external storage, > but they were not in compliance with the compatibility definition in > other areas. Hence, when Android 2.2 was being baked, particularly > from the standpoint of low-level system stuff like external storage, > there may have been no compelling demands from manufacturers at the > time, so they focused on other areas. > > A fine example is Camera.Parameters. While that class existed from the > outset, a lot of capabilities were added in 2.0 (focus modes, flash > modes, etc.). Those were added to the SDK in response to device > manufacturers stepping up to the plate and wanting to support more > sophisticated cameras and wanting to put that sophistication in the > hands of developers. The core Android team *could* have tried > designing all of that back in Android 1.0, but they may well have > gotten it wrong, and they would have had to sacrifice some other piece > of functionality to "pay for" the engineering time. Instead, they > waited. > > > You have made it quite > > clear now that you have little interest in that or in adding device > > enumeration for other device classes. > > No, she has made it quite clear now that she has little interest in > doing any of that until there are concrete implementations ready to > be, um, implemented. > > -- > 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 [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
