cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Camera does too many things!!!!
Date Fri, 24 Jan 2014 02:38:24 GMT
I agree with separating the different functions - getPicture should just
get the picture. Have another API call to resize etc. This will be way
easier to test.
Also Data URLs are not practical - I haven't seen a good use case for this,
if needed perhaps another API call and/or general purpose plugin to convert
any binary...


On Thu, Jan 23, 2014 at 6:23 PM, Andrew Grieve <agrieve@chromium.org> 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.
>
> 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.
>
> 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.
>
>
> 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.
>
>
>
> On Thu, Jan 23, 2014 at 4:24 PM, Joe Bowser <bowserj@gmail.com> 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
> >
>

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