The new File plugin has been in the wild now for almost two months now, and it seems to be seeing a lot of real-world use (bug reports are coming in to JIRA almost daily :) )
There have been a lot of bugs fixed, and a fair number of people guided towards new ways of doing things, but there are definitely some recurring themes, and I think, looking at things pragmatically, that there are some things that we can do to make the whole file experience better for developers. ---- ONE ---- The first thing has to do with .toURL(), and it's new baby brother, .toNativeURL(). Originally, the ideal was that .toURL() would always return a URL with the prefix "cdvfile://", but this has caused problems with a number of use cases, all involving passing the URL to the webview as a "src" attribute. The Android code for resolving "src" attributes generally doesn't pass the URLs back to the application, and so a real file:/// URL is required. Because of this, I introduced .toNativeURL, which will try to return a file:/// URL, or a content:// URL, and will only return a cdvfile:// URL if it has no other alternative. I've been providing guidance to developers to try to use that if they want to use File-plugin-files in video or audio tags, or even for img tags on Android <= 3.0 This is ugly, though, and is going to get worse over time, and become a division between Cordova and any platforms which actually implement the File API correctly. I'd like to propose switching the behaviour of .toURL(), to match .toNativeURL -- returning a webview-usable URL by default -- and implementing some other method or property to get the CDV URL when it's necessary. ---- TWO ---- The second issue has to do with the filesystem locations which are made available to Cordova apps. The File plugin provides two sandboxed filesystem locations, one for persistent files, and one for temporary files. Files which reside outside of those two locations are not accessible to the plugin, by default. (For comparison, the old version of File would happily access files anywhere on the device, even well outside of the claimed 'roots') This generally works, doesn't cause problems with applications using the File plugin, and is (I think) still a good idea. It breaks down, however, when other plugins come in to the mix. Before File was released, I made changes to FileTransfer, and since, I have changed Camera, and been working on MediaCapture -- all to ensure that they play within File's sandboxes. MediaCapture, though, is more difficult, because it's the OS that is creating the files, and it will create them where it wants to, not where we think it should. I revived the file-system-roots plugin to take care of this problem -- when installed, it registers several additional file systems, covering other areas of the device, allowing access to places like "SD Card storage", "external cache", "internal cache", etc (see the plugin README for all of the details). It's even possible to register the "root" filesystem, which re-enables access to the *entire* device. Adding this plugin has worked for basically everyone who's had a problem with file locations, but it seems wrong to have to recommend an outside-of-core plugin to fix a problem with core plugins. The question here, I guess -- because a number of people have required this feature, and there may be additional third-party plugins out there that will require it as well -- is whether it makes sense to include this functionality in the core File plugin, or whether to just continue to recommend it to people whose apps write files in locations outside of the standard persistent/temporary file systems. Thoughts, opinions, flames -- all welcomed. Thanks for reading this far :) Ian
