cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Camera does too many things!!!!
Date Fri, 24 Jan 2014 05:48:23 GMT
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 <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.

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 <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
View raw message