You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Ian Clelland <ic...@chromium.org> on 2013/12/16 06:38:08 UTC
New and/or improved file plugin
On Friday I finally committed the Android changes and the last of the iOS
changes to the file plugin to the dev branch of cordova-plugin-file.
For those of you who haven't been following along, there are two big
changes in this release:
1. The plugin is now modular; code that handles regular files on the
filesystem is now separate from code that handles e.g., app assets.
2. FileEntry objects now use a new URL scheme:
filesystem://localhost/<filesystemType>/<path to file>. These URLs are
generated by all file operations, and are passed over the bridge to native
code. (This is in contrast to the previous version, which passed around
absolute paths on the device filesystem).
For app developers:
- If you have previously been storing file:/// urls on the device, and
those files exist *outside* of the standard filesystem roots, (this should
only be the case if you are manipulating the URLs that the File plugin
sends back,) those URLs will almost certainly not work with filesystem
operations in this new version. (For instance, you may still be able to set
them as image sources, etc, but you won't be able to create readers or
writers to them with the File API)
- If you have been storing file:/// URLs that exist within the normal
(temporary, persistent) filesystems, then they probably still work, as long
as you are calling window.resolveLocalFileSystemURI on them to get
FileEntries. You may find that they need to be converted to the new
filesystem:// scheme for some operations -- if you do, then just call
resolveLocalFileSystemURI on them, and use .toURL() on the entry that you
get back.
- If you just use window.requestFilesystem(), and traverse the
filesystem from there, then you should see no changes at all. The values
you will see if you call toURL() on any of the FileEntry or DirectoryEntry
objects will be different than before, but will be accepted by any of the
filesystem methods that take URLs.
For cordova developers:
I'm sure that, despite passing all of the original tests, and the tests
that I've added, there are still some bugs lurking somewhere. If you have
apps that use File or FileTransfer, please take some time to try them out
with the dev version of File, and report any bugs that you find.
Thanks!
Ian
Re: New and/or improved file plugin
Posted by Ian Clelland <ic...@google.com>.
Thanks :)
And I expect to be around this week, at least to fix issues with this as
they arise. After that I'll be mostly off the grid until the new year.
On Mon, Dec 16, 2013 at 2:37 AM, Brian LeRoux <b...@brian.io> wrote:
> thx so much for tackling this Ian, its a super complex part of the story.
>
> will dig in over the break / hopefully you are now taking a break!
>
>
> On Mon, Dec 16, 2013 at 4:38 PM, Ian Clelland <iclelland@chromium.org
> >wrote:
>
> > On Friday I finally committed the Android changes and the last of the iOS
> > changes to the file plugin to the dev branch of cordova-plugin-file.
> >
> > For those of you who haven't been following along, there are two big
> > changes in this release:
> >
> >
> > 1. The plugin is now modular; code that handles regular files on the
> > filesystem is now separate from code that handles e.g., app assets.
> > 2. FileEntry objects now use a new URL scheme:
> > filesystem://localhost/<filesystemType>/<path to file>. These URLs are
> > generated by all file operations, and are passed over the bridge to
> > native
> > code. (This is in contrast to the previous version, which passed
> around
> > absolute paths on the device filesystem).
> >
> > For app developers:
> >
> >
> > - If you have previously been storing file:/// urls on the device, and
> > those files exist *outside* of the standard filesystem roots, (this
> > should
> > only be the case if you are manipulating the URLs that the File plugin
> > sends back,) those URLs will almost certainly not work with filesystem
> > operations in this new version. (For instance, you may still be able
> to
> > set
> > them as image sources, etc, but you won't be able to create readers or
> > writers to them with the File API)
> > - If you have been storing file:/// URLs that exist within the normal
> > (temporary, persistent) filesystems, then they probably still work, as
> > long
> > as you are calling window.resolveLocalFileSystemURI on them to get
> > FileEntries. You may find that they need to be converted to the new
> > filesystem:// scheme for some operations -- if you do, then just call
> > resolveLocalFileSystemURI on them, and use .toURL() on the entry that
> > you
> > get back.
> > - If you just use window.requestFilesystem(), and traverse the
> > filesystem from there, then you should see no changes at all. The
> values
> > you will see if you call toURL() on any of the FileEntry or
> > DirectoryEntry
> > objects will be different than before, but will be accepted by any of
> > the
> > filesystem methods that take URLs.
> >
> > For cordova developers:
> >
> > I'm sure that, despite passing all of the original tests, and the tests
> > that I've added, there are still some bugs lurking somewhere. If you have
> > apps that use File or FileTransfer, please take some time to try them out
> > with the dev version of File, and report any bugs that you find.
> >
> > Thanks!
> >
> > Ian
> >
>
Re: New and/or improved file plugin
Posted by Carlos Santana <cs...@gmail.com>.
Ian great work !!!! tackling this beast
On Mon, Dec 16, 2013 at 7:33 AM, Ian Clelland <ic...@google.com> wrote:
> On Mon, Dec 16, 2013 at 4:32 AM, Tommy Williams <to...@devgeeks.org>
> wrote:
>
> > Ian,
> >
> > Congrats on getting this over the line!
> >
> > We have a *very* file/file-transfer dependent app. I will be keen to
> change
> > it over to using this and see how we go. :)
> >
> > Has file transfer been updated to play nicely with it? If so, were there
> > many big changes to file-transfer?
> >
>
> Yeah, file-transfer was one of the hairier parts of this bear -- the latest
> dev version of file-transfer should work with *both* the new and old
> versions of file; I've been running all of the unit tests against both
> versions.
>
> On iOS, the changes were to file-transfer itself (647dad7 has the most
> recent changes), but it recognizes both old (paths) and new (URLs) and
> deals with them correctly. On Android, the CordovaResourceAPI library made
> it easier; the File plugin just takes care of everything.
>
>
> > Again, congrats for tackling a sleeping bear no one wanted to wake ;)
> >
>
> Thanks :)
> Ian
>
> >
> > - tommy
> > On 16/12/2013 6:38 pm, "Brian LeRoux" <b...@brian.io> wrote:
> >
> > > thx so much for tackling this Ian, its a super complex part of the
> story.
> > >
> > > will dig in over the break / hopefully you are now taking a break!
> > >
> > >
> > > On Mon, Dec 16, 2013 at 4:38 PM, Ian Clelland <iclelland@chromium.org
> > > >wrote:
> > >
> > > > On Friday I finally committed the Android changes and the last of the
> > iOS
> > > > changes to the file plugin to the dev branch of cordova-plugin-file.
> > > >
> > > > For those of you who haven't been following along, there are two big
> > > > changes in this release:
> > > >
> > > >
> > > > 1. The plugin is now modular; code that handles regular files on
> the
> > > > filesystem is now separate from code that handles e.g., app
> assets.
> > > > 2. FileEntry objects now use a new URL scheme:
> > > > filesystem://localhost/<filesystemType>/<path to file>. These URLs
> > are
> > > > generated by all file operations, and are passed over the bridge
> to
> > > > native
> > > > code. (This is in contrast to the previous version, which passed
> > > around
> > > > absolute paths on the device filesystem).
> > > >
> > > > For app developers:
> > > >
> > > >
> > > > - If you have previously been storing file:/// urls on the device,
> > and
> > > > those files exist *outside* of the standard filesystem roots,
> (this
> > > > should
> > > > only be the case if you are manipulating the URLs that the File
> > plugin
> > > > sends back,) those URLs will almost certainly not work with
> > filesystem
> > > > operations in this new version. (For instance, you may still be
> able
> > > to
> > > > set
> > > > them as image sources, etc, but you won't be able to create
> readers
> > or
> > > > writers to them with the File API)
> > > > - If you have been storing file:/// URLs that exist within the
> > normal
> > > > (temporary, persistent) filesystems, then they probably still
> work,
> > as
> > > > long
> > > > as you are calling window.resolveLocalFileSystemURI on them to get
> > > > FileEntries. You may find that they need to be converted to the
> new
> > > > filesystem:// scheme for some operations -- if you do, then just
> > call
> > > > resolveLocalFileSystemURI on them, and use .toURL() on the entry
> > that
> > > > you
> > > > get back.
> > > > - If you just use window.requestFilesystem(), and traverse the
> > > > filesystem from there, then you should see no changes at all. The
> > > values
> > > > you will see if you call toURL() on any of the FileEntry or
> > > > DirectoryEntry
> > > > objects will be different than before, but will be accepted by any
> > of
> > > > the
> > > > filesystem methods that take URLs.
> > > >
> > > > For cordova developers:
> > > >
> > > > I'm sure that, despite passing all of the original tests, and the
> tests
> > > > that I've added, there are still some bugs lurking somewhere. If you
> > have
> > > > apps that use File or FileTransfer, please take some time to try them
> > out
> > > > with the dev version of File, and report any bugs that you find.
> > > >
> > > > Thanks!
> > > >
> > > > Ian
> > > >
> > >
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: New and/or improved file plugin
Posted by Ian Clelland <ic...@google.com>.
On Mon, Dec 16, 2013 at 4:32 AM, Tommy Williams <to...@devgeeks.org> wrote:
> Ian,
>
> Congrats on getting this over the line!
>
> We have a *very* file/file-transfer dependent app. I will be keen to change
> it over to using this and see how we go. :)
>
> Has file transfer been updated to play nicely with it? If so, were there
> many big changes to file-transfer?
>
Yeah, file-transfer was one of the hairier parts of this bear -- the latest
dev version of file-transfer should work with *both* the new and old
versions of file; I've been running all of the unit tests against both
versions.
On iOS, the changes were to file-transfer itself (647dad7 has the most
recent changes), but it recognizes both old (paths) and new (URLs) and
deals with them correctly. On Android, the CordovaResourceAPI library made
it easier; the File plugin just takes care of everything.
> Again, congrats for tackling a sleeping bear no one wanted to wake ;)
>
Thanks :)
Ian
>
> - tommy
> On 16/12/2013 6:38 pm, "Brian LeRoux" <b...@brian.io> wrote:
>
> > thx so much for tackling this Ian, its a super complex part of the story.
> >
> > will dig in over the break / hopefully you are now taking a break!
> >
> >
> > On Mon, Dec 16, 2013 at 4:38 PM, Ian Clelland <iclelland@chromium.org
> > >wrote:
> >
> > > On Friday I finally committed the Android changes and the last of the
> iOS
> > > changes to the file plugin to the dev branch of cordova-plugin-file.
> > >
> > > For those of you who haven't been following along, there are two big
> > > changes in this release:
> > >
> > >
> > > 1. The plugin is now modular; code that handles regular files on the
> > > filesystem is now separate from code that handles e.g., app assets.
> > > 2. FileEntry objects now use a new URL scheme:
> > > filesystem://localhost/<filesystemType>/<path to file>. These URLs
> are
> > > generated by all file operations, and are passed over the bridge to
> > > native
> > > code. (This is in contrast to the previous version, which passed
> > around
> > > absolute paths on the device filesystem).
> > >
> > > For app developers:
> > >
> > >
> > > - If you have previously been storing file:/// urls on the device,
> and
> > > those files exist *outside* of the standard filesystem roots, (this
> > > should
> > > only be the case if you are manipulating the URLs that the File
> plugin
> > > sends back,) those URLs will almost certainly not work with
> filesystem
> > > operations in this new version. (For instance, you may still be able
> > to
> > > set
> > > them as image sources, etc, but you won't be able to create readers
> or
> > > writers to them with the File API)
> > > - If you have been storing file:/// URLs that exist within the
> normal
> > > (temporary, persistent) filesystems, then they probably still work,
> as
> > > long
> > > as you are calling window.resolveLocalFileSystemURI on them to get
> > > FileEntries. You may find that they need to be converted to the new
> > > filesystem:// scheme for some operations -- if you do, then just
> call
> > > resolveLocalFileSystemURI on them, and use .toURL() on the entry
> that
> > > you
> > > get back.
> > > - If you just use window.requestFilesystem(), and traverse the
> > > filesystem from there, then you should see no changes at all. The
> > values
> > > you will see if you call toURL() on any of the FileEntry or
> > > DirectoryEntry
> > > objects will be different than before, but will be accepted by any
> of
> > > the
> > > filesystem methods that take URLs.
> > >
> > > For cordova developers:
> > >
> > > I'm sure that, despite passing all of the original tests, and the tests
> > > that I've added, there are still some bugs lurking somewhere. If you
> have
> > > apps that use File or FileTransfer, please take some time to try them
> out
> > > with the dev version of File, and report any bugs that you find.
> > >
> > > Thanks!
> > >
> > > Ian
> > >
> >
>
Re: New and/or improved file plugin
Posted by Tommy Williams <to...@devgeeks.org>.
Ian,
Congrats on getting this over the line!
We have a *very* file/file-transfer dependent app. I will be keen to change
it over to using this and see how we go. :)
Has file transfer been updated to play nicely with it? If so, were there
many big changes to file-transfer?
Again, congrats for tackling a sleeping bear no one wanted to wake ;)
- tommy
On 16/12/2013 6:38 pm, "Brian LeRoux" <b...@brian.io> wrote:
> thx so much for tackling this Ian, its a super complex part of the story.
>
> will dig in over the break / hopefully you are now taking a break!
>
>
> On Mon, Dec 16, 2013 at 4:38 PM, Ian Clelland <iclelland@chromium.org
> >wrote:
>
> > On Friday I finally committed the Android changes and the last of the iOS
> > changes to the file plugin to the dev branch of cordova-plugin-file.
> >
> > For those of you who haven't been following along, there are two big
> > changes in this release:
> >
> >
> > 1. The plugin is now modular; code that handles regular files on the
> > filesystem is now separate from code that handles e.g., app assets.
> > 2. FileEntry objects now use a new URL scheme:
> > filesystem://localhost/<filesystemType>/<path to file>. These URLs are
> > generated by all file operations, and are passed over the bridge to
> > native
> > code. (This is in contrast to the previous version, which passed
> around
> > absolute paths on the device filesystem).
> >
> > For app developers:
> >
> >
> > - If you have previously been storing file:/// urls on the device, and
> > those files exist *outside* of the standard filesystem roots, (this
> > should
> > only be the case if you are manipulating the URLs that the File plugin
> > sends back,) those URLs will almost certainly not work with filesystem
> > operations in this new version. (For instance, you may still be able
> to
> > set
> > them as image sources, etc, but you won't be able to create readers or
> > writers to them with the File API)
> > - If you have been storing file:/// URLs that exist within the normal
> > (temporary, persistent) filesystems, then they probably still work, as
> > long
> > as you are calling window.resolveLocalFileSystemURI on them to get
> > FileEntries. You may find that they need to be converted to the new
> > filesystem:// scheme for some operations -- if you do, then just call
> > resolveLocalFileSystemURI on them, and use .toURL() on the entry that
> > you
> > get back.
> > - If you just use window.requestFilesystem(), and traverse the
> > filesystem from there, then you should see no changes at all. The
> values
> > you will see if you call toURL() on any of the FileEntry or
> > DirectoryEntry
> > objects will be different than before, but will be accepted by any of
> > the
> > filesystem methods that take URLs.
> >
> > For cordova developers:
> >
> > I'm sure that, despite passing all of the original tests, and the tests
> > that I've added, there are still some bugs lurking somewhere. If you have
> > apps that use File or FileTransfer, please take some time to try them out
> > with the dev version of File, and report any bugs that you find.
> >
> > Thanks!
> >
> > Ian
> >
>
Re: New and/or improved file plugin
Posted by Brian LeRoux <b...@brian.io>.
thx so much for tackling this Ian, its a super complex part of the story.
will dig in over the break / hopefully you are now taking a break!
On Mon, Dec 16, 2013 at 4:38 PM, Ian Clelland <ic...@chromium.org>wrote:
> On Friday I finally committed the Android changes and the last of the iOS
> changes to the file plugin to the dev branch of cordova-plugin-file.
>
> For those of you who haven't been following along, there are two big
> changes in this release:
>
>
> 1. The plugin is now modular; code that handles regular files on the
> filesystem is now separate from code that handles e.g., app assets.
> 2. FileEntry objects now use a new URL scheme:
> filesystem://localhost/<filesystemType>/<path to file>. These URLs are
> generated by all file operations, and are passed over the bridge to
> native
> code. (This is in contrast to the previous version, which passed around
> absolute paths on the device filesystem).
>
> For app developers:
>
>
> - If you have previously been storing file:/// urls on the device, and
> those files exist *outside* of the standard filesystem roots, (this
> should
> only be the case if you are manipulating the URLs that the File plugin
> sends back,) those URLs will almost certainly not work with filesystem
> operations in this new version. (For instance, you may still be able to
> set
> them as image sources, etc, but you won't be able to create readers or
> writers to them with the File API)
> - If you have been storing file:/// URLs that exist within the normal
> (temporary, persistent) filesystems, then they probably still work, as
> long
> as you are calling window.resolveLocalFileSystemURI on them to get
> FileEntries. You may find that they need to be converted to the new
> filesystem:// scheme for some operations -- if you do, then just call
> resolveLocalFileSystemURI on them, and use .toURL() on the entry that
> you
> get back.
> - If you just use window.requestFilesystem(), and traverse the
> filesystem from there, then you should see no changes at all. The values
> you will see if you call toURL() on any of the FileEntry or
> DirectoryEntry
> objects will be different than before, but will be accepted by any of
> the
> filesystem methods that take URLs.
>
> For cordova developers:
>
> I'm sure that, despite passing all of the original tests, and the tests
> that I've added, there are still some bugs lurking somewhere. If you have
> apps that use File or FileTransfer, please take some time to try them out
> with the dev version of File, and report any bugs that you find.
>
> Thanks!
>
> Ian
>