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 <[email protected]> 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 <[email protected]> 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 > > >
