You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Jesse <pu...@gmail.com> on 2014/06/23 23:06:02 UTC
File API as implemented by cordova-plugins-file
I am working through numerous failing tests in the file plugin, but the
documentation is non-existent.
Is there some reference to this somewhere? Pointing to ever-changing
defunct specs that aren't even followed makes this impossible to resolve
without going and reading the code from other platforms. ( likely all of
them, since it seems to be quirk-ville )
Currently the docs say:
This plugin provides the HTML5 FileSystem API
( http://dev.w3.org/2009/dap/file-system/pub/FileSystem/ )
which provides little if any info.
Mozilla has done a better job of documenting some of this stuff, but not
the cordova specific additions.
https://developer.mozilla.org/en-US/docs/Web/API/File_System_API
My first implementation question:
What is a nativeURL? It is a non-standard property that was added to Entry
and therefore FileEntry and DirectoryEntry, but documentation makes no
mention of it.
It would be great if we could document FIRST when we add breaking changes
that affect other 'less important' platforms.
@purplecabbage
risingj.com
Re: File API as implemented by cordova-plugins-file
Posted by Brian LeRoux <b...@brian.io>.
ah the deadly peril of living on the edge of moving specs. to make things
even more fun Mozilla just made everything promises.
On Mon, Jun 23, 2014 at 2:08 PM, Ray Camden <ra...@adobe.com> wrote:
> As just an FYI - I swear 99% of the questions I get on my blog about
> Cordova/PG involve the File stuff.
> ________________________________________
> From: Jesse <pu...@gmail.com>
> Sent: Monday, June 23, 2014 4:06 PM
> To: dev@cordova.apache.org
> Subject: File API as implemented by cordova-plugins-file
>
> I am working through numerous failing tests in the file plugin, but the
> documentation is non-existent.
>
> Is there some reference to this somewhere? Pointing to ever-changing
> defunct specs that aren't even followed makes this impossible to resolve
> without going and reading the code from other platforms. ( likely all of
> them, since it seems to be quirk-ville )
>
>
RE: File API as implemented by cordova-plugins-file
Posted by Ray Camden <ra...@adobe.com>.
As just an FYI - I swear 99% of the questions I get on my blog about Cordova/PG involve the File stuff.
________________________________________
From: Jesse <pu...@gmail.com>
Sent: Monday, June 23, 2014 4:06 PM
To: dev@cordova.apache.org
Subject: File API as implemented by cordova-plugins-file
I am working through numerous failing tests in the file plugin, but the
documentation is non-existent.
Is there some reference to this somewhere? Pointing to ever-changing
defunct specs that aren't even followed makes this impossible to resolve
without going and reading the code from other platforms. ( likely all of
them, since it seems to be quirk-ville )
Re: Inconsistent behavior when opening inappbrowser window
Posted by Andrew Grieve <ag...@chromium.org>.
It's certainly not ideal. It would be better for this to be consistent.
That said, probably low priority to fix (pull requests welcome). Could
maybe even fix it on the JS side (existing.close() before open() next)
On Wed, Jul 2, 2014 at 3:20 PM, Li, Jonathan <jo...@sap.com> wrote:
>
> When creating inappBrowser in cordova app, for iOS, only a single
> uiwebview instance is created for multiple window.open method calls, and
> it only shows the content of last window.open's url content. However, on
> Android client, each window.open method call will create a separate
> webview instance with its own url content.
>
> Just want to confirm is this an expected behavior? Is there any change
> planned to make the behavior more consistent across all client platforms?
>
> Sample code to call window.open multiple times:
> var windowRef = window.open( 'http://google.com', '_blank',
> 'location=yes');
> var windowRef2 = window.open('http://apache.org', '_blank',
> 'location=yes');
>
>
> Regards
> Jonathan
>
>
Inconsistent behavior when opening inappbrowser window
Posted by "Li, Jonathan" <jo...@sap.com>.
When creating inappBrowser in cordova app, for iOS, only a single
uiwebview instance is created for multiple window.open method calls, and
it only shows the content of last window.open's url content. However, on
Android client, each window.open method call will create a separate
webview instance with its own url content.
Just want to confirm is this an expected behavior? Is there any change
planned to make the behavior more consistent across all client platforms?
Sample code to call window.open multiple times:
var windowRef = window.open( 'http://google.com', '_blank',
'location=yes');
var windowRef2 = window.open('http://apache.org', '_blank',
'location=yes');
Regards
Jonathan
Re: File API as implemented by cordova-plugins-file
Posted by Shazron <sh...@gmail.com>.
Jesse: http://www.w3.org/TR/FileAPI/
On Mon, Jun 23, 2014 at 2:06 PM, Jesse <pu...@gmail.com> wrote:
> I am working through numerous failing tests in the file plugin, but the
> documentation is non-existent.
>
> Is there some reference to this somewhere? Pointing to ever-changing
> defunct specs that aren't even followed makes this impossible to resolve
> without going and reading the code from other platforms. ( likely all of
> them, since it seems to be quirk-ville )
>
> Currently the docs say:
> This plugin provides the HTML5 FileSystem API
> ( http://dev.w3.org/2009/dap/file-system/pub/FileSystem/ )
> which provides little if any info.
>
> Mozilla has done a better job of documenting some of this stuff, but not
> the cordova specific additions.
> https://developer.mozilla.org/en-US/docs/Web/API/File_System_API
>
> My first implementation question:
> What is a nativeURL? It is a non-standard property that was added to Entry
> and therefore FileEntry and DirectoryEntry, but documentation makes no
> mention of it.
>
> It would be great if we could document FIRST when we add breaking changes
> that affect other 'less important' platforms.
>
>
>
>
>
> @purplecabbage
> risingj.com
Re: File API as implemented by cordova-plugins-file
Posted by Rodrigo Silveira <rs...@mozilla.com>.
To help me write the file plugin for FirefoxOS I wrote a test app[1]. I wrote it based on the HTML5 rocks post. I was hoping to integrate some of this into mobile-spec or whatever is our next testing framework.
Hope it helps,
Rodrigo.
[1] - https://github.com/rodms10/FileTest
[2] - http://www.html5rocks.com/en/tutorials/file/filesystem/
----- Original Message -----
From: "Martin Gonzalez" <ma...@gmail.com>
To: dev@cordova.apache.org
Sent: Monday, June 23, 2014 3:46:08 PM
Subject: Re: File API as implemented by cordova-plugins-file
I've been working on fixing those the file API tests, I have filled several
bugs at JIRA, about some issues with the native side as well. At the end I
have just 14 tests failing (fixing the issues just 5). I'll deliver the
fixes for mobilespec at night.
Totally agree, some changes for other platforms breaks functionality, I was
having more than 60 failing tests before the fix in the issue CB-6980,
cause by the changes in CB-6525 that provides only solution for iOS and
Android.
On Jun 23, 2014 4:06 PM, "Jesse" <pu...@gmail.com> wrote:
> I am working through numerous failing tests in the file plugin, but the
> documentation is non-existent.
>
> Is there some reference to this somewhere? Pointing to ever-changing
> defunct specs that aren't even followed makes this impossible to resolve
> without going and reading the code from other platforms. ( likely all of
> them, since it seems to be quirk-ville )
>
> Currently the docs say:
> This plugin provides the HTML5 FileSystem API
> ( http://dev.w3.org/2009/dap/file-system/pub/FileSystem/ )
> which provides little if any info.
>
> Mozilla has done a better job of documenting some of this stuff, but not
> the cordova specific additions.
> https://developer.mozilla.org/en-US/docs/Web/API/File_System_API
>
> My first implementation question:
> What is a nativeURL? It is a non-standard property that was added to Entry
> and therefore FileEntry and DirectoryEntry, but documentation makes no
> mention of it.
>
> It would be great if we could document FIRST when we add breaking changes
> that affect other 'less important' platforms.
>
>
>
>
>
> @purplecabbage
> risingj.com
>
Re: File API as implemented by cordova-plugins-file
Posted by Martin Gonzalez <ma...@gmail.com>.
I've been working on fixing those the file API tests, I have filled several
bugs at JIRA, about some issues with the native side as well. At the end I
have just 14 tests failing (fixing the issues just 5). I'll deliver the
fixes for mobilespec at night.
Totally agree, some changes for other platforms breaks functionality, I was
having more than 60 failing tests before the fix in the issue CB-6980,
cause by the changes in CB-6525 that provides only solution for iOS and
Android.
On Jun 23, 2014 4:06 PM, "Jesse" <pu...@gmail.com> wrote:
> I am working through numerous failing tests in the file plugin, but the
> documentation is non-existent.
>
> Is there some reference to this somewhere? Pointing to ever-changing
> defunct specs that aren't even followed makes this impossible to resolve
> without going and reading the code from other platforms. ( likely all of
> them, since it seems to be quirk-ville )
>
> Currently the docs say:
> This plugin provides the HTML5 FileSystem API
> ( http://dev.w3.org/2009/dap/file-system/pub/FileSystem/ )
> which provides little if any info.
>
> Mozilla has done a better job of documenting some of this stuff, but not
> the cordova specific additions.
> https://developer.mozilla.org/en-US/docs/Web/API/File_System_API
>
> My first implementation question:
> What is a nativeURL? It is a non-standard property that was added to Entry
> and therefore FileEntry and DirectoryEntry, but documentation makes no
> mention of it.
>
> It would be great if we could document FIRST when we add breaking changes
> that affect other 'less important' platforms.
>
>
>
>
>
> @purplecabbage
> risingj.com
>
Re: File API as implemented by cordova-plugins-file
Posted by Jesse <pu...@gmail.com>.
Thanks Ian, that's precisely the info I was looking for.
I'll keep track of my questions along the way, but you've given me enough
to move forward.
I'll update the doc right now with your added info on specs.
btw, the 'less important platforms' was meant as a troll. If anyone here
needs a windows phone 8 device to test on, I believe Olivier can make it
happen. ... and window8.1 runs great in bootcamp on my mbp.
@purplecabbage
risingj.com
On Mon, Jun 23, 2014 at 3:04 PM, Ian Clelland <ic...@chromium.org>
wrote:
> On Mon, Jun 23, 2014 at 5:06 PM, Jesse <pu...@gmail.com> wrote:
>
> > I am working through numerous failing tests in the file plugin, but the
> > documentation is non-existent.
> >
> > Is there some reference to this somewhere? Pointing to ever-changing
> > defunct specs
>
>
> I'm pretty sure that those are almost mutually exclusive ;)
>
>
> > that aren't even followed makes this impossible to resolve
> > without going and reading the code from other platforms. ( likely all of
> > them, since it seems to be quirk-ville )
> >
>
> I'd like to think that the tests are more-or-less definitive, but I'm sure
> there are lots of things that aren't covered, or are over-specified by the
> tests. I'd be glad to sit down some day and sort out what still needs
> testing, and what is just testing odd compatibility requirements or
> implementation details that needs to be split out.
>
>
> >
> > Currently the docs say:
> > This plugin provides the HTML5 FileSystem API
> > ( http://dev.w3.org/2009/dap/file-system/pub/FileSystem/ )
> > which provides little if any info.
> >
>
> That's not a great URL to use -- The File plugin provides both the File API
> (http://www.w3.org/TR/FileAPI/), and the (now-defunct) Directories and
> System extension to it (
> http://www.w3.org/TR/2012/WD-file-system-api-20120417/ is the latest,
> although the plugin was mostly written when
> http://www.w3.org/TR/2011/WD-file-system-api-20110419/ was current).
>
> It also implements the FileWriter spec (
> http://dev.w3.org/2009/dap/file-system/file-writer.html), although I often
> forget that one :)
>
>
> > Mozilla has done a better job of documenting some of this stuff, but not
> > the cordova specific additions.
> > https://developer.mozilla.org/en-US/docs/Web/API/File_System_API
> >
> > My first implementation question:
> > What is a nativeURL? It is a non-standard property that was added to
> Entry
> > and therefore FileEntry and DirectoryEntry, but documentation makes no
> > mention of it.
> >
>
> It is a non-standard extension, necessitated by the fact that on at least
> Android and iOS, some URLs are more equal than others. Specifically, things
> like <audio> and <video> tags on Android, and (I think) <link> tags on iOS,
> *have* to use URLs that are understood by the WebView. Our
> url-request-intercept code is never even called when the webview tries to
> get those resources, and so we can't use custom URL schemes; they *need* to
> be actual file:/// or equivalent URLs.
>
> There is a .toNativeURL() method exposed on Entry for application code to
> get those. It will use the .nativeURL property, if it exists, and will fall
> back to the regular .toURL() code if it doesn't.
>
> You're right that it could be better documented; one of my long-standing
> to-dos is to revamp the whole of the File plugin documentation.
>
>
> > It would be great if we could document FIRST when we add breaking changes
> > that affect other 'less important' platforms.
> >
>
> I specifically tried to implement the JS side of the code for .toNativeURL
> in a way that wouldn't break the platforms that I don't use (and can't
> currently test on). There are multiple fallbacks in the code that should
> make the JS behave correctly, even if the property hasn't been implemented.
>
> I'm more than happy to set up a call with you, if you have more questions
> about File specifically, or to work things out on the list. Just let me
> know.
>
> Ian
>
>
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
>
Re: File API as implemented by cordova-plugins-file
Posted by Ian Clelland <ic...@chromium.org>.
On Mon, Jun 23, 2014 at 5:06 PM, Jesse <pu...@gmail.com> wrote:
> I am working through numerous failing tests in the file plugin, but the
> documentation is non-existent.
>
> Is there some reference to this somewhere? Pointing to ever-changing
> defunct specs
I'm pretty sure that those are almost mutually exclusive ;)
> that aren't even followed makes this impossible to resolve
> without going and reading the code from other platforms. ( likely all of
> them, since it seems to be quirk-ville )
>
I'd like to think that the tests are more-or-less definitive, but I'm sure
there are lots of things that aren't covered, or are over-specified by the
tests. I'd be glad to sit down some day and sort out what still needs
testing, and what is just testing odd compatibility requirements or
implementation details that needs to be split out.
>
> Currently the docs say:
> This plugin provides the HTML5 FileSystem API
> ( http://dev.w3.org/2009/dap/file-system/pub/FileSystem/ )
> which provides little if any info.
>
That's not a great URL to use -- The File plugin provides both the File API
(http://www.w3.org/TR/FileAPI/), and the (now-defunct) Directories and
System extension to it (
http://www.w3.org/TR/2012/WD-file-system-api-20120417/ is the latest,
although the plugin was mostly written when
http://www.w3.org/TR/2011/WD-file-system-api-20110419/ was current).
It also implements the FileWriter spec (
http://dev.w3.org/2009/dap/file-system/file-writer.html), although I often
forget that one :)
> Mozilla has done a better job of documenting some of this stuff, but not
> the cordova specific additions.
> https://developer.mozilla.org/en-US/docs/Web/API/File_System_API
>
> My first implementation question:
> What is a nativeURL? It is a non-standard property that was added to Entry
> and therefore FileEntry and DirectoryEntry, but documentation makes no
> mention of it.
>
It is a non-standard extension, necessitated by the fact that on at least
Android and iOS, some URLs are more equal than others. Specifically, things
like <audio> and <video> tags on Android, and (I think) <link> tags on iOS,
*have* to use URLs that are understood by the WebView. Our
url-request-intercept code is never even called when the webview tries to
get those resources, and so we can't use custom URL schemes; they *need* to
be actual file:/// or equivalent URLs.
There is a .toNativeURL() method exposed on Entry for application code to
get those. It will use the .nativeURL property, if it exists, and will fall
back to the regular .toURL() code if it doesn't.
You're right that it could be better documented; one of my long-standing
to-dos is to revamp the whole of the File plugin documentation.
> It would be great if we could document FIRST when we add breaking changes
> that affect other 'less important' platforms.
>
I specifically tried to implement the JS side of the code for .toNativeURL
in a way that wouldn't break the platforms that I don't use (and can't
currently test on). There are multiple fallbacks in the code that should
make the JS behave correctly, even if the property hasn't been implemented.
I'm more than happy to set up a call with you, if you have more questions
about File specifically, or to work things out on the list. Just let me
know.
Ian
>
>
>
>
> @purplecabbage
> risingj.com
>