cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Billau <>
Subject Re: Camera does too many things!!!!
Date Fri, 24 Jan 2014 13:47:14 GMT
How does this coincide with the recent thread about Camera vs Capture?

Maybe the best idea would be rewrite Camera from the ground up with simple
API calls and put it all into Capture plugin, then remove Camera. I imagine
there will be a lot of shared code between the two plugins, especially for
things like resolving URI's and dealing with the new StorageAccessFramework.

Re: resizing images, I think it would be nice to be able to resize images
on the phone. While it makes sense that you would offload that to a server
somewhere, I think there are plenty of use cases for somebody taking a
photo and not being connected to a network but still needing a resize. If
it's too much of a pain we could push it (and orientation correction, and
any other "meta" procedures, into a plugin.)

Agree about getting rid of Data URIs - I haven't seen anybody use these

On Fri, Jan 24, 2014 at 12:48 AM, Joe Bowser <> wrote:

> This is mostly going to be a "I agree" e-mail, but the response is still
> inline:
> On Thu, Jan 23, 2014 at 6:23 PM, Andrew Grieve <>
> wrote:
> > When I was last looking at Camera, I came away thinking that there are
> two
> > main things that could be done to make it nicer:
> >
> > 1. Don't allow the client to dictate the type of URL.
> A Big +1 to this.  I've gotten so much grief for closing issues with
> DATA_URL as "Don't use DATA_URL", including one time to my face in
> Portland.  This wasn't even a good idea back in Nov 2008, since
> Android always saved the photo to an SDCard by default, and DATA_URL
> was added to bring it in line with iOS.
> >
> > Full explanation - There are four scenarios that I think are important:
> > 1. Pick a photo from the library (always returns content: urls)
> > 2. Take a photo and save it to the shared SD card location (requires user
> > set the android permission in their manifest) (returns file:// URL)
> > 3. Take a photo and save it to the app's private storage, still register
> it
> > with the Gallery (returns file:// URL)
> > 4. Take a photo and save it to the app's private storage, no not register
> > it (returns file:// URL)
> >
> > Data URLs pretty much never make sense and as of late cause OOM
> exceptions.
> > Requesting file:// URLs when the image is a content: makes us need to
> copy
> > the file needlessly (and it's impossible to know when it's safe to delete
> > the copy). We should just choose the URL that makes sense / is most
> > efficient.
> >
> We MAY have to get the file:// URI to display on KitKat because of the
> whole colon bug in the old MediaProvider and the new DocumentProvider
> where doesn't map for some reason.  That being said, it is possible to
> get the file location without having to make a copy.
> > 2. Make image resizing a separate API call
> >  - Often what you want is multiple sizes anyways (thumbnail + some other
> > size).
> >  - Specifying a size means sometimes you need to make a copy & sometimes.
> > you don't. The app then has no idea that it needs to delete the copy.
> Does this have to be in the Camera? Does this have to be done on the
> phone, even?  I think the existing code does do some math to check
> whether a resize is needed, and I believe that works, although I would
> like it better if there were JUnit tests for.  I think this time we
> should do more TDD with this thing.
> >
> > As for correcting the orientation, I don't know enough about what
> webviews
> > don't support it to know if it's important, but that does sound like it
> > makes sense in the plugin if it's important.
> >
> I think this has similar problems to resizing.
> >
> >
> > On Thu, Jan 23, 2014 at 4:24 PM, Joe Bowser <> wrote:
> >
> >> Hey
> >>
> >> I've been trying the last couple of days to refactor the camera, and
> >> I'm just getting bogged down in a ton of old, legacy code that was
> >> added to fix various JIRA and GitHub issues.  I've come to the
> >> conclusion that currently, our Camera plugin does TOO MANY things.
> >>
> >> Right now, it seems that our camera does the following on Android:
> >> * Launches an intent to get the Camera or the Gallery
> >> * Does image manipulation on the image
> >> * Corrects the Orientation of the image
> >> * Calculates the Aspect Ratio of the image
> >> * Saves the Image into the Gallery if taken from the Camera
> >>
> >> Now, we're stuck doing ALL of these things, but I feel like on Android
> >> we need to greenfield this plugin, since I'm finding it too difficult
> >> to refactor it to work across all the multiple Android versions.  We
> >> access the file system way too much, and the MediaProvider and
> >> DocumentProvider code is turning out to be a nightmare.
> >>
> >> What do people think about tossing this out and starting over? Or is
> >> there some worth in trying to untangle all the spaghetti?
> >>
> >> Joe
> >>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message