Add getting image as file URL about cordova-plugin-photos HOT 3 CLOSED

This functionality means that image or thumbnail should be saved as new file somewhere in filesystem before file url may be created. I believe this functionality isn't strongly required for this plugin, moreover - saving ArrayBuffer as a file is already implemented in cordova-plugin-file, so I decided do not add this functionality as a code into plugin, but provide a snippet with example in README instead. Thus, it is developer's decision to have this functionality or not.

from cordova-plugin-photos.

I'm trying to create a multi-image-picker/uploader. I have never worked with ArrayBuffers before, but doesn't it still load the whole picture into the js context? Having access to a native file uri would be much more performant.

This is the use case:

1. Load all images from the device and sort it newest to oldest (I don't see anything about sorting in the docs. Would this be possible to do natively? That would allow for on-demand chunked loads with the offset/limit.)
2. Generate thumbnails of the visible pictures (You mention that not too many should be created in parallel. Approximately how many would still be ok?)
3. The user can click on images which will mark them as selected.
4. The user clicks upload, which will fetch the full sized pictures from the device and upload them to the server.

Now, my main issue is in step 4. If a user selects 10 pictures, that could potentially be a lot of data loaded into the js context. It would be much cleaner to just get a file URI and then pass that to the cordova-transfer-plugin (which is what I'm doing now with the single picture upload and the cordova-plugin-camera).

Could you consider adding this feature? I have never worked with Objective-C/Swift before, so I'm not sure if I would be able to do it myself.

from cordova-plugin-photos.

I have never worked with ArrayBuffers before, but doesn't it still load the whole picture into the js context?

It does, and not ;). In case you show full image using Blob, it doesn't matter - window.URL.createObjectURL(new Blob([data], {"type": "image/jpeg"})) doesn't eat more memory, it just provides info about type of data - the same action as it would be done by webview for file. When you put blob url into DOM, you attach an image there, and this data doesn't belong to JS context anymore (unless you saved link/pointer/variable of source data array in JS context somewhere). After you remove a pane with picture from DOM, webview engine frees the memory used.

Load all images from the device and sort it newest to oldest

It is exactly a sorting mode is used for fetching. I'll add this info into README, thanks for notice.

You mention that not too many should be created in parallel. Approximately how many would still be ok?

It depends on device. No universal answer for that unfortunately, but 3-5 would be OK for most cases. If you want more, then just test it on your target devices. My testing iPhone 4s didn't want to process >~10 thumbnails with dimension 300, however quite old Nexus 4 successfully created 100 and more. But such a limitation is not a big deal IMHO - it's quite easy in JS to create a code that will get thumbnails by chunks of 3 or 5.

The user clicks upload, which will fetch the full sized pictures from the device and upload them to the server... If a user selects 10 pictures, that could potentially be a lot of data loaded into the js context.

That's not correct. In case if business logic, that gets images from the device and then uploads them somewhere, is on JS side, you have just 1 thread (JS doesn't work with threads - asynchronous behavior isn't parallel in JS); so, all that you need, is just create a piece of code that will get a full image from device and upload it into server in one loop iteration. Whether this iteration is synchronous (for/while loop) or asynchronous (callback results of image() function) - all iterations will be processed one by one, so maximum memory usage will be just one, biggest image you processed.

Could you consider adding this feature?

Nope. As I mentioned above, a functionality to deal with files is implemented in cordova-plugin-file, and I provided code snippets that demonstrate how to deal with it (see examples for image() and thumbnail() functions). I see no sense to duplicate this code in my plugin.
Moreover, I really believe that parallel image processing isn't good idea: parallel thumbnail generating is good explanation of my doubts.

After experiments with similar functionality in my app I stopped with the following solution:

1. Thumbnails are generated asynchronously one by one in non-blocking mode for UI, by timer events (next thumbnail is starting after previous is ready). While thumbnail isn't available yet, a stub picture is shown.
2. Both thumbnails and full images are cached as files - in similar way I provided in 4th example for image().
3. That was OK for performance, but temporary FS was garbaged a lot, so I added a sanitation check on app startup that removes all old images that weren't accessed in some time period (a week in my case) - it was enough just to change image timestamp every time you get it from filesystem.

from cordova-plugin-photos.