cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Looking at the new File API pragmatically
Date Mon, 31 Mar 2014 19:39:55 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message