Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of iclelland@google.com designates
 209.85.219.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPTyS6D=m+h498qjtkOASY739dacj83xdWZURe9ZkxHj8a-qkw@mail.gmail.com>
References: 
 <CAK_TSXK=22uNyvK1QQa_X9DQxZ4FjZAZufbB85r1Y-uTBgNbdQ@mail.gmail.com>
 <CADVgkyP39htqWm92okufRO5bMC9zKJ8UUYMejvDeUG77YUtQHQ@mail.gmail.com>
 <CAPTyS6D=m+h498qjtkOASY739dacj83xdWZURe9ZkxHj8a-qkw@mail.gmail.com>
From: Ian Clelland <iclelland@google.com>
Date: Mon, 16 Dec 2013 07:33:54 -0500
Message-ID: 
 <CAK_TSXK6SS3zRoVxtmugc4mGziN5qxwj3N3ies3wVw6CU-8WBg@mail.gmail.com>
Subject: Re: New and/or improved file plugin
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7bd767209523aa04eda60761

--047d7bd767209523aa04eda60761
Content-Type: text/plain; charset=UTF-8

On Mon, Dec 16, 2013 at 4:32 AM, Tommy Williams <tommy@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
> > >
> >
>

--047d7bd767209523aa04eda60761--