Re: Review Request 16354: Clarified parameters in the "cordova create" command.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/16354/#review30698 --- Ship it! Only part I'm not sure about is if it's true that you can't specify just 2 args. Reads well anyways. - Andrew Grieve On Dec. 18, 2013, 8:23 p.m., Marcel Kinard wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/16354/ > --- > > (Updated Dec. 18, 2013, 8:23 p.m.) > > > Review request for cordova. > > > Bugs: CB-5648 > https://issues.apache.org/jira/browse/CB-5648 > > > Repository: cordova-docs > > > Description > --- > > Clarified parameters (especially the optional ones) in the "cordova create" > command. > > > Diffs > - > > docs/en/edge/guide/cli/index.md 7cf5bfc > > Diff: https://reviews.apache.org/r/16354/diff/ > > > Testing > --- > > > Thanks, > > Marcel Kinard > >
Re: Point Release for BB
We decided to revert the commit which broke init.bat rather than apply the full fix now. BlackBerry is tagged at 3.3.1. Should CLI get bumped to 3.3.1 or 3.3.0-0.2.0 ? On Tue, Dec 17, 2013 at 10:57 PM, Josh Soref wrote: > Andrew wrote: > > How's this going? > > It took a bit more than I had expected, and testing it took longer, but we > have a fix and it's tested. I assume it will land tomorrow morning. > - > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. >
Re: Point Release for BB
3.3.1-0.1.1 makes sense to me since it's a change to the platforms.js file. Since there's a couple of bugfixes since it was released, might want to bump both numbers: 3.3.1-0.1.2 On Thu, Dec 19, 2013 at 11:18 AM, Bryan Higgins wrote: > We decided to revert the commit which broke init.bat rather than apply the > full fix now. > > BlackBerry is tagged at 3.3.1. > > Should CLI get bumped to 3.3.1 or 3.3.0-0.2.0 ? > > > On Tue, Dec 17, 2013 at 10:57 PM, Josh Soref > wrote: > > > Andrew wrote: > > > How's this going? > > > > It took a bit more than I had expected, and testing it took longer, but > we > > have a fix and it's tested. I assume it will land tomorrow morning. > > - > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute > non-public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in error, > > please immediately reply to the sender and delete this information from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > unlawful. > > >
Re: Dropping iOS 5.0 support
Starting Feb 1st, 2014, Xcode 5 is required: https://developer.apple.com/news/index.php?id=12172013a This is the perfect time to drop iOS 5.0 support, and support arm64. I would say the Jan 2014 release should have this change. See: https://issues.apache.org/jira/browse/CB-4863 https://issues.apache.org/jira/browse/CB-5286 On Tue, Sep 17, 2013 at 3:45 PM, Shazron wrote: > On the eve of the launch of iOS 7, I filed this issue: > https://issues.apache.org/jira/browse/CB-4863 > > I left the "Fix version" empty for now... >
Re: Point Release for BB
Done! On Thu, Dec 19, 2013 at 11:57 AM, Andrew Grieve wrote: > 3.3.1-0.1.1 makes sense to me since it's a change to the platforms.js file. > > Since there's a couple of bugfixes since it was released, might want to > bump both numbers: > 3.3.1-0.1.2 > > > > > > On Thu, Dec 19, 2013 at 11:18 AM, Bryan Higgins >wrote: > > > We decided to revert the commit which broke init.bat rather than apply > the > > full fix now. > > > > BlackBerry is tagged at 3.3.1. > > > > Should CLI get bumped to 3.3.1 or 3.3.0-0.2.0 ? > > > > > > On Tue, Dec 17, 2013 at 10:57 PM, Josh Soref > > wrote: > > > > > Andrew wrote: > > > > How's this going? > > > > > > It took a bit more than I had expected, and testing it took longer, but > > we > > > have a fix and it's tested. I assume it will land tomorrow morning. > > > - > > > This transmission (including any attachments) may contain confidential > > > information, privileged material (including material protected by the > > > solicitor-client or other applicable privileges), or constitute > > non-public > > > information. Any use of this information by anyone other than the > > intended > > > recipient is prohibited. If you have received this transmission in > error, > > > please immediately reply to the sender and delete this information from > > > your system. Use, dissemination, distribution, or reproduction of this > > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > >
Re: Deleting Plugin Docs
Nice Andrew. I think the "Plugins API" page is a good start. We can iterate on it to improve the experience. Personally, I would rather not have cut out the quick examples, full examples, etc. Some of the most positive feedback for our documentation is that it's thorough and copy & paste ready. This helps to get people up and running quickly. Just my two cents. I am very hesitant about removing the File API documentation and linking to external sources. When files become too large - similar to functions - we use multiple files. In the past, we've found that the W3C spec or external documentation (e.g. File API used by certain browsers) is a moving target. How confident are we that the Cordova File API will be a 100% match to the HTML 5 Rocks documentation? Michael On Wed, Dec 18, 2013 at 7:39 PM, Andrew Grieve wrote: > This is now done! Woo! No more having plugins code separate from their docs > (I hear we might even get tests to live within plugin repos in the next > while too!). > > I tried to be diligent, but it's possible I made mistakes along the way. > You can see the result on the edge version of the docs: > http://cordova.apache.org/docs/en/edge/ > > There's a new "Plugins API" page, and all of the plugin docs are moved into > the respective repos within a doc/index.md file. > > Some of doc/index.md files are fairly large, and to help with that I > attempted to remove some of the repetition that I found: Quick Examples vs. > Full Examples, Overviews vs Descriptions (in cases where they were saying > the same thing). > > Also - for the file API, I just wrote to refer to the FileSystem spec for > the API and copied over only the Cordova platform quirks. This will be a > bad offline experience, so I'm not 100% convinced that was the right thing > to do, but wow is that file big if you were to copy over all of the > documentation! > > https://github.com/apache/cordova-plugin-file/blob/dev/doc/index.md
Re: Dropping iOS 5.0 support
+1 On 20 Dec 2013, at 4:32 am, Shazron wrote: > Starting Feb 1st, 2014, Xcode 5 is required: > https://developer.apple.com/news/index.php?id=12172013a > > This is the perfect time to drop iOS 5.0 support, and support arm64. I > would say the Jan 2014 release should have this change. > > See: > https://issues.apache.org/jira/browse/CB-4863 > https://issues.apache.org/jira/browse/CB-5286 > > > > On Tue, Sep 17, 2013 at 3:45 PM, Shazron wrote: > >> On the eve of the launch of iOS 7, I filed this issue: >> https://issues.apache.org/jira/browse/CB-4863 >> >> I left the "Fix version" empty for now... >>
Re: Deleting Plugin Docs
+1 to Michael's comments. And I know it is a bit too early to do this, but the links to the docs on github should point to the master branch, not the dev branch, correct? I don't think there is anything wrong with big docs, as long as they are useful and navigable.
Re: Ideas for cordova-vm.apache.org
+1 for shared BuildBot master On Dec 18, 2013, at 10:37 PM, Andrew Grieve wrote: > 1. Use the machine for pushing website updates > - Generating the docs / website on different machines causes whitespace > differences to occur in generated files and really messes up diffs. > - If we all use this machine for website updates, then this problem will > go away. Hmm, this sounds like our doc generation tooling is glitchy if we are experiencing this kind of behavior. So yeah, doing it all on one machine would be one way to get consistency, but that's a bandaid. But I understand that sometimes a bandaid is more reasonable than major surgery. ;-)
Re: Dropping iOS 5.0 support
I know I'm going to look like a whacko and this will probably go over like a lead balloon, but I'll say it anyway: I'd like to see iOS 5 stay in Cordova for the next while. This is with my customer hat on, not my Cordova developer hat on. The reason is because our distribution has customers internationally, including Asia. In Asia there are higher concentrations of iOS devices that aren't upgraded like other geographies, which there becomes a significant amount of end-user devices instead of a trivial amount. iOS 5 end users are important to app developers in Asia using our distribution - they want to support these end users. I'm gating this based on the following understandings, please point out any errors: - Xcode 5 can target iOS 5.0 and 5.1 - Xcode 5 has emulators for iOS 5.0 and 5.1 - the fat binary support in Xcode 5 can generate 32-bit code that can run on iOS 5.0 and 5.1. [1] - there isn't code that needs to be ripped out or a bunch of conditional branches that need to stay in especially if iOS 6 is supported, it's really a matter of test effort to cover iOS 5.x [1] per the Xcode release notes, it actually looks like the min target for fat binaries is iOS 5.1.1. This pokes at least one hole in my argument if the desire is to generate only a fat binary. I understand the thought process around supporting iOS n and n-1. And the desire to set a cutoff at a 5% global average usage. But Asia isn't average, and averages can hide things. My suggestion is to align more (not entirely) with what the current Xcode supports as deployment targets with emulators. Apple seems to keep the cutoff level in Xcode moving up. To keep balance, I also wouldn't suggest to do something unnatural (i.e., iOS 4.3). On Dec 19, 2013, at 1:32 PM, Shazron wrote: > Starting Feb 1st, 2014, Xcode 5 is required: > https://developer.apple.com/news/index.php?id=12172013a > > This is the perfect time to drop iOS 5.0 support, and support arm64. I > would say the Jan 2014 release should have this change.
Upleveled 3.3.x branch of cordova-amazon-fireos
Hi, Devs I have pulled in more latest commits from cordova-android to amazon-fireos in branch 3.3.x. Here is the link: https://github.com/archananaik/cordova-amazon-fireos/tree/3.3.x Is it possible to merge these commits to cordova-amazon-fireos apache repo in 3.3.x branch? Thanks Archana
Cordova 3.3.1-0.1.2 doesn't load javascript for plugins
I upgraded to 3.3.1-0.1.2 and iOS isn't working anymore.
Based on Greg's bug report it looks like Android has a similar problem
https://issues.apache.org/jira/browse/CB-5647
I'm using Cordova 3.3.1-0.1.2 on OS X 10.9.1, Xcode 5.0.2 (5A3005), Node
v0.10.22
$ cordova create foo com.example.foo Foo
$ cd foo
$ cordova platform add ios
$ cordova plugin add org.apache.cordova.device
add the following to app.deviceReady in www/js/index.js
alert("Device Name " + device.name);
device.name fails
cordova_plugins.js doesn't contain any plugins
Re: Cordova 3.3.1-0.1.2 doesn't load javascript for plugins
device.name has been deprecated for some time, and probably has been
removed (but doc not updated)
just repro'ed your steps with 3.3.1-0.1.2
if you tried device.model - it should work
On Thu, Dec 19, 2013 at 3:49 PM, Don Coleman wrote:
> I upgraded to 3.3.1-0.1.2 and iOS isn't working anymore.
>
> Based on Greg's bug report it looks like Android has a similar problem
> https://issues.apache.org/jira/browse/CB-5647
>
> I'm using Cordova 3.3.1-0.1.2 on OS X 10.9.1, Xcode 5.0.2 (5A3005), Node
> v0.10.22
> $ cordova create foo com.example.foo Foo
> $ cd foo
> $ cordova platform add ios
> $ cordova plugin add org.apache.cordova.device
>
> add the following to app.deviceReady in www/js/index.js
>
>alert("Device Name " + device.name);
>
> device.name fails
> cordova_plugins.js doesn't contain any plugins
>
RE: Embedded WebView support on Windows 8
Hi Jian, Parashuram Thanks for your comments. Since we developed an Android app with Cordova in the way of Embedding WebView as described in http://cordova.apache.org/docs/en/2.8.0/guide_cordova-webview_android.md .html#Embedding%20Cordova%20WebView%20on%20Android, I am wondering if it is possible to develop Windows8 app in the same way. I am quite new to Windows Store App so my question might be pointless. >From your comments, my understanding might wrong but it sounds that basically there is a way that Windows Store App can be developed only with JavaScript. I found that Windows 8 core and plugins doesn't have native source code. So I am going to look into Windows Store App anyway. Regards, Shingo Toda -Original Message- From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panar...@microsoft.com] Sent: Wednesday, December 18, 2013 5:45 PM To: dev@cordova.apache.org Subject: RE: Embedded WebView support on Windows 8 Is there a specific reason you are looking WebView instead of using the way Cordova already does it. For Windows 8, Cordova basically packages your app as a WWA. This gives you additional benefits if you look at the app from Visual Studio. If you are looking at writing Windows 8 app and only looking to embed webview for a smaller part - note that Windows 8 apps already support Javascript and HTML. What is this "bigger app" written in? -Original Message- From: Jian Ouyang [mailto:jian.ouyang.em...@gmail.com] Sent: Tuesday, December 17, 2013 3:35 PM To: dev@cordova.apache.org Subject: Re: Embedded WebView support on Windows 8 I am not a Cordva developer, but I do use Cordova for cross-platform development. My suggestion is that you use the CLI to create an application for the Windows 8 platform and go through the code, if you think you can augment the code for you purpose, use it. Otherwise, forget about it. Cordova's Windows 8 support is not based on embedded web view as Visual Studio already comes with store apps dev in javascript only so why bother for an embeded control. The support is quite neat if you really get into it. On Dec 16, 2013, at 12:23 AM, Toda, Shingo wrote: > Hi Cordova devs > > > > I would like to ask you about Embedded WebView support on Windows 8 > (not phone). > > I have been using Cordova for Android and now I am thinking about > creating app for Windows8 (but I am new to Windows 8). > > > > I am wondering if it is possible to create an application for Windows > 8 with Cordova as a part of (larger) application. > > Actually the following page says currently embedding WebView is not > supported on Windows 8. > > > http://cordova.apache.org/docs/en/3.3.0/guide_support_index.md.html#Pl > at > form%20Support > > > > So my question is > > 1. Could you confirm if this restriction is still current? > > 2. Do you have any plans to support this method in the future? > > 3. Are there any easy workarounds with Cordova which is currently > available (latest is currently 3.3)? > > > > Any advises will be appreciated. > > > > Regards, > > Shingo > > >
Re: Dropping iOS 5.0 support
Just to note: On my particular machine (OS X Mavericks), Xcode 5 does not provide iOS 5.0 and 5.1 simulators. The minimum version is 6.0. From a quick google search, it also appears that iOS 5.x simulators are out-of-reach -- they apparently aren't supported under ML or later So Xcode 5 will support different simulator sets based on the user's OS. Which does tend to poke a hole in the argument -- at least for those devs who have upgraded their OS. All that said, if iOS 5 is important to a dev, they should have a physical device with iOS 5 on it, so it's not a fatal flaw in the argument either way. ___ Kerri Shotts photoKandy Studios, LLC On the Web: http://www.photokandy.com/ Social Media: Twitter: @photokandy, http://twitter.com/photokandy Tumblr: http://photokandy.tumblr.com/ Github: https://github.com/kerrishotts https://github.com/organizations/photokandyStudios CoderWall: https://coderwall.com/kerrishotts Apps on the Apple Store: https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 Books: http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book http://www.packtpub.com/phonegap-social-app-development/book On Thu, Dec 19, 2013 at 5:01 PM, Marcel Kinard wrote: > I know I'm going to look like a whacko and this will probably go over like > a lead balloon, but I'll say it anyway: I'd like to see iOS 5 stay in > Cordova for the next while. This is with my customer hat on, not my Cordova > developer hat on. > > The reason is because our distribution has customers internationally, > including Asia. In Asia there are higher concentrations of iOS devices that > aren't upgraded like other geographies, which there becomes a significant > amount of end-user devices instead of a trivial amount. iOS 5 end users are > important to app developers in Asia using our distribution - they want to > support these end users. > > I'm gating this based on the following understandings, please point out > any errors: > - Xcode 5 can target iOS 5.0 and 5.1 > - Xcode 5 has emulators for iOS 5.0 and 5.1 > - the fat binary support in Xcode 5 can generate 32-bit code that can run > on iOS 5.0 and 5.1. [1] > - there isn't code that needs to be ripped out or a bunch of conditional > branches that need to stay in especially if iOS 6 is supported, it's really > a matter of test effort to cover iOS 5.x > > [1] per the Xcode release notes, it actually looks like the min target for > fat binaries is iOS 5.1.1. This pokes at least one hole in my argument if > the desire is to generate only a fat binary. > > I understand the thought process around supporting iOS n and n-1. And the > desire to set a cutoff at a 5% global average usage. But Asia isn't > average, and averages can hide things. My suggestion is to align more (not > entirely) with what the current Xcode supports as deployment targets with > emulators. Apple seems to keep the cutoff level in Xcode moving up. To keep > balance, I also wouldn't suggest to do something unnatural (i.e., iOS 4.3). > > On Dec 19, 2013, at 1:32 PM, Shazron wrote: > > > Starting Feb 1st, 2014, Xcode 5 is required: > > https://developer.apple.com/news/index.php?id=12172013a > > > > This is the perfect time to drop iOS 5.0 support, and support arm64. I > > would say the Jan 2014 release should have this change. > >
