[
https://issues.apache.org/jira/browse/CB-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Sawatzky updated CB-6618:
------------------------------
Description:
Here is a little matrix that I've put together based on my experiences:
|X|||iOS|||Android||
|*Photo Saved to Library*|yes|yes|
|*Video Saved to Library*|no|yes|
|*Location of Media returned*|tmp|library|
So, as you can see, there are inconsistencies with whether or not the captured
media is saved to the user's library. Also, there are inconsistencies with
whether or not it returns a copy in the tmp folder (even if it did save to the
library), or a path to the version in the library. And this is just for iOS and
Android. If we added more platforms, what would it look like?
This causes issues with my app when trying to decide if it is safe to delete
the file returned once I am done with it. On android the user has the gallery
app to manage the files so I don't need to delete them. On iOS there is no UI
to manage the tmp files, so I need to delete them once I am done with them.
Problem is, I don't want to be writing a bunch of code for each platform (isn't
cordova supposed to abstract this for us). It would be nice if the capture
plugin provided details as to whether or not we should be cleaning up the media
returned.
This gets even more complicated if we throw audio capture into the mix since
iOS doesn't even have the concept of an audio library (as far as I know).
was:
Here is a little matrix that I've put together based on my experiences:
|X|||iOS|||Android||
|*Photo Saved to Library*|yes|yes|
|*Video Saved to Library*|no|yes|
|*Location of Media returned*|tmp|library|
So, as you can see, there are inconsistencies with whether or not the captured
media is saved to the user's library. Also, there are inconsistencies with
whether or not it returns a copy in the tmp folder (even if it did save to the
library), or a path to the version in the library.
This causes issues with my app when trying to decide if it is safe to delete
the file returned once I am done with it. On android the user has the gallery
app to manage the files so I don't need to delete them. On iOS there is no UI
to manage the tmp files, so I need to delete them once I am done with them.
Problem is, I don't want to be writing a bunch of code for each platform (isn't
cordova supposed to abstract this for us). It would be nice if the capture
plugin provided details as to whether or not we should be cleaning up the media
returned.
> Returned file inconsistencies between platforms
> -----------------------------------------------
>
> Key: CB-6618
> URL: https://issues.apache.org/jira/browse/CB-6618
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Plugin Media Capture
> Affects Versions: 3.4.0
> Environment: iOS, Android
> Reporter: Jeff Sawatzky
>
> Here is a little matrix that I've put together based on my experiences:
> |X|||iOS|||Android||
> |*Photo Saved to Library*|yes|yes|
> |*Video Saved to Library*|no|yes|
> |*Location of Media returned*|tmp|library|
> So, as you can see, there are inconsistencies with whether or not the
> captured media is saved to the user's library. Also, there are
> inconsistencies with whether or not it returns a copy in the tmp folder (even
> if it did save to the library), or a path to the version in the library. And
> this is just for iOS and Android. If we added more platforms, what would it
> look like?
> This causes issues with my app when trying to decide if it is safe to delete
> the file returned once I am done with it. On android the user has the gallery
> app to manage the files so I don't need to delete them. On iOS there is no UI
> to manage the tmp files, so I need to delete them once I am done with them.
> Problem is, I don't want to be writing a bunch of code for each platform
> (isn't cordova supposed to abstract this for us). It would be nice if the
> capture plugin provided details as to whether or not we should be cleaning up
> the media returned.
> This gets even more complicated if we throw audio capture into the mix since
> iOS doesn't even have the concept of an audio library (as far as I know).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
