Re: cordova-lib in BitHound
Thanks for the shoutout! Cordova.js has been one of our test case repos in the development of bitHound. Gord On Tue, Feb 10, 2015 at 7:01 AM Andrew Grieve agri...@chromium.org wrote: Pretty cool code analysis tool from the creators of Ripple! https://www.bithound.io/apache/cordova-lib
Re: [Node 101] Part 1: Small Modules
I also agree with this except for returning a function from module.exports.
It is possible but makes mocking much much harder for testing.
think of:
var foo = require('foo');
module.exports = {
awesome: function (a) {
foo(a+1);
}
};
It is kind of awkward to test this module's use of the foo module. It can
be done with rewire [1] but is a little awkward.
If foo was designed where it exported an object literal with functions it
would be much easier to mock:
var foo = require('foo');
module.exports = {
awesome: function (a) {
foo.bar(a+1);
}
};
it(calls foo.bar, function () {
var foo = require('foo');
spyOn(foo, bar);
});
Just my 2 cents from a testing perspective.
[1] - https://github.com/jhnns/rewire
On Thu, Dec 12, 2013 at 6:06 PM, Brian LeRoux b...@brian.io wrote:
Create modules that are the smallest possible unit of code. Less code is
fast code. Faster to write. Faster to maintain. Faster to test. On the
extreme end characters in the Node community such as Substack advocate a
single function per module definition.
module.exports = function() {
// my logic here
}
This is kind of extreme and not always possible but a good practice
nonetheless. The idea is not new. Its a part of the UNIX philosophy: do
one thing well coined by Doug Mcilroy. [1]
It can help you make code that looks like this [2] into this [3].
[1] http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html
[2]
https://github.com/apache/cordova-js/blob/c320378b484a172a02d3ee26634bcc584f43b939/Gruntfile.js
[3] https://github.com/apache/cordova-js/blob/master/Gruntfile.js
Re: [Node 101] Part 1: Small Modules
It depends what you define as outputs.
in a given module:
var foo = require('foo'), bar = require('bar'), baz = require('baz');
module.exports = function(a, b) {
foo(3);
bar.method(a);
baz(b);
return done;
}
I have always counted the calls to foo, bar and baz as output that needs to
be tested. This would produce a spec like:
when calling this module:
it calls foo with 3
it calls bar.method with a
it calls baz with b
it returns done
It is just easier to mock bar.method then foo
ie:
var rewire = require('rewire');
var example = rewire('example'); //NOTE: rewire rather then require
example.__set__('foo', jasmine.createSpy());
vrs:
var example = require('example');
var bar = require('bar');
spyOn(bar, method);
I came across this problem when using one of Isaac's modules (rimraf [1])
where I obviously didn't want to call that in a unit test from my module
but I need to mock it out. Rewire was the only way I could.
[1] - https://github.com/isaacs/rimraf
On Thu, Dec 12, 2013 at 6:37 PM, Brian LeRoux b...@brian.io wrote:
ALSO: lets avoid using terms like 'I agree' or 'I disagree'. Its
programming. The answer is ALWAYS 'it depends'. No absolutes in the sea of
change.
On Fri, Dec 13, 2013 at 10:34 AM, Brian LeRoux b...@brian.io wrote:
Maybe. Have a look at Substack's code and you'll see he has no trouble
testing. The reason being he tests interfaces and outputs instead of
implementations. That will be another Node 101!
On Fri, Dec 13, 2013 at 10:24 AM, Gord Tanner gtan...@gmail.com wrote:
I also agree with this except for returning a function from
module.exports.
It is possible but makes mocking much much harder for testing.
think of:
var foo = require('foo');
module.exports = {
awesome: function (a) {
foo(a+1);
}
};
It is kind of awkward to test this module's use of the foo module. It
can
be done with rewire [1] but is a little awkward.
If foo was designed where it exported an object literal with functions
it
would be much easier to mock:
var foo = require('foo');
module.exports = {
awesome: function (a) {
foo.bar(a+1);
}
};
it(calls foo.bar, function () {
var foo = require('foo');
spyOn(foo, bar);
});
Just my 2 cents from a testing perspective.
[1] - https://github.com/jhnns/rewire
On Thu, Dec 12, 2013 at 6:06 PM, Brian LeRoux b...@brian.io wrote:
Create modules that are the smallest possible unit of code. Less code
is
fast code. Faster to write. Faster to maintain. Faster to test. On the
extreme end characters in the Node community such as Substack
advocate a
single function per module definition.
module.exports = function() {
// my logic here
}
This is kind of extreme and not always possible but a good practice
nonetheless. The idea is not new. Its a part of the UNIX philosophy:
do
one thing well coined by Doug Mcilroy. [1]
It can help you make code that looks like this [2] into this [3].
[1]
http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html
[2]
https://github.com/apache/cordova-js/blob/c320378b484a172a02d3ee26634bcc584f43b939/Gruntfile.js
[3] https://github.com/apache/cordova-js/blob/master/Gruntfile.js
Re: Seeking a partner for a SXSW 2014 workshop on Cordova (Sat, March 8)
Hey, I can help out if you want. Here is a talk I have given in the past on Cordova: http://www.youtube.com/watch?v=ZsDPnxBfybo Gord On Mon, Dec 2, 2013 at 12:47 PM, Lindsey Simon els...@gmail.com wrote: Hey fellow Cordova devs, I'm wondering if anyone might want to partner with me to do a Cordova workshop at SXSW 2014 http://sxsw.com/interactive. I made a proposal that has been accepted for a 2.5hr talk for Sat. March 8th, and my plan is to do a walkthrough of taking a relatively simple website and showing how to convert it to a Cordova app while highlighting some gotchas and cool things along the way. If you're interested, please email me off-list before December 8th. I suspect I can add up to 2 other speakers onto this workshop. You'll receive a complimentary Gold access pass to SXSW as a speaker, but your flight/hotel/etc will be something you'd need to figure out. As far as the time commitment goes I think I'll likely do the bulk of the prep-work, but I'd love to have someone who's willing to spend some time on it as well in advance and get together beforehand for a few hours in Austin to really talk it through on Friday or Saturday. I'm hoping that some of the audience will actually participate along the way with a computer and so having someone else to walk around and help folks out in addition to myself will be helpful. Also - just a heads up that SXSW can be a big, unruly conference and this format, the 2.5hr workshop, is something kind of new and experimental, so I'm hoping to end up with some useful tutorial materials to post online as well after the fact to make the most of the effort. -l
Re: cordova serve broken
I can code up a quick sample integration to see what cordova serve (powered by ripple) would look like. On Thu, Nov 7, 2013 at 7:16 AM, Josh Soref jso...@blackberry.com wrote: Brian wrote: Feels like we're starting to regress rather often on the CLI these past two releases. This is due to not running tests (or indeed writing them). Thats fine. Stuff happens. A gentle reminder: - If there is a bug: write a test - If you are adding or refactoring code: run the tests http://wiki.apache.org/cordova/RunningTests isn't linked from http://wiki.apache.org/cordova/IssueWorkflow And the instructions in both sections are unusable. I'll try to improve both pages when I wake up. - 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.
CommandProxy and misbehaving plugins
Hey everyone, Long time no commit but I was working on getting cordova 3.X support working in ripple (really really close and about to release it) but I saw some weird stuff in some of the plugins. In the vibration plugin the base javascript calls into the cordova exec module [1] and does all the work in the native layer, which is perfect. BlackBerry 10 overrides the base javascript with their own implementation that just delegates this to navigator.vibrate [2]. This isn't a unique problem as firefox does the same thing but handles it behind the exec layer [3]. It would be nice if we could keep each platform as close to being the same as possible and diverge behind the exec layer (like firefox does). I saw that windows8 and firefox both have a commandProxy that they use to add in services and actions for the native layer. I moved this to a common plugin [4] (since it was duplicated anyway). Now that this is a common plugin we can use it to override and add in native modules so that BlackBerry and other platforms don't need to diverge at the javascript API layer making it harder to emulate. [1] - https://github.com/apache/cordova-plugin-vibration/blob/master/www/vibration.js [2] - https://github.com/apache/cordova-plugin-vibration/blob/master/www/blackberry10/vibrate.js [3] - https://github.com/apache/cordova-plugin-vibration/blob/master/src/firefoxos/VibrationProxy.js [4] - https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commitdiff;h=c6817556d90cc4e500c4f480b6e106b1b52d3002
Re: Serve vs. opening an HTML file in the browser
Do you get the prompt's for the calls to native? If you do press cancel which will should allow things to boot up. If not try opening your browser to *http://localhost:4400/ ?enableRipple=cordova-3.0.0 http://emulate.phonegap.com/#* On Tue, Sep 10, 2013 at 10:04 AM, Ray Camden rayca...@adobe.com wrote: That's the thing - I can't get Ripple to load. I get the console.log infinite recursion thing I've gotten with PG for a while now. I literally can't get to a point where any HTML shows and the extension can take over. On 9/9/13 5:23 PM, Gord Tanner gtan...@gmail.com wrote: Hey, got pulled off on some other stuff: Lets make sure you are not running an old copy of ripple: cordova create Baz cordova platform add android cordova prepare cd incubator-ripple jake ./bin/ripple emulate --path ../Baz/platforms/android/assets/www/ Ensure that you have cordova 3.0.0 selected as the platform.
Re: Serve vs. opening an HTML file in the browser
That is something I am working on in my branch ;) On Tue, Sep 10, 2013 at 10:54 AM, Ray Camden rayca...@adobe.com wrote: I can confirm it works. :) Any way to bypass those alerts? (To be clear, it is easy enough for me to do, but I worry about the folks new to Ripple.) On 9/10/13 9:17 AM, Gord Tanner gtan...@gmail.com wrote: Do you get the prompt's for the calls to native? If you do press cancel which will should allow things to boot up. If not try opening your browser to *http://localhost:4400/ ?enableRipple=cordova-3.0.0 http://emulate.phonegap.com/#* On Tue, Sep 10, 2013 at 10:04 AM, Ray Camden rayca...@adobe.com wrote: That's the thing - I can't get Ripple to load. I get the console.log infinite recursion thing I've gotten with PG for a while now. I literally can't get to a point where any HTML shows and the extension can take over. On 9/9/13 5:23 PM, Gord Tanner gtan...@gmail.com wrote:
Re: Serve vs. opening an HTML file in the browser
Hey, got pulled off on some other stuff: Lets make sure you are not running an old copy of ripple: cordova create Baz cordova platform add android cordova prepare cd incubator-ripple jake ./bin/ripple emulate --path ../Baz/platforms/android/assets/www/ Ensure that you have cordova 3.0.0 selected as the platform. On Mon, Sep 9, 2013 at 6:17 PM, Ray Camden rayca...@adobe.com wrote: Hey Gord - just checking in. If you've been too busy to return to this - sorry - but if you missed my messages - let me know. On 9/3/13 12:30 PM, Gord Tanner gtan...@gmail.com wrote: You will need to run: ripple emulate --path /path/to/cordova/project/platform/android/assets/www Let me know if that works for you. On Tue, Sep 3, 2013 at 12:27 PM, Ray Camden rayca...@adobe.com wrote: Ok, I forgot to run cordova serve. I did, and then I get the same behavior as before. A prompt and then infinite console.log messages. On 9/2/13 8:32 PM, Gord Tanner gtan...@gmail.com wrote: Good news!
Re: Serve vs. opening an HTML file in the browser
You will need to run: ripple emulate --path /path/to/cordova/project/platform/android/assets/www Let me know if that works for you. On Tue, Sep 3, 2013 at 12:27 PM, Ray Camden rayca...@adobe.com wrote: Ok, I forgot to run cordova serve. I did, and then I get the same behavior as before. A prompt and then infinite console.log messages. On 9/2/13 8:32 PM, Gord Tanner gtan...@gmail.com wrote: Good news! I have a branch that is booting projects made with cordova 3.0 [1]. It is basically a stripped down platform and I tested it booting a project with android and ios. To run: cordova create Baz cordova platform add android cordova prepare ripple emulate (make sure you pick cordova 3.0.0) I was noticing that when I ran cordova serve android it wouldn't have the cordova_plugins.js file. Next Steps: - audit API's that are emulated and ensure they are up to spec (most are just using the 2.0 emulated versions) - reintegrate with cordova cli. Let me know if you take this for a test drive and have any problems. Gord
Re: Serve vs. opening an HTML file in the browser
Good news! I have a branch that is booting projects made with cordova 3.0 [1]. It is basically a stripped down platform and I tested it booting a project with android and ios. To run: cordova create Baz cordova platform add android cordova prepare ripple emulate (make sure you pick cordova 3.0.0) I was noticing that when I ran cordova serve android it wouldn't have the cordova_plugins.js file. Next Steps: - audit API's that are emulated and ensure they are up to spec (most are just using the 2.0 emulated versions) - reintegrate with cordova cli. Let me know if you take this for a test drive and have any problems. Gord [1] - https://github.com/apache/incubator-ripple/tree/cordova-3.0 On Wed, Aug 28, 2013 at 6:21 AM, Ray Camden rayca...@adobe.com wrote: On 8/27/13 11:41 PM, Gord Tanner gtan...@gmail.com wrote: I think with some tweaks we could have ripple working on all platform cordova.js files again. I am going to need to version out a new platform for cordova to handle the updated hacks and overrides to boot each platform cleanly but doesn't seem like an impossible task. If you need someone to help test, just let me know. -rc
Re: Moving on
Oh that is low Michal ;) Don't make me walk the 2 blocks to break my foot off in your ass. On Fri, Aug 30, 2013 at 2:58 PM, Michal Mocny mmo...@chromium.org wrote: Bah! Nonsense! Inconceivable! You will be missed, Fil, but do have fun in your new adventure. Also, speak up more often than Gord here on this lists, will ya? ;) -Michal On Fri, Aug 30, 2013 at 2:50 PM, Max Woghiren m...@chromium.org wrote: Best of luck, Fil! On Fri, Aug 30, 2013 at 2:48 PM, Gord Tanner gtan...@gmail.com wrote: Best of luck dude! On Fri, Aug 30, 2013 at 2:45 PM, Filip Maj maj@gmail.com wrote: Sweet, glad there are volunteers willing to take on stuff right away! And yes: I've got my phonegapday EU ticket and will be booking travel this weekend. Hopefully I'll see most of you there! P.S. who's going to lxjs? I'm going to be there along with a few good folk from the Adobe Cordova team :) On Fri, Aug 30, 2013 at 11:42 AM, Ian Clelland iclell...@google.com wrote: Best of luck, Fil! Glad to hear you're not stepping away from the project entirely, but your CLI and Plugman efforts will be missed, for sure. Will we still see you at PGDay? On Fri, Aug 30, 2013 at 2:33 PM, Lucas Holmquist lholm...@redhat.com wrote: good luck dude On Aug 30, 2013, at 2:31 PM, Filip Maj maj@gmail.com wrote: Hey everyone, Wanted to let the community know that I'm moving on from Adobe. Tuesday I'll be starting at Saucelabs, working on mobile automation on the RD team. My focus is going to shift away from cordova a little bit, but not entirely. My plan is to be involved a lot more in cordova-medic moving forward, but stepping away from the tooling (plugman + cli), JS, spec and platform work. As such, I'll be removing myself as lead in JIRA on the cordovaJS, mobile-spec, cli and plugman components. If any committers want to step up and take on a more involved role on those components, I'd recommend assigning yourself as lead in JIRA to those, that's always an easy way to be intimately familiar with issues coming down the pipeline :) Looking forward to working more on medic with you all! Cheers, Fil
Re: Moving on
Best of luck dude! On Fri, Aug 30, 2013 at 2:45 PM, Filip Maj maj@gmail.com wrote: Sweet, glad there are volunteers willing to take on stuff right away! And yes: I've got my phonegapday EU ticket and will be booking travel this weekend. Hopefully I'll see most of you there! P.S. who's going to lxjs? I'm going to be there along with a few good folk from the Adobe Cordova team :) On Fri, Aug 30, 2013 at 11:42 AM, Ian Clelland iclell...@google.com wrote: Best of luck, Fil! Glad to hear you're not stepping away from the project entirely, but your CLI and Plugman efforts will be missed, for sure. Will we still see you at PGDay? On Fri, Aug 30, 2013 at 2:33 PM, Lucas Holmquist lholm...@redhat.com wrote: good luck dude On Aug 30, 2013, at 2:31 PM, Filip Maj maj@gmail.com wrote: Hey everyone, Wanted to let the community know that I'm moving on from Adobe. Tuesday I'll be starting at Saucelabs, working on mobile automation on the RD team. My focus is going to shift away from cordova a little bit, but not entirely. My plan is to be involved a lot more in cordova-medic moving forward, but stepping away from the tooling (plugman + cli), JS, spec and platform work. As such, I'll be removing myself as lead in JIRA on the cordovaJS, mobile-spec, cli and plugman components. If any committers want to step up and take on a more involved role on those components, I'd recommend assigning yourself as lead in JIRA to those, that's always an easy way to be intimately familiar with issues coming down the pipeline :) Looking forward to working more on medic with you all! Cheers, Fil
Re: Serve vs. opening an HTML file in the browser
Took a look at what was breaking ripple and it is a little more involved then I was hoping: - Android crashing the browser is caused by changes to how android sets up it's polling and how the modules all work together in the exec module. We used to have everything regarding polling rolled into the 'cordova/plugin/android/polling' module in which ripple would just override [1] to do nothing since ripple handled everything by replacing the entire exec function. I think this module was removed / moved to another place in 3.0 but there is much more thought to be done to get this working better. Switched over to using the cordova.ios.js file since it doesn't have this problem and ripple was able to boot and emulate geolocation fine. The plugins were not loading from cordova serve ios though (couldn't load cordova_plugins.js). I think with some tweaks we could have ripple working on all platform cordova.js files again. I am going to need to version out a new platform for cordova to handle the updated hacks and overrides to boot each platform cleanly but doesn't seem like an impossible task. [1] - https://github.com/apache/incubator-ripple/blob/master/lib/client/platform/cordova/2.0.0/spec.js#L81-L83 On Tue, Aug 27, 2013 at 5:45 PM, Brian LeRoux b...@brian.io wrote: I'll buy you a gord for that too! On Tue, Aug 27, 2013 at 11:19 AM, Ray Camden rayca...@adobe.com wrote: Dude, if you get this working, I won't buy you a beer. I'll go back and time and make it so that when beer was invented, it was called Gord, and your name would forever be synonymous with the best thing ever created. Not being able to use Ripple has been a real pain in my rear when doing presentations. I've even taken to just using a PG 2.6 files. On 8/27/13 1:16 PM, Gord Tanner gtan...@gmail.com wrote: I can take a look at this tonight. We may not be upto date with API support (not a lot of people working on the project right now) but we shouldn't crash. I will ping back on this list when I know more Gord
Re: NPM stats on ripple
For sure! Sent from my iPhone On 2013-07-24, at 3:05 PM, Filip Maj f...@adobe.com wrote: The stats are a bit wonky but yes, cordova cli seems to be powering those numbers. My plan is to put much more love into Ripple in the coming weeks/months! Hoping you can help me out with that too Gord ;) On 7/22/13 12:36 PM, Andrew Grieve agri...@chromium.org wrote: CLI depends on Ripple, right? So wouldn't that mean Ripple should have as many downloads as CLI? It seems to have only ~half as many. Unless the charts don't include packages downloaded as dependencies? On Mon, Jul 22, 2013 at 3:14 PM, Gord Tanner gtan...@gmail.com wrote: Just thought I would let everyone know we have had 7600 downloads of Ripple via npm this month. http://npm-stat.vorb.de/charts.html?package=ripple-emulator #OMFG
Re: cordova-playbook 'deprecation'
I am just a little annoyed because of the promise that we would get PlayBook support with the big BlackBerry 10 rewrite that was done. The promise was we were just shelving the Java Phone OS code and cleaning up things for PlayBook and BlackBerry 10. I hope that the official support for BlackBerry 10 isn't thrown out as quickly as PlayBook support was as soon as BlackBerry 11 is released. Like I said in a previous email, we went from supporting every blackberry device in cordova to supporting only 2 devices (Z10 and Q10). Would the community be as accepting if we said Cordova only supported iOS7 on the iPhone5? On Tue, Jul 23, 2013 at 11:19 AM, Brian LeRoux b...@brian.io wrote: I think, or at least thought, that is what Lorin meant. On Tue, Jul 23, 2013 at 11:07 AM, Anis KADRI anis.ka...@gmail.com wrote: Remove ? No! Just leave the source in there. Somebody might be interested in it. We can stop shipping it though if we are still doing it. On Tue, Jul 23, 2013 at 8:04 AM, Lorin Beer lorin.beer@gmail.com wrote: Scare-quotes due to playbook never being an officially supported platform. After discussing playbook with Bryan and Jeff from BlackBerry, a few points came up: 1. BB10 won't be coming to the PlayBook platform 2. The work required to bring it up to 3.0 spec is not justified by interest or number of devices 3. Many would rather see any effort directed to Playbook go towards BBOS instead, and that is unlikely to happen. Without further support for the platform, and with that support being poorly justified, I suggest the Playbook platform be removed from Cordova. - Lorin
NPM stats on ripple
Just thought I would let everyone know we have had 7600 downloads of Ripple via npm this month. http://npm-stat.vorb.de/charts.html?package=ripple-emulator #OMFG
Cordova BlackBerry PlayBook Support
I just read that the PlayBook is no longer getting BlackBerry 10 [1] which is kinda shitty since now the official support for cordova on BlackBerry is now 2 phones which have not been getting good market traction [2]. - Anyone from BlackBerry able to comment on the PlayBook? - Are you guys still making a tablet? - what does this mean for the current playbook support? [1] - http://crackberry.com/blackberry-announces-bb10-not-coming-playbook [2] - http://crackberry.com/blackberry-q1-f2014-results-are-they-executing
Re: onNativeReady and FirefoxOS
I could have swore there was one at one point ;)
but it is going to look exactly like the webos one [1]
[1] -
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob_plain;f=lib/scripts/bootstrap-webos.js;hb=HEAD
On Tue, Jun 25, 2013 at 10:52 AM, Andrew Grieve agri...@chromium.orgwrote:
likely you want to add a bootstrap.firefoxos.js file
On Tue, Jun 25, 2013 at 3:40 AM, Piotr Zalewa pzal...@mozilla.com wrote:
Hi,
Here is me again.
I commented out the reinstantiating window.navigator to make it not
throw SecurityError under FxOS.
I then realized the 'deviceready' isn't fired.
It should be fired in
https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5977afterchannel.onDOMContentLoaded,
channel.onNativeReady,
channel.onPluginsReady.
onDOMContentLoaded and onPluginsReady are fired, but onNativeReady is
not.
The only place in this file which is related to this event is this:
https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5954
// _nativeReady is global variable that the native side can set
// to signify that the native code is ready. It is a global since
// it may be called before any cordova JS is ready.
if (window._nativeReady) {
channel.onNativeReady.fire();
}
Is this event not fired because of my change to cordova-firefoxos.js
(commenting out
https://github.com/apache/cordova-firefoxos/blob/master/lib/cordova.firefoxos.js#L5945
)?
Please help
zalun
PS.
There is also an issue later on with onCordovaConnectionReady (but I
forced onNativeReady before, so too many variables to play)
Re: Jake woes
Ex-term-in-ate Sent from my iPhone On 2013-06-21, at 6:52 PM, Simon MacDonald simon.macdon...@gmail.com wrote: Guys no one can completely defeat the daleks. I'm sure that they will be back. Possibly in rainbow colours. On Jun 21, 2013 6:27 PM, Lorin Beer lorin.beer@gmail.com wrote: HORRIBLE On Fri, Jun 21, 2013 at 2:43 PM, Jesse purplecabb...@gmail.com wrote: Punishable by death or bunga-bunga, your choice. @purplecabbage risingj.com On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj f...@adobe.com wrote: noo On 6/21/13 2:01 PM, Patrick Mueller pmue...@gmail.com wrote: It appears you've made a horrible, HORRIBLE mistake with your patch [1], and deleted the dalek. HORRIBLE. [1] https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a 3a ps: I too once tried to delete the dalek, and look what happened to me. and the dalek :-( On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes benn.ma...@gmail.com wrote: Could you also update the README? https://issues.apache.org/jira/browse/CB-3966 Thanks! On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - 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. -- Patrick Mueller http://muellerware.org
Re: BB10 bundling of node.js
-1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins bhigg...@blackberry.comwrote: I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Re: BB10 bundling of node.js
I would expect they would have a supported node version when they type: npm install cordova which would do any version checks in the package.json [1] for supported node versions [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=package.json;hb=HEAD On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins br...@bryanhiggins.netwrote: So for Cordova 3.0 in general, users will be required to pre-install a minimum version of node globally? We have had issues where upgrading node breaks stuff. I'd like to avoid that and give users flexibility with their own system configuration. On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner gtan...@gmail.com wrote: -1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins bhigg...@blackberry.com wrote: I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Re: BB10 bundling of node.js
Still a -1, cordova (and all it's projects) should use the globally installed version of node. If someone needs multiple versions of node the should probably use nvm [1] to manage it. IMHO this is a user problem and not something we should magically solve via bundled copies of node or hardcoded paths to specific versions of node. I agree we should have a version of node we support, it just needs to be consistent and common across all of our tools and require the user to have that version range in their path. [1] - https://github.com/creationix/nvm On Wed, Jun 19, 2013 at 3:57 PM, Bryan Higgins br...@bryanhiggins.netwrote: For 3.0 will there still be a ZIP file released by Apache? Will the instructions be download the latest version of node then run npm install -g path to cordova-cli? My assumption was the individual project templates will continue to work independently of CLI. Also, keep in mind that CLI invokes BB via shell scripts which in turn call node. So for environments where people need different versions of node installed, invoking CLI with an alternate node version will cause BB to be invoked via the globally installed version. Perhaps that is an edge case, but it's still something that needs to be supported by allowing them to configure node path for BB. On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner gtan...@gmail.com wrote: I would expect they would have a supported node version when they type: npm install cordova which would do any version checks in the package.json [1] for supported node versions [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=package.json;hb=HEAD On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins br...@bryanhiggins.net wrote: So for Cordova 3.0 in general, users will be required to pre-install a minimum version of node globally? We have had issues where upgrading node breaks stuff. I'd like to avoid that and give users flexibility with their own system configuration. On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner gtan...@gmail.com wrote: -1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins bhigg...@blackberry.com wrote: I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Re: [cordova-cli] ripple instead of serve
+1 Currently the ripple command runs on top of serve [1] but should be really easy to refactor. Once the integration is a bit more solid we need to start routing emulate commands for unsupported platforms to ripple. [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=src/ripple.js;hb=HEAD On Mon, Jun 10, 2013 at 4:03 PM, Braden Shepherdson bra...@chromium.orgwrote: +1 I hacked serve together in a couple of hours, and it is not in active use. Corporate network environments are generally not open to your phone connecting directly to a serve running on your laptop or desktop, making 'serve' not very useful. Braden On Mon, Jun 10, 2013 at 2:25 PM, Filip Maj f...@adobe.com wrote: HI GUYS! I'm reviving this thread :) There are a couple of issues filed for both CLI commands `ripple` and `serve`. We've spoke in the past about axing `serve` in favor of `ripple` (see below in this thread). My suggestion: remove `serve` altogether in 3.0. There was consensus for this before but just wanted to loop back with folks to make sure this sounded alright. Serve seems to be completely abandoned: the tests are currently disabled (and not passing), so I am in favor of closing the serve-related issues as won't fix and suggesting people employ `cordova ripple` instead. On 3/23/13 7:15 AM, Andrew Grieve agri...@chromium.org wrote: https://uwaterloo.ca/engineering/events/first-robotics-waterloo-regional I was a score keeper last year (two years ago?) and it was super cool. On Fri, Mar 22, 2013 at 10:03 PM, Michal Mocny mmo...@chromium.org wrote: Dan, my brother showed me this (he is mechatronics student at UW). Is it still on tomorrow? On Fri, Mar 22, 2013 at 6:41 PM, Dan Silivestru dan.silives...@gmail.com wrote: +1 Sorry I'm late to the game, I was judging frisbee throwing, pyramid climbing robots all day :-) https://twitter.com/confusement/status/315162754619162625 On Fri, Mar 22, 2013 at 6:35 PM, Filip Maj f...@adobe.com wrote: K lets try to land it in 2.6.0rc1. There is still time Gord! Blackberry + iOS not tagged yet so we can land some more commits in cordova-cli On 3/22/13 3:02 PM, Brian LeRoux b...@brian.io wrote: Like that plan. Say we proceed and land it in 2.6 to feel out. On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj f...@adobe.com wrote: I'm fine with removing server. In my mind ripple is just a serve command on steroids. At this morning's meeting I believe some of the Googlers expressed concerns about axing out serve, so perhaps a prudent first step would be to add Ripple as an `emulate` command and then we can take baby steps to extract out serve over the coming weeks. On 3/22/13 2:45 PM, Gord Tanner gtan...@gmail.com wrote: Ripple is now ready to be integrated, currently I have it added as a seperate ripple command in a personal branch [1] Most of the work on Ripple was a much needed feature we knew we needed (Device Selection via query string [2]) as well as adding the ability to serve content from multiple directories [3] (to support www/ merged with platform/www/). Should I do the full remove serve and add this to emulate or merge this in as is? (maybe remove serve in the meantime) [1] - https://github.com/gtanner/cordova-cli/tree/ripple [2] - https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitd if f;h=b36213d426700a3cc62b4701bc75806ff8539528 [3] - https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitd if f;h=2e483836bc5a24397ed002556f4209fac9508438 On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny mmo...@chromium.org wrote: Thats awesome ;) On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner gtan...@gmail.com wrote: Yeah Michal, That is the exact use case I had in mind. When we were a startup we couldn't afford mac's so just used linux and ripple for all our contract work and borrowed a friends macbook when we needed to compile. On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny mmo...@chromium.org wrote: Very interesting. Combined with Bradens proposal to support pointing to a local platform, looks very good. Also note, offline isn't the only reason, platform support on a given machine as well: ie, can test iPhone (sorta) on a linux box through Ripple. On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux b...@brian.io wrote: omg I just realized this would fulfill offline use case
Re: [cordova-cli] ripple instead of serve
Also with Ripple: If you don't pass the ?enableRipple=true qs param it does exactly what serve does ;) On Mon, Jun 10, 2013 at 4:29 PM, Filip Maj f...@adobe.com wrote: My view is that both `ripple` and `serve` do essentially the same thing: host local assets for viewing/editing/testing in a browser. Essentially enabling that fast edit/refresh cycle without have to compile/redeploy to a device every time. And as Gord chimed in, current `cordova ripple` relies to a degree on `serve`. Definitely do NOT want to eliminate the ability to do edit/refresh. Rather, we have two fairly buggy implementations that I would like to see consolidated and fixed. DEFINITELY want to have good integration with the app harness. I have yet to play around with it, actually, to my shame. Michal are there any specific things necessary for the app-harness other than a local server? On 6/10/13 1:23 PM, Michal Mocny mmo...@chromium.org wrote: If the current 'serve' implementation needs axing, thats fine. However, curious if you are implying that 'ripple' will be the only way to do repid edit-refresh without rebuilding native components? We need a way to get app updates to a device running e.g. app-harness right? I thought that was the point of 'serve'. Is the proposal to remove the current implementation and re-add something functional later, or is the argument that we don't need a serve feature at all? -Michal On Mon, Jun 10, 2013 at 4:12 PM, Gord Tanner gtan...@gmail.com wrote: +1 Currently the ripple command runs on top of serve [1] but should be really easy to refactor. Once the integration is a bit more solid we need to start routing emulate commands for unsupported platforms to ripple. [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f= src/ripple.js;hb=HEAD On Mon, Jun 10, 2013 at 4:03 PM, Braden Shepherdson bra...@chromium.org wrote: +1 I hacked serve together in a couple of hours, and it is not in active use. Corporate network environments are generally not open to your phone connecting directly to a serve running on your laptop or desktop, making 'serve' not very useful. Braden On Mon, Jun 10, 2013 at 2:25 PM, Filip Maj f...@adobe.com wrote: HI GUYS! I'm reviving this thread :) There are a couple of issues filed for both CLI commands `ripple` and `serve`. We've spoke in the past about axing `serve` in favor of `ripple` (see below in this thread). My suggestion: remove `serve` altogether in 3.0. There was consensus for this before but just wanted to loop back with folks to make sure this sounded alright. Serve seems to be completely abandoned: the tests are currently disabled (and not passing), so I am in favor of closing the serve-related issues as won't fix and suggesting people employ `cordova ripple` instead. On 3/23/13 7:15 AM, Andrew Grieve agri...@chromium.org wrote: https://uwaterloo.ca/engineering/events/first-robotics-waterloo-regional I was a score keeper last year (two years ago?) and it was super cool. On Fri, Mar 22, 2013 at 10:03 PM, Michal Mocny mmo...@chromium.org wrote: Dan, my brother showed me this (he is mechatronics student at UW). Is it still on tomorrow? On Fri, Mar 22, 2013 at 6:41 PM, Dan Silivestru dan.silives...@gmail.com wrote: +1 Sorry I'm late to the game, I was judging frisbee throwing, pyramid climbing robots all day :-) https://twitter.com/confusement/status/315162754619162625 On Fri, Mar 22, 2013 at 6:35 PM, Filip Maj f...@adobe.com wrote: K lets try to land it in 2.6.0rc1. There is still time Gord! Blackberry + iOS not tagged yet so we can land some more commits in cordova-cli On 3/22/13 3:02 PM, Brian LeRoux b...@brian.io wrote: Like that plan. Say we proceed and land it in 2.6 to feel out. On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj f...@adobe.com wrote: I'm fine with removing server. In my mind ripple is just a serve command on steroids. At this morning's meeting I believe some of the Googlers expressed concerns about axing out serve, so perhaps a prudent first step would be to add Ripple as an `emulate` command and then we can take baby steps to extract out serve over the coming weeks. On 3/22/13 2:45 PM, Gord Tanner gtan...@gmail.com wrote: Ripple is now ready to be integrated, currently I have it added as a seperate ripple command in a personal branch [1] Most of the work on Ripple was a much needed feature we knew we needed (Device Selection via query string [2]) as well as adding
Re: Baby Grieve
Congrats! On Fri, May 31, 2013 at 10:05 AM, Bryan Higgins br...@bryanhiggins.netwrote: Congrats!!! On Fri, May 31, 2013 at 10:03 AM, Steven Gill stevengil...@gmail.com wrote: Congrats Andrew!!! On Fri, May 31, 2013 at 7:00 AM, Andrew Grieve agri...@chromium.org wrote: Coming 1 month early Everett Arend Grieve born Thursday May 30 at 9:45 am. 5 lbs 15 oz. 18.5 inches long. Mom is currently in the ACOU and Everett in the ICU. They are on track to meet today! We will be a few days in the hospital, but everything's looking good! Not sure how much I'll be checking email in the next little while. Good luck with the release! Andrew
Re: Roadmap for BB7
From what I understand BlackBerry is focused on BlackBerry 10 and there is no plan to update or add features to BlackBerry 7 On Tue, May 7, 2013 at 5:36 PM, Don Coleman don.cole...@gmail.com wrote: Is there a roadmap for BlackBerry 7 support in future versions of Cordova?
Ch-ch-ch-ch-changes
Hey everyone. Just a heads up that I am no longer working at BlackBerry anymore. I will be still contributing to Cordova on my own time but more directed at the tooling layer in regards to Ripple and Cordova integration. The great news is that BlackBerry has a whole team to step up and continue support for BlackBerry and Cordova. Gord
Re: BB10 and JIRA Etiquette
The BlackBerry team has said on this list that they are rewriting everything for BlackBerry 10. They haven't shared any of the code yet but have warned that it is a complete rewrite. I am expecting it to be about the same support (or more). I think the issues are still valid as I can't imagine much changing when they rewrite everything. BlackBerry can chime in with more information. On Thu, Apr 4, 2013 at 6:10 AM, Lorin Beer lorin.beer@gmail.com wrote: I've started cataloguing the failing tests and missing functionality on BB10. There's about 50 failing tests, and many more missing features (minor and major). What I'm wondering is this: 1. dump all the issues in jira as I find them or 2. report the issues as I get an opportunity to fix them given the number of failing tests and issues, it would be some months before I could get around to fixing all of them. On one hand, we get these issues documented so users see were aware of it, and can indicate what they need fixed, not to mention encouraging others to take on some of these issues. On the other hand, it'll bloat our issue count. :) Wondering what the best approach is. - Lorin
Re: [cordova-cli] vendoring the platforms instead of lazy download
There was some issues over download size for our cli, any idea what the size of all the platforms are? Sent from my iPhone On 2013-03-22, at 1:42 PM, Braden Shepherdson bra...@chromium.org wrote: I'm content to have the vendoring, it has some advantages as you wrote. However, I would also very much like to add a platform that's running from somewhere on my local disk, as I described in my feature request in the doc. So I propose a flag like cordova platform add android --target=../../cordova-android where that local directory can have whatever locally patched code I want. Braden On Fri, Mar 22, 2013 at 1:37 PM, Brian LeRoux b...@brian.io wrote: Right now we put the release of Cordova into the npm package for cordova-cli and we version lock the two. (Codova/CLI 2.5.x === Cordova/Platform 2.5.latest). We did this because: - has to work offline - cannot have a Git dep to do development - issue tracking locked to the real version of Cordova We can solve all these issues. The code to do that isn't really a huge deal. But to add it we gain very little that isn't already achieved by vendoring. I'd like for us to be aware the current can be improved but its low priority compared to, say, ripple and plugin integration.
Re: [cordova-cli] ripple instead of serve
+1 With this I would want to add the ability to add a platform to a project even if we don't have the build dependencies. Emulate would just default to ripple so is still usable if we can't build/deploy Sent from my iPhone On 2013-03-22, at 1:55 PM, Brian LeRoux b...@brian.io wrote: I think this bleeds back into other discussions. It was mentioned in the call earlier. I think some tacit agreement that ./serve goes away and Ripple is the default ./emulate command. But lets discuss. (Just this. Lets keep thread focused.)
Re: [cordova-cli] ripple instead of serve
Yeah Michal, That is the exact use case I had in mind. When we were a startup we couldn't afford mac's so just used linux and ripple for all our contract work and borrowed a friends macbook when we needed to compile. On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny mmo...@chromium.org wrote: Very interesting. Combined with Bradens proposal to support pointing to a local platform, looks very good. Also note, offline isn't the only reason, platform support on a given machine as well: ie, can test iPhone (sorta) on a linux box through Ripple. On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux b...@brian.io wrote: omg I just realized this would fulfill offline use case vs lazy load vendoring caching could be a future thing might be a really nice path On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner gtan...@gmail.com wrote: +1 With this I would want to add the ability to add a platform to a project even if we don't have the build dependencies. Emulate would just default to ripple so is still usable if we can't build/deploy Sent from my iPhone On 2013-03-22, at 1:55 PM, Brian LeRoux b...@brian.io wrote: I think this bleeds back into other discussions. It was mentioned in the call earlier. I think some tacit agreement that ./serve goes away and Ripple is the default ./emulate command. But lets discuss. (Just this. Lets keep thread focused.)
Re: [cordova-cli] ripple instead of serve
Merged into next [1]. I am currently at the pub and a beer or two in so I am not going to code to much. If someone wants to axe serve (or refactor it to just use ripple) that would be awesome. [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/heads/next On Fri, Mar 22, 2013 at 6:41 PM, Andrew Grieve agri...@chromium.org wrote: To clarify - I don't mind if serve gets axed for now. On Fri, Mar 22, 2013 at 6:02 PM, Brian LeRoux b...@brian.io wrote: Like that plan. Say we proceed and land it in 2.6 to feel out. On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj f...@adobe.com wrote: I'm fine with removing server. In my mind ripple is just a serve command on steroids. At this morning's meeting I believe some of the Googlers expressed concerns about axing out serve, so perhaps a prudent first step would be to add Ripple as an `emulate` command and then we can take baby steps to extract out serve over the coming weeks. On 3/22/13 2:45 PM, Gord Tanner gtan...@gmail.com wrote: Ripple is now ready to be integrated, currently I have it added as a seperate ripple command in a personal branch [1] Most of the work on Ripple was a much needed feature we knew we needed (Device Selection via query string [2]) as well as adding the ability to serve content from multiple directories [3] (to support www/ merged with platform/www/). Should I do the full remove serve and add this to emulate or merge this in as is? (maybe remove serve in the meantime) [1] - https://github.com/gtanner/cordova-cli/tree/ripple [2] - https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif f;h=b36213d426700a3cc62b4701bc75806ff8539528 [3] - https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif f;h=2e483836bc5a24397ed002556f4209fac9508438 On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny mmo...@chromium.org wrote: Thats awesome ;) On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner gtan...@gmail.com wrote: Yeah Michal, That is the exact use case I had in mind. When we were a startup we couldn't afford mac's so just used linux and ripple for all our contract work and borrowed a friends macbook when we needed to compile. On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny mmo...@chromium.org wrote: Very interesting. Combined with Bradens proposal to support pointing to a local platform, looks very good. Also note, offline isn't the only reason, platform support on a given machine as well: ie, can test iPhone (sorta) on a linux box through Ripple. On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux b...@brian.io wrote: omg I just realized this would fulfill offline use case vs lazy load vendoring caching could be a future thing might be a really nice path On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner gtan...@gmail.com wrote: +1 With this I would want to add the ability to add a platform to a project even if we don't have the build dependencies. Emulate would just default to ripple so is still usable if we can't build/deploy Sent from my iPhone On 2013-03-22, at 1:55 PM, Brian LeRoux b...@brian.io wrote: I think this bleeds back into other discussions. It was mentioned in the call earlier. I think some tacit agreement that ./serve goes away and Ripple is the default ./emulate command. But lets discuss. (Just this. Lets keep thread focused.)
Re: archiving older platforms
I am confused, who are the stewards and what platforms are being stewarded? Sent from my iPhone On 2013-03-21, at 6:00 PM, Filip Maj f...@adobe.com wrote: +1 On 3/21/13 2:12 PM, Shazron shaz...@gmail.com wrote: +1 On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny mmo...@chromium.org wrote: +1 On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux b...@brian.io wrote: Ok, I think we have agreement that we'll put these guys on hold until they find a steward. This means: - we won't be taggin them further - we won't be including them in a release This does not mean: - deletion or archiving or attic for the src (Think of it as a pause button!) Agree/disagree? On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve agri...@chromium.org wrote: If there are no fixes going into these platforms, then there is no benefit in their users updating them to newer versions of Cordova. There's going to be more refactoring required when moving plugins to their own repos. We'll really need owners for all platforms that will make the transition, or else we won't have any way to test that the refactoring hasn't broken a platform. On specific example is that blackberry's JS repo is really 4-in-1 currently, and our plugin spec doesn't have support for this. They will need to be split out into 4 separate platforms, at least as far as the JS is concerned. So... I guess my +1 is just for any platform that doesn't have a someone willing to focus on it. E.g. I'm fine with keeping WebOS around if Markus wants to do the work to support it through this transition. On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis kwal...@blackberry.com wrote: We will try to provide relevant stats on platform adoption as we are able. I am anxiously awaiting that information myself. ;) While lacking this information, I still feel that BBOS will be with us for a deal of time, particularly in the enterprise where we are seeing a significant trend towards Cordova/PhoneGap/WebWorks as the primary platform of choice for apps. This is, frustratingly, a difficult market to get adequate metrics out of, as they will typically not use PhoneGap Build IMO, and they don't deploy to commercial application stores. A bit of a black box, but our enterprise support teams continually support the notion that enterprise looks at HTML5 apps first. In this regard, we would like to see support for BBOS be maintained in the short term. Our team is focused on bringing up BlackBerry 10 built on Cordova, and once that has gotten to a stable point we will then be able to look at resources and determine if BBOS is still a valuable platform to support and if we can port BBOS to the new structures. Hope that makes sense. Sent from my BlackBerry Z10 smartphone. From: Anis KADRI Sent: Monday, March 18, 2013 1:00 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: archiving older platforms s/QR/Qt On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer lorin.beer@gmail.com wrote: +1 Bada/webOS/QR echoing Michael's point, I'd like to see usage stats on the older BB platforms. BB10 should absolutely be the focus, but If they are currently being used, mothballing may be premature. Revisiting the issues regularly, and making one based on usage stats makes the most sense to me. On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj f...@adobe.com wrote: +1 all of them, Java and Air implementations of BlackBerry as well. For the older implementations of BlackBerry, nothing is stopping anyone from using that code. The fact is that Java and Air-related fixes have not been going in regularly. The implementations are stable enough that drawing a line in the sand and saying no more active support for the older BB SDKs is acceptable in my opinion. On 3/17/13 11:44 AM, Michael Brooks mich...@michaelbrooks.ca wrote: As far as bb 6 and 7, I am sure the majority of devices out there are BB 6 and 7. BB10 just came out so there can't be that many yet. Developers don't seem to be interested in those platform though and I think the focus should be on BB10. It would probably be more accurate to say BlackBerry Java which includes BB 4.6/5/6/7 - yep, we support all the way back 4.6 although no one tests that far back anymore. I've heard BlackBerry voice the opinion that they would like to see Apache Cordova focus solely on BlackBerry 10. However, PhoneGap/Build has seen a large demand for BlackBerry 5 and 6. +1 Bada +1 webOS - we may want to bring this out of the Attic in the future +1 QR - we may want to bring it this out of the Attic when gearing up for Ubuntu Phone +0 BB - I want to talk with the our PhoneGap/Build team to better understand their stance. I'd also like Ken or Jeff from BlackBerry to chime in with their opinion. On Sun, Mar 17, 2013 at 10:11 AM, Anis KADRI
Re: [DISCUSS] Add Ripple support to cordova-cli
+1 to Micheal's API. I am going to do the initial integration in with the ripple command (just to keep that commit isolated to some changes to serve and the new ripple command). On Wed, Mar 20, 2013 at 2:30 PM, Filip Maj f...@adobe.com wrote: Agreed, I am summarizing my thoughts on the other thread, but as Gord originally insinuated, these commands should lie in cordova-cli, not in the underlying platform scripts. On 3/20/13 10:32 AM, Michael Brooks mich...@michaelbrooks.ca wrote: We have a discussion going on the Cordova list running about this right now. The idea will be that `cordova run` will launch the app in Ripple. (And we're going to kill off the `cordova serve` cmd.) We'll keep `cordova emulate [platform]` around but I doubt ppl will use it much once `run` is there. I'd like to avoid the sprawl of commands and keep it more organized and intuitive. Ripple is an emulator and belongs under the emulate command. The command signature should be: $ cordova emulate [options] platform $ cordova emulate platform Launches the platform's SDK emulator $ cordova emulate platform --ripple [--port p] Launches the platform in the Ripple emulator Michael On Wed, Mar 20, 2013 at 3:30 AM, Brian LeRoux b...@brian.io wrote: We have a discussion going on the Cordova list running about this right now. The idea will be that `cordova run` will launch the app in Ripple. (And we're going to kill off the `cordova serve` cmd.) We'll keep `cordova emulate [platform]` around but I doubt ppl will use it much once `run` is there. Good times! =) On Wed, Mar 20, 2013 at 1:12 AM, Alessandro Aprile aprile.alessan...@gmail.com wrote: +1 ripple is so simple and useful... 2013/3/20 Tommy-Carlos Williams to...@devgeeks.org +1 Ripple is all I use `cordova serve` for anyway :) On 20/03/2013, at 10:14 AM, Filip Maj f...@adobe.com wrote: I would like to see Ripple support completely replace the cordova server command - they both do the same thing but Ripple is better tailored at doing the server+emulation job. On 3/9/13 12:08 PM, Brian LeRoux b...@brian.io wrote: Yes, this is awesome, think a Ripple command is good while we suss it out: `cordova emulate ripple` or even just `cordova ripple`. Eventually I'd think we'd want `cordova emulate` to just default to Ripple once it feels baked enough. On Thu, Mar 7, 2013 at 11:12 AM, Gord Tanner gtan...@gmail.com wrote: Hello everyone, I made a quick prototype to add support for using ripple from the cordova-cli [1]. Currently I just added a new command called ripple that calls the cordova emulate command and then starts the ripple server to point to it. It will then launch the default browser (cross platform) which will launch your App in ripple. This does not require the plugin to be installed as Ripple is functioning as a proxy / web app. I have a question on how to handle this command: - Should this be a flag on the cordova emulate command? The Command could ether be: cordova serve platform [port] --ripple or cordova ripple platform [port] There are also a couple of todos: - Ripple needs to be published to npm and we should install it via that, currently I am just cloning via git. This will happen soon and is just a temp hack. - Ripple is currently starting its own server, we should allow the cordova emulate middleware to be usable by ripple - Ripple should allow us to pick the device we want to launch on. If I launch using blackberry I shouldn't have ripple emulate an iPhone. [1] https://github.com/gtanner/cordova-cli/commit/cf499d53b3e6f6631513fd5 110c0861f8f01
Re: cordova-firefoxos repo has been created
Nice! Seems to be missing one commit: https://git-wip-us.apache.org/repos/asf?p=cordova-labs.git;a=commitdiff;h=76ecc678a888932695eb62695711b8a83f85ae87 Still waiting for Mozilla to send me the dev phone. Sent from my iPhone On 2013-03-14, at 1:18 AM, Brian LeRoux b...@brian.io wrote: *guitar solo* On Wed, Mar 13, 2013 at 3:36 PM, Filip Maj f...@adobe.com wrote: Rad! On 3/13/13 3:34 PM, Herm Wong kingoftheo...@hotmail.com wrote: Cordova-FirefoxOS repo has been created with the initial project. https://git-wip-us.apache.org/repos/asf?p=cordova-firefoxos.git;a=summary Should propagate to github soon.
Re: Who's who at cordova
what about http://people.phonegap.com/? On Tue, Mar 12, 2013 at 2:55 PM, Shazron shaz...@gmail.com wrote: +1 On Tue, Mar 12, 2013 at 11:31 AM, Michal Mocny mmo...@google.com wrote: I'de like to make a wiki page with a brief bio of all cordova contributors (a who's who, if you will). This helps new contributors, and frankly, helps me with my terrible memory keep track of the less vocal members. Is anyone apposed to this for any reason? -Michal
Re: who is James
Welcome! Sent from my iPhone On 2013-03-12, at 5:26 PM, Lorin Beer lorin.beer@gmail.com wrote: Hi James, thanks for the intro! On Tue, Mar 12, 2013 at 2:18 PM, Anis KADRI anis.ka...@gmail.com wrote: Welcome James! On Tue, Mar 12, 2013 at 12:41 PM, Brian LeRoux b...@brian.io wrote: Welcome to the fray James! On Tue, Mar 12, 2013 at 12:32 PM, Michal Mocny mmo...@chromium.org wrote: Hi James! Thanks for the intro. I think its worthwhile to make a page with reverse intros from all of us to you, I'll get on that. On Tue, Mar 12, 2013 at 3:29 PM, Filip Maj f...@adobe.com wrote: Welcome! Looking forward to collaborating with you :) On 3/12/13 2:27 PM, James Jong wjamesj...@gmail.com wrote: Hey everyone, I just wanted to introduce myself to the group since I'm sure some of you are wondering who this 'James Jong' guy is. Probably not, but let's pretend you doĹ ;-) I work in the mobile software group in IBM and my current job role is to help build and foster the Cordova community as best as I can. I work on a small team and that's our (very cool) mission. You may already know some of the folks I'm working with (Simon, Becky, Bryce, Pat, Marcel). We actively use Cordova and want to contribute to the long-term success of Cordova. I will likely be focusing more on iOS and mobile-spec initially, but also have an interest in the CLI work and debugging. Personally, I think it's awesome that I get to work with Cordova as my full-time job and that is the main reason I jumped at this opportunity. My previous roles have all been with internal development within IBM, mostly on the server-side. I've worked on linux, network security, user interfaces, C/C++ and Java in those roles. I am really looking forward to getting to know you and working with the community. Thanks to Andrew for suggesting that I do this. Hopefully it gives you a better background on me. Feel free to contact me if you want more details or just to chat. -James Jong
[DISCUSS] Add Ripple support to cordova-cli
Hello everyone, I made a quick prototype to add support for using ripple from the cordova-cli [1]. Currently I just added a new command called ripple that calls the cordova emulate command and then starts the ripple server to point to it. It will then launch the default browser (cross platform) which will launch your App in ripple. This does not require the plugin to be installed as Ripple is functioning as a proxy / web app. I have a question on how to handle this command: - Should this be a flag on the cordova emulate command? The Command could ether be: cordova serve platform [port] --ripple or cordova ripple platform [port] There are also a couple of todos: - Ripple needs to be published to npm and we should install it via that, currently I am just cloning via git. This will happen soon and is just a temp hack. - Ripple is currently starting its own server, we should allow the cordova emulate middleware to be usable by ripple - Ripple should allow us to pick the device we want to launch on. If I launch using blackberry I shouldn't have ripple emulate an iPhone. [1] https://github.com/gtanner/cordova-cli/commit/cf499d53b3e6f6631513fd5110c0861f8f01
Re: Retag JS
The second change is a very localized bugfix: https://issues.apache.org/jira/browse/CB-2158 All this does is make a broken API work and doesn't leach out into any other areas of BlackBerry. I have tested these changes and the worst case is that we end up with an API broken in another way ;) On Wed, Feb 27, 2013 at 4:36 AM, Andrew Grieve agri...@chromium.org wrote: On Wed, Feb 27, 2013 at 12:53 AM, Anis KADRI anis.ka...@gmail.com wrote: I'd like to add bada specific code as well. No impact on any other platforms. On Tuesday, February 26, 2013, Shazron wrote: Seems fine to me since it's all BB stuff On Tue, Feb 26, 2013 at 8:37 PM, Gord Tanner gtan...@gmail.com javascript:; wrote: I would like to add a couple changes into the cordova.blackberry.js for 2.5. - https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commitdiff;h=03a4b305393735717b5775390695036fa6e43fcc - https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commitdiff;h=7cb3604b21ce77c442ce469ae7de85f8ccb4b818 This second one seems not small, and not a regression fix. Why not just wait for 2.6? Is everyone ok if I put these in and retag?
Re: Proposition to split cordova-blackberry into two separate plugins
Just my 2 cents on this in regards to the performance argument. The plugin code is not executed unless it is on the platform it targets so the only cost is the initial interpretation of the code and would be directly tied to the size of the file. the entire cordova.blackberry.js file is currently 343k that contains all three platforms. The average size of cordova.js for all the platforms is 228k and the next largest (windows8) comes in at 282k. Is there a problem in BlackBerry 10 for supporting files larger than 300k? I can't imagine so but do you have a number in mind that would cause issues in the browser that we should keep in mind in case when you start adding in some more code to cordova.blackberry.js we don't reach it. Also with PlayBook migrating to BlackBerry 10 later I would imagine the entire cordova.blackberry.js file will shrink down to the same size as the rest of the platforms as we get get rid of the air platform. On Fri, Feb 22, 2013 at 10:34 AM, Jeffrey Heifetz jheif...@rim.com wrote: Hey Brian, BB10 is not just a specific version number of an SDK like BBOS v 10, its a brand new OS. Like Mac OSX vs Classical Mac OS. But independent of the technology differences I believe this approach will improve things for cordova developers targeting blackberry by making it more consistent with the approach taken with other platforms. Firstly the developer experience for developers targeting both BB10 and one of BBOS and PBOS. The current implementation based on 3 slightly different versions of webworks means that there are similar things that end up acting quite differently. One example is the config.xml. Currently the solution is that Cordova populates one massive config.xml that attempts to satisfy all 3 sub-platforms and cordova at large as well. Unfortunately the SDKS are quite different offering very different functionalities through the config, and there is currently no way to handle these differences in the sub-platforms. By splitting we can handle these in the same way all other cordova platforms do (unsure what this is) and once the core plugins are split accurately let the individual plugins add these values accordingly (something that may not be possible when BBOS and PBOS share a config entry but BB10 does not). Even developer experience for developers making cross platform plugins thinking to add support for blackberry. Currently blackberry has a unique structure requiring plugins to have their code in a specific way for 3 different platforms. While adding support for just one is not difficult, its different from any other platform (to my knowledge). Another example will be simple performance. The way the repo is architected right now, javascript is loaded that runs for all 3 platforms and it runtime detects which one to use. Its not even clear how this will work once all of the plugins are split into their own repos, but having this adds unnecessary complications that can be removed. We're in the midst of getting our code up on github, maybe it'll be clearer what we want to do when there's code to see. On 2013-02-20, at 12:47 PM, Brian LeRoux wrote: Hey Jeffrey, I'm sorry but I'm not convinced by 'its cleaner' as an argument. Its not. Its a specific version number to a specific SDK. I understand that you have more than one SDK: this is common in mobile platforms, and addressed by the current repo. Can you be more precise and explain exactly what you envision this new repo to contain, and specifically why it can't come as a pull request to the existing repo/codebase? On Tue, Feb 19, 2013 at 5:47 PM, Jeffrey Heifetz jheif...@rim.com wrote: Sharzon, sorry I have no clue when BB10 will be making its way to playbook. Bryan, whatever the next version is called BB11 or not, that would still be within the same repo. Conceptually BB10 is a brand new platform based on a very different SDK and unless I'm mistaken BlackBerry is the only platform to have 3 different SDKS within one repo (BBOS java, AIR, and BB10 C++). I know windows phone is separated. Plus we feel this way it will be cleanest for our developers and more conformant with the cordova dev experience. Tim we're in the midst of creating a much more CLI friendly (Not ANT) repo right now that would be based on our last webworks packager and framework but would be built directly on the NDK. As per the plugins, I'll take a look tomorrow but it's impressive when anyone makes a plugin for bb1010. Current docs are definitely lacking. Sent from my BlackBerry 10 smartphone. From: Tim Kim Sent: Tuesday, February 19, 2013 7:11 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Proposition to split cordova-blackberry into two separate plugins I don't mind either way, but I think we should have at least an idea what the cordova-blackberry10 repo should look like before we create it. To separate them
Re: cordova.js changes
Probably your best bet would be to add it to the initialize function for
your platform (example:
https://github.com/gtanner/cordova-js/blob/master/lib/blackberry/plugin/qnx/platform.js#L26-42
)
If you need it to be sooner you have the option of the bootstrap file which
gets tacked to the end of the cordova.js file (Example:
https://github.com/gtanner/cordova-js/blob/master/lib/scripts/bootstrap-blackberry.js
)
On Tue, Feb 19, 2013 at 10:45 AM, Leutwyler, Markus markus.leutwy...@hp.com
wrote:
What's the process for adding stuff to cordova.js or how can i make such
changes platform specific?
Let's say I want to add a new (in my case probably webOS specific)
document event for show/hide/relaunch to Cordova:
Cordova.js, line 240
channel.onShow = cordova.addDocumentEventHandler('show');
Markus
Re: CEF Cordova?
You can always use Ripple. Github.com/blackberry/ripple-ui Install it via npm: Npm install ripple -g From developer.blackberry.com Or From the chrome App Store Sent from my iPhone On 2013-02-08, at 4:16 PM, David Lewis lewi...@gmail.com wrote: Yes. Specifically Windows 7 as Win8 isn't even being talked about. http://code.google.com/p/chromiumembedded/ The cefclient looks to be a might more reasonable to work with than actual webkit. I've tweaked it to load locally and display as kiosk. Just need to wrap my head around exec(). On Fri, Feb 8, 2013 at 4:08 PM, Kerri Shotts kerrisho...@gmail.com wrote: Wait -- are you asking if there's a desktop version of Phonegap? I was assuming you meant a Chrome-based render for mobile devices, esp. since the webkit on some mobile devices is quite borked. (Android 2.x, I'm looking at you.) ___ 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 On Friday, February 8, 2013 at 2:57 PM, David Lewis wrote: That's unfortunate. My team is working on webkit specific apps just because so many mobile devices use it; iOS, Android, and Blackberry 7+. Having a desktop webkit container would alleviate a lot of work forking Windows specific versions. I need to get it done anyway, I just thought I'd ask. The closest I've found is DesktopGap but it has less PG support than the current Win7 container. On Fri, Feb 8, 2013 at 3:27 PM, Kerri Shotts kerrisho...@gmail.com (mailto:kerrisho...@gmail.com) wrote: Most modern platform's internal browsers are based on webkit -- iPhone and Android, etc. Windows Phone (and the upcoming Firefox OS) would be exceptions to the rule. I know there's been work done on supporting PG with Chrome as the renderer, but don't hold your breath for it; a lot of stuff would have to be rewritten. ___ 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 On Friday, February 8, 2013 at 1:33 PM, David Lewis wrote: My project requires a webkit browser. Does anyone have experience adding Cordova support to Chromium Embedded Framework?
Re: a Cordova Jake Error ?
I can clean this up today Sent from my iPhone On 2013-02-06, at 4:28 AM, Plaquette, Paul paul.plaque...@intel.com wrote: I would love to... But it seems I am not yet a double zero committer I Mean with the permission to commit ;-) -Original Message- From: Filip Maj [mailto:f...@adobe.com] Sent: Wednesday, February 06, 2013 1:21 AM To: dev@cordova.apache.org Subject: Re: a Cordova Jake Error ? Hey Paul, I believe this issue already notes this problem: https://issues.apache.org/jira/browse/CB-2345 Feel free to patch it, you are a committer after all :) On 2/5/13 7:53 AM, Plaquette, Paul paul.plaque...@intel.com rote: sounds the culprit might be a line in the jakefile: lib/firefoxos/plugin/firefoxos/Device.js:/(this\.cordova\s=\s).+()/ , in place of: lib/firefoxos/plugin/firefoxos/device.js:/(this\.cordova\s=\s).+()/ , hope this helps ! On Tue, Feb 5, 2013 at 4:45 PM, Plaquette, Paul paul.plaque...@intel.comwrote: Hi all, I get a fresh Cordova repository and by the way I also updated node on my ubuntu 12.04 laptop. When I build using command line jake I got this: a set of wanings jake aborted. Error: ENOENT, no such file or directory 'lib/firefoxos/plugin/firefoxos/Device.js' at Object.openSync (fs.js:230:18) (See full trace by running task with --trace) the build succeed if the device.js file in firefoxos is renamed as Device.js Does someone see what is going wrong? (Actually I wonder if it is an issue on may machine or not) Cordially, Paul -- Paul Plaquette, Senior Software Engineer Intel Corporation SAS Open source Technology Center - OTC France, Montpellier -- Paul Plaquette, Senior Software Engineer Intel Corporation SAS Open source Technology Center - OTC France, Montpellier - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: a Cordova Jake Error ?
Also developing a platform during a hackathon ;) #WorksOnMyMachine https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commitdiff;h=5ec7041147258854d34935ddcfc224af13d0b583 On Wed, Feb 6, 2013 at 2:11 PM, Anis KADRI anis.ka...@gmail.com wrote: The beauty of Mac OS X users and their case-insensitive filesystems :-) On Wed, Feb 6, 2013 at 4:50 AM, Gord Tanner gtan...@gmail.com wrote: I can clean this up today Sent from my iPhone On 2013-02-06, at 4:28 AM, Plaquette, Paul paul.plaque...@intel.com wrote: I would love to... But it seems I am not yet a double zero committer I Mean with the permission to commit ;-) -Original Message- From: Filip Maj [mailto:f...@adobe.com] Sent: Wednesday, February 06, 2013 1:21 AM To: dev@cordova.apache.org Subject: Re: a Cordova Jake Error ? Hey Paul, I believe this issue already notes this problem: https://issues.apache.org/jira/browse/CB-2345 Feel free to patch it, you are a committer after all :) On 2/5/13 7:53 AM, Plaquette, Paul paul.plaque...@intel.com rote: sounds the culprit might be a line in the jakefile: lib/firefoxos/plugin/firefoxos/Device.js:/(this\.cordova\s=\s).+()/ , in place of: lib/firefoxos/plugin/firefoxos/device.js:/(this\.cordova\s=\s).+()/ , hope this helps ! On Tue, Feb 5, 2013 at 4:45 PM, Plaquette, Paul paul.plaque...@intel.comwrote: Hi all, I get a fresh Cordova repository and by the way I also updated node on my ubuntu 12.04 laptop. When I build using command line jake I got this: a set of wanings jake aborted. Error: ENOENT, no such file or directory 'lib/firefoxos/plugin/firefoxos/Device.js' at Object.openSync (fs.js:230:18) (See full trace by running task with --trace) the build succeed if the device.js file in firefoxos is renamed as Device.js Does someone see what is going wrong? (Actually I wonder if it is an issue on may machine or not) Cordially, Paul -- Paul Plaquette, Senior Software Engineer Intel Corporation SAS Open source Technology Center - OTC France, Montpellier -- Paul Plaquette, Senior Software Engineer Intel Corporation SAS Open source Technology Center - OTC France, Montpellier - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: [FYI] call for cordova devs to participate in phonegap day event in july
If I am selected my talk is going to be on the dirty hacks that are in our codebase. Kind of pealing back the layers and showing some of the crazy stuff we need to do to get things working clean for our users. On the theme of : Our Pain is your Gain For example I am going to talk about the hack I do for BlackBerry OS7 config.xml parsing where I make our plugin match the namespaces for BlackBerry 10 API's so I can have one config.xml file for all three platforms: https://github.com/apache/cordova-blackberry/blob/master/framework/ext/src/library.xml#L26-L33 If I do get selected I will we asking people on the list for all of those crazy neat / dirty hacks we have all put into this project to hide the chaos of cross platform development from our users. On Fri, Feb 1, 2013 at 9:40 AM, Simon MacDonald simon.macdon...@gmail.comwrote: Tommy, Working hockey metaphors into the conversation will only increase your chances of being selected to talk 1000%. Well done. I'd love to make it out myself. If selected, my planned talk is also on something that should exist by July, the polyfil of the WebSpeech API into PhoneGap Android. Simon Mac Donald http://hi.im/simonmacdonald On Thu, Jan 31, 2013 at 3:08 PM, Tommy-Carlos Williams to...@devgeeks.org wrote: Sorry to break in on the thread, but that's what I did… I submitted based on something that doesn't exist yet, but very much SHOULD exist by July (or I will have bigger problems). :) Skate to where the puck is going to be and all that hockey business. My concern is more around the submission and acceptance process.. there didn't seem to be any kind on confirmation on the submission and with July so far away, I was wondering how long it might be before finding anything out. I don't want to come across as impatient, I only bring it up because flying from Australia is best done with plenty of advanced warning ;) Is there any anticipated deadline to the submission process? - tommy On 01/02/2013, at 5:47 AM, Brian LeRoux b...@brian.io wrote: No problem, how about I pencil you in for the USA event and let the talk TBD? On Thu, Jan 31, 2013 at 10:17 AM, Andrew Grieve agri...@chromium.org wrote: Hey Brian, July is still a mile away. How much lead-time are you actually looking for here? A couple of my talk ideas are contingent on whether projects meet their targets :P On Fri, Jan 11, 2013 at 6:46 PM, Brian LeRoux b...@brian.io wrote: http://goo.gl/fYW3J
Re: Cordova for Firefox OS
Javascript switched to cordova.firefoxos.js and commited to cordova-js: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=summary Commited to labs: https://git-wip-us.apache.org/repos/asf?p=cordova-labs.git;a=tree;h=refs/heads/cordova-firefoxos;hb=cordova-firefoxos On Mon, Jan 28, 2013 at 2:41 PM, Brian LeRoux b...@brian.io wrote: +1 lowcase cordova-firefoxos +1 branch in cordova-labs for now On Mon, Jan 28, 2013 at 11:32 AM, Michael Brooks mich...@michaelbrooks.ca wrote: I'm in favor of just using Cordova-FirefoxOS since it is an explicitly clear name that makes it easy to find. I agree with Herm on using Cordova-FirefoxOS (cordova-firefoxos) for the same reasons. Matching the official name is important for ease of use. While we wait for Infra to create the repository, Dan and Gord can push to a branch in the labs repo. That way the code can easily be pushed to the official repo whenever it's created. Michael On Mon, Jan 28, 2013 at 11:23 AM, Dan Silivestru dan.silives...@gmail.comwrote: I like the sound of FxOS, it's short :-) Also the CLI for deploying directly to device would be very helpful, Gord and I couldn't find a way to do it with the currently published docs. Looking forward to that addition. Dan. On Mon, Jan 28, 2013 at 1:29 PM, Herm Wong kingoftheo...@hotmail.com wrote: The B2G name has been deprecated in favor of Firefox OS; internally (at Mozilla) they seem to be using the acronym FxOS. I'm in favor of just using Cordova-FirefoxOS since it is an explicitly clear name that makes it easy to find. I'm also in favor of Gord Dan pushing up their Cordova-JS changes for Firefox OS, I'll merge my changes after their initial commit. I've been working directly with Mozilla to finalize some of CL interfaces so that we will be able to using build scripts to package and deploy apps directly to the devices. Date: Mon, 28 Jan 2013 07:05:20 +0100 Subject: Re: Cordova for Firefox OS From: g.nat...@gnstudio.com To: dev@cordova.apache.org Hi Gord, I'm trying to get a device too, as soon as I get I would volunteer to test each new feature you will port on the device. Hope it can help... Giorgio On 1/28/13 2:51 AM, Gord Tanner gtan...@gmail.com wrote: Hello, Dan Silivestru and I were at a hackathon on the weekend at Mozilla and we took the day to port Cordova over to the Firefox OS phone. We got it running successfully on the simulator and device that day. Currently it just supports firing of deviceready and the accelerometer (not really tested). The code can be found here: https://github.com/gtanner/cordova-b2g and the javascript code here: https://github.com/gtanner/cordova-js We won a phone for our efforts (so did Fil and Steve) so we will have a real device or two to test and work on for the platform. What is the next steps for getting this into the apache repo's and merged in? -- Dan Silivestru +1 (519) 589-3624
Cordova for Firefox OS
Hello, Dan Silivestru and I were at a hackathon on the weekend at Mozilla and we took the day to port Cordova over to the Firefox OS phone. We got it running successfully on the simulator and device that day. Currently it just supports firing of deviceready and the accelerometer (not really tested). The code can be found here: https://github.com/gtanner/cordova-b2g and the javascript code here: https://github.com/gtanner/cordova-js We won a phone for our efforts (so did Fil and Steve) so we will have a real device or two to test and work on for the platform. What is the next steps for getting this into the apache repo's and merged in?
Re: Cordova for Firefox OS
Yes, The JavaScript is all very localized and new / unstable code is only included in the newly built cordova.b2g.js file. I would say it is zero risk commiting now. Would be awesome to get infra to create the cordova-b2g repo and to merge this in. On Sun, Jan 27, 2013 at 8:59 PM, Simon MacDonald simon.macdon...@gmail.comwrote: Don't quote me on this but I think we need to file an infrastructure ticket to get a firefox OS repo opened. I don't see any reason why you couldn't commit the JS now. Although on the JS maybe you want to create your own FF OS branch until it becomes more stable. Simon Mac Donald http://hi.im/simonmacdonald On Sun, Jan 27, 2013 at 8:51 PM, Gord Tanner gtan...@gmail.com wrote: Hello, Dan Silivestru and I were at a hackathon on the weekend at Mozilla and we took the day to port Cordova over to the Firefox OS phone. We got it running successfully on the simulator and device that day. Currently it just supports firing of deviceready and the accelerometer (not really tested). The code can be found here: https://github.com/gtanner/cordova-b2g and the javascript code here: https://github.com/gtanner/cordova-js We won a phone for our efforts (so did Fil and Steve) so we will have a real device or two to test and work on for the platform. What is the next steps for getting this into the apache repo's and merged in?
Re: Cygwin for Windows
+1 Sent from my iPhone On 2013-01-20, at 9:14 AM, Andrew Grieve agri...@google.com wrote: I'm sure this has come up some time in the past, but why not require cygwin so that our scripts will work on windows? Cygwin has been a requirement of most of the windows projects I've worked on in the past (when at different companies).
Re: Moving plugin JS files around
plugin is distributed 'built' meaning for an API like file or
contacts, there is only 1 js file, and while it depends on cordova.js,
it is not part of it. ( or possibly just a concat )
- plugman does the work of adding/removing but it is really just
changing script tags for the js portion
This means all our core plugs will need to be modified as the
currently depend on the builder to wrap them.
I spent some time working with your approach Andrew, and I think it
sounds better than it is. Blackberry has 4 inter-related branches to
consider, webos shares hardly any code with the other platforms, ... I
am more keen on adding consistency than I am to making the tool work
around it.
If we were only concerned with iOS, Android, and windows phone, then
your approach might be best, but there are some messes in there.
I will continue to push for the simpler solution, but I won't block
you anymore.
I do think you should dive a little deeper into your approach, and
possibly prove me wrong. I am completely open to further discussion on
the point.
Cheers,
Jesse
Sent from my iPhone5
On 2013-01-10, at 8:09 PM, Andrew Grieve agri...@chromium.org
wrote:
On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner gtan...@gmail.com
wrote:
Ideally the require paths should stay true to the following rules
(not
that
we follow them exactly now but we are close):
1. should always start with cordova (in case we ever share a require
framework)
2. should follow as close as possible to the folder structure.
We don't really do this now (but we are close). It is mainly to
help
with
navigation of the project from a require statement:
var foo = require('cordova/plugin/foo/submodule')
Ideally I should be able to navigate to a file that lives in:
~/cordova.js/plugin/foo/submodule.js
But realistically we are probably going to see:
~/cordova.js/plugin/foo/js/submodule.js
Assuming we are dumping everything into a js folder here is the
mapping
off the top of my head:
var foo = require('cordova/plugin/foo')
~/cordova.js/plugin/foo/js/index.js
var foo = require('cordova/plugin/foo/ios')
~/cordova.js/plugin/foo/js/ios.js
var foo = require('cordova/plugin/foo/blackberry/qnx')
~/cordova.js/plugin/foo/js/blackberry/qnx.js
What does a plugin (native and js code) folder structure look like?
Have a look at this plugin: https://github.com/shazron/KeychainPlugin
With the JS changes I'm proposing, it would look like:
/src/ios/*.h, *.m
/www - empty!
/src/js/common/keychain.js
or
/src/js/ios/keychain.js
So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
within cordova-js, is that when they move out, there will be the
mapping:
cordova-js/plugin/$PLUGIN_NAME --- $PLUGIN_REPO/src/js
When a plugin is installed into a project via cordova-cli, I suggest
that
we get a structure like this:
MyApp/platforms/ios/... same as before ...
MyApp/cordova-js/... copy of cordova-js
MyApp/cordova-js/plugin/keychain/common/keychain.js
MyApp/plugins/keychain/plugin.xml
MyApp/www
So, the idea here is that the cordova-js will have no top-level
plugin/
directory, but one will be added when plugins are added.
Also, like other sources, .js file should be listed in the plugin.xml
so
that they can be reliably removed.
About the require paths. I think for files in cordova-js, the prefix
should
be cordova/, but for plugin files, it should be plugin/ (or maybe
cordovaplugin/?), so that plugin JS doesn't accidentally clobber
core
cordova modules.
For the keychain example: require('cordovaplugin/keychain/keychain')
In terms of changes to the builder, we'd need to add the idea of
multiple
roots. Instead of just 'lib', there will also be 'plugin' as a root.
On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve agri...@google.com
wrote:
I'd like to take a first step towards moving plugin JS into
separate
repos
by first moving them around within cordova-js.
Here is my proposal:
Current structure:
lib/common/plugin/*.js
lib/$PLATFORM/plugin/*.js
New structure:
plugin/$PLUGIN_NAME/js/common/*.js
plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
The require path will need to change. Going from:
cordova.require('cordova/plugin/FileTransferError')
To:
cordova.require('plugin/file/FileTransferError')
I'll obviously need to update the builder scripts accordingly. The
idea
here is that we:
1. cordova plugin add will copy files into a project's
plugins
directory
2. cordova build ios will use the cordova-js packager and
pass
Re: Moving plugin JS files around
I was envisioning this working closer to the node_modules pattern.
Ideally with a module loading framework you should be able to XHR these
modules over at require time.
Here is where the debate of commonJS vrs AMD will heat up. CommonJS will
require sync XHR because of it's ties to node (which I don't think is a bad
thing ;))
Since we have made the leap to a module based javascript layer we should be
able to leverage it to dynamically load the modules for us (may it be XHR,
over the exec bridge, voodoo).
On Mon, Jan 14, 2013 at 4:19 PM, Andrew Grieve agri...@chromium.org wrote:
On Mon, Jan 14, 2013 at 4:04 PM, Gord Tanner gtan...@gmail.com wrote:
Yes,
BlackBerry is really 3 platforms in one. We used to have them as 3
seperate platforms but was a headache for writing apps and ensuring that
you had the right javascript file in the right place.
Just so I understand this, is it that blackberry has fat binaries? e.g. one
binary can be deployed to multiple platforms?
Otherwise, it's quite likely that cordova-cli will make the old
multi-platform headaches go away.
Since I wrote most of the module stuff I agree I have abused it a little
with some of the tricks of the trade we have in place with the build
step.
I would rather see us handle this via the exec bridge than including
script
files in the DOM (stay with me for a little bit).
Not a final spec but an idea would be:
var foo = require('cordova/plugin/foo')
inside require we would realize we don't have foo preloaded in cordova.js
and call exec
exec(success, fail, 'PluginManager', 'getPluginSource', {plugin: foo,
platform: ios})
where success would be something like:
function (func) {
cordova.define('cordova/plugin/foo', func);
}
Thoughts?
Gord, what's the motivation for this? Maybe that it addresses the having
alter script tags when adding/removing plugins?
You'd still need to deal with knowing which JS to include in your App
package (might be a bit bloated to include all JS for all platforms in all
apps)
It would mean making require() an async call (unless you use sync. XHRs),
and I think would have negative effects on performance.
On Mon, Jan 14, 2013 at 3:41 PM, Jesse purplecabb...@gmail.com wrote:
Comments inline below.
On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve agri...@chromium.org
wrote:
Created a bug for the file moving part (CB-2214), but we can
continue discussing here.
On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve agri...@chromium.org
wrote:
Jesse, thanks for the explanation. Certainly my experience is just
with
Android iOS, so it's good to get opinions from the other
platforms.
I took a look at WebOS, but pkg/cordova.webos.js does seem to pull
in
all
of the shared plugin modules and hooks them up with the common
bootstrap.
Why do you say that WebOS shares hardly any code?
What I meant about WebOS, was just that it overwrites most of the APIs.
There is a distinct difference in the way the platforms without a
native
counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)
Blackberry certainly seems to be a bit different in that it looks
like
it
is actually 4 platforms in one. Not sure why we don't just make it
four
separate platforms. Gord?
That said, Blackberry uses the module system even more than other
platforms. I think it would be a lot of work to make plugin within
blackberry have it's own loading logic that selectively loads
module
based
on the sub-platform (if we went with a single-file pre-built
approach).
With the single-file prebuilt approach, I'd guess it would look
something
like this:
plugin.xml says which .js file to include for the platform:
platform name=android
source-file src=filetransfer.js /
/platform
And maybe even:
platform name=android
source-file src=filetransfer-common.js /
source-file src=filetransfer-android.js /
/platform
...
There is certainly a bug-report advantage to having each in its own
.js
file. If everything is in cordova.js, and we get bugs with Error
on
line
##, we can't actually map that to a file. On the other hand, each
platform
has bootstrap logic that must come after plugins are loaded. This
might
turn into a source of errors if we have a bunch of .js files being
added
via script tags.
One aspect of plugin JS that I don't want to lose, is our separate
pass
of
module - symbol (defaults/merges/clobbers). In fact, I think this
is
an
area that we may wish to enhance in the future. E.g. a couple of
releases
ago we added the ability to print a deprecation message when old
namespaces
are referenced. Other advantages of the system
Re: Correct spelling for Blackberry?
correct: BlackBerry On Wed, Jan 2, 2013 at 2:21 PM, Filip Maj f...@adobe.com wrote: I believe it is 'BlackBerry' ( ) On 1/2/13 11:17 AM, Becky Gibson gibson.be...@gmail.com wrote: Note that this commit, https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803 c3f161830656, to cordova-docs breaks the link to the blackberry file on the Getting Started page because it changes the case of the second b in BlackBerry. I didn't fix it because I'm not sure what the correct spelling is. -becky
Re: too long to package a release?
This is what we have done in ripple (and webworks) master - always stable current shipping code next - always 'stable' next release. Expectation that code has been tested / run before merged into this branch. feature branches - branched off of next and merged into next when stable / done. Not expected to be stable or runnable until merge time. On Wed, Jan 2, 2013 at 2:32 PM, Filip Maj f...@adobe.com wrote: Am I correct when I say that, with this approach, master becomes a series of merge commits coming from dev, then ? A couple questions to follow up: - features get forked from stable - forked from master, yes? - features, when ready, tested against dev branch - what does this mean? Does this mean, you would merge feature branch into dev branch (locally) then run tests to make sure things work? On 1/2/13 11:19 AM, Joe Bowser bows...@gmail.com wrote: OK, Let's rethink this: After talking with Brian on the 21st, I think we agree on this: * Master remains stable and sits at the most recent released code (i.e. 2.3.0 once we get 2.3.0 done) (Stable Channel) * Dev happens on branches for the releases (i.e. 2.4.0) (Dev Channel) * In the case of a point release, dev happens in the branch of the major release (i.e. 2.3.1 would happen in the 2.3.0 branch, not master) (Testing Channel) * Features get forked on stable then once the feature is ready, tested against the dev branch. If they work with stable, they SHOULD work with 2.4.0. If they don't, the tickets get added to 2.4.0 to make it work with that release. That way things are more predictable as far as new features are concerned. (You will burn your face channel). Does that make sense? Working on master for things causes us pain and we should use git conventions to make it simpler for people who expect our master to work all the time. I don't think this will speed up the release as much as automating tagging of RCs so that when the JS is tagged, everything else is tagged. The week it takes to tag an RC is way too long. On Wed, Jan 2, 2013 at 11:08 AM, Filip Maj f...@adobe.com wrote: Bumping this thread. I'd like Joe to clarify as well. On 12/20/12 12:26 PM, Brian LeRoux b...@brian.io wrote: Ok, I want to understand this, let me take a stab. You describe three long-lived branches like this: - Master: This is stable and frozen on the last tagged release. - Dev: the next release to be tagged. Feature branches merged from master when confident. - Unstable: the current working branch for a particular tag. Feature branches merged as needed for collaboration. Everyone works from local feature branch rebasing and committing to master. When that feature branch is considered good enough, it is merged into dev, and work continues. Whatever date we happen to pick for a release that is what dev becomes, we tag, and move that sha to stable if its not an RC. ? On Thu, Dec 20, 2012 at 10:52 AM, Joe Bowser bows...@gmail.com wrote: I'm OK with this, but I think your example is off: Where n is the current released piece of the software: n.x.x = Stable n+1.x.x = Dev master = Unstable, can have things merged in from feature branches This fully uncouples features from release planning, which is good because it means the release will land in the version when it's ready, and not for any other reason. I also propose that we keep using the same RC tags and that for a final release we tag it x.x.xFinal. We still need to tag an RC and re-tag it. Release Process: 1. Tag the dev tree 2. merge the dev tree back into master 3. Create 2.5.0 branch 4. File issues from 2.5.0 in JIRA I also propose that we automate the tagging. If an RC is broken, we just cut another RC. A lot of our retagging is done to get around the pain of having to do another RC. The biggest part of the delay is waiting for every single platform maintainer to tag their platform after the JS was tagged. For example, I tagged rc2 for the JS and for Android on Monday last week from my hotel room, and the release wasn't fully tagged until this week. I'm fine with RCs going up to 10 as long as we can release early, release often and release when we want to and not run out of time and have to delay. On Thu, Dec 20, 2012 at 10:33 AM, Brian LeRoux b...@brian.io wrote: Truth. Though lets not get hung up on the past and just focus on the present. We've done a really good job getting where we are. So, Joe, are you saying you like the idea of three long lived branches and merges happen from local feature branches? On Thu, Dec 20, 2012 at 10:22 AM, Joe Bowser bows...@gmail.com wrote: We are totally doing something wrong with the way that we do releases. I personally think that we're not using git right, and here's why: Currently, when we do a release, we tag the RC, and we test the RC. There's nothing preventing us from putting things after that
Re: too long to package a release?
Also a problem we have encountered with using a 'next' branch for active development is from third party commits. Every single 3rd party pull request is going to come into master. You can ether: 1. tell them to redo it on next 2. rebase it into next for them and let them know for next time. The cost of option 2 gets more the longer it takes to release. A 3rd party pull request coming in could be based on code that is 2+ months old. This isn't a vote against a development branch, but a small annoyance we have run into. On Wed, Jan 2, 2013 at 5:08 PM, Gord Tanner gtan...@gmail.com wrote: A hot fix is usually branched off of master, tested, merged and released. We then rebase / merge the hotfix up into next. On Wed, Jan 2, 2013 at 4:51 PM, Michal Mocny mmo...@chromium.org wrote: Also: while I personally prefer master to be the dev channel, I will say that I do like Gord's suggestion of how its done in ripple in that the name of the dev branch is 'next' and not '2.3.0' so that your dev setup doesn't need to change every month. Gord: how do you deal with bugfixes/point releases? Do you fix in feature branch, merge into next, and then cherry-pick/merge just that fix into master before doing a major release? Or, do you just offer bugfixes via 'next'? On Wed, Jan 2, 2013 at 4:45 PM, Michal Mocny mmo...@chromium.org wrote: I don't have much weight here, but personally I feel that this seems backwards. With this proposal (if I understand it), when you do a fresh checkout of the codebase, instead of sitting on the bleeding edge, you would be sitting at a stable release which is conceptually read-only for most contributors (writes happen in the form of batch releases which itself would just be some git-fu to rebase master). I am happy enough to have features be worked on in branches etc, I just think that it should be flipped and the stable release be the branch and dev to be on master. As a separate issue, I would suggest not using branches to name point releases, but just tag them. If you have a 2.3.0 release, and you need to fix a bug in 2.3.1, those should not become two logically separate code branches with independent dev, but rather they are a logically single timeline with many names for each historically significant commit, right? Thats what tags are for (http://git-scm.com/book/en/Git-Basics-Tagging ). -Michal On Wed, Jan 2, 2013 at 3:05 PM, Gord Tanner gtan...@gmail.com wrote: This is what we have done in ripple (and webworks) master - always stable current shipping code next - always 'stable' next release. Expectation that code has been tested / run before merged into this branch. feature branches - branched off of next and merged into next when stable / done. Not expected to be stable or runnable until merge time. On Wed, Jan 2, 2013 at 2:32 PM, Filip Maj f...@adobe.com wrote: Am I correct when I say that, with this approach, master becomes a series of merge commits coming from dev, then ? A couple questions to follow up: - features get forked from stable - forked from master, yes? - features, when ready, tested against dev branch - what does this mean? Does this mean, you would merge feature branch into dev branch (locally) then run tests to make sure things work? On 1/2/13 11:19 AM, Joe Bowser bows...@gmail.com wrote: OK, Let's rethink this: After talking with Brian on the 21st, I think we agree on this: * Master remains stable and sits at the most recent released code (i.e. 2.3.0 once we get 2.3.0 done) (Stable Channel) * Dev happens on branches for the releases (i.e. 2.4.0) (Dev Channel) * In the case of a point release, dev happens in the branch of the major release (i.e. 2.3.1 would happen in the 2.3.0 branch, not master) (Testing Channel) * Features get forked on stable then once the feature is ready, tested against the dev branch. If they work with stable, they SHOULD work with 2.4.0. If they don't, the tickets get added to 2.4.0 to make it work with that release. That way things are more predictable as far as new features are concerned. (You will burn your face channel). Does that make sense? Working on master for things causes us pain and we should use git conventions to make it simpler for people who expect our master to work all the time. I don't think this will speed up the release as much as automating tagging of RCs so that when the JS is tagged, everything else is tagged. The week it takes to tag an RC is way too long. On Wed, Jan 2, 2013 at 11:08 AM, Filip Maj f...@adobe.com wrote: Bumping this thread. I'd like Joe to clarify as well. On 12/20/12 12:26 PM, Brian LeRoux b...@brian.io wrote: Ok, I want to understand this, let me take a stab. You describe three long-lived branches like this: - Master
Re: [DISCUSS] Switch BlackBerry 10 Cordova download from WebWorks to NDK
Just tested setting this up on my personal macbook and it all seemed to go fine. (Somehow I got ant on this machine and I don't remember installing it, does it come with xcode?) As for the node dependency it looks like the packager bundles node with it ( https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node ). I had node setup and installed on this laptop before so I can't verify the experience without. On Fri, Dec 7, 2012 at 8:21 PM, Gord Tanner gtan...@gmail.com wrote: I put together a small prototype so people can see what the user feel would be like: https://github.com/gtanner/incubator-cordova-blackberry-webworks/tree/blackberry.ndk This currently only works and has been tested on OSX (sorry Jesse :P) but I will add windows support of this idea takes off. If you clone the above branch and run ./bin/create it will prompt you to setup the WebWorks SDK. Please download the native SDK before running that script from (http://developer.blackberry.com/native/beta/) On Wed, Dec 5, 2012 at 6:30 PM, Drew Walters deedu...@gmail.com wrote: Just to be clear, I wasn't complaining about node/npm dependencies, was just curious what full dependencies would be. On Wed, Dec 5, 2012 at 4:59 PM, Filip Maj f...@adobe.com wrote: I donÂąt think a dependency on node/npm is any more problematic than a dependency on ANT, for example. On 12/5/12 2:55 PM, Gord Tanner gtan...@gmail.com wrote: Is dependencies on node and npm a problem? I was thinking this wouldn't be that big of a problem since Cordova-client depends on those projects too. If it is a huge deal I can look into removing those dependencies Sent from my iPhone On 2012-12-05, at 3:30 PM, Drew Walters deedu...@gmail.com wrote: So, if the WebWorks SDK itself needs to provide native code for functionality, how will that be provided? What dependency differences are we looking at? Looks like to pull and build WebWorks SDK it would require git, node, npm, native SDK. Anything else? Does the native SDK have any pre-reqs? On Wed, Dec 5, 2012 at 2:21 PM, Nukul Bhasin m...@nukulb.com wrote: Does the WebWorks packager for BB 10 handle the compilation of native plugins or do they have to be pre-compiled prior to packaging now? No. BB10 WebWorks Packager includes built binaries that are then packaged into the app. If you want to build native extensions you must use the NDK. For OS5-7 and playbook WebWorks SDK included BlackBerry Java SDK or Air SDK but WebWorks BB10 does not include the NDK To answer the question why its different for BB10, because I like 9MB instead of 900 MB :) On Wed, Dec 5, 2012 at 3:14 PM, Drew Walters deedu...@gmail.com wrote: Call me old fashioned but I like 9MB downloads better the 900MB :-) I guess the necessity for this is because unlike WebWorks for OS5-7, the native libraries are not included in WebWorks for BB 10. Does the WebWorks packager for BB 10 handle the compilation of native plugins or do they have to be pre-compiled prior to packaging now? On Wed, Dec 5, 2012 at 2:02 PM, Gord Tanner gtan...@gmail.com wrote: Correct. This would be for any cordova BlackBerry 10 APIs (not external plugins). This will allow us the native compile step for Cordova that we don't have access to with WebWorks (that other platforms have). The key for this is flexibility. Nothing is changing with this now but allows us more tools to support BlackBerry 10 Cordova in the future. On Wed, Dec 5, 2012 at 2:53 PM, Drew Walters deedu...@gmail.com wrote: Making sure I understand the steps: 1. User downloads and installs BlackBerry 10 Native SDK and Cordova. 2. Executing the create script to create a project will somehow determine if the user has the WebWorks SDK and if not... 3. Clone the WebWorks SDK using git. 4. Build the WebWorks SDK. 5. Update the project.properties for the project to point at the built WebWorks SDK. I would prefer to not dynamically clone and build the WebWorks SDK as part of Cordova project creation, seems like that could be prone to issues. I would tend to think the majority of developers would not be building custom plugins for their application. Would the native SDK be required by Cordova end developers if Cordova for BlackBerry 10 contains some native (C++) plugins? On Wed, Dec 5, 2012 at 1:05 PM, Gord Tanner gtan...@gmail.com wrote: Currently for developing for BlackBerry 10 the user needs to download and install the WebWorks SDK. [1]. This SDK is opensource and available from github [2] and users are able to clone and build the SDK with the native development tools available [3]. I would like to switch the BlackBerry 10 platform for cordova to use
Re: [DISCUSS] Switch BlackBerry 10 Cordova download from WebWorks to NDK
I put together a small prototype so people can see what the user feel would be like: https://github.com/gtanner/incubator-cordova-blackberry-webworks/tree/blackberry.ndk This currently only works and has been tested on OSX (sorry Jesse :P) but I will add windows support of this idea takes off. If you clone the above branch and run ./bin/create it will prompt you to setup the WebWorks SDK. Please download the native SDK before running that script from (http://developer.blackberry.com/native/beta/) On Wed, Dec 5, 2012 at 6:30 PM, Drew Walters deedu...@gmail.com wrote: Just to be clear, I wasn't complaining about node/npm dependencies, was just curious what full dependencies would be. On Wed, Dec 5, 2012 at 4:59 PM, Filip Maj f...@adobe.com wrote: I donÂąt think a dependency on node/npm is any more problematic than a dependency on ANT, for example. On 12/5/12 2:55 PM, Gord Tanner gtan...@gmail.com wrote: Is dependencies on node and npm a problem? I was thinking this wouldn't be that big of a problem since Cordova-client depends on those projects too. If it is a huge deal I can look into removing those dependencies Sent from my iPhone On 2012-12-05, at 3:30 PM, Drew Walters deedu...@gmail.com wrote: So, if the WebWorks SDK itself needs to provide native code for functionality, how will that be provided? What dependency differences are we looking at? Looks like to pull and build WebWorks SDK it would require git, node, npm, native SDK. Anything else? Does the native SDK have any pre-reqs? On Wed, Dec 5, 2012 at 2:21 PM, Nukul Bhasin m...@nukulb.com wrote: Does the WebWorks packager for BB 10 handle the compilation of native plugins or do they have to be pre-compiled prior to packaging now? No. BB10 WebWorks Packager includes built binaries that are then packaged into the app. If you want to build native extensions you must use the NDK. For OS5-7 and playbook WebWorks SDK included BlackBerry Java SDK or Air SDK but WebWorks BB10 does not include the NDK To answer the question why its different for BB10, because I like 9MB instead of 900 MB :) On Wed, Dec 5, 2012 at 3:14 PM, Drew Walters deedu...@gmail.com wrote: Call me old fashioned but I like 9MB downloads better the 900MB :-) I guess the necessity for this is because unlike WebWorks for OS5-7, the native libraries are not included in WebWorks for BB 10. Does the WebWorks packager for BB 10 handle the compilation of native plugins or do they have to be pre-compiled prior to packaging now? On Wed, Dec 5, 2012 at 2:02 PM, Gord Tanner gtan...@gmail.com wrote: Correct. This would be for any cordova BlackBerry 10 APIs (not external plugins). This will allow us the native compile step for Cordova that we don't have access to with WebWorks (that other platforms have). The key for this is flexibility. Nothing is changing with this now but allows us more tools to support BlackBerry 10 Cordova in the future. On Wed, Dec 5, 2012 at 2:53 PM, Drew Walters deedu...@gmail.com wrote: Making sure I understand the steps: 1. User downloads and installs BlackBerry 10 Native SDK and Cordova. 2. Executing the create script to create a project will somehow determine if the user has the WebWorks SDK and if not... 3. Clone the WebWorks SDK using git. 4. Build the WebWorks SDK. 5. Update the project.properties for the project to point at the built WebWorks SDK. I would prefer to not dynamically clone and build the WebWorks SDK as part of Cordova project creation, seems like that could be prone to issues. I would tend to think the majority of developers would not be building custom plugins for their application. Would the native SDK be required by Cordova end developers if Cordova for BlackBerry 10 contains some native (C++) plugins? On Wed, Dec 5, 2012 at 1:05 PM, Gord Tanner gtan...@gmail.com wrote: Currently for developing for BlackBerry 10 the user needs to download and install the WebWorks SDK. [1]. This SDK is opensource and available from github [2] and users are able to clone and build the SDK with the native development tools available [3]. I would like to switch the BlackBerry 10 platform for cordova to use the NDK and clone WebWorks from github. The only difference a cordova developer would notice would be what download we tell them to install in the documentations, everything else would be handled by the ./bin/create script and ./cordova/* scripts pointing where the WebWorks SDK lives. This preps us to have the tools available on the developers machine to build any native extensions that may or may not be needed for BlackBerry 10 development. [1] https
Re: [DISCUSS] Switch BlackBerry 10 Cordova download from WebWorks to NDK
Correct, they would be building webworks from source during ./bin/create. This solves the problem which we haven't run into yet where webworks doesn't yet, or can't expose something from native and we need to dive down to c via a native plugin. It also allows us like Tim said to point to a commit or tag and base off of that rather than wait for a WebWorks release. On Wed, Dec 5, 2012 at 2:38 PM, Filip Maj f...@adobe.com wrote: Hey Gord, what's the idea behind this switch? Why do you want to do this? And if I understand correctly, users would essentially be building WebWorks from scratch, with a few modifications (?), on their own machine the first time they run ./bin/create ? On 12/5/12 11:31 AM, Tim Kim timki...@gmail.com wrote: +1 I would like to be able to access the latest updates of webworks as opposed to waiting around for a release to land on the bb webworks download page. On 5 December 2012 11:05, Gord Tanner gtan...@gmail.com wrote: Currently for developing for BlackBerry 10 the user needs to download and install the WebWorks SDK. [1]. This SDK is opensource and available from github [2] and users are able to clone and build the SDK with the native development tools available [3]. I would like to switch the BlackBerry 10 platform for cordova to use the NDK and clone WebWorks from github. The only difference a cordova developer would notice would be what download we tell them to install in the documentations, everything else would be handled by the ./bin/create script and ./cordova/* scripts pointing where the WebWorks SDK lives. This preps us to have the tools available on the developers machine to build any native extensions that may or may not be needed for BlackBerry 10 development. [1] https://developer.blackberry.com/html5/download/ [2] https://github.com/blackberry/BB10-Webworks-Packager [3] http://developer.blackberry.com/native/beta/ -- Timothy Kim
Re: [DISCUSS] Switch BlackBerry 10 Cordova download from WebWorks to NDK
Correct. This would be for any cordova BlackBerry 10 APIs (not external plugins). This will allow us the native compile step for Cordova that we don't have access to with WebWorks (that other platforms have). The key for this is flexibility. Nothing is changing with this now but allows us more tools to support BlackBerry 10 Cordova in the future. On Wed, Dec 5, 2012 at 2:53 PM, Drew Walters deedu...@gmail.com wrote: Making sure I understand the steps: 1. User downloads and installs BlackBerry 10 Native SDK and Cordova. 2. Executing the create script to create a project will somehow determine if the user has the WebWorks SDK and if not... 3. Clone the WebWorks SDK using git. 4. Build the WebWorks SDK. 5. Update the project.properties for the project to point at the built WebWorks SDK. I would prefer to not dynamically clone and build the WebWorks SDK as part of Cordova project creation, seems like that could be prone to issues. I would tend to think the majority of developers would not be building custom plugins for their application. Would the native SDK be required by Cordova end developers if Cordova for BlackBerry 10 contains some native (C++) plugins? On Wed, Dec 5, 2012 at 1:05 PM, Gord Tanner gtan...@gmail.com wrote: Currently for developing for BlackBerry 10 the user needs to download and install the WebWorks SDK. [1]. This SDK is opensource and available from github [2] and users are able to clone and build the SDK with the native development tools available [3]. I would like to switch the BlackBerry 10 platform for cordova to use the NDK and clone WebWorks from github. The only difference a cordova developer would notice would be what download we tell them to install in the documentations, everything else would be handled by the ./bin/create script and ./cordova/* scripts pointing where the WebWorks SDK lives. This preps us to have the tools available on the developers machine to build any native extensions that may or may not be needed for BlackBerry 10 development. [1] https://developer.blackberry.com/html5/download/ [2] https://github.com/blackberry/BB10-Webworks-Packager [3] http://developer.blackberry.com/native/beta/
Re: [DISCUSS] Switch BlackBerry 10 Cordova download from WebWorks to NDK
+1 I want this to go over more than a Works on my machine test before I land this in master. On Wed, Dec 5, 2012 at 3:11 PM, Filip Maj f...@adobe.com wrote: I think it's worth investigating and having a working prototype but would caution against immediately merging in until different folk have had a chance to play with it and make sure our end-user dev experience is cool. On 12/5/12 12:02 PM, Gord Tanner gtan...@gmail.com wrote: Correct. This would be for any cordova BlackBerry 10 APIs (not external plugins). This will allow us the native compile step for Cordova that we don't have access to with WebWorks (that other platforms have). The key for this is flexibility. Nothing is changing with this now but allows us more tools to support BlackBerry 10 Cordova in the future. On Wed, Dec 5, 2012 at 2:53 PM, Drew Walters deedu...@gmail.com wrote: Making sure I understand the steps: 1. User downloads and installs BlackBerry 10 Native SDK and Cordova. 2. Executing the create script to create a project will somehow determine if the user has the WebWorks SDK and if not... 3. Clone the WebWorks SDK using git. 4. Build the WebWorks SDK. 5. Update the project.properties for the project to point at the built WebWorks SDK. I would prefer to not dynamically clone and build the WebWorks SDK as part of Cordova project creation, seems like that could be prone to issues. I would tend to think the majority of developers would not be building custom plugins for their application. Would the native SDK be required by Cordova end developers if Cordova for BlackBerry 10 contains some native (C++) plugins? On Wed, Dec 5, 2012 at 1:05 PM, Gord Tanner gtan...@gmail.com wrote: Currently for developing for BlackBerry 10 the user needs to download and install the WebWorks SDK. [1]. This SDK is opensource and available from github [2] and users are able to clone and build the SDK with the native development tools available [3]. I would like to switch the BlackBerry 10 platform for cordova to use the NDK and clone WebWorks from github. The only difference a cordova developer would notice would be what download we tell them to install in the documentations, everything else would be handled by the ./bin/create script and ./cordova/* scripts pointing where the WebWorks SDK lives. This preps us to have the tools available on the developers machine to build any native extensions that may or may not be needed for BlackBerry 10 development. [1] https://developer.blackberry.com/html5/download/ [2] https://github.com/blackberry/BB10-Webworks-Packager [3] http://developer.blackberry.com/native/beta/
Re: [DISCUSS] Switch BlackBerry 10 Cordova download from WebWorks to NDK
Is dependencies on node and npm a problem? I was thinking this wouldn't be that big of a problem since Cordova-client depends on those projects too. If it is a huge deal I can look into removing those dependencies Sent from my iPhone On 2012-12-05, at 3:30 PM, Drew Walters deedu...@gmail.com wrote: So, if the WebWorks SDK itself needs to provide native code for functionality, how will that be provided? What dependency differences are we looking at? Looks like to pull and build WebWorks SDK it would require git, node, npm, native SDK. Anything else? Does the native SDK have any pre-reqs? On Wed, Dec 5, 2012 at 2:21 PM, Nukul Bhasin m...@nukulb.com wrote: Does the WebWorks packager for BB 10 handle the compilation of native plugins or do they have to be pre-compiled prior to packaging now? No. BB10 WebWorks Packager includes built binaries that are then packaged into the app. If you want to build native extensions you must use the NDK. For OS5-7 and playbook WebWorks SDK included BlackBerry Java SDK or Air SDK but WebWorks BB10 does not include the NDK To answer the question why its different for BB10, because I like 9MB instead of 900 MB :) On Wed, Dec 5, 2012 at 3:14 PM, Drew Walters deedu...@gmail.com wrote: Call me old fashioned but I like 9MB downloads better the 900MB :-) I guess the necessity for this is because unlike WebWorks for OS5-7, the native libraries are not included in WebWorks for BB 10. Does the WebWorks packager for BB 10 handle the compilation of native plugins or do they have to be pre-compiled prior to packaging now? On Wed, Dec 5, 2012 at 2:02 PM, Gord Tanner gtan...@gmail.com wrote: Correct. This would be for any cordova BlackBerry 10 APIs (not external plugins). This will allow us the native compile step for Cordova that we don't have access to with WebWorks (that other platforms have). The key for this is flexibility. Nothing is changing with this now but allows us more tools to support BlackBerry 10 Cordova in the future. On Wed, Dec 5, 2012 at 2:53 PM, Drew Walters deedu...@gmail.com wrote: Making sure I understand the steps: 1. User downloads and installs BlackBerry 10 Native SDK and Cordova. 2. Executing the create script to create a project will somehow determine if the user has the WebWorks SDK and if not... 3. Clone the WebWorks SDK using git. 4. Build the WebWorks SDK. 5. Update the project.properties for the project to point at the built WebWorks SDK. I would prefer to not dynamically clone and build the WebWorks SDK as part of Cordova project creation, seems like that could be prone to issues. I would tend to think the majority of developers would not be building custom plugins for their application. Would the native SDK be required by Cordova end developers if Cordova for BlackBerry 10 contains some native (C++) plugins? On Wed, Dec 5, 2012 at 1:05 PM, Gord Tanner gtan...@gmail.com wrote: Currently for developing for BlackBerry 10 the user needs to download and install the WebWorks SDK. [1]. This SDK is opensource and available from github [2] and users are able to clone and build the SDK with the native development tools available [3]. I would like to switch the BlackBerry 10 platform for cordova to use the NDK and clone WebWorks from github. The only difference a cordova developer would notice would be what download we tell them to install in the documentations, everything else would be handled by the ./bin/create script and ./cordova/* scripts pointing where the WebWorks SDK lives. This preps us to have the tools available on the developers machine to build any native extensions that may or may not be needed for BlackBerry 10 development. [1] https://developer.blackberry.com/html5/download/ [2] https://github.com/blackberry/BB10-Webworks-Packager [3] http://developer.blackberry.com/native/beta/ -- *Nukul Bhasin* *Computer Engineer, B.Eng* *10 Queens Quay W, suite#1710* *Toronto, ON, Canada* *Ph: 416 508 3157*
Re: Determining if you're in cordova
Is what people in the browser wanting the deviceready event to fire? Sent from my iPhone On 2012-12-03, at 5:54 PM, Max Ogden m...@maxogden.com wrote: I dont think modifying the UA is a good idea but I strongly believe that cordova needs to set *something* that is immediately available from browser JS on app load that says hi you're running in cordova On Mon, Dec 3, 2012 at 1:31 PM, Anis KADRI anis.ka...@gmail.com wrote: 1) Set a specific UA string like the wikimedia guys do (even tough they do it for other reasons). 2) I remember us talking about a capabilities api. Not sure what transpired from that discussion. On Mon, Dec 3, 2012 at 1:29 PM, Brian LeRoux b...@brian.io wrote: Back to our original thread. I'm seeing a couple of scenarios. 1. wants to do analytics reporting (needs user agent) 2. wants to do be capability responsive (needs to see if there are device apis, usually a specific capability/api combo such as camera) Thoughts? On Mon, Dec 3, 2012 at 9:10 PM, Simon MacDonald simon.macdon...@gmail.com wrote: Yup, window.open(url, _blank) will load the InAppBrowser which is basically a renamed ChildBrowser that actually follows a spec for events. Simon Mac Donald http://hi.im/simonmacdonald On Mon, Dec 3, 2012 at 2:40 PM, Max Ogden m...@maxogden.com wrote: In Gather we have a login page that uses childbrowser popup windows for oauth if its running in phonegap or popup windows in javascript if in browser. It would be nice childbrowser polyfilled target=_blank (which I understand is happening in the future) but as for now the heuristics for detecting which strategy to use boil down to sniffing window.location.href which isn't ideal: - if I open my apps index.html in chrome it will have a file:// url but wont be in phonegap. - if I hardcode a domain into my app so that it knows if it is running from a server its another thing to remember to update every time the domain name changes - I already do conditional loading of stylesheets and JS based on user agent. I think it would be super useful if there was a user agent equivalent for cordova so the code could decide what to do based on environment and not guesses based on href On Sun, Dec 2, 2012 at 11:30 AM, Brian LeRoux b...@brian.io wrote: Eh Fil, is this so they can detect if they have device apis ultimately? On Sat, Dec 1, 2012 at 1:31 AM, Bryce Curtis curtis.br...@gmail.com wrote: I think the answer depends upon when the app checks to see if it is running in cordova webview. If it is loading a remote url with remote cordova.js, then the native side will become available well before cordova.js finished loading. So, I would either check for device.cordova or register for deviceready and wait for it to fire. On Fri, Nov 30, 2012 at 5:53 PM, Gord Tanner gtan...@gmail.com wrote: +1 This isn't a platform issue but rather a developer issue Sent from my iPhone On 2012-11-30, at 7:11 PM, Jesse purplecabb...@gmail.com wrote: Presumably the developer knows the url of their own server, so wouldn't it be easier to just test for that in window.location? On Fri, Nov 30, 2012 at 4:07 PM, Jesse purplecabb...@gmail.com wrote: So the bigger question then is how to handle the differences ... On Fri, Nov 30, 2012 at 4:04 PM, Filip Maj f...@adobe.com wrote: It is to run a single codebase (or as close to it as possible minus the differences in cordova.js) across web and cordova apps. On 11/30/12 4:02 PM, Jesse purplecabb...@gmail.com wrote: Can we back up and discuss the goal? Is it to use the same code on the server + inside an app ( that is packaged for multiple platforms ) ? OR Is it to load an app on multiple devices all served by the same server? On Fri, Nov 30, 2012 at 3:56 PM, Shazron shaz...@gmail.com wrote: Its yucky and may break in a future platform version, but since each platform requires its own cordova.js -- then each platform could define its own cordova.isWebView? wp7 is x-wmapp iOS is file:// BB is http://localhost Android is ? On Fri, Nov 30, 2012 at 3:49 PM, Jesse purplecabb...@gmail.com wrote: WP7 app is loaded from x-wmapp1:/ WP8 app is loaded from x-wmapp0:/ So file:// will not work There are probably numerous other approches ... deviceready will/should never fire, but that is difficult to test for, because it could just be taking a real long time. I see many issues with this though: - each platform still requires it's own cordova.js, so this would only work with 1 platform + a webserver, so no idea we come up for this will solve the bigger problem. On Fri, Nov 30, 2012 at 3:46 PM, Shazron shaz...@gmail.com wrote: document.location starts with http://localhost OR starts with file:// then? ;) In any case, any js variable that we could set can be overridden of course. On Fri, Nov 30, 2012 at 3:38 PM, Filip Maj f...@adobe.com wrote
Re: Determining if you're in cordova
I am having a hard time making this seem like a Cordova problem.
There are many different and easy ways to fix this for the developer but I
can't see a good way for us to handle it.
Do we create a Cordova.web.js that a developer can include on their server?
It would enable as much as it can (geo, accel via devicemotion) and fire
deviceready?
Sent from my iPhone
On 2012-12-03, at 6:30 PM, Max Ogden m...@maxogden.com wrote:
actual code from gather:
if (inBrowser()) setTimeout(function() {
app.emit('deviceReady')
}, 50)
right now inBrowser looks at window.location.href and fires the event if it
isnt in phonegap. but I use the inBrowser function elsewhere to determine
what login strategy to use (see my previous messages).
if phonegap fires deviceready for me I still won't know if i'm in phonegap
or not
On Mon, Dec 3, 2012 at 3:06 PM, Brian LeRoux b...@brian.io wrote:
So, would that not be deviceready? (I get that those apps that run in
browser probably fake this event but, if thats the case, then the
faking would be a userland place to put that sort of thing.)
On Mon, Dec 3, 2012 at 10:54 PM, Max Ogden m...@maxogden.com wrote:
I dont think modifying the UA is a good idea but I strongly believe that
cordova needs to set *something* that is immediately available from
browser
JS on app load that says hi you're running in cordova
On Mon, Dec 3, 2012 at 1:31 PM, Anis KADRI anis.ka...@gmail.com wrote:
1) Set a specific UA string like the wikimedia guys do (even tough they
do
it for other reasons).
2) I remember us talking about a capabilities api. Not sure what
transpired
from that discussion.
On Mon, Dec 3, 2012 at 1:29 PM, Brian LeRoux b...@brian.io wrote:
Back to our original thread. I'm seeing a couple of scenarios.
1. wants to do analytics reporting (needs user agent)
2. wants to do be capability responsive (needs to see if there are
device apis, usually a specific capability/api combo such as camera)
Thoughts?
On Mon, Dec 3, 2012 at 9:10 PM, Simon MacDonald
simon.macdon...@gmail.com wrote:
Yup, window.open(url, _blank) will load the InAppBrowser which is
basically a renamed ChildBrowser that actually follows a spec for
events.
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Dec 3, 2012 at 2:40 PM, Max Ogden m...@maxogden.com wrote:
In Gather we have a login page that uses childbrowser popup windows
for
oauth if its running in phonegap or popup windows in javascript if
in
browser. It would be nice childbrowser polyfilled target=_blank
(which I
understand is happening in the future) but as for now the
heuristics
for
detecting which strategy to use boil down to sniffing
window.location.href
which isn't ideal:
- if I open my apps index.html in chrome it will have a file:// url
but
wont be in phonegap.
- if I hardcode a domain into my app so that it knows if it is
running
from
a server its another thing to remember to update every time the
domain
name
changes
- I already do conditional loading of stylesheets and JS based on
user
agent. I think it would be super useful if there was a user agent
equivalent for cordova so the code could decide what to do based on
environment and not guesses based on href
On Sun, Dec 2, 2012 at 11:30 AM, Brian LeRoux b...@brian.io wrote:
Eh Fil, is this so they can detect if they have device apis
ultimately?
On Sat, Dec 1, 2012 at 1:31 AM, Bryce Curtis
curtis.br...@gmail.com
wrote:
I think the answer depends upon when the app checks to see if
it is
running in cordova webview. If it is loading a remote url with
remote
cordova.js, then the native side will become available well
before
cordova.js finished loading. So, I would either check for
device.cordova or register for deviceready and wait for it to
fire.
On Fri, Nov 30, 2012 at 5:53 PM, Gord Tanner gtan...@gmail.com
wrote:
+1
This isn't a platform issue but rather a developer issue
Sent from my iPhone
On 2012-11-30, at 7:11 PM, Jesse purplecabb...@gmail.com
wrote:
Presumably the developer knows the url of their own server, so
wouldn't it be easier to just test for that in
window.location?
On Fri, Nov 30, 2012 at 4:07 PM, Jesse
purplecabb...@gmail.com
wrote:
So the bigger question then is how to handle the differences
...
On Fri, Nov 30, 2012 at 4:04 PM, Filip Maj f...@adobe.com
wrote:
It is to run a single codebase (or as close to it as
possible
minus
the
differences in cordova.js) across web and cordova apps.
On 11/30/12 4:02 PM, Jesse purplecabb...@gmail.com
wrote:
Can we back up and discuss the goal?
Is it to use the same code on the server + inside an app (
that
is
packaged for multiple platforms ) ?
OR
Is it to load an app on multiple devices all served by the
same
server?
On Fri, Nov 30, 2012 at 3:56 PM, Shazron
shaz...@gmail.com
wrote:
Its yucky and may break in a future platform version, but
since
each
WARNING: Updated BlackBerry 10 SDK
The BlackBerry 10 SDK and OS versions were updated this week, this broke compatibility the previous SDK. Until BlackBerry 10 is released we will have to keep on the bleeding edge to ensure device to SDK compatibility. I updated cordova-blackberry to use the new SDK (also use the provided path for webworks.js and took out the task of copying the webworks.js ourselves) https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commitdiff;h=c747a03f7037e85ee81af86530bf6cc126fed5e4 We should make sure that this is in the release notes for the 2.3 release.
Re: Determining if you're in cordova
My gut told me _nativeReady but I don't think that is cross platform. I think we should work harder at making Cordova.js be a noop when in a standard browser which shouldn't be to hard. Sent from my iPhone On 2012-11-30, at 6:38 PM, Filip Maj f...@adobe.com wrote: I think in BB WEbWorks you get http://localhost/somethingsoemthing On 11/30/12 3:35 PM, Shazron shaz...@gmail.com wrote: how do we know if we're in cordova or not? -- document.location starts with file:// ?
Re: Determining if you're in cordova
+1 This isn't a platform issue but rather a developer issue Sent from my iPhone On 2012-11-30, at 7:11 PM, Jesse purplecabb...@gmail.com wrote: Presumably the developer knows the url of their own server, so wouldn't it be easier to just test for that in window.location? On Fri, Nov 30, 2012 at 4:07 PM, Jesse purplecabb...@gmail.com wrote: So the bigger question then is how to handle the differences ... On Fri, Nov 30, 2012 at 4:04 PM, Filip Maj f...@adobe.com wrote: It is to run a single codebase (or as close to it as possible minus the differences in cordova.js) across web and cordova apps. On 11/30/12 4:02 PM, Jesse purplecabb...@gmail.com wrote: Can we back up and discuss the goal? Is it to use the same code on the server + inside an app ( that is packaged for multiple platforms ) ? OR Is it to load an app on multiple devices all served by the same server? On Fri, Nov 30, 2012 at 3:56 PM, Shazron shaz...@gmail.com wrote: Its yucky and may break in a future platform version, but since each platform requires its own cordova.js -- then each platform could define its own cordova.isWebView? wp7 is x-wmapp iOS is file:// BB is http://localhost Android is ? On Fri, Nov 30, 2012 at 3:49 PM, Jesse purplecabb...@gmail.com wrote: WP7 app is loaded from x-wmapp1:/ WP8 app is loaded from x-wmapp0:/ So file:// will not work There are probably numerous other approches ... deviceready will/should never fire, but that is difficult to test for, because it could just be taking a real long time. I see many issues with this though: - each platform still requires it's own cordova.js, so this would only work with 1 platform + a webserver, so no idea we come up for this will solve the bigger problem. On Fri, Nov 30, 2012 at 3:46 PM, Shazron shaz...@gmail.com wrote: document.location starts with http://localhost OR starts with file:// then? ;) In any case, any js variable that we could set can be overridden of course. On Fri, Nov 30, 2012 at 3:38 PM, Filip Maj f...@adobe.com wrote: I think in BB WEbWorks you get http://localhost/somethingsoemthing On 11/30/12 3:35 PM, Shazron shaz...@gmail.com wrote: how do we know if we're in cordova or not? -- document.location starts with file:// ? -- @purplecabbage risingj.com -- @purplecabbage risingj.com -- @purplecabbage risingj.com -- @purplecabbage risingj.com
Re: Jasmine and Cordova
I use jasmine for most of the projects I am involved in: - cordova.js - modile spec - ripple - etc. I set up most of these projects to use jasmine and can answer any questions you have getting started. They should probably be off list so just ask me directly. On Wed, Nov 28, 2012 at 3:13 PM, Filip Maj f...@adobe.com wrote: https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=summary
Re: Attempting to add debug token support for building on PlayBook
seems to work for me (just double checked to make sure my blackberry-tablet.xml wasn't updated) On Fri, Nov 23, 2012 at 12:03 PM, Filip Maj f...@adobe.com wrote: I tried the path thing initially but it didn't work.. On 11/23/12 8:35 AM, Gord Tanner gtan...@gmail.com wrote: Ok, debug token support added to playbook: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commitd iff;h=ef16d935bf08e0baaa8c1d875edd5af76c856f1f Let us never speak of this again. This should make the CI stuff for Fil suck a whole lot less. On Fri, Nov 23, 2012 at 10:43 AM, Gord Tanner gtan...@gmail.com wrote: So I found out it doesn't suck as bad as we all thought ;) From: https://developer.blackberry.com/html5/documentation/runnning_unsigned_ap ps_using_a_debug_token_1866987_11.html It looks like all we need to do is provide the path to the debug token in the bbwp.properties file. I tested this on my playbook and was able to deploy to it. This is a lot easier to automate in the build script then the Rube Goldburg machine mentioned above. From the link: 1. In the BlackBerry WebWorks SDK for BlackBerry Tablet OS installation folder, navigate to the*bbwp\bin* folder. 2. Using a text editor, open the bbwp.properties file. 3. Add the path to the debug token file by using debug_token tags. debug_tokenpath to debug token file/debug_token On Thu, Nov 22, 2012 at 3:51 PM, Josh Soref jso...@rim.com wrote: Gord wrote: not the best way to do it now ;) I should be able to automate this in the playbook.xml so our users don't have to deal with it. The way I'm told is to just remove those items from the PlayBook.xml file entirely and just rely on the packager/debugtoken to magically set them or somehow make it work. (this was advice I got from non-RIM people, to me,...) - 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: Attempting to add debug token support for building on PlayBook
wow, so yeah that works.
not the best way to do it now ;)
I should be able to automate this in the playbook.xml so our users don't
have to deal with it.
On Thu, Nov 22, 2012 at 2:46 PM, Filip Maj f...@adobe.com wrote:
O HELL YEAH I HAVE. Let me, an Adobe employee, give you, a RIM employee,
the awesome run down of how to fix this. This is gonna be fun and I get to
vent a bit too! :D
1. Locate your debug token.
2. Extract the .bar of the debug token with an archive app
3. There will be a META-INF folder
4. Open up META-INF/MANIFEST.MF
5. In there you will see Package-Author and Package-Author-ID. Note down
those values.
6. Locate your playbook sdk install dir
7. Go to sdk/bbwp/AirAppTemplates/src
8. Edit blackberry-tablet.xml
9. Make sure blackberry-tablet.xml has the following XML elements that
match the values in your MANIFEST.MF file of your debug token:
- publisher should match Package-Author
- author should match Package-Author
- authorId should match Package-Author-Id
10. You may have to add some of these elements if they are missing. Yeah.
Try figuring that out.
I highly recommend RIM fix this as this process is FKN HORSESHIT.
That is all. I'm done :)
On 11/22/12 11:37 AM, Gord Tanner gtan...@gmail.com wrote:
I added debug token support to working on BB10 for cordova and would like
to do the same with playbook but I have the following problem:
Output of cordova build script when running 'ant playbook debug-device'
[exec] Info: Debug token created.
[exec] Info: Sending request: Install and Launch
[exec] Info: Action: Install and Launch
[exec] Info: File size: 2269
[exec] Info: Installing debug.token.gYABgBzNRmtRA7cXnit_yEsmdx4...
[exec] Info: Processing 2269 bytes
[exec] actual_dname::debug.token.gYABgBzNRmtRA7cXnit_yEsmdx4
[exec] actual_id::gYABgBzNRmtRA7cXnit_yEsmdx4
[exec] actual_version::0.0.0.48
[exec] result::success
[exec] Info: Launching debug.token.gYABgBzNRmtRA7cXnit_yEsmdx4...
[exec] result::Invalid
[exec] Info: done
[exec] [INFO] Parsing command line options
[exec] [INFO] Parsing bbwp.properties
[exec] [INFO] Validating WebWorks archive
[exec] [INFO] Parsing config.xml
[exec] [INFO] Populating application source
[exec] [INFO] Compiling WebWorks application
[exec] [INFO] Packaging the bar file
[exec] [INFO] Bar packaging complete
[exec] [INFO] WebWorks application packaging complete
[exec] Info: Sending request: Install and Launch
[exec] Info: Action: Install and Launch
[exec] Info: File size: 510530
[exec] Info: Installing
cordovaExample66daa65d5ab3c8ba4e3a9403c3a28a7.testDev_9403c3a28a75887c750.
..
[exec] Info: Processing 510530 bytes
[exec] actual_dname::
[exec] actual_id::
[exec] actual_version::
[exec] result::failure 881 application author does not match debug
token author
The value in my config.xml author tag is Gord Tanner, which is the same
displayed for the debug token author shown on the playbook.
The ant script I am using is:
!-- install debug token --
+macrodef name=generate-debug-token
+sequential
+exec executable=${blackberry-debugtokenrequest} dir=.
failonerror=true
+arg value=-storepass /
+arg value=${properties.playbook.sigtool.csk.password}
/
+arg value=-deviceID /
+arg value=0x${properties.qnx.device.pin} /
+arg file=${properties.qnx.bbwp.dir}/debugtoken.bar /
+/exec
+
+exec executable=${blackberry-deploy} dir=.
failonerror=true
+arg value=-installApp /
+arg value=-launchApp /
+arg value=-device /
+arg value=${properties.playbook.device.ip} /
+arg value=-password /
+arg value=${properties.playbook.device.password} /
+arg value=-package /
+arg file=${properties.qnx.bbwp.dir}/debugtoken.bar /
+/exec
+/sequential
+/macrodef
Has anyone come across this before?
Re: Fast edit-refresh cycles
This also is feeding into some of the work we are doing with ripple. Ripple will serve up the app and host it kind of like how we do debug.phonegap.com for in browser testing. Sent from my iPhone On 2012-11-22, at 3:15 PM, Filip Maj f...@adobe.com wrote: Agree with Jesse. Automatically adding the plugin's .js to html pages inside a www dir can be done by the cordova-client tool anyways. Agree this should go to vote before we proceed. On 11/22/12 12:13 PM, Jesse purplecabb...@gmail.com wrote: I think all the refresh stuff is super cool, I will share how I work, so you can get another perspective. 90% of my code is written on localhost, either running directly in a browser to work out UI stuff. When I need access to actual device APIs, I simply put a redirect in my index.html. This gets me through 99% of my work, after which I can fine tune an individual device or functional piece in XCode, Eclipse, Visual Studio, et al When it comes to inclusion of multiple script tags, I do not see this as a barrier at all. This is the way the internet has always worked, and it ain't broke. I like the explicit declaration of having a script tag, plus you can have multiple pages, with different plugin requirements. Adding an extra build step, + reinventing the internet inside our framework is madness in my opinion. This of course does not preclude use of this technique, however, I feel very strongly that we should NOT be building this into our framework, and forcing developers to use this approach. I think this is definitely something that we should vote on before developing further if the goal is inclusion in cordova. Cheers, Jesse On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux b...@brian.io wrote: super interesting. I like where this is going. On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve agri...@chromium.org wrote: On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj f...@adobe.com wrote: Dude: awesome! My answers in-line: 2. Manually adding the script tags to include every new plugin is really lame. I propose a unified file, plugins.js or similar, that's always included in the index.html. Every time you add or remove a plugin, the Javascript files for all the plugins are concatenated into this file. There are likely some problems with this approach. Inserting/removing the script tags from the index page is also an option, though it requires more clever scripts. Can you elaborate more on this? I don't understand. Here's the motivating example to explain this: - Our goal for 3.0 is to have cordova be just the bridge, and to have all core plugins in separate repos - Right now, when you pluginstall a plugin, you need to manually edit your .html to add the .js of the plugin in a script tag. - This will be quite annoying to have to add ~10 script tags, (one for each core plugin, plus one for each non-core plugin you have) Here's Braden's idea explained a bit more: - Have a plugin.js file in addition to the cordova.js file - cordova.js to have the platform's bridge init code - plugins.js to contain the concatenation of all plugin .js files - plugins.js to be regenerated whenever a plugin is added / removed - Apps will need to add both .js files to their html, but not need to add a script for every plugin separately. 3. Setting the start page manually on every platform sucks. I think this should be a value in config.xml that gets set on cordova build. Obviously that requires 1. to be fixed, but we'll get there soon. Yes, there is config.xml prior art for this: http://www.w3.org/TR/widgets/#the-content-element-and-its-attributes We should file issues to add support for this. Thanks for forking + contributing to cordova-client, stoked to see more contributors in there! Related: once we migrate to our new git repos we should get a new one set up for cordova-client. -- @purplecabbage risingj.com
Re: RIM/BlackBerry folk: please help
Weird, it has been deploying for me. I have seen that black screen lag for a long time when I have done remote debugger + a remote starting page, which is not what you are describing. Any tips nukul? Sent from my iPhone On 2012-11-19, at 6:58 PM, Filip Maj f...@adobe.com wrote: I'm using the latest commit from cordova-blackberry and run the example app with as little changes as possible. My shell commands are (make sure there's no example directory with an app already present in the root of the repo): ./bin/create cd example edit project.properties with my BB10 SDK location, signing password, device ip and device password ant qnx debug-device Shell Output: fil-MacBookAir:example fil$ ant qnx debug-device Buildfile: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build.xml qnx: debug-device: generate-cod-name: [echo] Generated name: cordovaExample.bar clean: package-app: [mkdir] Created dir: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/widget [copy] Copying 22 files to /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/widget [copy] Copying 1 file to /Users/fil/src/incubator-cordova-blackberry-webworks/example/www/js [zip] Building zip: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/cordovaE xample.zip debug-device: [exec] Info: Debug token created. [exec] Info: Sending request: Install [exec] Info: Action: Install [exec] Info: File size: 2263 [exec] Info: Installing ... [exec] Info: Processing 2263 bytes [exec] actual_dname::debug.token.gYABgIVTqbRuktLyOHwoFTMiQyw [exec] actual_id::gYABgIVTqbRuktLyOHwoFTMiQyw [exec] actual_version::0.0.0.6 [exec] result::success [exec] [INFO]Populating application source [exec] [INFO]Parsing config.xml [exec] [WARN]Build ID set in config.xml [version], but no signing password was provided [-g]. Bar will be unsigned [exec] [WARN]Failed to find feature with id: org.apache.cordova [exec] [WARN]Failed to find feature with id: blackberry.find [exec] [WARN]Failed to find feature with id: blackberry.identity.phone [exec] [WARN]Failed to find feature with id: blackberry.pim.Address [exec] [WARN]Failed to find feature with id: blackberry.pim.Contact [exec] [WARN]Failed to find feature with id: blackberry.io.file [exec] [WARN]Failed to find feature with id: blackberry.utils [exec] [WARN]Failed to find feature with id: blackberry.io.dir [exec] [WARN]Failed to find feature with id: blackberry.app.event [exec] [WARN]Failed to find feature with id: blackberry.system.event [exec] [WARN]Failed to find feature with id: blackberry.widgetcache [exec] [WARN]Failed to find feature with id: blackberry.media.camera [exec] [WARN]Failed to find feature with id: blackberry.media.microphone [exec] [INFO]Generating output files [exec] [INFO]Info: Package created: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/simulato r/cordovaExample.bar [exec] [INFO]Info: Package created: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/device/c ordovaExample.bar [exec] [INFO]BAR packaging complete [exec] Info: Sending request: Install and Launch [exec] Info: Action: Install and Launch [exec] Info: File size: 948106 [exec] Info: Installing cordovaExample.testDev_dovaExamplee1922ce_... [exec] Info: Processing 948106 bytes [exec] Info: Progress 28%... [exec] Info: Progress 67%... [exec] Info: Progress 100%... [exec] actual_dname::cordovaExample.testDev_dovaExamplee1922ce_ [exec] actual_id::testDev_dovaExamplee1922ce_ [exec] actual_version::1.0.0.0 [exec] result::success [exec] Info: Launching cordovaExample.testDev_dovaExamplee1922ce_... [exec] result::11276465 [exec] Info: done BUILD SUCCESSFUL Total time: 25 seconds It loads an app called cordovaExample properly. It has no icon for some reason, and the only thing that I see when the app loads is a very dark screen with the BlackBerry logo. On 11/19/12 3:51 PM, Nukul Bhasin m...@nukulb.com wrote: Send us your app From: Filip Maj To: dev@cordova.apache.org Reply To: dev@cordova.apache.org *Re: RIM/BlackBerry folk: please help* 2012-11-19 6:46:11 PM Hey Gord, This is awesome! Thank you. Indeed this is exactly what I wanted. Now for the CI setup I no longer have to worry about debug tokens expiring. Unfortunately no matter how I package my webworks app, when I launch the app a black BlackBerry loading screen comes up on my dev alpha A device and doesn't go any further :( Any debugging approach you can recommend ? On 11/18/12 7:19 AM, Gord Tanner wrote: I updated the ant scripts for blackberry to support debug tokens when
Re: RIM/BlackBerry folk: please help
Also on another note we should be able to port the same debug token stuff to the playbook building as well Sent from my iPhone On 2012-11-19, at 6:58 PM, Filip Maj f...@adobe.com wrote: I'm using the latest commit from cordova-blackberry and run the example app with as little changes as possible. My shell commands are (make sure there's no example directory with an app already present in the root of the repo): ./bin/create cd example edit project.properties with my BB10 SDK location, signing password, device ip and device password ant qnx debug-device Shell Output: fil-MacBookAir:example fil$ ant qnx debug-device Buildfile: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build.xml qnx: debug-device: generate-cod-name: [echo] Generated name: cordovaExample.bar clean: package-app: [mkdir] Created dir: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/widget [copy] Copying 22 files to /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/widget [copy] Copying 1 file to /Users/fil/src/incubator-cordova-blackberry-webworks/example/www/js [zip] Building zip: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/cordovaE xample.zip debug-device: [exec] Info: Debug token created. [exec] Info: Sending request: Install [exec] Info: Action: Install [exec] Info: File size: 2263 [exec] Info: Installing ... [exec] Info: Processing 2263 bytes [exec] actual_dname::debug.token.gYABgIVTqbRuktLyOHwoFTMiQyw [exec] actual_id::gYABgIVTqbRuktLyOHwoFTMiQyw [exec] actual_version::0.0.0.6 [exec] result::success [exec] [INFO]Populating application source [exec] [INFO]Parsing config.xml [exec] [WARN]Build ID set in config.xml [version], but no signing password was provided [-g]. Bar will be unsigned [exec] [WARN]Failed to find feature with id: org.apache.cordova [exec] [WARN]Failed to find feature with id: blackberry.find [exec] [WARN]Failed to find feature with id: blackberry.identity.phone [exec] [WARN]Failed to find feature with id: blackberry.pim.Address [exec] [WARN]Failed to find feature with id: blackberry.pim.Contact [exec] [WARN]Failed to find feature with id: blackberry.io.file [exec] [WARN]Failed to find feature with id: blackberry.utils [exec] [WARN]Failed to find feature with id: blackberry.io.dir [exec] [WARN]Failed to find feature with id: blackberry.app.event [exec] [WARN]Failed to find feature with id: blackberry.system.event [exec] [WARN]Failed to find feature with id: blackberry.widgetcache [exec] [WARN]Failed to find feature with id: blackberry.media.camera [exec] [WARN]Failed to find feature with id: blackberry.media.microphone [exec] [INFO]Generating output files [exec] [INFO]Info: Package created: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/simulato r/cordovaExample.bar [exec] [INFO]Info: Package created: /Users/fil/src/incubator-cordova-blackberry-webworks/example/build/device/c ordovaExample.bar [exec] [INFO]BAR packaging complete [exec] Info: Sending request: Install and Launch [exec] Info: Action: Install and Launch [exec] Info: File size: 948106 [exec] Info: Installing cordovaExample.testDev_dovaExamplee1922ce_... [exec] Info: Processing 948106 bytes [exec] Info: Progress 28%... [exec] Info: Progress 67%... [exec] Info: Progress 100%... [exec] actual_dname::cordovaExample.testDev_dovaExamplee1922ce_ [exec] actual_id::testDev_dovaExamplee1922ce_ [exec] actual_version::1.0.0.0 [exec] result::success [exec] Info: Launching cordovaExample.testDev_dovaExamplee1922ce_... [exec] result::11276465 [exec] Info: done BUILD SUCCESSFUL Total time: 25 seconds It loads an app called cordovaExample properly. It has no icon for some reason, and the only thing that I see when the app loads is a very dark screen with the BlackBerry logo. On 11/19/12 3:51 PM, Nukul Bhasin m...@nukulb.com wrote: Send us your app From: Filip Maj To: dev@cordova.apache.org Reply To: dev@cordova.apache.org *Re: RIM/BlackBerry folk: please help* 2012-11-19 6:46:11 PM Hey Gord, This is awesome! Thank you. Indeed this is exactly what I wanted. Now for the CI setup I no longer have to worry about debug tokens expiring. Unfortunately no matter how I package my webworks app, when I launch the app a black BlackBerry loading screen comes up on my dev alpha A device and doesn't go any further :( Any debugging approach you can recommend ? On 11/18/12 7:19 AM, Gord Tanner wrote: I updated the ant scripts for blackberry to support debug tokens when debugging on a device: https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-we b
Re: RIM/BlackBerry folk: please help
I updated the ant scripts for blackberry to support debug tokens when
debugging on a device:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-webworks.git;a=commitdiff;h=9c1edccf60b48e1914f4b7093cf00d477908a05d
If you fill in the qnx.device.pin value in project.properties it will now
create and load a debug token on your device and load unsigned when using
the debug-device command.
I hope this is a little closer for your CI stuff.
On Thu, Nov 15, 2012 at 8:49 AM, Nukul Bhasin m...@nukulb.com wrote:
I agree with Gord's evaluation of the problem,
The error you are getting is often because of buildId not getting
incrementing
Setting up debug tokens can really suck, but its the reality of where we
are today. If you use QNX momentics (NDK tooling) it will hide all the
ugliness for you.
Command Line tools are lagging in bringing the same experience but Signing
improvements are on the roadmap, no landing date yet though but its being
re-thought completely.
On Wed, Nov 14, 2012 at 6:26 PM, Filip Maj f...@adobe.com wrote:
Whatever. I gave up and used debug tokens. IT was fucking difficult to
get
working but am now at a barely-workable level.
On 11/14/12 3:18 PM, Gord Tanner gtan...@gmail.com wrote:
Signing worked for me with my super epic script:
var sys = require('sys')
var exec = require('child_process').exec;
exec(ant qnx load-device, function (error, stdout, stderr) {
sys.print('stdout: ' + stdout);
sys.print('stderr: ' + stderr);
if (error !== null) {
console.log('exec error: ' + error);
}
});
I think your main issue is the version number and buildId hackery for
signing.
On Wed, Nov 14, 2012 at 5:38 PM, Filip Maj f...@adobe.com wrote:
That's not what happens though.
When I create a fresh project, the name and version are always the
same.
When I run the signing via node, it fails.
Then I'll CD into this exact same project folder and run the signing
manually. It works.
I'll also create a new project manually with that same version and app
name. If I sign it via command line it works. If I do it via my node
script it fails.
On 11/14/12 2:32 PM, Tim Kim timki...@gmail.com wrote:
The reason why you keep getting signing failures even with a fresh
project
is that you already did it once. ie, in your config.xml, the widget
version
is set to 1.0.0.0 and the name attribute is cordovaExample. So
the
first time should work, but every new fresh project there after will
have
the same values.
I would recommend updating the version number every time you deploy
and
not
worry about that debug-token business - I've never used it.
--
Timothy Kim
--
*Nukul Bhasin*
*Computer Engineer, B.Eng*
*10 Queens Quay W, suite#1710*
*Toronto, ON, Canada*
*Ph: 416 508 3157*
Re: RIM/BlackBerry folk: please help
So to reproduce I just shell execute ant qnx load-device via a node script? On Wed, Nov 14, 2012 at 3:20 PM, Filip Maj f...@adobe.com wrote: I am working on a continuous integration setup. Got android and iOS working. Now trying to get it working with playbook + BB10. I've tried many avenues to automate the compilation / signing / deployment / launching aspect. Using blackberry-deploy I can launch an app. Hooray! However, I can't sign the app when I shell out to the ant file (ant target build with code.sign=true). I get code signing failed as this package is already signed. If I run this command interactively from my command line it works fine. Perhaps some kind of permission issue with a node process shelling out to ant which in turn fires off to bbwp? Then I tried using the debug tokens instead of signing the app. This is a shitshow in itself. I keep getting author does not match or something along those lines. Tried the various solutions mentioned on the BB support forums [1] and none of them work, including: - Author tag in config.xml matches the debug token author - tablet-sdk/bbwp/bin/bbwp.properties points to the debug token I created and installed on the device I would also recommend reviewing this whole debug token process as it sucks and doesn't work. Echoing the questions in the thread, basically Why do I have to enter my company name in 20 different locations? Any insight into how to fix the author mismatch or automated signing would be helpful. [1] http://supportforums.blackberry.com/t5/Web-and-WebWorks-Development/Applica tion-author-does-not-match-debug-token-author/td-p/1471779
Re: InAppBrowser api questions
Nice!!!
When is the next release? I will create a jira to track looking into getting
the child browser plugin working for Cordova once the bb10 API is available
On 2012-11-09, at 3:24 PM, Nukul Bhasin m...@nukulb.com wrote:
BB10 WebWorks implements something similar. It will be a part of the next
release
here is the definition for what we implemented for BB10
https://github.com/blackberry/BB10-WebWorks-Framework/issues/230
On Fri, Nov 9, 2012 at 12:43 PM, Shazron shaz...@gmail.com wrote:
WIki page: http://wiki.apache.org/cordova/InAppBrowser
Some questions brought up by Jesse in JIRA (replicated below):
http://goo.gl/cZe84
Jesse MacFadyen:
I have some open questions about the wiki defined 'spec'
1. window.open('http://random-url.com', '_self'); // loads in InAppBrowser
so even though the random-url is not whitelisted, it is permitted to
load within the application, inside the InAppBrowser. This is currently not
trivial on iOS.
2. How can I open a whitelisted url in the native browser? ie. mobile
safari
there is no clear path to targeting ALL 3 possibilities or a)the app
page, b) the InAppBrowser, c) the system browser ( for a whitelisted URL )
it makes sense that you cannot open a file:// url in the system browser
+ you cannot open a non-whitelisted url in the app.
My comments:
1. This as Jesse points out, is not trivial on iOS. The easy way would be
to not allow this, but kick it out to the system browser (Mobile Safari),
and have that as a general rule, any non-whitelisted URLs for the
InAppBrowser are kicked out to the system browser. I don't know how hard it
is for Android.
If we were to do this, we would have to temporarily allow the url to bypass
the whitelist which could be kludgy (since we can't know what other URLs
that URL will load) -- essentially this issue
http://issues.cordova.io/1695would totally solve this correctly, but
we don't have a solution yet for
that issue.
2. This case has not been addressed. I would think _blank would be the case
but this is specified as the InAppBrowser here. How about this case, we
could use _parent for InAppBrowser, but _blank for system browser? However,
this would not be consistent with how the other calls are specified (unless
we change the others to be consistent).
Another possible solution is to kick out to the system browser if an
unknown value is used (some random value), that will use the system
browser, which is consistent with how window.open works.
--
*Nukul Bhasin*
*Computer Engineer, B.Eng*
*10 Queens Quay W, suite#1710*
*Toronto, ON, Canada*
*Ph: 416 508 3157*
Re: BB10 Custom Extensions Testing
Same!
Awesomesauce
Sent from my iPhone
On 2012-11-07, at 7:22 PM, Steven Gill stevengil...@gmail.com wrote:
Nice work Tim. I will give it a go tomorrow on my BB10 dev device.
-Steve
On Wed, Nov 7, 2012 at 4:11 PM, Tim Kim timki...@gmail.com wrote:
Howdy everyone,
I've been working on the bb10 extension for about a month and I've finally
gotten it to a point where it's ready for some good old human testing.
If you've got a bb10 device, try running these steps for me and tell me
what you think!
0) Clone this repo/branch:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-webworks.git;a=shortlog;h=refs/heads/bb10_ext_qnx
1) Download and install the bb10 native sdk:
http://developer.blackberry.com/native/beta/
2) cd into the cordova blackberry webworks repo
3) cd into the framework/ext-qnx
4) Find the bb10 native sdk directory and run source
path_to_your_bb10_native_sdk_dir/bbndk-env.sh
5) hit make
6) An *.so file will be generated in the nto/arm/so.le-v7/ - copy and
rename this file to echoJNext.so and place it
in the cordova.echo/device folder
7) Use ant dist in the cordova blackberry webworks repo to create a new
project with the echo plugin
8) Modify project settings and deploy to device
9) Using the remote web-inspector, call these javascript commands:
var message = { 'message' : hello}
win = function(result){ alert(result == hello) }
fail = function(){ alert('failed') }
cordova.echo.doEcho(message,win,fail)
--
Timothy Kim
Re: 2.2.0rc2 Monday?
-1568? On Thu, Oct 25, 2012 at 2:46 PM, Andrew Grieve agri...@chromium.org wrote: I still need to re-tag android. Just finishing up fixes for CB-1744 and CB-1745 On Thu, Oct 25, 2012 at 2:45 PM, Filip Maj f...@adobe.com wrote: Cordova-mac, docs and WP7 are all that零 left On 10/25/12 11:44 AM, Herm Wong kingoftheo...@hotmail.com wrote: webOS tagged 2.2.0rc2. From: simon.macdon...@gmail.com Date: Thu, 25 Oct 2012 12:08:38 -0400 Subject: Re: 2.2.0rc2 Monday? To: callback-dev@incubator.apache.**org callback-...@incubator.apache.org If I had know about the bug before you tagged I would have opened an issue. It was exposed by running mobile spec on an Android 2.2 emulator while I was in the gym. Over 50% of the automated tests failed. Basically anything that was returning a string payload from the Java side did not work. Simon Mac Donald http://hi.im/simonmacdonald On Wed, Oct 24, 2012 at 4:38 PM, Joe Bowser bows...@gmail.com wrote: What bug? Do we have a way to test it? We're still in an RC, so it's ok for there to be bugs. That being said, I wish this was in JIRA so that I knew about it before tagging. Joe On Wed, Oct 24, 2012 at 1:33 PM, Simon MacDonald simon.macdon...@gmail.com wrote: Okay JS and Android re-tagged to 2.2.0 cause of soem Android 2.2 craziness. Simon Mac Donald http://hi.im/simonmacdonald On Wed, Oct 24, 2012 at 4:24 PM, Simon MacDonald simon.macdon...@gmail.com**wrote: I have to re-tag JS and Android. There is a bug that causes almost everything to fail on Android 2.2. The code is in the Android version of exec so other platforms will not need to pick up the new JS. Simon Mac Donald http://hi.im/simonmacdonald On Wed, Oct 24, 2012 at 4:00 PM, Joe Bowser bows...@gmail.com wrote: Tagged Android. It's ready to go! On Wed, Oct 24, 2012 at 12:57 PM, Shazron shaz...@gmail.com wrote: I'll update the iOS bits right now. On Wed, Oct 24, 2012 at 11:57 AM, Filip Maj f...@adobe.com wrote: JS. Mobile spec and hello world app is tagged. Gogo! On 10/19/12 1:41 AM, Leutwyler, Markus markus.leutwy...@hp.com wrote: +1 Let me know if you need any help Markus -Original Message- From: Filip Maj [mailto:f...@adobe.com] Sent: Donnerstag, 18. Oktober 2012 20:47 To: callback-dev@incubator.apache.**org callback-...@incubator.apache.org Subject: 2.2.0rc2 Monday? That cool? Would be good to get a cordova-js friendly version of webos out there. -- Gord Tanner Senior Developer / Code Poet tinyHippos Inc. @tinyhippos
Re: 2.2.0rc2 Monday?
thanks :) Teach a man to fish! retagged blackberry On Fri, Oct 26, 2012 at 1:14 PM, Andrew Grieve agri...@chromium.org wrote: FYI - the problem I was facing was not knowing the git foo for pushing tags. To re-tag: git fetch apache # Fetch tags git tag --force 2.2.0rc2 # Re-tag locally git push apache master --tag # Push tags I'll put this on the CuttingReleases wiki page. On Fri, Oct 26, 2012 at 1:11 PM, Gord Tanner g...@tinyhippos.com wrote: anyone have any objections of getting this fix into blackberry for 2.2? https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-blackberry-webworks.git;a=commit;h=6ae80d9ac480f01c2d5734656a7f33c044d11139 also I fail at teh git so if there is no objections could someone retag blackberry for me? On Fri, Oct 26, 2012 at 10:42 AM, Andrew Grieve agri...@chromium.org wrote: Sounds good. I've now re-tagged the JS and Android. On Thu, Oct 25, 2012 at 10:56 PM, Simon MacDonald simon.macdon...@gmail.com wrote: I'm still seeing the bug but I don't think it should hold up the tagging of 2.2.0rc2 at this point. I created a small sync Plugin for testing and it runs fine in my mobile spec test case. Now the same plugin called in the downstream app which uses the same Android library project for Cordova and the same .js file returns the wrong value when I call the plugin. At this point I'm not convinced it is a Cordova issue. Simon Mac Donald http://hi.im/simonmacdonald On Thu, Oct 25, 2012 at 8:56 PM, Andrew Grieve agri...@chromium.org wrote: Joe - my thinking here is that it's fine to re-tag and re-tag until we actually produce an RC with everything tagged. rc2 is still in the process of being tagged, and until the tagging is all done, it just causes more work to scratch it and have to re-tag all of the other repos. Once we create an rc2 archive though, no more adjusting. Marcel - yes, my intention is to retag the JS with the Android changes, and to update the JS in android repo and then re-tag that as well. Simon was still seeing a bug with one of his projects though, even after the fix, so I'd like to wait for his verification before continuing. On Thu, Oct 25, 2012 at 5:13 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Sorry, just catching up on the conversations. Ey Mr. Brooks do you have a script or something that we can use to easily/quickly clone/create the behemoth tag all the things parent issue with subtasks in JIRA? This seems like a worthwhile pursuit. Just find go to the parent issue (e.g. Tag 2.2.0rc1https://issues.apache.org/jira/browse/CB-1622#), click More Actions, and click Clone. JIRA will do the rest by spamming everyone. For the most part, I've worded each task in a generic manner, but you may need to edit the odd sub-tasks description if it mentions a version. Michael On Thu, Oct 25, 2012 at 2:08 PM, Marcel Kinard cmarc...@gmail.com wrote: I'm interested in the latest fix that Andrew put in the js repo: https://git-wip-us.apache.org/**repos/asf?p=incubator-cordova-** js.git;a=commitdiff;h=**97a05cb0f672ee1bfb7e9e14a0dfd4**52d7763ba9 https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-js.git;a=commitdiff;h=97a05cb0f672ee1bfb7e9e14a0dfd452d7763ba9 https://issues.apache.org/**jira/browse/CB-1745 https://issues.apache.org/jira/browse/CB-1745 When I browse the Apache repos, I see that: 1) this fix was committed to the js repo after the rc2 tag. Is this thread going to include this fix inside the rc2 tag? 2) the corresponding js artifact in the android repo needs to be refreshed to pick up this fix, and I don't see that commit at all. Is someone going to do that? And then will the rc2 tag on this repo include this refresh? Thanks! -- Marcel Kinard On 10/25/2012 4:03 PM, Andrew Grieve wrote: Okay. I'll co-ordinate with Simon on the re-tagging. He's still working through one of the bugs. On Thu, Oct 25, 2012 at 3:23 PM, Filip Maj f...@adobe.com wrote: You just need to delete the tag and re-add it. Then when you push with --tags it'll move the tag to the newer commit. And yeah retagging just android is fine. On 10/25/12 12:20 PM, Andrew Grieve agri...@chromium.org wrote: What I think we want to do is just update the existing 2.2.0rc2 tag to point to HEAD, unless we want to call rc2 a fail and move to rc3. I think
