Well, you caught me in an error in conversion of predicates, yet still managed to miss the point. Again: I am not arguing that you had to support device enumeration with the first release of getExternalStorageDirectory(), I am aware of the difficulties of dealing with discovery and UX (as you mention). What I am arguing is Google's mistake is designing getExternalStorageDirectory() etc. so that they are not readily adaptable to systems with more than 1 SD card. THAT is your mistake.
The right thing to do would have been to release an API that supports 1 SD card, but can be extended in a backwards compatible way to support more than one -- when that becomes timely. You could have, for example, given us an Iterator, which in the first release always returns only one directory. Then Samsung would have known what API they had to conform to before releasing their phone w/ 2 SD cards, yet you would have deferred all the hard UX problems for later, all for no additional effort. BTW: it the time when "that becomes timely" is not already upon us, then the Samsung phone supporting 2 SD cards should not have been approved: it is markedly inferior to require a third party API, or any other third party dependencies, since as it is now, anyone who wants to support the 2 SD cards must now write the code in a manner specific to the Samsung phone. But the nature of the feature itself is generic, not specific to Samsung at all: only the implementation is. On Sep 12, 4:30 pm, Dianne Hackborn <hack...@android.com> wrote: > On Sun, Sep 12, 2010 at 2:55 PM, Indicator Veritatis <mej1...@yahoo.com>wrote: > > > I really don't think he is the one missing the point. Your talk about > > "supporting an arbitrary number of everything" is a straw-man > > argument. Other than you, nobody proposed that in this thread. > > Um I was directly responding to "I am really surprised that the Android > design would only account for one of anything." ... > > > What has been observed with 20-20 hindsight though, is that the > > desirability of two SD cards should have been easy to foresee, as it > > is much more useful than "an arbitrary number of everything". It is > > much more useful, and for only a little extra hardware, than two > > screens, for example. Or two keyboards. > > As I have *already* said, it's not as simple as just saying "oh we will > allow an arbitrary number of storage mounts." How does this get reflected > in the UI? How is the user made aware of it? Does there need to be a > facility for the user to trawl through these different storage areas and > move things around if they are running out of space on one? Does every > single application need to provide a UI for the user to select where to > store its data, and to move it between storage when needed? > > If you just add the API, then it gets used, and app developers are obligated > to support it, and you are stuck with it, and it becomes a big mess if you > don't have answers to all of those hard questions. Heck just the single SD > card is already quite a mess, and we have been struggling to clean that up. > > In fact I think going down this road very likely leads to a really crummy > UX. It begs a lot of questions: so my device has 16GB of built in storage, > and why can't I just use that as I want? Why does it need to be arbitrarily > divided between "apps" and "media"? What if I want more of one or the > other? > > There needs to be a better solution to this than just "oh hey here's an API > to find out about a potentially infinite amount of storage in various > capacities, and y'all can figure out what the heck that means and what to do > with it." To my mind what has been done so far on devices here is really > half-assed, and when that kind of thing gets introduced into the base > platform it needs to be much better thought out. > > (And yes, I realize this is the situation on desktops. This is an area > where we don't want to replicate the desktop experience.) > > If manufacturers think what they are doing is super great and want to have > app developers support it, there is nothing stopping them from defining > their own third party API to allow it. Or even working together to define > an API that is common between them. It's not like you have to wait for the > base platform to take care of things for you. > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- 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
