On Sun, Sep 12, 2010 at 2:55 PM, Indicator Veritatis <[email protected]>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 [email protected] 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 [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
