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
