> 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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
