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/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 [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
