On Mon, Dec 16, 2013 at 4:32 AM, Tommy Williams <[email protected]> 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" <[email protected]> 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 <[email protected] > > >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 > > > > > >
