> Ummmm... I'll only support one touch screen! Okay. I'll only support one > DPAD! Okay. I'll only support one CPU! Okay. I'll only support one > graphics accelerator! Okay. I'll only support one SIM! Okay. I'll only > support one headphone output! Okay. I'll only support one camera! Okay.
you forgot I'll only support one carrier in the US..... oh no - that's that other phone OS... I think it would be wonderful to have an OS that supports multiple everything but as Dianne said it would never get shipped. Worse than that it would be slow and painful to develop for and use. Let's just be thankful we have multitasking (not forgetting all the other awesomeness that is Android). One way around it would have classes of files e.g. "Media", "Cache", "Applications", "Settings".... The user could setup a shared set of settings to say "Media" goes on this SD card, "Settings" go on this SD card.... Then apps could say this file is of class "Media". Even with this approach you'll always find things that don't fall neatly into one category or things that don't fall into any. It's a huge challenge to come up with a solution that is good for users and developers alike. A challenge that is probably in capable hands with Google. Ed On Sep 11, 11:04 am, Dianne Hackborn <hack...@android.com> wrote: > On Fri, Sep 10, 2010 at 2:33 PM, Doug Gordon <gordo...@gmail.com> wrote: > > I am really surprised that the Android design would only account for > > one of anything. In my experience, any time you say "we're only going > > to support one of feature X", the marketing or engineering departments > > decide to add another "X". In any case, having support for more than > > one is the same as having support for any quantity. > > Ummmm... I'll only support one touch screen! Okay. I'll only support one > DPAD! Okay. I'll only support one CPU! Okay. I'll only support one > graphics accelerator! Okay. I'll only support one SIM! Okay. I'll only > support one headphone output! Okay. I'll only support one camera! Okay. > > A marketing or engineering department that can't accept limitations is an > organization that will never ship a product. > > (And you don't note all of the complexity that comes from going from 1 to 2 > -- how is this reflecting in the UI? How does the user decide where they > want their stuff to go? How about telling them how much space is where? > And now you've got to let them move stuff around. I can make a good > argument that multiple SD cards is just intrinsically a crummy user > experience and should be avoided. Heck even one SD card significantly > complicates the UX.) > > -- > 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
