Hi Dianne, Thank you for confirming my expectations.
I hope your colleagues will consider device enumeration as being important for limiting future fragmentation of a supposedly open platform and for encouraging new application areas, going well beyond "nice". Regards On Sep 12, 12:40 am, 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
