I agree about the camera, and about the overall gist that, while staying well within the boundaries of the documented APIs, it is possible to build applications that will require modification as the platform evolves. Having written software for many platforms and over many years, I have come to expect this, particularly where low-level features are used. The camera is a great example; the API is immature, but I trust it will become more complete with time.
Fortunately, we have places like Google Groups to discuss the 'gotchas' as we find them, and given the number of participating developers, I'm not worried about the changes as they come. On Wed, Oct 21, 2009 at 7:31 AM, blindfold <[email protected]>wrote: > > Clearly you have not done any work on processing live camera preview > images. > > AFAIK I have not gone outside the defined API, but the documentation > was/is simply vague and incomplete on various important details. Just > ask *anyone* who has worked with the camera preview callback > mechanism! And I'm not even talking about the many bugs and > undocumented "features" and performance issues in the camera API > implementation that one had to find workarounds for. > > > What you need to do is figure out a way to accomplish what you are > > after withOUT resorting to HACKS or reverse engineering. > > In an ideal world, yes. In the real world, new device APIs and media > formats are poorly defined, wrongly implemented, device drivers can > and do freeze, and so on. The camera part of Android remains among its > weakest spots. It is very naive and one-sided to simply blame the > application programmer here if things break at some point. > > On Oct 21, 3:18 pm, lbcoder <[email protected]> wrote: > > You can't make any assumptions when you are working outside of the > > defined API. > > Going outside of the API is PROGRAMMER ERROR. > > > > What you need to do is figure out a way to accomplish what you are > > after withOUT resorting to HACKS or reverse engineering. > > > > On Oct 21, 4:30 am, blindfold <[email protected]> wrote: > > > > > My biggest concern is that differences in (default?) preview frame > > > encoding will arise, as this is a rather poorly defined area of the > > > Android API where a lot of reverse engineering had to be applied to > > > analyze G1's color preview content. I'm not confident that what I > > > finally got working on the emulator and ADP1/G1 will work with all > > > future Android camera devices. > > > > > On Oct 20, 11:29 pm, JP <[email protected]> wrote: > > > > > > So you can get a taste of what's coming. This was/is between the G1 > > > > and the Ion. On the Ion, Android 1.5 allows access to the camera > > > > preview without having to request the respective permission. It just > > > > works. On the G1, you don't get through, and your app will crash with > > > > an out of memory exception. Go figure. Oh, and if you develop on the > > > > G1, expecting a camera button, you're out of luck b/c this isn't > > > > standard on board equipment. That, of course is trivial, by > > > > comparison. > > > > > > On Oct 20, 10:52 am, lbcoder <[email protected]> wrote: > > > > When you talk about the camera differences between MAGIC and DREAM, > > > > to > > > > what specifically are you referring and what did you have to do to > > > > deal with it? From what I can tell, they are *identical* in that > > > > respect... Are you certain that it was due to hardware difference > and > > > > not due to running a different version of 'droid? > > > > > > > -- Warm regards, The PhoneMyPC Team --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
