Re: Camera does too many things!!!!
+1 for nuking data uris On Fri, Jan 24, 2014 at 11:36 AM, Don Coleman wrote: > I like the Camera API because it's simple. Capture might be standard but it > seems too complex. > > Resizing and orientation are important features. I never use data URLs. > What's going on in the standards bodies around image capture? Is there an > emerging standard that we could scope down to, or is nothing emerging and > we get to make it up in the meantime? > > I do like the simplicity of the camera plugin (roughly) just doing capture, > and pushing the utilities into a separate plugin (perhaps even non-core). I > hear that picture capture and uploading is a common pattern, so we should > consider the migration impact to existing users. > > On Jan 24, 2014, at 8:47 AM, Mike Billau wrote: > > > How does this coincide with the recent thread about Camera vs Capture? > > Yeah, seems like these are part of the same big picture that should be > thought through simultaneously. >
Re: Camera does too many things!!!!
I like the Camera API because it's simple. Capture might be standard but it seems too complex. Resizing and orientation are important features. I never use data URLs. What's going on in the standards bodies around image capture? Is there an emerging standard that we could scope down to, or is nothing emerging and we get to make it up in the meantime? I do like the simplicity of the camera plugin (roughly) just doing capture, and pushing the utilities into a separate plugin (perhaps even non-core). I hear that picture capture and uploading is a common pattern, so we should consider the migration impact to existing users. On Jan 24, 2014, at 8:47 AM, Mike Billau wrote: > How does this coincide with the recent thread about Camera vs Capture? Yeah, seems like these are part of the same big picture that should be thought through simultaneously.
Re: Camera does too many things!!!!
I'm on the DAP w3c group: http://www.w3.org/2009/dap/ Here is the working draft for the MediaStream Image Capture (taking still images from a camera stream) - http://www.w3.org/TR/2013/WD-image-capture-20130709/ Lisa Lisa Seacat DeLuca Twitter: @LisaSeacat website: lisaseacat.com ldel...@apache.org ldel...@us.ibm.com From: Marcel Kinard To: dev@cordova.apache.org Date: 01/24/2014 01:42 PM Subject: Re: Camera does too many things What's going on in the standards bodies around image capture? Is there an emerging standard that we could scope down to, or is nothing emerging and we get to make it up in the meantime? I do like the simplicity of the camera plugin (roughly) just doing capture, and pushing the utilities into a separate plugin (perhaps even non-core). I hear that picture capture and uploading is a common pattern, so we should consider the migration impact to existing users. On Jan 24, 2014, at 8:47 AM, Mike Billau wrote: > How does this coincide with the recent thread about Camera vs Capture? Yeah, seems like these are part of the same big picture that should be thought through simultaneously.
Re: Camera does too many things!!!!
What's going on in the standards bodies around image capture? Is there an emerging standard that we could scope down to, or is nothing emerging and we get to make it up in the meantime? I do like the simplicity of the camera plugin (roughly) just doing capture, and pushing the utilities into a separate plugin (perhaps even non-core). I hear that picture capture and uploading is a common pattern, so we should consider the migration impact to existing users. On Jan 24, 2014, at 8:47 AM, Mike Billau wrote: > How does this coincide with the recent thread about Camera vs Capture? Yeah, seems like these are part of the same big picture that should be thought through simultaneously.
Re: Camera does too many things!!!!
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 either. 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 > >> >
Re: Camera does too many things!!!!
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 >>
Re: Camera does too many things!!!!
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 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 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 > > >
Re: Camera does too many things!!!!
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 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 >
