Re: volumeup and volumedown events in Android Working
I think it's a bug in the docs. On Fri, Nov 7, 2014 at 7:08 AM, Joshi, Pavankumar jos...@fast.au.fujitsu.com wrote: Hello Devs, I have a question regarding volumeup and volumedown events on Android platform. These 2 events work fine on Android platform. I am currently testing mobilespec 3.6.3 version on Android 4.4.3 and Android 4.0.4 versions and these events work fine. But the latest cordova-docs mentions that these 2 events are only supported on Blackberry platform. Is it deliberately not mentioned in docs or Should the docs be updated and platform Android mentioned in the supported platform for these 2 events? Thanks and Regards Pavan Joshi
Re: Summarizing thoughts on cordova-browser vs Ripple
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. var div = ... createUI; ripple.registerPluginUi(div) Still also seems powerful though, to have Ripple be able to add UI for plugins that don't provide their own. On Mon, Nov 10, 2014 at 3:48 PM, Michal Mocny mmo...@chromium.org wrote: On Thu, Nov 6, 2014 at 6:52 PM, Horn, Julian C julian.c.h...@intel.com wrote: I'd like to introduce myself and put in my two cents here. My name is Julian Horn. I work for Intel on the XDK, an integrated development environment for cross-platform HTML5 applications. I am the team lead for the Device Emulator component, which is our Ripple derivative. My background is mostly in software development tools: compilers, debuggers, simulators and analysis tools. I have been working with the Ripple code base for a couple of years now. If I'm understanding the cordova-browser concept, the implementation of a Cordova API for the browser platform should consist of code that bridges between the platform-independent Cordova API and whatever equivalent is available in the current browser session. For example, the camera API getPicture function would invoke the getUserMedia API, which is the closest thing we have to a W3C standard way to take a picture. If the browser doesn't implement this API or the host system doesn't have a camera, then the getPicture call fails with camera unavailable. This seems like a fine way to gradually migrate from packaged apps that rely on native code plugins to pure web apps that rely on the browser to access mobile device resources. This should work great when you have a browser-portable implementation. It may be a challenge with some plugins, since of course Cordova/PhoneGap was designed to cover gaps in browser support. But at least we don't have to wait for a real W3C standard to be agreed. The goal of our XDK product is to facilitate development of cross-platform mobile HTML5 applications. We see the Device Emulator (our Ripple) as enabling developers to test an HTML5 mobile application on the host system. While this is no substitute for testing on real hardware, the Device Emulator does offers some advantages that can accelerate the development process. To summarize quickly: * It’s really fast. * You don't need an array of mobile devices. * You can put off dealing with weird target system quirks until after you get your basic application logic debugged. * You get full native JavaScript debugging, which is faster, simpler, and more available than remote debug. * You can create testing situations that are difficult or impossible to create in real life, such as GPS timeout. * It's a great teaching tool. * It allows you to prototype quickly. Assuming the functionality delivered by Ripple has value (and we find it does), one needs a way to reconcile this with the cordova-browser effort. Here's how I see that working out. One idea is to rely on the browser developer tools to supply emulation support and just drop Ripple. I don't like this much. Today the developer tools emulation UI is fairly primitive, but of course, there is nothing stopping the browser vendors from building all the functionality in the Ripple Geolocation panel (or indeed all of Ripple) into the developer tools. The bigger problem from my point of view is that this is a closed system. There's no way for a non-browser-vendor to extend the browser to provide emulation support for new plugin APIs. The alternative is to do a cordova prepare browser and load the results into Ripple. This would be my preference if at all possible. Specifically, I think ripple would move much faster and be better architected if it didn't have to depend on making changes directly to cordova. Though it should be acceptable to create a ripple platform (cordova run ripple) if really need be. Assuming the browser platform code follows the usual pattern, that is, that it goes through an exec/execProxy layer, it should be possible for Ripple to intercept at that level. Ripple can delegate to the execProxy implementation if it has no emulation-time implementation of its own. This means that unrecognized APIs run unaltered, in which case you get whatever behavior you get on the browser platform. This is a really exciting prospect. It's way better than that we don't know what to do dialog that Ripple puts up when an exec layer function it doesn't recognize is called. Thats interesting. I hadn't considered doing it this way, but it actually sounds like a great solution. In fact there are some Cordova APIs that Ripple implements by mostly delegating to a Chrome-specific API. For example, the simulation of the
Re: introduction
Sounds great! On Thu, Nov 13, 2014 at 3:21 AM, Carlos Santana csantan...@gmail.com wrote: Welcome Jonathan ! On Wed, Nov 12, 2014 at 10:31 AM Michal Mocny mmo...@chromium.org wrote: Hi Jonathan! Seems you've been a lurker on these lists for a while and have helped submit issues in the past. Thanks for signing up to contribute directly. -Michal On Wed, Nov 12, 2014 at 9:51 AM, Li, Jonathan jonathan...@sap.com wrote: Hi all, I'm getting myself set up as a contributor to Cordova. So far I've just been working on projects that use Cordova, but I hope to contribute back to Cordova in the future. The first change I plan to make is fixing bug CB-3071, so iOS cordova app does not need to use SDURLCache as a workaround for this issue. Few crashes have been reported in SDURLCache code, and it is better to fix the issue in cordova and get rid of SDURLCache from the project. Regards, Jonathan
[GitHub] cordova-plugin-file pull request: CB-7917 Fixed tests file.spec.11...
Github user MariaBukharina commented on the pull request: https://github.com/apache/cordova-plugin-file/pull/88#issuecomment-63028689 Thank you very much! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-file-transfer pull request: CB-7944 Pending unsuppo...
Github user MariaBukharina commented on the pull request: https://github.com/apache/cordova-plugin-file-transfer/pull/48#issuecomment-63062423 Thaks for you comments! I've fixed small formatting issues. Please review, if everything ok now? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-media pull request: Add seekCompleteCallback to see...
GitHub user mattgrande opened a pull request: https://github.com/apache/cordova-plugin-media/pull/37 Add seekCompleteCallback to seekTo. I had created an audio sprite elsewhere: var sprite = new Media(/* omitted */); sprite.play(); sprite.pause(); Then, further along, went to play the clip: sprite.seekTo( track.startTime ); sprite.play(); In iOS 7 and below, as well as Android, this worked. However, in iOS 8, nothing would be played. When I inspected the position, `spirte._position`, a value of `-1` was shown. Basically, seeking to a position took some undetermined amount of time, and the audio couldn't be played until the seek had completed. This pull request adds a callback to the `seekTo` method that is fired when the seek is complete. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mattgrande/cordova-plugin-media master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-media/pull/37.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #37 commit 730b1dbef264ffd8aab45a9bde5d13066716af58 Author: Matt Grande m...@weeverapps.com Date: 2014-11-13T23:22:41Z Add seekCompleteCallback to seekTo. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [GitHub] cordova-plugin-file-transfer pull request: CB-7944 Pending unsuppo...
Looks good, thanks! I've pushed it up to master. On Fri Nov 14 2014 at 8:11:27 AM MariaBukharina g...@git.apache.org wrote: Github user MariaBukharina commented on the pull request: https://github.com/apache/cordova-plugin-file-transfer/ pull/48#issuecomment-63062423 Thaks for you comments! I've fixed small formatting issues. Please review, if everything ok now? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - 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?
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 On Tue, Nov 11, 2014 at 10:00 AM, Ray Camden rayca...@adobe.com wrote: 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
[GitHub] cordova-lib pull request: Add a type named gradleReference in fr...
Github user clelland commented on the pull request: https://github.com/apache/cordova-lib/pull/119#issuecomment-63091257 Finally had the chance to review and test this. Looks good; tests fine; I'm merging it in to master. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-file-transfer pull request: CB-7944 Pending unsuppo...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-file-transfer/pull/48 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-vibration pull request: CB-8018 Add vibrate(pattern...
GitHub user daserge opened a pull request: https://github.com/apache/cordova-plugin-vibration/pull/26 CB-8018 Add vibrate(pattern) fallback on vibrate for Windows Phone 8 Added vibrate(pattern) fallback on vibrate for Windows Phone 8 Added vibration cancelling support for Windows Phone 8 [JIRA issue](https://issues.apache.org/jira/browse/CB-8018) You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-plugin-vibration CB-8018 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-vibration/pull/26.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #26 commit 621984529a2ecaa4879012aeef078413742d5797 Author: daserge dase...@yandex.ru Date: 2014-11-14T16:30:11Z CB-8018 Add vibrate(pattern) fallback on vibrate for Windows Phone 8 Added vibrate(pattern) fallback on vibrate for Windows Phone 8 Added vibration cancelling support for Windows Phone 8 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: I've fixed an issue. What's next?
Well, I think what you've just done (pinging the list) is pretty close to the right next step. You should probably assign the issue back to Shaz with a note directed to him asking him to take a look and merge it in. (I'd merge it, but I haven't been following iOS 8 development closely enough to judge its correctness) And thanks for taking it on! Ian On Fri Nov 14 2014 at 2:32:14 AM julio cesar sanchez jcesarmob...@gmail.com wrote: CB-7734 (https://issues.apache.org/jira/browse/CB-7734) was reported and I asked if it could be assigned to me. Shazron assigned to me and I fixed it with this pull request https://github.com/apache/cordova-plugin-dialogs/pull/39 It's been 3 weeks and it hasn't been merged, so I don't know if I have to do something else, it's the first issue assigned to me.
[GitHub] cordova-cli pull request: support for searchpath option to restore...
GitHub user gorkem opened a pull request: https://github.com/apache/cordova-cli/pull/197 support for searchpath option to restore plugins Correctly passes the searchpath option to restore command. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gorkem/cordova-cli restore_searchpath Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-cli/pull/197.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #197 commit d23f4b8bb148bfc8afd86913337ade1df5238ebf Author: Gorkem Ercan gorkem.er...@gmail.com Date: 2014-11-14T17:09:15Z searchpath option is added to restore Correctly passes the searchpath option to restore command. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-lib pull request: Support for searchpath option when resto...
GitHub user gorkem opened a pull request: https://github.com/apache/cordova-lib/pull/120 Support for searchpath option when restoring plugins passes the searchpath option to plugin add You can merge this pull request into a Git repository by running: $ git pull https://github.com/gorkem/cordova-lib restore_searchpath Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-lib/pull/120.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #120 commit e156ed5303ef258103b2d1b9bb7f3b8f6dfb0384 Author: Gorkem Ercan gorkem.er...@gmail.com Date: 2014-11-14T17:12:32Z pass the searchpath when installing plugins passes the searchpath option to plugin add --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-lib pull request: Add a type named gradleReference in fr...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-lib/pull/119 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - 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: Summarizing thoughts on cordova-browser vs Ripple
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 -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Friday, November 14, 2014 4:07 AM To: dev Subject: Re: Summarizing thoughts on cordova-browser vs Ripple 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. var div = ... createUI; ripple.registerPluginUi(div) Still also seems powerful though, to have Ripple be able to add UI for plugins that don't provide their own. On Mon, Nov 10, 2014 at 3:48 PM, Michal Mocny mmo...@chromium.org wrote: On Thu, Nov 6, 2014 at 6:52 PM, Horn, Julian C julian.c.h...@intel.com wrote: I'd like to introduce myself and put in my two cents here. My name is Julian Horn. I work for Intel on the XDK, an integrated development environment for cross-platform HTML5 applications. I am the team lead for the Device Emulator component, which is our Ripple derivative. My background is mostly in software development tools: compilers, debuggers, simulators and analysis tools. I have been working with the Ripple code base for a couple of years now. If I'm understanding the cordova-browser concept, the implementation of a Cordova API for the browser platform should consist of code that bridges between the platform-independent Cordova API and whatever equivalent is available in the current browser session. For example, the camera API getPicture function would invoke the getUserMedia API, which is the closest thing we have to a W3C standard way to take a picture. If the browser doesn't implement this API or the host system doesn't have a camera, then the getPicture call fails with camera unavailable. This seems like a fine way to gradually migrate from packaged apps that rely on native code plugins to pure web apps that rely on the browser to access mobile device resources. This should work great when you have a browser-portable implementation. It may be a challenge with some plugins, since of course Cordova/PhoneGap was designed to cover gaps in browser support. But at least we don't have to wait for a real W3C standard to be agreed. The goal of our XDK product is to facilitate development of cross-platform mobile HTML5 applications. We see the Device Emulator (our Ripple) as enabling developers to test an HTML5 mobile application on the host system. While this is no substitute for testing on real hardware, the Device Emulator does offers some advantages that can accelerate the development process. To summarize quickly: * It’s really fast. * You don't need an array of mobile devices. * You can put off dealing with weird target system quirks until after you get your basic application logic debugged. * You get full native JavaScript debugging, which is faster, simpler, and more available than remote debug. * You can create testing situations that are difficult or impossible to create in real life, such as GPS timeout. * It's a great teaching tool. * It allows you to prototype quickly. Assuming the functionality delivered by Ripple has value (and we find it does), one needs a way to reconcile this with the cordova-browser effort. Here's how I see that working out. One idea is to rely on the browser developer tools to supply emulation support and just drop Ripple. I don't like this much. Today the developer tools emulation UI is fairly primitive, but of
[GitHub] cordova-plugin-vibration pull request: CB-8018 Add vibrate(pattern...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-vibration/pull/26 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [iOS 8] WKWebView moving forward
Update: Xcode 6.1.1 GM seed (Nov 14th 2014) does not include the loadFileURL:readAccessURL: selector in the WKWebView.h header. So the bug fix we are waiting for most likely won't be in iOS 8.1.1 On Mon, Nov 10, 2014 at 3:30 PM, tommy-carlos williams to...@devgeeks.org wrote: Yeah… I’ll try to report some of it and get back to you. -- tommy-carlos williams On 11 November 2014 at 09:50:55, Shazron (shaz...@gmail.com) wrote: Bug report? Or email me personally. Which ones besides the ones that will have problems as we discussed on this thread. On Mon, Nov 10, 2014 at 2:41 PM, tommy-carlos williams to...@devgeeks.org wrote: I had much less success… it doesn’t play well with other legacy plugins, does it? -- tommy-carlos williams On 11 November 2014 at 03:00:30, Michal Mocny (mmo...@chromium.org) wrote: Success! I did indeed have to add the framework manually. Thanks for instructions. On Thu, Nov 6, 2014 at 7:49 PM, Shazron shaz...@gmail.com wrote: There have been major changes to the `wkwebview` branch of `cordova-ios`. The `WKWebView` functionality has been moved to a plugin in the `cordova-plugins` repo. So, for now you can do: cordova create wkwvtest test.project wkwvtest cd wkwvtest cordova platform add ios@wkwebview --usegit cordova plugin add https://github.com/apache/cordova-plugins.git#master:wkwebview-engine Modify the root `config.xml` and edit this value to: content src=http://localhost:0; / Then: cordova emulate You might get a build error, this is a `plugman` bug that doesn't install `WebKit.framework` properly even though it is defined in plugin.xml. You might have to do a: open -a Xcode platforms/ios ...and add the framework manually. On Thu, Nov 6, 2014 at 11:15 AM, Shazron shaz...@gmail.com wrote: Thanks Tony - I'll look at that PR when I have some time. Yesterday I did some major work to isolate the webviews into plugins (CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the risk by extracting the WKWebView items into a plugin, and the core has no dependency on WebKit.framework anymore, plus speedy (well, speedier) updates if it needs updating. The CDVUIWebViewEngine will remain in the core as the default engine. I'm still working on this, but it already works currently. I'm abstracting things out more, and removing code from the CDVViewController which has become unwieldy. Swapping out engines would use the preference: preference name=CordovaWebViewEngine value=CDVWKWebViewEngine / Any new web engine needs to implement the new CDVWebViewEngineProtocol protocol, and installed as a plugin. On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony tony.ho...@intel.com wrote: I have already forked it and made the changes in a topic branch. I was originally thinking that I would make 2 topic branches: 1 for localhost-only and 1 for auth tokens. However, after I finished the first set of changes I realized that the second set would be dependent on the first. I’ll submit a pull request tomorrow for you to look at - I’ll be happy to redo it as multiple branches if that makes sense. I got a little sidetracked with local web server plugin, but I’ve also forked cordova-ios and made a topic branch from wkwebview. I'll start working on some of the changes I proposed earlier in this thread tomorrow (for plugins like camera that return file:// urls, etc.). Tony On 11/3/14, 7:23 PM, Shazron shaz...@gmail.com wrote: Thanks Tony for all the investigation. Please do fork the local web server plugin and put all your work in topic branches for eventual pull requests to the main repo. This is precisely why the local web server is a plugin, and not in the core. I don't profess to be a security expert, and we can update this plugin to cover most of the security cases or someone else can provide their better plugin. I don't think this needs to be bulletproof, not that we can entirely be (has there ever been a Security Update by Apple that *didn't* include a WebKit vulnerability?) I'd like to get the cordova-ios/wkwebview branch back into the mainline as soon as possible, but under an experimental flag (--experimental ?) for bin/create. This will choose a new template that has WebKit.framework in it, which will also define a macro to conditionally compile the new bits in (I haven't added the macros yet in the topic branch). On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony tony.ho...@intel.com wrote: I spent a lot of time thinking about ways to avoid replay attacks for the local web server plugin this weekend. Specifically, I felt like there should be a way
Re: I've fixed an issue. What's next?
Thanks Julio! I'll comment on the PR itself. Shaz On Fri, Nov 14, 2014 at 8:42 AM, Ian Clelland iclell...@chromium.org wrote: Well, I think what you've just done (pinging the list) is pretty close to the right next step. You should probably assign the issue back to Shaz with a note directed to him asking him to take a look and merge it in. (I'd merge it, but I haven't been following iOS 8 development closely enough to judge its correctness) And thanks for taking it on! Ian On Fri Nov 14 2014 at 2:32:14 AM julio cesar sanchez jcesarmob...@gmail.com wrote: CB-7734 (https://issues.apache.org/jira/browse/CB-7734) was reported and I asked if it could be assigned to me. Shazron assigned to me and I fixed it with this pull request https://github.com/apache/cordova-plugin-dialogs/pull/39 It's been 3 weeks and it hasn't been merged, so I don't know if I have to do something else, it's the first issue assigned to me.
Re: [iOS 8] WKWebView moving forward
le *sigh* :-( ___ *Kerri Shotts* photoKandy Studios, LLC
Re: I've fixed an issue. What's next?
General question to everybody: The patch requires the iOS 8 SDK (i.e. Xcode 6). We require Xcode 6 in cordova-ios 3.7.0 and there was consensus on it. However, the plugin.xml itself does not have an engine tag to specify what it supports. Question: Do we have engine tag support in the CLI, where it won't install a plugin if the requirements are not met? If not, we would have to do a #ifdef __IPHONE_8_0 macro in the code. On Fri, Nov 14, 2014 at 11:18 AM, Shazron shaz...@gmail.com wrote: Thanks Julio! I'll comment on the PR itself. Shaz On Fri, Nov 14, 2014 at 8:42 AM, Ian Clelland iclell...@chromium.org wrote: Well, I think what you've just done (pinging the list) is pretty close to the right next step. You should probably assign the issue back to Shaz with a note directed to him asking him to take a look and merge it in. (I'd merge it, but I haven't been following iOS 8 development closely enough to judge its correctness) And thanks for taking it on! Ian On Fri Nov 14 2014 at 2:32:14 AM julio cesar sanchez jcesarmob...@gmail.com wrote: CB-7734 (https://issues.apache.org/jira/browse/CB-7734) was reported and I asked if it could be assigned to me. Shazron assigned to me and I fixed it with this pull request https://github.com/apache/cordova-plugin-dialogs/pull/39 It's been 3 weeks and it hasn't been merged, so I don't know if I have to do something else, it's the first issue assigned to me.
Re: I've fixed an issue. What's next?
On Fri Nov 14 2014 at 2:24:41 PM Shazron shaz...@gmail.com wrote: General question to everybody: The patch requires the iOS 8 SDK (i.e. Xcode 6). We require Xcode 6 in cordova-ios 3.7.0 and there was consensus on it. However, the plugin.xml itself does not have an engine tag to specify what it supports. Question: Do we have engine tag support in the CLI, where it won't install a plugin if the requirements are not met? We certainly do, for Android at least -- I've been using it for Crosswalk development, and it works (I get caught every time I switch back to master, and the crosswalk plugin refuses to install :) ) If not, we would have to do a #ifdef __IPHONE_8_0 macro in the code. On Fri, Nov 14, 2014 at 11:18 AM, Shazron shaz...@gmail.com wrote: Thanks Julio! I'll comment on the PR itself. Shaz On Fri, Nov 14, 2014 at 8:42 AM, Ian Clelland iclell...@chromium.org wrote: Well, I think what you've just done (pinging the list) is pretty close to the right next step. You should probably assign the issue back to Shaz with a note directed to him asking him to take a look and merge it in. (I'd merge it, but I haven't been following iOS 8 development closely enough to judge its correctness) And thanks for taking it on! Ian On Fri Nov 14 2014 at 2:32:14 AM julio cesar sanchez jcesarmob...@gmail.com wrote: CB-7734 (https://issues.apache.org/jira/browse/CB-7734) was reported and I asked if it could be assigned to me. Shazron assigned to me and I fixed it with this pull request https://github.com/apache/cordova-plugin-dialogs/pull/39 It's been 3 weeks and it hasn't been merged, so I don't know if I have to do something else, it's the first issue assigned to me.
Re: I've fixed an issue. What's next?
Nope, just wait patiently. Someone will get to it soon. @purplecabbage risingj.com On Thu, Nov 13, 2014 at 11:31 PM, julio cesar sanchez jcesarmob...@gmail.com wrote: CB-7734 (https://issues.apache.org/jira/browse/CB-7734) was reported and I asked if it could be assigned to me. Shazron assigned to me and I fixed it with this pull request https://github.com/apache/cordova-plugin-dialogs/pull/39 It's been 3 weeks and it hasn't been merged, so I don't know if I have to do something else, it's the first issue assigned to me.
Re: cordova-browser plugin polyfills -- which projects already have work in this space?
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: I've fixed an issue. What's next?
Maybe we should have it auto grab an older version of the plugin that is supported? Or at least a better error message telling them to try older versions of the plugin with cordova plugin add org.apache.cordova.file@VERSION On Fri, Nov 14, 2014 at 11:49 AM, Michal Mocny mmo...@chromium.org wrote: I just added this to org.apache.cordova.file's plugin.xml as a test: engines engine name=cordova-ios version==4.0.0 / /engines Then tried to install that version locally in a project, and got: Installing org.apache.cordova.file for ios Failed to install 'org.apache.cordova.file':CordovaError: Plugin doesn't support this project's cordova-ios version. cordova-ios: 3.6.3, failed version requirement: =4.0.0 Would probably prefer to clean up the error a bit, but seems to work well. On Fri, Nov 14, 2014 at 2:33 PM, Ian Clelland iclell...@chromium.org wrote: On Fri Nov 14 2014 at 2:24:41 PM Shazron shaz...@gmail.com wrote: General question to everybody: The patch requires the iOS 8 SDK (i.e. Xcode 6). We require Xcode 6 in cordova-ios 3.7.0 and there was consensus on it. However, the plugin.xml itself does not have an engine tag to specify what it supports. Question: Do we have engine tag support in the CLI, where it won't install a plugin if the requirements are not met? We certainly do, for Android at least -- I've been using it for Crosswalk development, and it works (I get caught every time I switch back to master, and the crosswalk plugin refuses to install :) ) If not, we would have to do a #ifdef __IPHONE_8_0 macro in the code. On Fri, Nov 14, 2014 at 11:18 AM, Shazron shaz...@gmail.com wrote: Thanks Julio! I'll comment on the PR itself. Shaz On Fri, Nov 14, 2014 at 8:42 AM, Ian Clelland iclell...@chromium.org wrote: Well, I think what you've just done (pinging the list) is pretty close to the right next step. You should probably assign the issue back to Shaz with a note directed to him asking him to take a look and merge it in. (I'd merge it, but I haven't been following iOS 8 development closely enough to judge its correctness) And thanks for taking it on! Ian On Fri Nov 14 2014 at 2:32:14 AM julio cesar sanchez jcesarmob...@gmail.com wrote: CB-7734 (https://issues.apache.org/jira/browse/CB-7734) was reported and I asked if it could be assigned to me. Shazron assigned to me and I fixed it with this pull request https://github.com/apache/cordova-plugin-dialogs/pull/39 It's been 3 weeks and it hasn't been merged, so I don't know if I have to do something else, it's the first issue assigned to me.
Re: I've fixed an issue. What's next?
Michal Mocny wrote: I just added this to org.apache.cordova.file's plugin.xml as a test: engines engine name=cordova-ios version==4.0.0 / /engines Then tried to install that version locally in a project, and got: Installing org.apache.cordova.file for ios Failed to install 'org.apache.cordova.file':CordovaError: Plugin doesn't support this project's cordova-ios version. cordova-ios: 3.6.3, failed version requirement: =4.0.0 Would probably prefer to clean up the error a bit, but seems to work well. Hrm, does that mean that someone using an old version of a platform can't install *any* version of a plugin (easily) if the latest version requires a newer platform? That'd be rather unfortunate…
Re: I've fixed an issue. What's next?
I know that it is unfortunate that's why I think the macro solution instead of the engine solution is best for core plugins (I discovered from the spec I could use 'apple-xcode' and 'apple-ios' to further differentiate, but never mind). We can take care of this as committers for the core plugins by using the macros, but a lot of plugin authors and contributors are careless in that: 1. They either don't use an engine tag 2. Or they don't adequately protect newer iOS SDK calls from crashing on older iOS runtime. Sure, it compiles in iOS 8 SDK, but if a user runs it on an iOS 6 or 7 device, it will crash when it reaches that iOS 8 API function. I don't think there are any open source linters out there that will help us with this (there is a commercial one: http://www.deploymateapp.com) On Fri, Nov 14, 2014 at 11:54 AM, Josh Soref jso...@blackberry.com wrote: Michal Mocny wrote: I just added this to org.apache.cordova.file's plugin.xml as a test: engines engine name=cordova-ios version==4.0.0 / /engines Then tried to install that version locally in a project, and got: Installing org.apache.cordova.file for ios Failed to install 'org.apache.cordova.file':CordovaError: Plugin doesn't support this project's cordova-ios version. cordova-ios: 3.6.3, failed version requirement: =4.0.0 Would probably prefer to clean up the error a bit, but seems to work well. Hrm, does that mean that someone using an old version of a platform can't install *any* version of a plugin (easily) if the latest version requires a newer platform? That'd be rather unfortunate…
[GitHub] cordova-plugin-dialogs pull request: Fix CB-7734. Changed plugin t...
Github user shazron commented on the pull request: https://github.com/apache/cordova-plugin-dialogs/pull/39#issuecomment-63123720 Hi Julio, I'm sure you will have followed the dev@ discussion by now. Two changes are required, since you are using iOS 8 API code. 1. Change your use of `[UIAlertController class]` to `NSClassFromString(@UIAlertController)`. On iOS devices iOS 8 your code will crash. 2. Wrap the whole code block with iOS 8 code with `#ifdef __IPHONE_8_0`. This way people using the Xcode 5 (which is still allowed by Apple) will not have compilation errors. I would test the adjusted code out on an iOS 7 and iOS 8 device, and compile using Xcode 5 and 6. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: I've fixed an issue. What's next?
Steven Gill wrote: Maybe we should have it auto grab an older version of the plugin that is supported? Or at least a better error message telling them to try older versions of the plugin with cordova plugin add org.apache.cordova.file@VERSION Ian Clelland wrote: I'd love to have the plugin registry automatically serve the most-recent-still-compatible version of a plugin. I don't know how that works when you install plugins *before* platforms, though. I think plugman or someone at a prepare stage when a platform installs could warn and try (network could be offline) to get a compatible version. Note that there's an interesting problem here: Suppose I have 1 plugin, and I install version 20 of it to my project. I then install platform A which is happy w/ version 20. I then install platform B which only works w/ version 19, so something automatically installs version 19 for this platform. If the API between the two versions isn't compatible (and we don't have an api validator to tell the developer if it is), then the resulting app won't work properly on that platform.
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: cordova-browser plugin polyfills -- which projects already have work in this space?
Does the browser platform always target Chrome? When implementing the browser platform in a plugin can I access protected chrome APIs such as https://developer.chrome.com/apps/bluetooth and https://developer.chrome.com/apps/bluetoothLowEnergy? On Fri, Nov 14, 2014 at 4:07 PM, Ray Camden rayca...@adobe.com wrote: 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: cordova-browser plugin polyfills -- which projects already have work in this space?
No. Or if it does, it won't ... You should use feature detection to determine if you can respond correctly to an API call, and/or throw a descriptive error if you cannot make it work. @purplecabbage risingj.com On Fri, Nov 14, 2014 at 1:29 PM, Don Coleman don.cole...@gmail.com wrote: Does the browser platform always target Chrome? When implementing the browser platform in a plugin can I access protected chrome APIs such as https://developer.chrome.com/apps/bluetooth and https://developer.chrome.com/apps/bluetoothLowEnergy? On Fri, Nov 14, 2014 at 4:07 PM, Ray Camden rayca...@adobe.com wrote: 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: cordova-browser plugin polyfills -- which projects already have work in this space?
Also - I believe those APIs are available only to Chrome apps extensions. I do know though, that Chrome team is trying to make bluetooth on the open web a thing: https://github.com/WebBluetoothCG/web-bluetooth. I doubt all the access that you'd want will be available any time soon though (they are targeting just the safe subset of Bluetooth). On Fri, Nov 14, 2014 at 10:35 PM, Jesse purplecabb...@gmail.com wrote: No. Or if it does, it won't ... You should use feature detection to determine if you can respond correctly to an API call, and/or throw a descriptive error if you cannot make it work. @purplecabbage risingj.com On Fri, Nov 14, 2014 at 1:29 PM, Don Coleman don.cole...@gmail.com wrote: Does the browser platform always target Chrome? When implementing the browser platform in a plugin can I access protected chrome APIs such as https://developer.chrome.com/apps/bluetooth and https://developer.chrome.com/apps/bluetoothLowEnergy? On Fri, Nov 14, 2014 at 4:07 PM, Ray Camden rayca...@adobe.com wrote: 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
[GitHub] cordova-plugin-dialogs pull request: Fix CB-7734. Changed plugin t...
Github user jcesarmobile commented on the pull request: https://github.com/apache/cordova-plugin-dialogs/pull/39#issuecomment-63144935 [UIAlertController class] doesn't crash on iOS 7 devices if you compile it on xcode 6 using iOS 8 SDK. I'm making the changes for Xcode 5 right now --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-dialogs pull request: Fix CB-7734. Changed plugin t...
Github user shazron commented on the pull request: https://github.com/apache/cordova-plugin-dialogs/pull/39#issuecomment-63145321 In any case, NSClassFromString is the safest thing you can do, and is the best practice for supporting iOS 8-6. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-dialogs pull request: Fix CB-7734. Changed plugin t...
Github user jcesarmobile commented on the pull request: https://github.com/apache/cordova-plugin-dialogs/pull/39#issuecomment-63145889 done --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-dialogs pull request: Fix CB-7734. Changed plugin t...
Github user bau720123 commented on the pull request: https://github.com/apache/cordova-plugin-dialogs/pull/39#issuecomment-63158994 I am the original post https://issues.apache.org/jira/browse/CB-7734 well... really thanks for @jcesarmobile and @shazron help --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
