Re: File plugin threading on iOS
On 2013-12-10 18:10, Ian Clelland wrote:
On Tue, Dec 10, 2013 at 4:40 PM, Michael Gauthier m...@silverorange.comwrote:
I quickly updated the File plugin to do the local file uri stuff in
resolveLocalFileSystemURI in the background using [self.commandDelegate
runInBackground:^{}].
Dev or master?
I made the change in master. Dev looks way awesomer. When do you think
you will release?
It works and allows my app interface to respond while the FS calls are
resolving. Is this approach crazy or obviously broken in some way?
Probably not crazy -- depending on how you've implemented it :) It's
basically what I'm doing in my branch as well.
Currently, I have CDVFile using that pattern, [self.commandDelegate
runInBackground:], to call the actual implementation method in
CDVLocalFilesystem or CDVAssetLibraryFilesystem. CDVFile passes the
implementation methods a callback function that sends the actual plugin
response when the operation is finished. (Keeping all of the
Cordova-plugin-y bits in CDVFile, and just having the raw file operations
in the file system implementation classes.
You can see an example of what I've done in the implementation of [CDVFile
readAsText:] and in [CDVLocalFilesystem readFileAtURL:start:end:callback:]
in the dev branch.
Ian
Using cordova in web workers
Is it possible to use cordova inside a web worker? I tried importing the cordova script but it makes reference to 'window' which is forbidden in web-worker context. It would be useful to be able to call cordova functions from within a web worker. Cheers, Mike
Re: Transitioning to a better File API implementation
Hmm.. The two directories have different defined roles on iOS and both are normal targets for applications to read/write files. Library is for cache data or app-specific resources. Documents is for saving/loading actual things created by users within apps. See https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW14 Supporting both should be a goal. Cheers, Mike On 2013-12-10 14:39, Ian Clelland wrote: If you could do that before, it was probably a bug :) (You shouldn't be able to use getParent on the filesystem root, and the native code was supposed to be checking for the correct path prefix before allowing access to any files on the device) At the moment, it's not possible to do that -- the filesystems should be properly isolated, and only allow access to correctly formed urls, like filesystem://localhost/persistent/some-file-here.txt. What we *can* do easily, though, is allow a new URL scheme for library assets; something like filesystem://localhost/library/some-file-here.txt, and we can have a filesystem handler for those URLs. That'll work if your use case is just I need access to files in /Library, rather than I need to get to them via string manipulation. I've also had some discussions about making /Library the default place for the persistent filesystem, and leaving /Documents either just for legacy apps, or making *that* the target of the special URL scheme. That's a proposal for a different day, though. There are some pretty big backwards-compatibility issues there. On Tue, Dec 10, 2013 at 11:54 AM, Michael Gauthier m...@silverorange.comwrote: Ian, With the new URLs will it be possible to write to both /Documents and /Library for iOS apps? In the old version, the filesystem root resolved as /Documents but it was possible to get to /Library by navigating the the parent dir. Cheers, Mike On 2013-11-15 15:19, Ian Clelland wrote: On Fri, Nov 15, 2013 at 1:40 PM, purplecabbage purplecabb...@gmail.com wrote: Considering the magnitude of the changes I would have expected that this was just a new file plugin. The previous version was based on a spec, and if we are deviating from it we should probably maintain both, and possibly even make a recommendation to the w3c. I hope we at least do a major version update for this if APIs have changed. Yes, definitely a major version bump, at least so that devs aren't caught by the URL-format-change. There aren't any changes to external APIs; I've been very careful to maintain conformance with the existing tests, except where those tests have been for undocumented implementation details. The only app-visible change is that URLs returned by the .toURL() method will look like filesystem://localhost/persistent/my/file.jpg rather than file:///var/mobile/Applications/app id/Documents/my/file.jpg We are still following the spec -- in fact, this brings us closer in line with the W3C File API spec, on these points: http://www.w3.org/TR/file-system-api/#widl-Entry-fullPath -- The fullPath of an entry should be the path from the root (of the HTML filesystem, not the underlying device file system). http://www.w3.org/TR/file-system-api/#widl-Entry-toURL-DOMString -- This is a note, rather than a requirement, but a filesystem url scheme is mentioned there. We're considering extending the spec in one way, which should be compatible with the spirit of the spec, and backwards-compatible with the previous API. That is the ability to declare new filesystem types, beyond temporary and persistent, so that we can access things like device media and app bundle assets using the same APIs that we use for accessing user-defined files. If we're happy with the way that works, then we should definitely propose it for inclusion in the standard (not the specific filesystems, perhaps, but the mechanism for requesting and interacting with them) Ian Sent from my iPhone On Nov 15, 2013, at 8:36 AM, Ian Clelland iclell...@chromium.org wrote: I've created CB-5403 as the über-ticket for this; various bits of it are in subtasks. Once I have the tests and the JS updated, then platform owners can take a look and see whether they have anything to do to support their own schemes. As general guidelines, I would say: * If you can intercept filesystem://* URLs in native code, and return arbitrary responses, then do it! It will let your platform support new filesystems in the future as we come up with them. Add a couple of subtasks for CB-5403 for your platform and go. * If you can't do that, but you *can* provide access to things like media through special urls, then try that! You should be able to create a FileSystem object that uses that URL as its root, and everything should work. Add a subtask for that, and see what you can do. * If you can't do that either, and you just want to stick with the file
Re: File plugin threading on iOS
I quickly updated the File plugin to do the local file uri stuff in
resolveLocalFileSystemURI in the background using [self.commandDelegate
runInBackground:^{}].
It works and allows my app interface to respond while the FS calls are
resolving. Is this approach crazy or obviously broken in some way?
Cheers,
Mike
On 10/12/13 12:57 PM, Ian Clelland wrote:
Unfortunately, except in a few cases (accessing asset-library urls and
actually reading and writing files) it is blocking.
Creating, finding, deleting and renaming regular files are all currently
synchronous operations on iOS. Reading and writing contents are async, and
shouldn't block anything.
Once I've pushed up the last changes to the File plugin, it's on my list of
things to tackle.
Ian
On Tue, Dec 10, 2013 at 11:45 AM, Michael Gauthier m...@silverorange.comwrote:
When using the File plugin on iOS I get a lot of THREAD WARNING Plugin
should use a background thread messages. Is the iOS plugin actually using
blocking filesystem calls internally?
Cheers,
Mike
Testing multiple iOS versions
Is there a way to test apps in older versions of iOS using the CLI? cordova emulate just runs iOS7. I want to test iOS6. Thanks, Mike
Re: Testing multiple iOS versions
Am I crazy, or is that an important missing feature of the CLI? It would be useful for Android as well. On 2013-11-20 17:36, Shazron wrote: There is no spec for this in the CLI. But for iOS, using the underlying ios-sim tool which runs the emulator, it is possible. On Wed, Nov 20, 2013 at 1:26 PM, Michael Gauthier m...@silverorange.comwrote: Is there a way to test apps in older versions of iOS using the CLI? cordova emulate just runs iOS7. I want to test iOS6. Thanks, Mike
Re: Media class downloading whole streaming file on iOS before play?
Can you start playing the local file before it's finished and will it play to the end of the file, or just to the length of the buffer when playback started? On 2013-11-13 15:48, Shazron wrote: Should have read the whole technote ;) AVPlayer *does* provide streaming support (it was new in iOS 4.0) while AVAudioPlayer does not. It's a whole new API in a new framework. We never did upgrade since this plugin was added in the iOS 2.0 days. Not sure if we are rewriting this plugin, but it using AVPlayer instead would be better. On Wed, Nov 13, 2013 at 11:41 AM, Shazron shaz...@gmail.com wrote: AVAudioPlayer does not provide streaming support anyway: https://developer.apple.com/library/ios/qa/qa1634/_index.html Related: https://issues.apache.org/jira/browse/CB-1176 The workaround here is to download the file first using the FileTransfer API (which has progress callbacks) and then load it using the Media API. On Wed, Nov 13, 2013 at 11:31 AM, Michal Mocny mmo...@chromium.orgwrote: And for what its worth, the exec bright is now async, so its likely that js execution is not actually blocked, but rather safari remote inspector is not showing output which the app UI thread blocked. Try to console.log(new Date()) and see if that is actually reporting a gap. If we fix this to move the download off-the-ui thread you will need to update your code to call mediaPlayer.play() from the success callback. On Wed, Nov 13, 2013 at 2:29 PM, Michal Mocny mmo...@chromium.org wrote: Yes, there is a bug that the media download is happening on the main ui thread. You should be seeing a native warning message (see https://issues.apache.org/jira/browse/CB-4133) about this. I've not found a bug filed specifically for this yet, so filed here: https://issues.apache.org/jira/browse/CB-5378 On Wed, Nov 13, 2013 at 1:43 PM, Nick Burka n...@silverorange.com wrote: I’ve been implementing a simple Media playback app. It looks something like: console.log(’start'); mediaPlayer = new Media( uri_to_my_mp3_file, mediaSuccess, mediaError, mediaStatus); console.log(’end’); mediaPlayer.play(); When the JavaScript executes, it takes 20+ seconds between the ‘start’ and ‘end’ logs. Then when I seekTo() on the playing file, it’s virtually instantaneous. I presume that the Media class is downloading the entire file on instantiation? A few other people seem to have the same problem: http://stackoverflow.com/questions/19938383/phonegap-build-media-play-takes-a-long-time-to-start-playing http://community.phonegap.com/nitobi/topics/phone_gap_media_api_ios_slow_loading Any help would be much appreciated.
Re: Updating plugin code on prepare
Did this feature land in 3.1.0 or is it targeted for 3.2.0? On 2013-10-03 11:30, Michal Mocny wrote: Yeah Braden we've diverged sorry, lets focus. Big +1 for your proposal to make prepare step do what users expect. -Michal On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson bra...@chromium.orgwrote: I agree that the syncing solutions are too complex and confusing. I return, then, to my original proposal all those emails ago: updating the native plugin files in platforms/foo when you prepare, to make life easier for plugin developers. When coupled with the present cordova plugin add --link, and future cordova watch, I think this makes the plugin developer flow pretty good, and without making it too magical or harder to understand. I think it simplifies prepare: on prepare, your native projects are updated to reflect the state of plugins/ and www/. Right now, only www/, assets and js-modules get updated, but not native code. As to Xcode and symlinks and all the rest of the borderline thread hijacking, I think that regardless of what editor you use, you have to be editing the right file. Xcode and Eclipse make this harder than it needs to be, but our job is not to make them suck less. Braden On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana csantan...@gmail.com wrote: +1 Anis corodova-cli/plugman should be building block components to higher level Tools/IDE. That we can do better sure, lets provide a few examples using blog pots and maybe videos tutorials vs. trying to support every use case with code. A watch function could be as simple as using grunt-contrib-watch to a more complicated environment like rsync/Eclipse I agree lets put emphasis on documenting use cases and the correct approach. When to get the best out of using prepare, merges, and hooks All I said applies when you have the Web Developer hat. For people that have the Native Plugin Developer hat then we can do things first for cordova-contributors than others can choose to use on their own risk since it could be changing too fast and maybe too narrow use case. --Carlos --Carlos On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI anis.ka...@gmail.com wrote: I gave some thought to this problem and I think we should just leave everything as is. Here's my reasoning: - Most web developers use a text editor (vim, sublime text, text mate, notepad++, ) to edit their HTML/CSS/Javascript. I've never seen anyone use a fully fledged IDE to edit web assets. It would be like using Microsoft Word to edit a simple .TXT or .MD file - Other developers, people who write Java or Objective C, etc.. use Xcode, Eclipse, IntelliJ, ...and I think these people are not good candidates for cordova-cli. The original PhoneGap promise (now Apache Cordova) was to make it easy for Web Developers to write Mobile Apps using web technologies and I believe that promise is fulfilled with cordova-cli. You have a folder where you drop in your web assets and you can build/deploy to a device or simulate. If people want to use an IDE, then they should be creating native projects with our create scripts and use plugman to manage their plugins. Our documentation should point our users to the right approach depending on the use case. For example: - Building for only one platform ? Building a hybrid app ? Want to use an IDE (Eclipse, Xcode) ? You should use the create scripts and plugman to manage plugins - Building a cross-platform app ? Like managing your project from the command-line ? Want to use your favo(u)rite text editor ? Use cordova-cli These double symlinking, backsyncing solutions will be a source of confusion and issues in my humble opinion. I've said it before but sometimes by trying to please everyone you end up pleasing no one. my .02c -a On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny mmo...@chromium.org wrote: On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve agri...@chromium.org wrote: Just tried some symlinks in Xcode 5: - Copying assets work (due to our custom build step) - Building works (compiler follows links just fine) - Editing a fail (big fail. Files open but changes cannot be saved.) Hmm, changes via xcode to symlinks fail, you mean? That would be hard to fix, but perhaps at least its feedback to the user not to make direct edits there, when using CLI workflow ;) so may still be a valid change to make. For Xcode though, it is an option to change our installation step to have Xcode reference the native files within plugins/ rather than within platforms/. Symlinks in Eclipse: - Copying assets works out-of-the-box - Build works fine - Editing seems to work fine (edits saved to symlinked location). Still though, maybe the best solution would be a combination of the two? Have prepare know when an remove+add is necessary? Yes, I think thats what we are suggesting. The original email mentioned prepare knowing when remove+add are necessary, which I think is already settled as a good idea. Not
cordova emulate ios not working
Hi Guys, I upgraded to 3.1.0 and cordova emulate ios no longer works. I filed report https://issues.apache.org/jira/browse/CB-4990. Cheers, Mike
Re: cordova emulate ios not working
$ ios-sim --version 1.8.2 On 2013-10-03 15:59, Shazron wrote: what does ios-sim --version show for you? On Thu, Oct 3, 2013 at 11:46 AM, Michael Gauthier m...@silverorange.comwrote: Hi Guys, I upgraded to 3.1.0 and cordova emulate ios no longer works. I filed report https://issues.apache.org/**jira/browse/CB-4990https://issues.apache.org/jira/browse/CB-4990 . Cheers, Mike
Issue with FileTransfer plugin identifier [PR]
Hi, I opened this issue a couple of days ago: https://issues.apache.org/jira/browse/CB-4902 The issue was the plugin identifiers were changed and the code wasn't updated with the new identifiers. I opened two pull requests to fix the issue but I can't figure out how to add them the to the Jira Issue. Can someone take a look and approve/reject them? https://github.com/apache/cordova-plugin-file/pull/6 https://github.com/apache/cordova-plugin-file-transfer/pull/7 Thanks, Mike
Re: Issue with FileTransfer plugin identifier [PR]
Michal, Awesome. I've sent in a signed copy of the CLA. Cheers, Mike On 2013-09-26 18:02, Michal Mocny wrote: Wow, this sounds like the problem I just ran into yesterday, so thanks for fixing it. I'm heading out for today so cannot reviewpull your patches, but to get the ball rolling for tomorrow, make sure you have signed the ICLA (http://www.apache.org/licenses/#clas) since It looks like you have not. Thanks! -Michal On Thu, Sep 26, 2013 at 4:51 PM, Michael Gauthier m...@silverorange.comwrote: Hi, I opened this issue a couple of days ago: https://issues.apache.org/**jira/browse/CB-4902https://issues.apache.org/jira/browse/CB-4902 The issue was the plugin identifiers were changed and the code wasn't updated with the new identifiers. I opened two pull requests to fix the issue but I can't figure out how to add them the to the Jira Issue. Can someone take a look and approve/reject them? https://github.com/apache/**cordova-plugin-file/pull/6https://github.com/apache/cordova-plugin-file/pull/6 https://github.com/apache/**cordova-plugin-file-transfer/**pull/7https://github.com/apache/cordova-plugin-file-transfer/pull/7 Thanks, Mike
