Re: Summarizing thoughts on cordova-browser vs Ripple
On 11/15/14, 2:17 PM, Michal Mocny mmo...@chromium.org wrote: Not at all. What is it you think we are proposing? I'm merely suggesting that the cordova-browser camera plugin implementation shouldn't *also* come with a DOM component that sits over top of your application to manipulate the camera. The existing BAAP camera implementation is great as currently implemented, and wouldn't change. Another example would better illustrate the difference: BAAP geolocation shim I believe should just use the browser geolocation api, or return a single fixed location if that isn't available. It needn't support programmatically / UI for manipulating custom location, which Ripple geolocation does. I’m with you on that - but I think that is an example that works well w/o UI and other plugins may not. Let’s consider contacts, specifically pickContact. I *would* be ok with a UI of some sort, perhaps just 3 simple contacts in a list, that that user can select. In theory it could also just automatically fire contactSuccess, but my point is that I’m not opposed to it providing a bit of UI as well. As an example, I¹ve got an app now which uses barcode scanning for one small part. By adding the Browser platform to the plugin, I am able to do all of my work in the browser now and fake a barcode when I need it. That is a problem that - imo - is much more valuable than supporting browser as a destination of my app. If you just want to return a single fixed barcode, I agree BAAP should do this. If you want to be able to customize the barcode at runtime, with a simple UI that is automatically injected into your page as part of the runtime, then I think that is a task for Ripple (or other emulators). So I think this is the crux of our disagreement then. :) Right now the plugin (and I wrote this, so I may be biased ;) uses a prompt so you can enter a code. My thinking there was if you didn’t care, you would type 1 and hit enter, but if you were passing the bar code to some service, you could paste something in. To me, that’s more useful then just using a hard coded value you can’t tweak. I think that usefulness outweighs the potential ‘loss’ of being able to run this as a real web app.
Re: Summarizing thoughts on cordova-browser vs Ripple
On 11/15/14, 2:17 PM, Michal Mocny mmo...@chromium.org wrote: Ray, I think (hope) you are slightly misreading the distinction. Trying to rephrase: Ripple is an (optional) tool for mobile-device-emulation. It just happens to be implemented in a browser, and yes has historically been used by devs to run cordova apps locally in a browser. But ripple does a lot more than some devs need/want. We want to take all those extras out for cordova-browser, and leave them in for Ripple. I disagree completely. ³just so happens to be implemented in a browser² makes it sound like a random thing. Ripple was a way to make use of the speed of a browser to run my PG/Cordova apps while Œfaking¹ stuff like camera and GPS. It let me focus on the non-Cordova stuff, like random APIs (especially since it lets me bypass the remote XHR restriction w/o CORS). Specifically, cordova-browser would provide a minimum valid cordova environment plugin browser shims, just so your app loads without errors in a browser. There would not be any specific mobile device or platform emulation. Many devs do this manually today (Adobe even presented on this topic at PGDay), but cordova-browser will automate some of the work now. And I strongly vote against this. The fact that I can fake camera w/ BAAP now and not rely on Ripple, which again was dead for like a *year*, is a huge big deal to me, and I¹d argue others as well. It sounds like we are saying we should take BAAP, which has the beginnings of a good Ripple replacement, and neuter it, which I think would be horrible. What you do with the browser targeted version of your application is up to you. Some developers won't use it at all, others may use it for rapid development on a subset of the app, while others may use it to actually publically host for the mobile web. I'm not necessarily sure if that last point is a great idea, but I'm convinced we shouldn't get in the way of others trying. (Ray, if you don't want the public to use your app from a browser, just don't host it, that will be your call to make). I guess this is the main sticking point then. It sounds like you are saying we should support browser as a complete platform, and having the plugins do too much will be a problem. I think there is a chance folks may want BAAP to be used publicly, but I think a good debugging alternative would be *much more* desired. As an example, I¹ve got an app now which uses barcode scanning for one small part. By adding the Browser platform to the plugin, I am able to do all of my work in the browser now and fake a barcode when I need it. That is a problem that - imo - is much more valuable than supporting browser as a destination of my app. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: cordova-browser plugin polyfills -- which projects already have work in this space?
Not sure if it was first - I added support for it to Barcode too. :) On 11/14/14, 10:34 AM, Michal Mocny mmo...@chromium.org wrote: Ray, thanks for adding this. Using it, I found: https://github.com/Binarypark/cordova_app_version_plugin which is the first non-core plugin to claim browser support :) (which, by the way, is both crazy that it required a plugin and awesome that someone wrote the feature as a small trivial plugin and shared with the world). -Michal O - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: cordova-browser plugin polyfills -- which projects already have work in this space?
Ah - looks like the barcode scanner isn¹t updated yet. I know my PR for it was accepted. On 11/14/14, 12:07 PM, Ray Camden rayca...@adobe.com wrote: Not sure if it was first - I added support for it to Barcode too. :) On 11/14/14, 10:34 AM, Michal Mocny mmo...@chromium.org wrote: Ray, thanks for adding this. Using it, I found: https://github.com/Binarypark/cordova_app_version_plugin which is the first non-core plugin to claim browser support :) (which, by the way, is both crazy that it required a plugin and awesome that someone wrote the feature as a small trivial plugin and shared with the world). -Michal O - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: cordova-browser plugin polyfills -- which projects already have work in this space?
Sorry - what I meant was - it wasn’t refreshed. It should be now and should show up when you filter to Browser. On 11/14/14, 1:44 PM, Michal Mocny mmo...@chromium.org wrote: Wasn't re-published? On Fri, Nov 14, 2014 at 1:08 PM, Ray Camden rayca...@adobe.com wrote: Ah - looks like the barcode scanner isn¹t updated yet. I know my PR for it was accepted. On 11/14/14, 12:07 PM, Ray Camden rayca...@adobe.com wrote: Not sure if it was first - I added support for it to Barcode too. :) On 11/14/14, 10:34 AM, Michal Mocny mmo...@chromium.org wrote: Ray, thanks for adding this. Using it, I found: https://github.com/Binarypark/cordova_app_version_plugin which is the first non-core plugin to claim browser support :) (which, by the way, is both crazy that it required a plugin and awesome that someone wrote the feature as a small trivial plugin and shared with the world). -Michal O - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Summarizing thoughts on cordova-browser vs Ripple
I¹m pretty late to responding to this thread, but I wanted to throw in a few comments. In the first msg, Michal Mocny said this: Basically, browser-platform is for getting apps running in a browser (duh) with as much working functionality as possible. Its supposed to simplify the 'if cordova then dialog else alert' problem, so you can build even more of your app with just local development. Seemingly this could be used to make targeting both web and app even easier. Ripple is for instrumenting/debugging apps by manipulating plugins. Its about having a UI that reaches into geolocation or camera and controls what the plugin returns to the app. Its about re-running the same device events over and over for tracking application logic changes.² I could not disagree with the second part more. I can tell you that from my experience, the casual end user/PG developer did not see Ripple as any different from what you described in the first paragraph. Maybe I¹m not reading you right, but I honestly don¹t think most users of Ripple saw it as anything but a way to test your code in the browser. Michael Brooks said: Ideally, the Browser Platform is a production deployment environment for the web, while Ripple is debugging instrumentation that runs on the Browser Platform.² Again, I just don¹t see this. ³Production deployment²? As in - it is used by the public? I don¹t think our users will see that. I don¹t want the public to use my PG/Cordova app in the browser. I, the developer, want to use the browser just because it is quicker and the debugging tool is better. Kirupa said: Cordova-browser shouldn't be responsible for providing mock data, UI, or any additional functionality for simulating a plug-in. It¹s primary goal is to (as you both mention) be responsible for getting apps to run in the browser.² I love Ripple, butŠ It was dead for a *very* long time. It has come back, and there is activity, but I¹m not convinced it will carry on. (Don¹t get me wrong, I want it to!) BAAP (I¹m using that for Browser As A Platform, much easier to type ;) is baked into Cordova and ³just plain works² once a plugin author adds support. It isn¹t an external tool - it is part of the core functionality. I think then that if it makes sense for a plugin to do UI, then BAAP should do it. I see no reason not too. Since the only one seeing it is the developer, then this UI, or mock data, can be simple and direct. If it lets me run my app quickly in the browser, then it doesn¹t have to be production-ready, just dev-ready. Andrew said: From reading this, seems like it could work well to have plugins provide both browser and ripple implementations. They could make them the same, or have the ripple one provide some sort of nice emulation UI. e.g.² I see that as unlikely myself. If I were to write a plugin (I¹ll be honest, I haven¹t yet), I can¹t imagine doing the same thing twice for both, especially with how little movement has been done in Ripple. As a feature, isn¹t it fair to say BAAP is ³done²? I mean it needs support from more plugins, but as a feature, it is complete. I don¹t have to worry about it not working in the future as Ripple did. On 11/14/14, 12:38 PM, Horn, Julian C julian.c.h...@intel.com wrote: Yes, that's absolutely right. The ripple and browser platforms can coexist, and you can refer to the API implementations in the cordova-browser platform from the ripple platform. You can imagine how this would work. The exec call should land in the ripple implementation of the API. That code can decide whether it needs to delegate to the browser implementation of the API. (It could use UI to guide this decision.) If so, it finds the browser implementation via execProxy and invokes it. This is easy when the ripple implementation is built in. Ripple's implementation of exec separates the Services registered with Ripple from those that self-register with execProxy. Ripple therefore can prefer its own implementation when both exist. When the ripple and browser implementations are both in the same plugin then you have a conflict because both of them want to self-register as the same service. Still, I'm confident that this can be sorted out. For example, say the JS part of a plugin calls exec for service S, function F. The browser implementation self-registers with execProxy as S. The ripple implementation could self-register as Ripple S. When asked to invoke a function in service S, the Ripple exec function can look for the object registered as Ripple S before looking for the object registered as S. Easy. Julian - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [VOTE] Tools Release, take 3
Mark, question about this: To update your tools: npm install -g cordova npm install -g plugman To be clear, a Œregular¹ user doesn¹t need to update plugman, right? On 11/12/14, 10:47 AM, Mark Koudritsky kam...@google.com wrote: Please also review the updated blog post: https://github.com/cordova/apache-blog-posts/blob/master/2014-11-10-tools- release.md - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [VOTE] Tools Release, take 3
+1 to this. That was my first though - a ‘regular’ user may be confused and think they need to get this when they don’t. On 11/13/14, 9:24 AM, Josh Soref jso...@blackberry.com wrote: Ray Camden wrote: The instructions would probably benefit from if you have foo installed, use X to update it. ?B�CB� ?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?�ܙ?ݘK�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[� ?�??K[XZ[?�??]�Z?[???�ܙ?ݘK�\?X�?K�ܙ�B - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: cordova-browser plugin polyfills -- which projects already have work in this space?
This went live yesterday. Let me know if it doesn¹t work for you. On 11/5/14, 11:02 AM, Victor Sosa sosah.vic...@gmail.com wrote: Good point, Michal. It would be nice if we could browse the plugins by just filtering the platform. 2014-11-05 10:53 GMT-06:00 Michal Mocny mmo...@chromium.org: Cool! But I can't find how to do this with browse all plugins. Appears to be a filter option on search results but cannot search for * or . -- and the filter doesn't persist nor alter url for linkability. -Michal On Wed, Nov 5, 2014 at 11:46 AM, Ray Camden rayca...@adobe.com wrote: As just an FYI, plugins.cordova.io can now filter to plugins that support browser as a platform. This could be used to figure out what plugins have added support. On 11/5/14, 9:57 AM, Michal Mocny mmo...@google.com wrote: The process for implementing a browser polyfill (I'm new to this, may be missing steps), appears to be just like any other platform whose implementations are in js (like firefoxos, windows). Here is the implementation for device plugin for example: - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org -- Victor Adrian Sosa Herrera IBM Software Engineer Guadalajara, Jalisco - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: cordova-browser plugin polyfills -- which projects already have work in this space?
As just an FYI, plugins.cordova.io can now filter to plugins that support browser as a platform. This could be used to figure out what plugins have added support. On 11/5/14, 9:57 AM, Michal Mocny mmo...@google.com wrote: The process for implementing a browser polyfill (I'm new to this, may be missing steps), appears to be just like any other platform whose implementations are in js (like firefoxos, windows). Here is the implementation for device plugin for example: - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: cordova-browser plugin polyfills -- which projects already have work in this space?
Hmpth - let me look into that post lunch. On 11/5/14, 10:53 AM, Michal Mocny mmo...@chromium.org wrote: Cool! But I can't find how to do this with browse all plugins. Appears to be a filter option on search results but cannot search for * or . -- and the filter doesn't persist nor alter url for linkability. -Michal On Wed, Nov 5, 2014 at 11:46 AM, Ray Camden rayca...@adobe.com wrote: As just an FYI, plugins.cordova.io can now filter to plugins that support browser as a platform. This could be used to figure out what plugins have added support. On 11/5/14, 9:57 AM, Michal Mocny mmo...@google.com wrote: The process for implementing a browser polyfill (I'm new to this, may be missing steps), appears to be just like any other platform whose implementations are in js (like firefoxos, windows). Here is the implementation for device plugin for example: - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Genymotion on Mac for Cordova testing
Bit late in replying, but I can confirm that Cisco Anyconnect also breaks Genymotion for me. On 10/23/14, 11:04 PM, Carlos Santana csantan...@gmail.com wrote: Lisa don't use the IBM VPN when using Genymotion. I had the same problems and discovered they only occur when I was running the Cisco Anyconnect VPN software, it changes the network settings makeing virtual box and the internal vlans get confused. If you disconnect the VPN, and try again the the virtual image runs fine and is able to find the host network/vlan. hope this is your problem and helps you. --Carlos - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
project version info
I¹m posting this here as opposed to the Google Group as it seems like the type of thing that may have been discussed, then turned down, and I figured this list was best to answer why. Unless I¹m not seeing it, there is no way to tell what version of the CLI was used to build a project. Oddly ³cordova info² will return Cordova version, but for me, the # makes no sense. Here is one I got with a recent project: 0.21.13. Is there a reason why 3.6.3 isn¹t returned and not saved in config.xml? I¹m assuming it is because plugin version info is more important, but I can definitely seeing wanting to know what CLI version was used. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: project version info
Thanks for the detailed response Michal. With your permission, I¹d like to reprint this on my blog. I will point out however that there was at least one time when the directory structure change broke something. I forget which version it was but at some point the CLI stopped making a .cordova folder and that broke Ripple. Not really a big deal, just FYI. ;) On 10/3/14, 9:58 AM, Michal Mocny mmo...@chromium.org wrote: The reason CLI is reporting that number is because we tried to go semver in an odd way (CAD-SEM) and CLI version was supposed to be just the SEM part and the CAD was just informational -- which hasn't worked out so well. The next CLI release is going to drop the old SEM and turn the existing CAD into the new SEM. i.e.: npm install -g cordova@rc you'll notice that its just 3.7.0. w.r.t. reporting installed version and not workspace created version: the version of the CLI that was used to create a project should not be what is important. Its the current versions of the platforms and plugins within your workspace that are actually important. This is because when you upgrade your CLI, we will not use the version that was used to create the project any more. There have been proposals for this, but its not implemented, we just assume you always want the latest CLI to manage your workspace. This could become an issue if the CLI breaks compatibility with directory structure / old platform/plugin structure, but that hasn't come up yet. If that *does* happen, we can introduce a created-with at that point, and use the lack of created-with as a signal for old version. For what its worth, for cca we drop a created-with-cca-version file inside your platforms/ folder, since we currently also pin platforms. When you upgrade your cca tool, we then know to prompt for a platforms upgrade. I don't know if this will still be necessary with independent platform releases. -Michal - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: project version info
Josh, we have this discussion already. I was asking to quote Michal, not you. I understand my blog entry may not be to your liking, but you are not my audience. My audience (in this case) is PG/Cordova devs outside the list. In fact, this thread started from a question asked on Twitter this morning, and I was looking to help out a user with a firm answer. On 10/3/14, 10:39 AM, Josh Soref jso...@blackberry.com wrote: I'd like to repeat that I don't like quoting text in blogs. It's unhelpful. Writing a summary is much more helpful. I do not want to be quoted. Nor do I as a developer want to read/parse quotes. I do not want to spend time parsing quotations/determining context. As a developer, I want to know what to do, and what I should understand. On 10/3/14, 11:37 AM, Ray Camden rayca...@adobe.com wrote: Thanks for the detailed response Michal. With your permission, I¹d like to reprint this on my blog. I will point out however that there was at least one time when the directory structure change broke something. I forget which version it was but at some point the CLI stopped making a .cordova folder and that broke Ripple. Not really a big deal, just FYI. ;)
Re: Cordova and OS X 10.10 Yosemite GM
I¹ll tell you now. On 10/1/14, 1:27 AM, Abdul Rahaman a.raha...@onnect.net wrote: Hi guys, I was wondering if Corodva will work fine with Yosemite GM. I was about to update from my Mavericks to Yosemite GM. Best regards, AR
Re: Cordova and OS X 10.10 Yosemite GM
All I did was make a virgin project, add ios, and send to emulator, and it worked. That isn¹t a terribly deep test, but there ya go. On 10/1/14, 1:27 AM, Abdul Rahaman a.raha...@onnect.net wrote: Hi guys, I was wondering if Corodva will work fine with Yosemite GM. I was about to update from my Mavericks to Yosemite GM. Best regards, AR
Re: 3.6 cordova plugin versions
No one complained, so I assume it is perfect. ;) Seriously though - feel free to comment on the blog if you have suggestions. On 9/30/14, 4:35 PM, Ray Camden rayca...@adobe.com wrote: Any comments folks? https://gist.github.com/cfjedimaster/b689cbf528cddaa2391a On 9/30/14, 11:57 AM, Michal Mocny mmo...@chromium.org wrote: I'm not an expert on engine requirements, but I'm happy to review your post. -Michal On Tue, Sep 30, 2014 at 12:41 PM, Ray Camden rayca...@adobe.com wrote: Ah, good point there. I¹m going to write up a blog post on this after I run some errands. I¹d love a quick review from you, or anyone, before I publish. I¹m also going to add something to the core docs.
Re: 3.6 cordova plugin versions
oh - I didn’t see your comment Shaz. Thanks! On 10/1/14, 9:33 AM, Ray Camden rayca...@adobe.com wrote: No one complained, so I assume it is perfect. ;) Seriously though - feel free to comment on the blog if you have suggestions. On 9/30/14, 4:35 PM, Ray Camden rayca...@adobe.com wrote: Any comments folks? https://gist.github.com/cfjedimaster/b689cbf528cddaa2391a On 9/30/14, 11:57 AM, Michal Mocny mmo...@chromium.org wrote: I'm not an expert on engine requirements, but I'm happy to review your post. -Michal On Tue, Sep 30, 2014 at 12:41 PM, Ray Camden rayca...@adobe.com wrote: Ah, good point there. I¹m going to write up a blog post on this after I run some errands. I¹d love a quick review from you, or anyone, before I publish. I¹m also going to add something to the core docs.
Re: 3.6 cordova plugin versions
Does it make sense to clarify that statement though? Not *every* plugin is tested like this, just the ³Core² set of Cordova plugins. If someone has a random plugin for Cowbell, there is no guarantee that it will work on _any_ release, right? (I know we were talking about core plugins, but I just wanted to be sure.) On 9/30/14, 9:04 AM, Shazron shaz...@gmail.com wrote: Yes On Monday, September 29, 2014, Joshi, Pavankumar jos...@fast.au.fujitsu.com wrote: Thanks for the mail. Kindly can you clarify this question, So every time a new version of plugin is released, is it tested with the already released latest Cordova version. Example: In Cordova 3.6 release it is stated that battery-status plugin version 0.2.10 is tested. Then on 22 September 0.2.11 version of battery-status plugin was released. So does it mean that 0.2.11 version was tested with 3.6.0 version of Cordova ? I am asking this because if I download and use Cordova 3.6.0 release, then can I continuously upgrade the plugins to the latest released version? Thanks and Regards Pavan Joshi -Original Message- From: Shazron [mailto:shaz...@gmail.com javascript:;] Sent: Monday, 29 September 2014 4:59 PM To: dev@cordova.apache.org javascript:; Subject: Re: 3.6 cordova plugin versions Plugins are independently released and not tied to a particular version. That just shows it was tested with that version. Just use the latest versions. On Sun, Sep 28, 2014 at 11:41 PM, Joshi, Pavankumar jos...@fast.au.fujitsu.com javascript:; wrote: Sorry, But then why the news section of plugins, http://cordova.apache.org/announcements/2014/09/22/cordova-361.html, still has an older version? In Cordova 3.6 release page it says Plugin versions tested with this release cordova-plugin-battery-status: 0.2.10 cordova-plugin-camera: 0.3.1 cordova-plugin-console: 0.2.10 cordova-plugin-contacts: 0.2.12 cordova-plugin-device: 0.2.11 cordova-plugin-device-motion: 0.2.9 cordova-plugin-device-orientation: 0.3.8 cordova-plugin-dialogs: 0.2.9 cordova-plugin-file: 1.3.0 cordova-plugin-file-transfer: 0.4.5 cordova-plugin-geolocation: 0.3.9 cordova-plugin-globalization: 0.3.0 cordova-plugin-inappbrowser: 0.5.1 cordova-plugin-media: 0.2.12 cordova-plugin-media-capture: 0.3.2 cordova-plugin-network-information: 0.2.11 cordova-plugin-splashscreen: 0.3.2 cordova-plugin-statusbar: 0.1.7 cordova-plugin-vibration: 0.3.10
Re: 3.6 cordova plugin versions
Just being annoying. ;) I can see this type of question though being something users will bring up. On 9/30/14, 9:46 AM, Shazron shaz...@gmail.com wrote: He didnt ask that question, but Ray: yes. On Tuesday, September 30, 2014, Ray Camden rayca...@adobe.com wrote: Does it make sense to clarify that statement though? Not *every* plugin is tested like this, just the ³Core² set of Cordova plugins. If someone has a random plugin for Cowbell, there is no guarantee that it will work on _any_ release, right? (I know we were talking about core plugins, but I just wanted to be sure.) On 9/30/14, 9:04 AM, Shazron shaz...@gmail.com javascript:; wrote:
Re: 3.6 cordova plugin versions
I don¹t have an answer, but I definitely see merit in documenting this here: http://cordova.apache.org/docs/en/3.6.0/cordova_plugins_pluginapis.md.html# Plugin%20APIs (replace 3.6.0 with ³most current² of course) We should clarify expectations for when/how the core plugins are tested in regards to the main Cordova release. I¹ll happily write something up. On 9/30/14, 10:16 AM, Fischer, Paul A paul.a.fisc...@intel.com wrote: But it is not wise to assume that the latest version of a core plugin is also tested against an older version of Cordova CLI? Is that true or false? In other words, when you test the latest version of a core plugin, you only test it against the latest released version of the Cordova CLI. Using the latest version of a core plugin is not guaranteed to work with a prior version of Cordova CLI. Are my assumptions correct or incorrect? -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Tuesday, September 30, 2014 07:05 To: dev@cordova.apache.org Subject: Re: 3.6 cordova plugin versions Yes On Monday, September 29, 2014, Joshi, Pavankumar jos...@fast.au.fujitsu.com wrote: Thanks for the mail. Kindly can you clarify this question, So every time a new version of plugin is released, is it tested with the already released latest Cordova version. Example: In Cordova 3.6 release it is stated that battery-status plugin version 0.2.10 is tested. Then on 22 September 0.2.11 version of battery-status plugin was released. So does it mean that 0.2.11 version was tested with 3.6.0 version of Cordova ? I am asking this because if I download and use Cordova 3.6.0 release, then can I continuously upgrade the plugins to the latest released version? Thanks and Regards Pavan Joshi
Re: 3.6 cordova plugin versions
Query - why isn¹t engine data shown on plugins.cordova.io? That seems like crucial data that should be displayed, right? On 9/30/14, 10:59 AM, Michal Mocny mmo...@chromium.org wrote: In theory, we should know when plugins depend on a certain minimum platform version, and even have a plugin.xml tag to specify this (engine), though its a bit indirect and in practice I'm not sure that the requirements are well specified (many plugins just say = 3.0.0).
Re: 3.6 cordova plugin versions
Ah - never mind. I picked a plugin that didn’t have it specified. I picked another random one and it *was* shown. I’d say that for plugins w/o engine support, the site should still say something, even if Engine Number Not Specified On 9/30/14, 11:09 AM, Ray Camden rayca...@adobe.com wrote: Query - why isn¹t engine data shown on plugins.cordova.io? That seems like crucial data that should be displayed, right? On 9/30/14, 10:59 AM, Michal Mocny mmo...@chromium.org wrote: In theory, we should know when plugins depend on a certain minimum platform version, and even have a plugin.xml tag to specify this (engine), though its a bit indirect and in practice I'm not sure that the requirements are well specified (many plugins just say = 3.0.0).
Re: 3.6 cordova plugin versions
Ah, good point there. I¹m going to write up a blog post on this after I run some errands. I¹d love a quick review from you, or anyone, before I publish. I¹m also going to add something to the core docs. On 9/30/14, 11:18 AM, Michal Mocny mmo...@chromium.org wrote: That sounds reasonable. The engine tag is a bit weird though, in that the dependency is on cli and not platform version. Combined with CLI semver and platform release unbundling, its a bit hard to reason about. It kinda still works because we have default platform versions pinned to cli versions, but users can explicitly install non-default platform versions if they chose, and plugins may have support for only a subset of platforms.. -Michal On Tue, Sep 30, 2014 at 12:11 PM, Ray Camden rayca...@adobe.com wrote: Ah - never mind. I picked a plugin that didn¹t have it specified. I picked another random one and it *was* shown. I¹d say that for plugins w/o engine support, the site should still say something, even if Engine Number Not Specified
Re: 3.6 cordova plugin versions
Any comments folks? https://gist.github.com/cfjedimaster/b689cbf528cddaa2391a On 9/30/14, 11:57 AM, Michal Mocny mmo...@chromium.org wrote: I'm not an expert on engine requirements, but I'm happy to review your post. -Michal On Tue, Sep 30, 2014 at 12:41 PM, Ray Camden rayca...@adobe.com wrote: Ah, good point there. I¹m going to write up a blog post on this after I run some errands. I¹d love a quick review from you, or anyone, before I publish. I¹m also going to add something to the core docs.
Re: [echo] Adding platform: browser [exec] npm http GET https://registry.npmjs.org/cordova-browser [exec] npm http 200 h[exec] Unable to fetch platform browser: Error: No compatible version found: cor
Yes - will be fixed in next release. For now, do this: cordova platform add browser ‹usegit On 9/26/14, 4:55 AM, Axel Nennker ignisvul...@gmail.com wrote: Hi, is this a glitch? I am running 3.6.3-0.2.13 and get this output when trying to use browser as a platform. [echo] Adding platform: browser [exec] npm http GET https://registry.npmjs.org/cordova-browser [exec] npm http 200 https://registry.npmjs.org/cordova-browser [exec] Unable to fetch platform browser: Error: No compatible version found: cordova-browser@'master' [exec] Valid install targets: [exec] [3.5.0,3.5.1,3.5.2] thanks Axel
Re: cordova camera.getpicture is not working with backbone/requireJS
Hey Frank, this list is for people who are developing Cordova itself, not
for general tech support. Please use this Google Group:
https://groups.google.com/forum/#!forum/phonegap
On 9/26/14, 10:13 AM, Frank He hexuf...@gmail.com wrote:
This is a very annoying issue, I am using cordova with backbone to build
hybrid solution, and I want user to select photo to upload. please see
following code:
events:{
click #btnPhotos: getPhoto,
click #btnCamera: capturePhoto
},
Re: Who is going to Chrome Dev Summit Nov19-20?
Joined the waiting list. No way I can get budget to attend, but figured I¹d try. ;) Happy to see they are streaming everything though. On 9/25/14, 1:40 PM, Carlos Santana csantan...@gmail.com wrote: I was able to get a ticket [1] to attend. Now waiting on corporate travel approval ... It will be awesome to meet with committers, contributors, end users of Cordova while there. [1]: http://developer.chrome.com/devsummit -- Carlos Santana csantan...@gmail.com
Re: [Vote] Tools Release 3.6.3-0.2.13
Odd - when I went to docs.cordova.io, it defaulted to 3.5. 3.6 is available in the dropdown, but not the default. On 9/22/14, 10:26 AM, Marcel Kinard cmarc...@gmail.com wrote: 3.6.3 is now live in npm, docs, and dist. Michael Brooks, could you update the link from docs.cordova.io? I looked at [1], but the VERSION file is currently set to 3.4.0, so I'm not sure if this location is still accurate to make the update, or if it is just missing a push. Steve (or someone that has access to the @apachecordova account) could you tweet it? And do you also have access to the G+ account to post there also? Thanks! [1] https://git-wip-us.apache.org/repos/asf?p=cordova-labs.git;a=shortlog;h=re fs/heads/docs-cordova-io On Sep 19, 2014, at 6:05 PM, Marcel Kinard cmarc...@gmail.com wrote: The vote has now closed. The results are: Positive Binding Votes: 4 - Mark Koudritsky - Bryan Higgins - Sergey Grebnov - Marcel Kinard Negative Binding Votes: 0 The vote has passed. I don't think it is a good idea for a significant upgrade to go live on a Friday evening, so I will wait until Monday morning to flip the switch on this in the npm registry and elsewhere. Thanks, everyone! On Sep 18, 2014, at 4:54 PM, Marcel Kinard cmarc...@gmail.com wrote: Please review and vote on this Tools Release. I believe this is the last redo of the long effort to get 3.6 out the door. Compared to the earlier vote, I cleaned up the shrinkwrap so the devDependencies don't get installed. Because I wanted to verify that it works, I published these RCs to npm under an rc tag, so you can do npm -g install cordova@rc and you should the versions as listed below. Release issue: https://issues.apache.org/jira/browse/CB-7383
Re: [Vote] Tools Release 3.6.3-0.2.13
Hmm - first thing I tried with Cordova 3.6.3 was to add browser as a platform. Unable to fetch platform browser: Error: No compatible version found: cordova-browser@'master' Valid install targets: [3.5.0,3.5.1,3.5.2] I¹ll file a report. On 9/22/14, 10:34 AM, Ray Camden rayca...@adobe.com wrote: Odd - when I went to docs.cordova.io, it defaulted to 3.5. 3.6 is available in the dropdown, but not the default.
Re: [Vote] Tools Release 3.6.3-0.2.13
Oh ok - was just noting the difference in default. :) On 9/22/14, 10:52 AM, Marcel Kinard cmarc...@gmail.com wrote: Correct. The redirect from docs.cordova.io needs to be updated per my original note below, and the only person with the keys to update the redirect is Michael B. On Sep 22, 2014, at 11:34 AM, Ray Camden rayca...@adobe.com wrote: Odd - when I went to docs.cordova.io, it defaulted to 3.5. 3.6 is available in the dropdown, but not the default. On 9/22/14, 10:26 AM, Marcel Kinard cmarc...@gmail.com wrote: Michael Brooks, could you update the link from docs.cordova.io? I looked at [1], but the VERSION file is currently set to 3.4.0, so I'm not sure if this location is still accurate to make the update, or if it is just missing a push.
Re: new NPM 2.x
Being lazy, but can you explain why it matters? Ie, is there a reason *not* to just upgrade? I assume most folks would think, ³new version of npm, just update and don¹t worry about it² - but does it impact using Cordova? On 9/22/14, 11:09 AM, Carlos Santana csantan...@gmail.com wrote: NPM 2.x was released last week. latest nodejs stable 0.10.32 comes with npm@1.4.28 if you do $ npm install -g npm (you will get npm@2.0.0) More about npm 2.x and semver: http://blog.npmjs.org/post/98131109725/npm-2-0-0 cordova and phonegap get's mentioned in the blog post. For now just pay close attention which npm you are using 1.x or 2.x with $ npm -v -- Carlos Santana csantan...@gmail.com
Re: new NPM 2.x
Gotcha. So not an issue for end users of Cordova - but perhaps for plugin authors. On 9/22/14, 11:34 AM, Ian Clelland iclell...@chromium.org wrote: It shouldn't matter for users, but I have seen several issues in the past where using the wrong version of npm means that you can't publish modules or plugins. It's something to be aware of, at least. On Mon, Sep 22, 2014 at 12:30 PM, Ray Camden rayca...@adobe.com wrote: Being lazy, but can you explain why it matters? Ie, is there a reason *not* to just upgrade? I assume most folks would think, ³new version of npm, just update and don¹t worry about it² - but does it impact using Cordova? On 9/22/14, 11:09 AM, Carlos Santana csantan...@gmail.com wrote: NPM 2.x was released last week.
RE: getting tired of using mouse to open safari to inspect and magic path for livereload
Try GapDebug. It will try to reconnect on app relaunch. Plus, it lets you do the iOS stuff in Chrome, not Safari. From: Carlos Santana csantan...@gmail.com Sent: Friday, August 22, 2014 10:31 AM To: dev@cordova.apache.org Subject: getting tired of using mouse to open safari to inspect and magic path for livereload I was going down the rabbit whole to see if there is a way I can launch the safari debugger after doing a cordova emulate ios, and maybe adding a cli command cordova inspect ios
RE: Is there a decent Getting Started guide without prerequisite loops?
I just went through this myself the past weekend. I did: Android SDK During that install, it noticed I didn't have Java (this was a VM) and it linked me to install that. Apache ANT Git Node.js (for npm) Then finally npm install -g cordova. That's it. From: Matteo Sisti Sette matteosistise...@gmail.com Sent: Friday, August 22, 2014 9:48 AM To: dev@cordova.apache.org Subject: Is there a decent Getting Started guide without prerequisite loops? Hi, I was looking for a Getting Started kind of guide for developing in Cordova for the Android platform, but I've found myself trapped in a loop of links where page A links you to page B to install something that is a requirement, and page B links you back to page A to install something that is a requirement. More details here: https://issues.apache.org/jira/browse/CB-7369 Is there ANYWHERE a simple monolythic step-by-step install guide without infinite requirement loops? Thanks m.
RE: What's Stopping us From Independent Platform Releases
I'll echo the issues I raised before. If the docs say that so and so is supported, but it is for edge and not the current release, I think that would be a huge mistake. I consider myself a pretty good Cordova dev and I think even I would be confused as well. (I almost never run anything but the released version so I can be sure what I blog, help folks with, etc, matches the released version.) Please, please, please do not do this. Why can't the docs simply be updated w/o updating the bits? Is that really the case? If so, fix *that* bug. From: Steven Gill stevengil...@gmail.com Sent: Wednesday, August 20, 2014 3:59 PM To: dev@cordova.apache.org Subject: Re: What's Stopping us From Independent Platform Releases I still feel it would be a mistake to stop versioning our docs. It would confuse our users. It is a norm for projects to have docs associated to specific versions. I think docs should be versioned when the cli gets released and docs.cordova.io should always point to edge. This would address the splashscreen docs not being live even though the feature has shipped. This use case can also handle us introducing breaking changes (ex: android 4.0) and not have to keep older docs on edge. Annotating with supported in android 3.6.0+ can start looking very ugly over time if we have lots of annotations all over the place. As for previous versions, bugs most likely won't be fixed unless it is something someone volunteers to do. I don't see much value in updating old versions of docs. But it is worth still having them available for people using those versions. I'd like to hear what others think about this? Both proposals are described at https://issues.apache.org/jira/browse/CB-7226
RE: What's Stopping us From Independent Platform Releases
Freaking Outlook kinda munged my reply, so I'll keep my replies on top. When I saw edge, I thought that meant *post* release. Err, I mean what's coming next. I've never read edge as being the current release. So if I'm wrong, and it sounds like i am,you can disregard everything I said. :) For either option, edge would be equivalent to latest released work. Even if you make changes on master for cordova-docs, it wouldn't be pushed to edge unless we were doing a docs release and the feature was being released. This is definitely something we need to keep track of. I don't think we have been bitten by this before though and don't imagine it being a big problem with either option and setting default docs to edge. Moving platform docs to platform repos and grabbing them at build time for docs would hopefully prevent this type of situation from arising. Please, please, please do not do this. Why can't the docs simply be updated w/o updating the bits? Is that really the case? If so, fix *that* bug. I'm not sure I understand what you mean by above? The reason we are needing to switch docs is because we are not doing cadence releases after 3.6.0. So either we have docs live with no version or we version it along side the CLI. Ex. CLI could be at version 5, cordova-firefox could be at version 3.7.0, cordova-android could be at version 4.2, etc. What would the versions of docs be? From: Steven Gill stevengil...@gmail.com Sent: Wednesday, August 20, 2014 3:59 PM To: dev@cordova.apache.org Subject: Re: What's Stopping us From Independent Platform Releases I still feel it would be a mistake to stop versioning our docs. It would confuse our users. It is a norm for projects to have docs associated to specific versions. I think docs should be versioned when the cli gets released and docs.cordova.io should always point to edge. This would address the splashscreen docs not being live even though the feature has shipped. This use case can also handle us introducing breaking changes (ex: android 4.0) and not have to keep older docs on edge. Annotating with supported in android 3.6.0+ can start looking very ugly over time if we have lots of annotations all over the place. As for previous versions, bugs most likely won't be fixed unless it is something someone volunteers to do. I don't see much value in updating old versions of docs. But it is worth still having them available for people using those versions. I'd like to hear what others think about this? Both proposals are described at https://issues.apache.org/jira/browse/CB-7226
RE: What's Stopping us From Independent Platform Releases
Keep in mind - the average developer probably has no idea what cordova-ios, cordova-cli, and cordova-lib means. They npm install cordova, and to them, that's it. From: Carlos Santana csantan...@gmail.com Sent: Wednesday, August 20, 2014 7:54 PM To: dev@cordova.apache.org Subject: Re: What's Stopping us From Independent Platform Releases I think we need to come down to the same conclusion as we did for plugins. The documentation for each component meaning cordova-ios, cordova-cli, cordova-lib needs to live with it's repo/code and version together. The remaining things can be left in cordova-docs that are independent of a version of a component to an extent like security guide. The Cordova Docs Website will need to have a new UX design to make sense of where links point and somehow allow the user know what's the latest release and the different components with each respective version.
RE: Chrome-axiom
Do you have an external URL? :) From: Andrew Grieve agri...@google.com Sent: Tuesday, August 12, 2014 10:49 AM To: dev Subject: Chrome-axiom New mailinglist that it may be worth joining. Chrome Axiom is the Chrome Developer Tooling platform. We're building the well lit path for web developers to succeed. http://goto/chrome-axiom
When is .cordova created?
(This question feels like it *should* be appropriate here, but if I should raise it on the PG Google group, I will.) I recently released a Brackets extension that wrapped calls to the Cordova CLI. I wrote some simple logic to handle checking if a folder is a Cordova project. I simply looked for a subdirectory called .cordova. But a user told me the extension wasn't correctly seeing a Cordova project and when I tested, it looks like the default cordova create command will not make the folder. It only exists (so far in my testing) if I create a new project and use --copy-from. Is there a reason why .cordova doesn't always exist? Worse comes to worse, I may just use some logic to see if platforms, plugins, and www exist as subdirectories.
RE: When is .cordova created?
Thanks all for the replies. For now, I'm simply going to look for the common
subdirectories (hook, plugins, platforms, and www) as a means of sniffing if
the project is a Cordova project.
From: mmo...@google.com mmo...@google.com on behalf of Michal Mocny
mmo...@chromium.org
Sent: Monday, July 21, 2014 1:42 PM
To: dev
Subject: Re: When is .cordova created?
That directory is optional. It will only exist if you have non standard
config options. When using --link-to and --copy-from, we set the config
option { lib: { www: { uri: ..., link: true/false } } }. We also set
config settings for e.g. Custom platform paths and plugin search paths.
RE: Pointing docs to edge
Personally I'd rather not have any coming soon paragraphs in the doc text. As a user, if I'm at the docs, I don't care what is coming next. I'm trying to solve a problem I have *now*, or trying to build now. Anything that is coming soon is a distractor. Do I feel strongly about it? No, but I'd vote against it being in the docs at all. Stuff like that should definitely be communicated to users - via the Cordova blog perhaps - but not in the mainline docs. From: m...@google.com m...@google.com on behalf of Max Woghiren m...@chromium.org Sent: Monday, July 14, 2014 10:27 AM To: dev Subject: Re: Pointing docs to edge Okay, so here are the current proposals for handling Ray's issue (thanks Ray!): 1. Update docs at commit-time and release-time. At commit-time, documentation changes can be marked with coming soon, or removed in next release, or whatever the relevant message is. At release-time, docs are further updated to remove these sub-messages. 2. Use CSS to do the manual marking in proposal 1. We could also use it to
RE: recent tools update, Splash screen support
Thank you - I finally get what the change was now. ;) From: Axel Nennker ignisvul...@gmail.com Sent: Sunday, July 13, 2014 11:17 AM To: dev Subject: Re: recent tools update, Splash screen support https://github.com/AxelNennker/cordova-docs/commit/a7b2f371c3d051a5a9d4818f3f9c9cb0eb5c57be Axel Sorry about the ton of changed files. I did a git fetch upstream today and then a merge and push to my repo... I wish I could delete my fork and start over but github does not allow this... 2014-07-13 17:56 GMT+02:00 Ray Camden rayca...@adobe.com: There are 500+ files changed with this PR - can you point to any specific files that would be helpful? From: Axel Nennker ignisvul...@gmail.com Sent: Sunday, July 13, 2014 10:50 AM To: dev Subject: Re: recent tools update, Splash screen support A pull request is here: https://github.com/apache/cordova-docs/pull/219 -Axel 2014-07-12 15:12 GMT+02:00 Ray Camden rayca...@adobe.com: Just raising this again - are there docs for this? From: Ray Camden rayca...@adobe.com Sent: Friday, July 11, 2014 5:46 AM To: dev@cordova.apache.org Subject: RE: recent tools update, Splash screen support So basically the docs are *not* up to the date for any of this yet? From: Sergey Grebnov (Akvelon) v-seg...@microsoft.com Sent: Friday, July 11, 2014 1:15 AM To: dev@cordova.apache.org Subject: RE: recent tools update, Splash screen support I volunteer to test splash/icons support one more time and update the docs where it is required. * The old documentation refers to PG Build. Cordova implementation is based on this idea, but there are some differences, for example we don't support gap: prefix and platform attribute, platform specific icons must be placed inside corresponding platform name='' element * We updated icons related docs as part of Cordova icons support implementation, I will double check that it is still accurate (for example I see that it mentions platform attribute which is not supported) * We should update splash screen related docs part (as per our implementation + examples) * Splash screen plugin and splash screen images support are related but different features. Core splash screen support by CLI allows replacing default template images which are showed automatically, where the plugin works on top of this and allows programmatically show/hide splash screen (pls correct me if I'm wrong).
RE: recent tools update, Splash screen support
Just raising this again - are there docs for this? From: Ray Camden rayca...@adobe.com Sent: Friday, July 11, 2014 5:46 AM To: dev@cordova.apache.org Subject: RE: recent tools update, Splash screen support So basically the docs are *not* up to the date for any of this yet? From: Sergey Grebnov (Akvelon) v-seg...@microsoft.com Sent: Friday, July 11, 2014 1:15 AM To: dev@cordova.apache.org Subject: RE: recent tools update, Splash screen support I volunteer to test splash/icons support one more time and update the docs where it is required. * The old documentation refers to PG Build. Cordova implementation is based on this idea, but there are some differences, for example we don't support gap: prefix and platform attribute, platform specific icons must be placed inside corresponding platform name='' element * We updated icons related docs as part of Cordova icons support implementation, I will double check that it is still accurate (for example I see that it mentions platform attribute which is not supported) * We should update splash screen related docs part (as per our implementation + examples) * Splash screen plugin and splash screen images support are related but different features. Core splash screen support by CLI allows replacing default template images which are showed automatically, where the plugin works on top of this and allows programmatically show/hide splash screen (pls correct me if I'm wrong).
RE: Pointing docs to edge
Is edge what people use when they get the latest version of cordova or a plugin? If not, I'd strongly argue against it. If I download the Camera plugin, I expect the default docs to match whats shipped in that version. From: m...@google.com m...@google.com on behalf of Max Woghiren m...@chromium.org Sent: Friday, July 11, 2014 10:46 AM To: dev Subject: Pointing docs to edge Just wanted to bring back this conversation—how does everyone feel about switching docs.cordova.io to point to edge? There has been some discussion about cutting versioned docs after 3.5.0, and we're approaching a good time to do it. :)
RE: Pointing docs to edge
Ok, so let me rephrase then. Imagine the next version of the CLI adds cowbell support: cordova cowbell --epic but this is NOT in the release version. If I go to docs.cordova.io, click on The Command Line Interface, will I see cowbell documented? If so, I think that is a mistake. From: agri...@google.com agri...@google.com on behalf of Andrew Grieve agri...@chromium.org Sent: Friday, July 11, 2014 11:39 AM To: dev Subject: Re: Pointing docs to edge Yeah, plugin docs are already gone from docs.cordova.io. This change is strictly for guides platform docs. The main motivation here is that it doesn't make sense to have versioned docs if platform versions diverge anyways. It actually already makes little sense for the tools guides, since they are released more often the platforms. On Fri, Jul 11, 2014 at 12:36 PM, Max Woghiren m...@chromium.org wrote: My understanding is that plugin docs live in plugin repos and will be versioned alongside the plugins themselves. They'll be removed from docs.cordova.io. On Fri, Jul 11, 2014 at 11:49 AM, Ray Camden rayca...@adobe.com wrote: Is edge what people use when they get the latest version of cordova or a plugin? If not, I'd strongly argue against it. If I download the Camera plugin, I expect the default docs to match whats shipped in that version. From: m...@google.com m...@google.com on behalf of Max Woghiren m...@chromium.org Sent: Friday, July 11, 2014 10:46 AM To: dev Subject: Pointing docs to edge Just wanted to bring back this conversation—how does everyone feel about switching docs.cordova.io to point to edge? There has been some discussion about cutting versioned docs after 3.5.0, and we're approaching a good time to do it. :)
recent tools update, Splash screen support
I'm a bit behind on the recent tooling update so forgive me if this is a dumb question. The very first item listed is: Support for splash screens Which is odd since I thought splash screens had been available for some time now. We've had an API to hide show them. We've also had documented ways to include them for a while - http://cordova.apache.org/docs/en/3.4.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens Going into the details in the blog post we see: CB-3571, CB-2606 support for splashscreens Ok, so CB-2606 is Add support for icon elements in config.xml. If it relates to this update, I don't see how, and the blog post doesn't say how it does. CB-3571 is definitely better: Add support for splash elements in config.xml. But this isn't documented here: http://cordova.apache.org/docs/en/3.5.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens nor here: http://cordova.apache.org/docs/en/3.5.0/config_ref_index.md.html#The%20config.xml%20File So while I can guess there is a new splash option for config.xml, where would our users get the specifics?
RE: Ajax search API on plugins.cordova.io
Am I right in seeing there isn't a search API then? If not, I'll continue to hit the URL I was using. From: Victor Sosa sosah.vic...@gmail.com Sent: Tuesday, July 08, 2014 8:45 AM To: dev@cordova.apache.org Subject: Re: Ajax search API on plugins.cordova.io Hello Folks. I've found it out that in the plugins.cordova.io page makes calls to this one: http://registry.cordova.io/. In fact, for you to get all the plugins information, you should point to http://registry.cordova.io/-/all, you'll get a JSON response with all the plugins.
Ajax search API on plugins.cordova.io
Is there an official API for plugins.cordova.io? I see I can hit http://plugins.cordova.io/_list/search/search?startkey=%22dialogs%22endkey=%22dialogsZZ%22limit=25 and get a response back but is there something more official then that?
RE: Ajax search API on plugins.cordova.io
Definitely not CORS enabled from what I can see in the dev tools. But I'm calling from Brackets so it shouldn't matter. From: Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com Sent: Monday, July 07, 2014 5:00 PM To: dev@cordova.apache.org Subject: RE: Ajax search API on plugins.cordova.io Also, is this CORS enabled so that other websites can use this official API ? -Original Message- From: Ray Camden [mailto:rayca...@adobe.com] Sent: Monday, July 7, 2014 2:58 PM To: dev@cordova.apache.org Subject: Ajax search API on plugins.cordova.io Is there an official API for plugins.cordova.io? I see I can hit http://plugins.cordova.io/_list/search/search?startkey=%22dialogs%22endkey=%22dialogsZZ%22limit=25 and get a response back but is there something more official then that?
RE: Ajax search API on plugins.cordova.io
Not so much concerned with the code part - I'm more concerned about if I should be hitting the URL. :) From: Anis KADRI anis.ka...@gmail.com Sent: Monday, July 07, 2014 5:38 PM To: dev@cordova.apache.org Subject: Re: Ajax search API on plugins.cordova.io But if you're looking for search specifically you can take a look at how Steve did it in the plugins site http://goo.gl/pxKE49 On Mon, Jul 7, 2014 at 6:31 PM, Anis KADRI anis.ka...@gmail.com wrote: https://github.com/imhotep/npmjs.org should work On Mon, Jul 7, 2014 at 6:13 PM, Ray Camden rayca...@adobe.com wrote: Definitely not CORS enabled from what I can see in the dev tools. But I'm calling from Brackets so it shouldn't matter. From: Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com Sent: Monday, July 07, 2014 5:00 PM To: dev@cordova.apache.org Subject: RE: Ajax search API on plugins.cordova.io Also, is this CORS enabled so that other websites can use this official API ? -Original Message- From: Ray Camden [mailto:rayca...@adobe.com] Sent: Monday, July 7, 2014 2:58 PM To: dev@cordova.apache.org Subject: Ajax search API on plugins.cordova.io Is there an official API for plugins.cordova.io? I see I can hit http://plugins.cordova.io/_list/search/search?startkey=%22dialogs%22endkey=%22dialogsZZ%22limit=25 and get a response back but is there something more official then that?
RE: Questions about FileSystem documentation and paths
If you want to move this to comments on the blog entry, that would be cool. Can you explain a bit more? I'm not seeing which step Oh... so resolveLocalFileSystemURL will call the second argument on success and the third on failure. Yeah - that's significant enough for me to rewrite the sample and blog post. From: agri...@google.com agri...@google.com on behalf of Andrew Grieve agri...@chromium.org Sent: Wednesday, July 02, 2014 8:20 PM To: dev Subject: Re: Questions about FileSystem documentation and paths Thanks for putting together this blog post Ray! Assume this is addressed in https://github.com/apache/cordova-plugin-file/pull/59? (Which is an awesome change! Thanks Kerri!) As a nit: you can simplify your code a bit by skipping the .getFile() call: resolveLocalFileSystemURL(cordova.file.dataDirectory + fileName, appStart, downloadAsset) On Sun, Jun 29, 2014 at 1:04 PM, Ray Camden rayca...@adobe.com wrote: Hey folks - I originally raised this on the Google Group as I assumed it was just an issue w/ my code, but I believe this is a documentation issue so I'm raising it here. If wrong, let me know. :) I'm working on a set of of demos related to the FileSystem feature to answer a series of FAQs risen on my blog. For my first sample app, I wanted to build something simple: Check for a file on the device. If not there, fetch it. Looking at the docs for the FileSystem important dirs, I assumed that cordova.file.applicationStorageDirectory made the most sense. The docs say it is: Root of app's private writable storage. Note the words private and writable. In my mind that was: I can write to it and it is private, no other app can use it. But in my testing when I tried to FileTransfer crap down to it, I always got this error: Could not create target file Not really sure what to do, I eventually tried cordova.file.dataDirectory. According to the docs for it, it is: Where to put app-specific data files. Since it didn't say Private, my understanding was: Ok, I can put crap here too, but it is public, so other apps can see it. Switching to this made my app work immediately. (Haven't tested Android yet.) So my question is - did I simply misunderstand the documentation for applicationStorageDirectory? If so, if someone can help explain what I did wrong, I'll happily write it up in a PR to improve the doc. If I didn't misunderstand it and there is a bug, I'll file a report. If you want to see the entire app (again, it is incredibly simple), you can see it here: https://github.com/cfjedimaster/Cordova-Examples/tree/master/checkanddownload/www
RE: More questions on FileSystem directories
Yes, I meant that the doc for cacheDirectory implies, at least to me, that the previous entry (dataDirectorry) will not persist. I think your modification makes sense. Do you want to make a PR for the doc or should I? From: julio cesar sanchez jcesarmob...@gmail.com Sent: Monday, June 30, 2014 2:19 AM To: dev@cordova.apache.org Subject: Re: More questions on FileSystem directories If you read this immediately after reading the docs for cordova.file.dataDirectory, you may think that files there do NOT survive app restarts. Which ones, the files from dataDirectory or the files from cacheDirectory? If you mean dataDirectory, maybe the doc should be something like this: cordova.file.dataDirectory - Persistent data directory where to put app-specific data files. (iOS, Android) cordova.file.cacheDirectory - Directory for cached data files or any files that your app can re-create easily. The OS may delete these files when the device runs low on storage, nevertheless, apps should not rely on the OS to delete files in here. (iOS, Android) It's a mix from the apple https://developer.apple.com/library/ios/Documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW11 and android doc http://developer.android.com/guide/topics/data/data-storage.html 2014-06-29 19:08 GMT+02:00 Ray Camden rayca...@adobe.com: According to the docs, cordova.file.cacheDirectory is: Cached files that should survive app restarts. Apps should not rely on the OS to delete files in here. If you read this immediately after reading the docs for cordova.file.dataDirectory, you may think that files there do NOT survive app restarts. Can we flesh out this a bit more perhaps?
RE: More questions on FileSystem directories
Kerri Shotts is going to be filing one soon. From: julio cesar sanchez jcesarmob...@gmail.com Sent: Monday, June 30, 2014 1:44 PM To: dev@cordova.apache.org Subject: Re: More questions on FileSystem directories Maybe we can wait to hear more opinios about my modification. Or you can create the pull request and they will merge if they agree. 2014-06-30 16:44 GMT+02:00 Ray Camden rayca...@adobe.com: Yes, I meant that the doc for cacheDirectory implies, at least to me, that the previous entry (dataDirectorry) will not persist. I think your modification makes sense. Do you want to make a PR for the doc or should I? From: julio cesar sanchez jcesarmob...@gmail.com Sent: Monday, June 30, 2014 2:19 AM To: dev@cordova.apache.org Subject: Re: More questions on FileSystem directories If you read this immediately after reading the docs for cordova.file.dataDirectory, you may think that files there do NOT survive app restarts. Which ones, the files from dataDirectory or the files from cacheDirectory? If you mean dataDirectory, maybe the doc should be something like this: cordova.file.dataDirectory - Persistent data directory where to put app-specific data files. (iOS, Android) cordova.file.cacheDirectory - Directory for cached data files or any files that your app can re-create easily. The OS may delete these files when the device runs low on storage, nevertheless, apps should not rely on the OS to delete files in here. (iOS, Android) It's a mix from the apple https://developer.apple.com/library/ios/Documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW11 and android doc http://developer.android.com/guide/topics/data/data-storage.html 2014-06-29 19:08 GMT+02:00 Ray Camden rayca...@adobe.com: According to the docs, cordova.file.cacheDirectory is: Cached files that should survive app restarts. Apps should not rely on the OS to delete files in here. If you read this immediately after reading the docs for cordova.file.dataDirectory, you may think that files there do NOT survive app restarts. Can we flesh out this a bit more perhaps?
Questions about FileSystem documentation and paths
Hey folks - I originally raised this on the Google Group as I assumed it was just an issue w/ my code, but I believe this is a documentation issue so I'm raising it here. If wrong, let me know. :) I'm working on a set of of demos related to the FileSystem feature to answer a series of FAQs risen on my blog. For my first sample app, I wanted to build something simple: Check for a file on the device. If not there, fetch it. Looking at the docs for the FileSystem important dirs, I assumed that cordova.file.applicationStorageDirectory made the most sense. The docs say it is: Root of app's private writable storage. Note the words private and writable. In my mind that was: I can write to it and it is private, no other app can use it. But in my testing when I tried to FileTransfer crap down to it, I always got this error: Could not create target file Not really sure what to do, I eventually tried cordova.file.dataDirectory. According to the docs for it, it is: Where to put app-specific data files. Since it didn't say Private, my understanding was: Ok, I can put crap here too, but it is public, so other apps can see it. Switching to this made my app work immediately. (Haven't tested Android yet.) So my question is - did I simply misunderstand the documentation for applicationStorageDirectory? If so, if someone can help explain what I did wrong, I'll happily write it up in a PR to improve the doc. If I didn't misunderstand it and there is a bug, I'll file a report. If you want to see the entire app (again, it is incredibly simple), you can see it here: https://github.com/cfjedimaster/Cordova-Examples/tree/master/checkanddownload/www
RE: How to initialize a Cordova project using CLI if I only have the www directory of the project?
The CLI allows you to copy from a folder to 'seed' a new project. I'd use that. Interesting - CowTipLine is my app - but that's not my repo. :) From: German Viscuso germanvisc...@gmail.com Sent: Tuesday, June 24, 2014 12:23 PM To: dev@cordova.apache.org Subject: How to initialize a Cordova project using CLI if I only have the www directory of the project? I'm new to Phonegap/Cordova and I installed the latest Cordova CLI via npm. I have a couple of projects that I want to build/run but the root dir seems to be only what you'd find on a www directory of a Cordova project: https://github.com/phonegap/phonegap-app-anyconference (Phonegap 2.9) https://github.com/germanviscuso/CowTipLine (Phonegap 2.0) How can I initialize/upgrade a Cordova project with these projects? I just want to be able to build and run these project using the latest Cordova CLI. Note that the 2nd project runs on a rather old version of Phonegap. I tried phonegap local run android when in the phonegap-app-anyconference directory and it doesn't work. Best! Thx a lot.
RE: Contacts API, iOS
So I just want to double check to make sure I'm groking it right myself - this was simply a mistake in terms of the doc for version X+1 going live before plugin version X+1 was ready, right? When/how will it be corrected? (Not trying to be pushy, just want to make sure I explain it well to others if asked. :) From: Carlos Santana csantan...@gmail.com Sent: Saturday, June 21, 2014 12:09 PM To: dev@cordova.apache.org Subject: Re: Contacts API, iOS Andrew plugins are not in npm, did you meant the plugin registry. Then yes I agree that way user can read the docs that go along with the version of the plugin. If they have an older version of the plugin the can use the drop down to switch the version to an older version and read the corresponding docs for that version.
RE: File API as implemented by cordova-plugins-file
As just an FYI - I swear 99% of the questions I get on my blog about Cordova/PG involve the File stuff. From: Jesse purplecabb...@gmail.com Sent: Monday, June 23, 2014 4:06 PM To: dev@cordova.apache.org Subject: File API as implemented by cordova-plugins-file I am working through numerous failing tests in the file plugin, but the documentation is non-existent. Is there some reference to this somewhere? Pointing to ever-changing defunct specs that aren't even followed makes this impossible to resolve without going and reading the code from other platforms. ( likely all of them, since it seems to be quirk-ville )
RE: Contacts API, iOS
My test was very simple -trying to use pickContact, so I would not have seen if
there were *other* problems.
I ended up testing with the unreleased version of the plugin and it worked
great.
Did we figure out what really happened though? Maybe a PR with the updated doc,
but not the plugin, accidentally got accepted?
From: Mike Billau mike.bil...@gmail.com
Sent: Friday, June 20, 2014 2:06 PM
To: dev@cordova.apache.org
Subject: Re: Contacts API, iOS
Just noticed this an hour ago as well. On Android, pickContact just doesn't
do anything, but some other people are reporting that the JavaScript itself
is hosed and the app won't load any .js - Ray, you didn't observe this on
iOS, right? It seems strange to me that an old version of the contact .js
would keep _any_ .js from loading.
In the mean time I am just going to direct people to get the plugin from
the git URL.
On Fri, Jun 20, 2014 at 2:43 PM, Ray Camden rayca...@adobe.com wrote:
If I had to guess, I'd say the docs lead to from docs.cordova.io are
going to an unreleased version. If you go to the docs via
plugins.cordova.io, you see the right docs.
I *was* able to test by explicitly getting the plugin from the Git URL and
it works cool - can't wait for this to officially land.
From: mmo...@google.com mmo...@google.com on behalf of Michal Mocny
mmo...@chromium.org
Sent: Friday, June 20, 2014 1:36 PM
To: Michal Mocny
Cc: dev
Subject: Re: Contacts API, iOS
As far as the API documentation, and why iOS has a different interface.. I
don't know the history, but this seems mighty confusing. I think contacts
plugin has been in need of some love for quite a while, but its been hard
to get anyone excited about it.
-Michal
On Fri, Jun 20, 2014 at 2:30 PM, Michal Mocny mmo...@chromium.org wrote:
Alright, sorry I got confused reading the history because of some
fast-forward merges.
Seems all is well in the repo -- but the last plugins release Steven held
back contacts due to failing tests, hence whats up on plugins.cordova.io
being so stale.
-Michal
On Fri, Jun 20, 2014 at 2:23 PM, Michal Mocny mmo...@chromium.org
wrote:
That may not be right at all. Something seems fishy at first glance,
but
its hard to track the history. Ian and I are looking at it.
On Fri, Jun 20, 2014 at 2:18 PM, Michal Mocny mmo...@chromium.org
wrote:
Looks like the last release was based on dev branch (
https://github.com/apache/cordova-plugin-contacts/blob/55ba3f2580d2c3bbd1662f49d89043710446220a/www/contacts.js
),
which was closed, but maybe wasn't merged in to master?
-Michal
On Fri, Jun 20, 2014 at 2:10 PM, Ray Camden rayca...@adobe.com
wrote:
Ok, so doing
cordova plugin add org.apache.cordova.contacts
brings in org.apache.cordova.contacts/www/contacts.js that does NOT
match what I'm seeing in
https://github.com/apache/cordova-plugin-contacts/blob/master/www/contacts.js
,
which was last updated *2* months ago.
Any ideas?
From: Ray Camden rayca...@adobe.com
Sent: Friday, June 20, 2014 1:07 PM
To: dev@cordova.apache.org
Subject: Contacts API, iOS
(I struggled with whether or not this should go here or the Google
Group. Settled on here but if folks think it should be moved, just
let me
know.)
I was building a small test of the pickContact API when I noticed it
didn't work in iOS. I opened up a remote debug session with Safari and
noticed it had chooseContact.
Thinking it was just a doc bug, I corrected it with a pull request and
returned to my code. But then my app crashed after selecting a
contact.
From what I can see, the chooseContact iOS API is:
chooseContact : function(successCallback, options) {
not
chooseContact : function(successCallback, errorCallback) {
So something is seriously weird here compared to the original docs.
Anyone know what is going on with the plugin?
RE: Getting 'type' of undefined in LogCat
In general, support questions should be posted to Stack Overflow, or the Google
group. This list is for the *development* of Cordova itself.
That being said, you probably forgot to add the plugin. Follow the instructions
here:
https://github.com/apache/cordova-plugin-network-information/blob/master/doc/index.md
From: dheeraj.she...@thomsonreuters.com dheeraj.she...@thomsonreuters.com
Sent: Friday, June 20, 2014 8:56 AM
To: dev@cordova.apache.org
Subject: Getting 'type' of undefined in LogCat
Hi,
We are developing a android app using Cordova. We are trying to detect the
network connection ,we are not able to get the network connection. Please guide
us on this regard.
Sample code for your reference,
!DOCTYPE html
html
head
titlenavigator.connection.type Example/title
script type=text/javascript charset=utf-8
src=../../js/cordova-2.2.0.js/script
script type=text/javascript charset=utf-8
// Wait for device API libraries to load
//
document.addEventListener(deviceready, onDeviceReady, false);
// device APIs are available
//
function onDeviceReady() {
checkConnection();
}
function checkConnection() {
var networkState = navigator.connection.type;
var states = {};
states[Connection.UNKNOWN] = 'Unknown connection';
states[Connection.ETHERNET] = 'Ethernet connection';
states[Connection.WIFI] = 'WiFi connection';
states[Connection.CELL_2G] = 'Cell 2G connection';
states[Connection.CELL_3G] = 'Cell 3G connection';
states[Connection.CELL_4G] = 'Cell 4G connection';
states[Connection.CELL] = 'Cell generic connection';
states[Connection.NONE] = 'No network connection';
alert('Connection type: ' + states[networkState]);
}
/script
/head
body onload=javascript:checkConnection();
pA dialog box will report the network state./p
/body
/html
Regards,
Dheeraj
RE: Contacts API, iOS
Ok, so doing
cordova plugin add org.apache.cordova.contacts
brings in org.apache.cordova.contacts/www/contacts.js that does NOT match what
I'm seeing in
https://github.com/apache/cordova-plugin-contacts/blob/master/www/contacts.js,
which was last updated *2* months ago.
Any ideas?
From: Ray Camden rayca...@adobe.com
Sent: Friday, June 20, 2014 1:07 PM
To: dev@cordova.apache.org
Subject: Contacts API, iOS
(I struggled with whether or not this should go here or the Google Group.
Settled on here but if folks think it should be moved, just let me know.)
I was building a small test of the pickContact API when I noticed it didn't
work in iOS. I opened up a remote debug session with Safari and noticed it had
chooseContact.
Thinking it was just a doc bug, I corrected it with a pull request and returned
to my code. But then my app crashed after selecting a contact.
From what I can see, the chooseContact iOS API is:
chooseContact : function(successCallback, options) {
not
chooseContact : function(successCallback, errorCallback) {
So something is seriously weird here compared to the original docs. Anyone know
what is going on with the plugin?
Contacts API, iOS
(I struggled with whether or not this should go here or the Google Group.
Settled on here but if folks think it should be moved, just let me know.)
I was building a small test of the pickContact API when I noticed it didn't
work in iOS. I opened up a remote debug session with Safari and noticed it had
chooseContact.
Thinking it was just a doc bug, I corrected it with a pull request and returned
to my code. But then my app crashed after selecting a contact.
From what I can see, the chooseContact iOS API is:
chooseContact : function(successCallback, options) {
not
chooseContact : function(successCallback, errorCallback) {
So something is seriously weird here compared to the original docs. Anyone know
what is going on with the plugin?
RE: Contacts API, iOS
If I had to guess, I'd say the docs lead to from docs.cordova.io are going to
an unreleased version. If you go to the docs via plugins.cordova.io, you see
the right docs.
I *was* able to test by explicitly getting the plugin from the Git URL and it
works cool - can't wait for this to officially land.
From: mmo...@google.com mmo...@google.com on behalf of Michal Mocny
mmo...@chromium.org
Sent: Friday, June 20, 2014 1:36 PM
To: Michal Mocny
Cc: dev
Subject: Re: Contacts API, iOS
As far as the API documentation, and why iOS has a different interface.. I
don't know the history, but this seems mighty confusing. I think contacts
plugin has been in need of some love for quite a while, but its been hard
to get anyone excited about it.
-Michal
On Fri, Jun 20, 2014 at 2:30 PM, Michal Mocny mmo...@chromium.org wrote:
Alright, sorry I got confused reading the history because of some
fast-forward merges.
Seems all is well in the repo -- but the last plugins release Steven held
back contacts due to failing tests, hence whats up on plugins.cordova.io
being so stale.
-Michal
On Fri, Jun 20, 2014 at 2:23 PM, Michal Mocny mmo...@chromium.org wrote:
That may not be right at all. Something seems fishy at first glance, but
its hard to track the history. Ian and I are looking at it.
On Fri, Jun 20, 2014 at 2:18 PM, Michal Mocny mmo...@chromium.org
wrote:
Looks like the last release was based on dev branch (
https://github.com/apache/cordova-plugin-contacts/blob/55ba3f2580d2c3bbd1662f49d89043710446220a/www/contacts.js),
which was closed, but maybe wasn't merged in to master?
-Michal
On Fri, Jun 20, 2014 at 2:10 PM, Ray Camden rayca...@adobe.com wrote:
Ok, so doing
cordova plugin add org.apache.cordova.contacts
brings in org.apache.cordova.contacts/www/contacts.js that does NOT
match what I'm seeing in
https://github.com/apache/cordova-plugin-contacts/blob/master/www/contacts.js,
which was last updated *2* months ago.
Any ideas?
From: Ray Camden rayca...@adobe.com
Sent: Friday, June 20, 2014 1:07 PM
To: dev@cordova.apache.org
Subject: Contacts API, iOS
(I struggled with whether or not this should go here or the Google
Group. Settled on here but if folks think it should be moved, just let me
know.)
I was building a small test of the pickContact API when I noticed it
didn't work in iOS. I opened up a remote debug session with Safari and
noticed it had chooseContact.
Thinking it was just a doc bug, I corrected it with a pull request and
returned to my code. But then my app crashed after selecting a contact.
From what I can see, the chooseContact iOS API is:
chooseContact : function(successCallback, options) {
not
chooseContact : function(successCallback, errorCallback) {
So something is seriously weird here compared to the original docs.
Anyone know what is going on with the plugin?
RE: ngCordova
Any plans on promising up FileSystem and Globalization? From: Max Lynch m...@drifty.com Sent: Tuesday, June 03, 2014 7:07 PM To: dev@cordova.apache.org Subject: ngCordova Hey everyone, We (the Ionic framework team) released a very early version of our Cordova plugin AngularJS wrapper project today, called ngCordova: http://ngCordova.com/ The goal is to make it a bit easier to use cordova plugins by adding promise support and a softer API in case cordova isn't available or you are mocking data for geolocation or the accelerometer. The project is MIT licensed and we have a lot of plugins we want to support. Any suggestions or PRs are greatly appreciated! Feel free to send me any thoughts you have about it, and I hope some find it useful! http://ngCordova.com/ Thanks, Max Lynch Ionic co-creator http://twitter.com/maxlynch
RE: Speculation: Apple supports WebGL in UIWebView, soon
Would I be crazy to say I'm more excited about the possible support of IndexedDB? :) From: iclell...@google.com iclell...@google.com on behalf of Ian Clelland iclell...@chromium.org Sent: Thursday, May 22, 2014 10:14 AM To: dev@cordova.apache.org Subject: Speculation: Apple supports WebGL in UIWebView, soon The reasoning is a little thin, but it's an interesting possibility: http://blog.playcanvas.com/apple-embraces-webgl/
RE: CLI implementation for the save and restore plugins
If the intent is for us to test them, then they should be documented. If I run across something and _don't_ see a doc, I get more upset about that then anything else. Just make it clear it is an experiment and it may change in the future. From: mmo...@google.com mmo...@google.com on behalf of Michal Mocny mmo...@chromium.org Sent: Wednesday, May 21, 2014 9:24 AM To: dev Subject: Re: CLI implementation for the save and restore plugins In theory, but I think the point for now was that we aren't sure about the syntax and semantics. We should probably reach out using various channels to get users to try it and chime in, but its really early to start documenting lest users get upset when it breaks. On Wed, May 21, 2014 at 10:16 AM, Gorkem Ercan gorkem.er...@gmail.comwrote: I was planning to add it when I got the restore/save platforms in but I can send an early PR. -- Gorkem
RE: Draft of Whitelist and Security Guide
Speaking of - when will the GS guide be on docs.cordova.io? With 3.5? From: Mike Billau mike.bil...@gmail.com Sent: Monday, May 19, 2014 8:42 AM To: dev@cordova.apache.org Subject: Re: Draft of Whitelist and Security Guide Thanks everyone for reading and looking this over. I'm going to make another pass and try to publish it this week.. .thinking about forwarding it to the Google Gro
RE: Draft of Whitelist and Security Guide
I did. From: brian.ler...@gmail.com brian.ler...@gmail.com on behalf of Brian LeRoux b...@brian.io Sent: Monday, May 19, 2014 9:41 AM To: dev@cordova.apache.org Subject: Re: Draft of Whitelist and Security Guide Did anyone submit is as a PR to the cordova-docs repo? On Mon, May 19, 2014 at 7:21 AM, Ray Camden rayca...@adobe.com wrote: Speaking of - when will the GS guide be on docs.cordova.io? With 3.5? From: Mike Billau mike.bil...@gmail.com Sent: Monday, May 19, 2014 8:42 AM To: dev@cordova.apache.org Subject: Re: Draft of Whitelist and Security Guide Thanks everyone for reading and looking this over. I'm going to make another pass and try to publish it this week.. .thinking about forwarding it to the Google Gro
RE: Draft of Whitelist and Security Guide
Looks like it was already merged: https://github.com/apache/cordova-docs/pull/203 Just curious why I don't see it then? It should be up at docs.cordova.io, right? From: brian.ler...@gmail.com brian.ler...@gmail.com on behalf of Brian LeRoux b...@brian.io Sent: Monday, May 19, 2014 9:53 AM To: dev@cordova.apache.org Subject: Re: Draft of Whitelist and Security Guide err, ok, I'm not seeing if it got merged or not…can you link to it Ray? On Mon, May 19, 2014 at 7:43 AM, Ray Camden rayca...@adobe.com wrote: I did. From: brian.ler...@gmail.com brian.ler...@gmail.com on behalf of Brian LeRoux b...@brian.io Sent: Monday, May 19, 2014 9:41 AM To: dev@cordova.apache.org Subject: Re: Draft of Whitelist and Security Guide Did anyone submit is as a PR to the cordova-docs repo? On Mon, May 19, 2014 at 7:21 AM, Ray Camden rayca...@adobe.com wrote: Speaking of - when will the GS guide be on docs.cordova.io? With 3.5? From: Mike Billau mike.bil...@gmail.com Sent: Monday, May 19, 2014 8:42 AM To: dev@cordova.apache.org Subject: Re: Draft of Whitelist and Security Guide Thanks everyone for reading and looking this over. I'm going to make another pass and try to publish it this week.. .thinking about forwarding it to the Google Gro
RE: Draft of Whitelist and Security Guide
Ok - gotcha - so you're telling me to be patient. Luckily I'm very good at that. ;) From: brian.ler...@gmail.com brian.ler...@gmail.com on behalf of Brian LeRoux b...@brian.io Sent: Monday, May 19, 2014 10:04 AM To: dev@cordova.apache.org Subject: Re: Draft of Whitelist and Security Guide no, deploying is a different thing altogether. a full rebuild of the docs so that is automated is forthcoming. (mike and steve are going to look at it when they can) On Mon, May 19, 2014 at 7:56 AM, Ray Camden rayca...@adobe.com wrote: Looks like it was already merged:
RE: First stab at Next Steps article
Yes, I'm mad you did this work for me. ;) I'm a bit behind so this is perfect, thank you. I still plan on checking over things today and seeing if it is ready to submit to Cordova for the initial doc. Thanks! From: Mike Billau mike.bil...@gmail.com Sent: Monday, May 05, 2014 10:31 AM To: dev@cordova.apache.org Subject: Re: First stab at Next Steps article I went through this morning and addressed most of the comments that people left (sorry Ray, hope you don't mind!). I think this guide is really shaping up and starting to look great. The only thing really left to resolve is some details around recommending FastClick or not using touch events at all. We can let it simmer for a few more days, then I can push it into the docs (unless somebody else wants to.) On Fri, May 2, 2014 at 9:57 PM, Carlos Santana csantan...@gmail.com wrote:
RE: First stab at Next Steps article
I'm going to turn off shared access - just while I do my review review (in case folks try to load it up). From: Ray Camden rayca...@adobe.com Sent: Monday, May 05, 2014 10:56 AM To: dev@cordova.apache.org Subject: RE: First stab at Next Steps article Yes, I'm mad you did this work for me. ;) I'm a bit behind so this is perfect, thank you. I still plan on checking over things today and seeing if it is ready to submit to Cordova for the initial doc. Thanks! From: Mike Billau mike.bil...@gmail.com Sent: Monday, May 05, 2014 10:31 AM To: dev@cordova.apache.org Subject: Re: First stab at Next Steps article I went through this morning and addressed most of the comments that people left (sorry Ray, hope you don't mind!). I think this guide is really shaping up and starting to look great. The only thing really left to resolve is some details around recommending FastClick or not using touch events at all. We can let it simmer for a few more days, then I can push it into the docs (unless somebody else wants to.) On Fri, May 2, 2014 at 9:57 PM, Carlos Santana csantan...@gmail.com wrote:
RE: First stab at Next Steps article
I can do so soon. From: Mike Billau mike.bil...@gmail.com Sent: Monday, May 05, 2014 2:02 PM To: dev@cordova.apache.org Subject: Re: First stab at Next Steps article Ray, why don't you do a PR to /cordova-docs? That way the initial commit will (should?) have your name on it. We should also update /cordova-docs/index.md and add a link to the guide so that it will appear in the left hand list on docs.cordova.io as a top level guide. I think a good spot would be between Using Plugman to Manage Plugins and The config.xml File. I think I have a VM floating around somewhere that is able to build the docs, so I can use that to test that the link works and page renders fine, unless somebody else can spin one up quicker.
RE: First stab at Next Steps article
PR submitted. ICLA submitted. From: brian.ler...@gmail.com brian.ler...@gmail.com on behalf of Brian LeRoux b...@brian.io Sent: Monday, May 05, 2014 2:13 PM To: dev@cordova.apache.org Subject: Re: First stab at Next Steps article +1. Its well beyond time you landed a commit or two into Cordova Ray! On Mon, May 5, 2014 at 12:02 PM, Mike Billau mike.bil...@gmail.com wrote: Ray, why don't you do a PR to /cordova-docs? That way the initial commit will (should?) have your name on it.
RE: First stab at Next Steps article
I've gotten a lot of good feedback. My plan is to review, update, etc, and see if it feels like a good 1.0 release for Monday at which point yall can take it over. From: kerrisho...@gmail.com kerrisho...@gmail.com on behalf of Kerri Shotts ke...@photokandy.com Sent: Friday, May 02, 2014 12:05 AM To: dev@cordova.apache.org Subject: Re: First stab at Next Steps article Awesome work thus far, and a good idea to have, imo. Getting to hello, world is great, but having a jumping-off point for how to proceed after that fact would be very beneficial. I added a few comments to the document, and also contributed some sections on upgrading projects/plugins and testing. If anything there is too much detail, wrong, or not desired in this document, feel free to remove as needed. :-) If an ICLA is needed for what I added, one is on its way. I've been meaning to send one anyway, but time keeps getting away from me!
RE: First stab at Next Steps article
I like his article - but don't think jQM is as bad as others do. (Disclaimer - I wrote a book on jQM.) From: tommy-carlos williams to...@devgeeks.org Sent: Wednesday, April 30, 2014 4:14 PM To: dev@cordova.apache.org Subject: Re: First stab at Next Steps article Ray, This looks great. Interesting choice to both link Brock’s “you half-assed it” article *and* list jQM first in the list of UI libs... :)
RE: First stab at Next Steps article
Replies with RKC. 1. Please don't mention WebSQL. RKC: Heh, well, it *works*, but yeah, ok, removed to make it more generic. 2. The offline/online event is not a great indicator, it's a hint, but it can be misleading. People need to try a connection (XHR) to their destination, if it works, great, if it doesn't that's it. If I'm in a captive portal, or if I'm in an office, I can easily not have access to your backend, even though I do have some form of network access. RKC: I'm going to add a bit of text to ensure folks know it isn't perfect, and mention the XHR suggestion, but the big point I think is doing *something*. 3. For Debugging, on BlackBerry 10, you get web inspector out of the box. https://developer.blackberry.com/html5/documentation/v2_0/enabling_web_insp ector.html https://developer.blackberry.com/html5/documentation/v2_0/debugging_using_w eb_inspector.html RKC: Not to diminish BB, but I added a final subsection called Other Options and used this as a bullet. I assume we can just add more there. If folks feel this should be a top level item in the section, go ahead. :) 4. I think we decided to favor stack overflow over google groups RKC: I think both have merit though. If folks feel strongly I can swap em. 5. s/you simulator the accelerometer to test shake events/you simulate the accelerometer to test shake events/ — this last one means you should introduce the document to WinWord and ask it for an opinion :). RKC: Nod, will do a grammar check before we officially hand this off to - whomever - to integrate. Actually - I have an official editor via Adobe for my blog - I may be able to use him.
RE: First stab at Next Steps article
Personally, version control feels more like something that should in a FAQ than this doc, but this isn't my call, if you feel like it should be added, do it. :) Should we add a section about version control? I see that question asked from time to time: What should I be checking in?, this could also be expanded to tips for working on a team (what happens when one person uses OSX and the other Windows) - although that is a more advanced use case. Maybe we can change the Handling Upgrades section to Handling Source Code and Cordova Upgrades. On Wed, Apr 30, 2014 at 5:40 PM, Andrew Grieve agri...@chromium.org wrote: On Wed, Apr 30, 2014 at 5:28 PM, Josh Soref jso...@blackberry.com wrote: Ray Camden wrote: I had 3 hours here at the airport so I took at stab at writing content for the Next Steps document. You can find (and edit) the document here: https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkc omWgk/edit# Personally, I favor ether pads / pirate pads. The main thing missing now (imo) is the Upgrade section. I think with that added - this is in a good place (at least initially). Thoughts, opinions, etc? I like it. Any volunteers ready to write out the upgrade section? I don't want to set up a Google account at work, but FYI - you don't need an account to edit a doc that's made editable via those with the link (as this one is). 1. Please don't mention WebSQL. 2. The offline/online event is not a great indicator, it's a hint, but it can be misleading. People need to try a connection (XHR) to their destination, if it works, great, if it doesn't that's it. If I'm in a captive portal, or if I'm in an office, I can easily not have access to your backend, even though I do have some form of network access. 3. For Debugging, on BlackBerry 10, you get web inspector out of the box. https://developer.blackberry.com/html5/documentation/v2_0/enabling_web_insp ector.html https://developer.blackberry.com/html5/documentation/v2_0/debugging_using_w eb_inspector.html 4. I think we decided to favor stack overflow over google groups 5. s/you simulator the accelerometer to test shake events/you simulate the accelerometer to test shake events/ — this last one means you should introduce the document to WinWord and ask it for an opinion :).
Docs for plugins
I just noticed that the links for plugins from docs.cordova.io go to a new page (http://plugins.cordova.io/#/package/org.apache.cordova.file as an example). The docs for this one in particular seem wrong. I recently did a small mod to add the error codes to the docs, and I'm not seeing it here. Mistake? Do I need to make a new PR on the repo? Related - why is the link to the github version gone?
RE: Docs for plugins
So... pretend I'm dumb here. Do I need to do anything? Will it just be updated in the next plugin release? From: mmo...@google.com mmo...@google.com on behalf of Michal Mocny mmo...@chromium.org Sent: Wednesday, April 30, 2014 8:50 AM To: Michal Mocny Cc: dev Subject: Re: Docs for plugins Ray, Yeah seems file plugin @c1a1052 was tagged for 1.1.0 release 13 days ago, you patched docs after that tag @abcaf70 12 days ago, and plugin was actually released with @e9efe65 7 days ago. You just missed the window narrowly! -Michal On Wed, Apr 30, 2014 at 9:45 AM, Michal Mocny mmo...@chromium.org wrote: I believe the plugin docs reflect what was bundled with the latest plugin release -- perhaps your recent changes were not released yet? Or has something gotten lost in the recent shuffle with dev/master branches? Its true, though, that for core plugins our registry links to the official apache repos and not the github mirrors, and the official repo links do not have a pretty renderers for markdown docs. Not sure what we want to do here. On Wed, Apr 30, 2014 at 9:14 AM, Ray Camden rayca...@adobe.com wrote: I just noticed that the links for plugins from docs.cordova.io go to a new page (http://plugins.cordova.io/#/package/org.apache.cordova.file as an example). The docs for this one in particular seem wrong. I recently did a small mod to add the error codes to the docs, and I'm not seeing it here. Mistake? Do I need to make a new PR on the repo? Related - why is the link to the github version gone?
RE: Some pain points from our users :'(
Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.) From: Marcel Kinard cmarc...@gmail.com Sent: Wednesday, April 30, 2014 10:22 AM To: dev@cordova.apache.org Subject: Re: Some pain points from our users :'( How about using a short-term wiki page to create/grow the draft? Then it could migrate into cordova-docs.git. Getting to the end of the Cordova docs with a working helloWorld, and then having signposts for the next places to go would be a significant gain in the perceived usability of Cordova. Ray, thank you! On Apr 30, 2014, at 9:11 AM, Ray Camden rayca...@adobe.com wrote: I'd love to take a stab at this. Where would be a good place for to post a draft that folks could edit and the Cordova team could just take it over when happy?
RE: Some pain points from our users :'(
It took some time to actually register, but I'll give it a shot. Traveling today but will try to get a basic outline up there asap. (And anyone else listening - don't wait for me - attack the doc if you can. :) From: Marcel Kinard cmarc...@gmail.com Sent: Wednesday, April 30, 2014 10:41 AM To: dev@cordova.apache.org Subject: Re: Some pain points from our users :'( How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this works, as long as the contributions are considered trivial by Apache standards. Otherwise pull requests to cordova-doc.git would be the [slower and more proper] way to go. On Apr 30, 2014, at 11:29 AM, Ray Camden rayca...@adobe.com wrote: Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
RE: Some pain points from our users :'(
Crap, I spoke too soon. it is a Immutable Page and I can't edit it. From: Marcel Kinard cmarc...@gmail.com Sent: Wednesday, April 30, 2014 10:41 AM To: dev@cordova.apache.org Subject: Re: Some pain points from our users :'( How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this works, as long as the contributions are considered trivial by Apache standards. Otherwise pull requests to cordova-doc.git would be the [slower and more proper] way to go. On Apr 30, 2014, at 11:29 AM, Ray Camden rayca...@adobe.com wrote: Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
RE: Some pain points from our users :'(
On it. From: Steven Gill stevengil...@gmail.com Sent: Wednesday, April 30, 2014 11:12 AM To: dev@cordova.apache.org Subject: RE: Some pain points from our users :'( I would suggest creating a Google doc and sharing it here. On Apr 30, 2014 8:59 AM, Ray Camden rayca...@adobe.com wrote: Crap, I spoke too soon. it is a Immutable Page and I can't edit it. From: Marcel Kinard cmarc...@gmail.com Sent: Wednesday, April 30, 2014 10:41 AM To: dev@cordova.apache.org Subject: Re: Some pain points from our users :'( How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this works, as long as the contributions are considered trivial by Apache standards. Otherwise pull requests to cordova-doc.git would be the [slower and more proper] way to go. On Apr 30, 2014, at 11:29 AM, Ray Camden rayca...@adobe.com wrote: Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
First stab at Next Steps article
I had 3 hours here at the airport so I took at stab at writing content for the Next Steps document. You can find (and edit) the document here: https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit# The main thing missing now (imo) is the Upgrade section. I think with that added - this is in a good place (at least initially). Thoughts, opinions, etc? Any volunteers ready to write out the upgrade section?
RE: [Discuss] The Future of Ripple as a Top Level ASF Project
Oh - when I read your call for Ripple devs to 'switch', I had assumed it was something already done. From: agri...@google.com agri...@google.com on behalf of Andrew Grieve agri...@chromium.org Sent: Monday, April 28, 2014 11:49 AM To: dev Subject: Re: [Discuss] The Future of Ripple as a Top Level ASF Project Right, it doesn't exist yet (no one's picked up working on it). +Brian made the original pitch for it, but my understanding is that it is meant to be adding first-class support for testing Cordova apps in the browser, but do so by being a fully-supported cordova platform. Another way to look at this is to say that there's already a place for Ripple to go within Cordova. The core logic should go into cordova-browser. Plugin logic should go into each plugin repo under the browser platform. And the bridge interception piece should go into cordova-js. If there is still need for a ripple server after all of this, then that belongs inside of cordova-cli.
RE: [Discuss] The Future of Ripple as a Top Level ASF Project
As just an FYI, I couldn't disagree more about your first point (minimal value). Now that Ripple is working again, I find it to be *extremely* helpful for prototyping, quick testing, and teaching as well. You mention built in emulation in Chrome, and yep, that's nice, but consider geolocation. In Chrome, you have to enter a long/lat value (and I don't know about you, but I don't keep those values in my head), in Ripple, you can use a much simpler map interface to pick your location. Hell, just running deviceready for me automatically is helpful. Maybe I'm just too passionate about it - but I really don't want to minimize the value of Ripple. Sorry - carry on. ;) From: Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com Sent: Monday, April 28, 2014 1:06 PM To: dev@cordova.apache.org Subject: RE: [Discuss] The Future of Ripple as a Top Level ASF Project So, should we start the formal proposal to the Apache Foundation to move on making Ripple a part of Cordova? I am guessing that we would need technical reasons on why that would make sense. I could help with drafting the proposal. - Ripple is mostly used for Cordova development. Browsers already have viewport/touch emulation built in and the value of ripple is minimal in this space - Ripple is very similar to other top level 'Cordova tools' like CLI, Medic, etc. Hence, it makes sense to treat it as such and make it a part of the Cordova like the other projects.
RE: [Discuss] The Future of Ripple as a Top Level ASF Project
I am naturally inclined to *not* leave Ripple as I think it is a great tool, but I'll check out cordova-browser. You say it is very similar to Ripple, but where exactly is it? The github repo is mostly empty now. From: agri...@google.com agri...@google.com on behalf of Andrew Grieve agri...@chromium.org Sent: Thursday, April 24, 2014 3:17 PM To: dev Subject: Re: [Discuss] The Future of Ripple as a Top Level ASF Project For those passionate about Ripple, I'd like to try and woo you to two other avenues, as I don't see Ripple in the Cordova workflow in the future. cordova-app-harness for on-device testing (this is essentially the same as PhoneGap Developer App) cordova-browser CLI platform for local in-browser testing (very similar to Ripple, but fully supported by CLI works with plugins in a generic way)
RE: Great writeup from Ray Camden on PG/Cordova
I wasn't *planning* a survey, but this sounds interesting. Let me chew on this and create an initial doc. I'll share it here for folks to comment on and will then publish it. From: mmo...@google.com mmo...@google.com on behalf of Michal Mocny mmo...@chromium.org Sent: Saturday, April 12, 2014 12:04 PM To: dev Subject: Re: Great writeup from Ray Camden on PG/Cordova Ray: for next survey, would you mind polling on usage of cordova-cli vs bin/create workflow? And as subpoints: - for cordova-cli, how many platforms? (curious how many use cli even for 1 platform) - for bin/create, do they use plugman? -Michal On Sat, Apr 12, 2014 at 10:31 AM, Ray Camden rayca...@adobe.com wrote: No problem - glad it gathered up some useful data. From: Steven Gill stevengil...@gmail.com Sent: Friday, April 11, 2014 6:52 PM To: dev@cordova.apache.org Subject: Re: Great writeup from Ray Camden on PG/Cordova Yeah! Thanks Ray for putting this together! On Fri, Apr 11, 2014 at 4:06 PM, Michal Mocny mmo...@google.com wrote: http://www.raymondcamden.com/index.cfm/2014/4/11/Results-of-PhoneGap-Survey A few take-aways in there for us, I think.
RE: Great writeup from Ray Camden on PG/Cordova
The raw data is linked to in the blog post. It is XLSX but if you need it some other way, let me know. From: mmo...@google.com mmo...@google.com on behalf of Michal Mocny mmo...@chromium.org Sent: Monday, April 14, 2014 11:39 AM To: dev Subject: Re: Great writeup from Ray Camden on PG/Cordova Also, you referenced complaints about File plugin. Discussed with Ian this morning that it may be great feedback to give him so he can address it. Can we get the raw results was it meant to be private? -Michal On Mon, Apr 14, 2014 at 11:08 AM, Ray Camden rayca...@adobe.com wrote: I wasn't *planning* a survey, but this sounds interesting. Let me chew on this and create an initial doc. I'll share it here for folks to comment on and will then publish it.
RE: Great writeup from Ray Camden on PG/Cordova
No problem - glad it gathered up some useful data. From: Steven Gill stevengil...@gmail.com Sent: Friday, April 11, 2014 6:52 PM To: dev@cordova.apache.org Subject: Re: Great writeup from Ray Camden on PG/Cordova Yeah! Thanks Ray for putting this together! On Fri, Apr 11, 2014 at 4:06 PM, Michal Mocny mmo...@google.com wrote: http://www.raymondcamden.com/index.cfm/2014/4/11/Results-of-PhoneGap-Survey A few take-aways in there for us, I think.
RE: support on phonegap/cordova?
I'd use the Google Group: https://groups.google.com/forum/#!forum/phonegap From: smo s.la...@gmail.com Sent: Wednesday, April 09, 2014 2:35 AM To: dev@cordova.apache.org Subject: support on phonegap/cordova? hi where must i post to get support on phonegap/cordova ios ? thanks
RE: Plugins Release!
Dumb question, but when I see things like this in the blog post: org.apache.cordova.camera CB-4919 firefox os quirks added and supported platforms list is updated Where is that actually documented? Since I've seen quirks listed in the main doc I assumed it would be there, but I do not see it here: http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html#Camera From: Steven Gill stevengil...@gmail.com Sent: Monday, February 10, 2014 5:53 PM To: dev@cordova.apache.org Subject: Re: Plugins Release! shipped. http://cordova.apache.org/news/2014/02/10/plugins-release.html On Sat, Feb 8, 2014 at 8:43 AM, Andrew Grieve agri...@chromium.org wrote: ship it. On Fri, Feb 7, 2014 at 7:35 PM, Steven Gill stevengil...@gmail.com wrote: ship it?
RE: Plugins Release!
Interesting. Um, I've got nothing to add here I guess. ;) I am curious to see what folks out there think. From: agri...@google.com agri...@google.com on behalf of Andrew Grieve agri...@chromium.org Sent: Monday, February 10, 2014 9:34 PM To: dev Subject: Re: Plugins Release! Feedback definitely welcome in this department. For the 3.4.0 release, the main docs for plugins will look like: http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden rayca...@adobe.com wrote:
Re: template?
On 1/3/14, 10:27 AM, Mark Koudritsky kam...@google.com wrote:
The option to specify a template was added here, via --src or --link
command line args.
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;h=9b7fedf
But it's not yet part of any released version.
Is there an ETA for it?
Passing a JSON string as the 4th param to CLI does seem to work, even
though originally it was an artifact of a change done for a completely
different purpose.
The JSON string should look like:
lib:{www:{uri:/path/to/custom_www}}
Can you say where the valid keys are documented? You definitely see this
argument documented when you type ³cordova², but nowhere do you see a list
of what can be specified here. It may be too long for the CLI docs, but
where can users find it online?
Re: Plugin download counts
Consistently now if I go to plugins.cordova.io, then More, than Stats, it does not load in OSX/Chrome. If I click Reload though it works. I notice 2 XHR events are *not* fired when I first hit the page but do fire on reload. Testing OSX/Firefox and it *never* works. I am seeing ³get #/_stats² in console, but that¹s it. On 11/12/13, 5:42 PM, Anis KADRI anis.ka...@gmail.com wrote: It's been there for over a week but I forgot to mention it here so if you didn't see it here it is... http://plugins.cordova.io/#/_stats if nothing shows up...refresh the page. -a
Re: create and override of default template
So I am *completely* lost then. Can you explain what the config.json file is? I¹ve never heard of it. On 10/28/13, 12:56 PM, Ian Clelland iclell...@chromium.org wrote: To be clear, as Michal said, the `cordova` CLI tool *does not* support this directly; only indirectly, as part of the config.json file. The fourth command line parameter relates only to the various bin/create scripts that are part of each platform. The default template that is overridden with this is the *platform* template, which contains all of the platform-specific code for a new Cordova project. That's why it isn't suitable for the multi-platform cordova create command. It might be possible to make this part of cordova platform add, but that's a different (JIRA) issue. Ian
Re: create and override of default template
I disagree completely. Why does cordova need to know about the platform? Right now when I make a virgin project, before I add *any* platform, there is a default project created. All we want (well, ok, all I want ;) is the ability to override that so I can have a ³blank² project as opposed to the hello world one. This is not project specific at all. Certainly after I create the project I¹ll add a platform or two, but this should be done on initial platform creation. On 10/28/13, 1:15 PM, Ian Clelland iclell...@chromium.org wrote: On Mon, Oct 28, 2013 at 2:07 PM, Michal Mocny mmo...@chromium.org wrote: +1 to suggestion for adding it as arg to cordova platform add. Could it be as simple as: cordova platform add path/to/platform/type ? Not sure if we could make it *that* simple :) At least we could very easily make it cordova platform add platform name [template directory] I think that the CLI needs to know a little bit about the platform itself, and couldn't just work from a raw directory without knowing what kind of device it was intended for. (I'd love to be shown wrong about that, though) Ian
Re: create and override of default template
Hmm. Ok, I *did* log a bug report for this already, and I think I just assumed that this (https://issues.apache.org/jira/browse/CB-4652) was a copy and mine was a dupe. Unfortunately now I can’t find it. So… I’ll file a new one. Sorry for the confusion folks! On 10/28/13, 1:46 PM, Ian Clelland iclell...@chromium.org wrote: On Mon, Oct 28, 2013 at 2:17 PM, Ray Camden rayca...@adobe.com wrote: I disagree completely. Why does cordova need to know about the platform? Right now when I make a virgin project, before I add *any* platform, there is a default project created. All we want (well, ok, all I want ;) is the ability to override that so I can have a ³blank² project as opposed to the hello world one. This is not project specific at all. Certainly after I create the project I¹ll add a platform or two, but this should be done on initial platform creation. That's a different template, Ray. (I can see where the confusion comes from now) The documentation that you mentioned in your initial email was about a new feature used by the platform scripts, to override the default platform code template.
