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.
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. Don't feel bad about Google failing to foresee this. Feel bad about Google failing to realize you are big enough to admit this failure. It is not THAT big a failure. On Sep 11, 3:40 pm, Dianne Hackborn <hack...@android.com> wrote: > Well you are totally missing my point. Of course it would be *nice* to > support an arbitrary number of everything. To actually ship a product on > time, though, you probably aren't going to be able to do so. > > The SD card is an especially good case of this, because it's not just a > matter of adding an API -- you also need to figure out the whole UX around > this, which is fairly non-trivial. > > Anyway, done with this thread. > > On Sat, Sep 11, 2010 at 1:51 AM, blindfold <seeingwithso...@gmail.com>wrote: > > > > A marketing or engineering department that can't accept limitations is an > > > organization that will never ship a product. > > > When you are a research department you aim to develop new products > > rather than shorten time to market. When even the basic building > > blocks are already highly restrictive it becomes much harder to > > innovate. > > > Although this thread is mostly about having a second SD card, your > > comments seem to indicate a general attitude towards and lack of > > interest in generalized API support for enumerating "peripherals": > > > > I'll only support one camera! Okay. > > > Not OK! If one wants to compete on the market one has to look at > > competitors that already sport two cameras, such as a front-facing > > camera. Think many Nokia phones, and Apple's iPhone 4G. (I added > > second camera support to my own Nokia Java MIDlet app back in 2006.) > > Do you want every Android phone manufacturer to invent and develop > > their own proprietary Android API extensions even to just keep up with > > existing functionality elsewhere? You encourage fragmentation! > > > Also, please look across platform boundaries as well as look at > > broadening the scope towards gaming devices. What Microsoft is doing > > with Kinect (formerly Natal) involves either a stereo camera or a time- > > of-flight camera. Do you want individual Android device manufacturers > > to create proprietary API extensions here too? Why make it impossible > > to develop an Android counterpart of the Nintendo 3DS by sticking to a > > conventional single camera API, forcing proprietary extensions? > > > Thanks! > > > The vOICe for Android > >http://www.seeingwithsound.com/android.htm > > > On Sep 11, 3: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<android-developers%2bunsubscr...@googlegroups.com> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > 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
