Joe- As far as I can tell, the API 23 calls are currently unguarded so smores will only work on M Preview. I know your smores branch is a POC, but I was wondering about backwards compatibility. Do you anticipate adding Build.VERSION.SDK_INT >= Build.VERSION_CODES.M guard clauses for backwards compatibility?
Tony On 9/23/15, 1:56 PM, "Joe Bowser" <[email protected]> wrote: >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <[email protected]> >wrote: > >> No need to major version change for the Plugins, the API of the didn't >> change. >> Web developer still uses the same JS API to use the plugin. >> >> >I would do a major version bump on Geolocation. The API itself didn't >change but the behaviour certainly did. On Marshmallow we have to add >this >extra shim that asks for permission, which means that there's now code >attached to Android Geolocation that didn't exist before. All the other >plugins should still be fine. > > >> Yes I did some thinking around the plugin search website. I think is a >>good >> topic for the F2F. >> Now that IBM is using Cordova Plugin more heavily to package our mobile >> SDKs using Cordova Plugins, I think is beneficial to expose more info >>about >> the plugin including engine tags >> >> I would not go and build our own backend and have our own registry with >> cordova metadata. >> >> I think the solution is to put the metadata of plugin.xml into >> package.json. We can show fast results in main search, but then user can >> drill into the plugin details, and we can have a view with more >>information >> and allow the user to select a specific version like we have today in >>our >> plugin website search using the cordova registry. >> >> The website can fetch the package.json and it will have the information >>to >> display to the user. >> >> So what I think we need to do is document and automate the information >>from >> plugin.xml including engine tags into the package.json. >> >> Today we have some sort of duplicate information between the "cordova" >>and >> "keywords", I think it would be a good time to clean it up and add an >>array >> in cordova.engines >> >> >> >> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal >><[email protected] >> > >> wrote: >> >> > Merging threads. I was no aware of any security implications of using >> > reflection - Perhaps if the reflection target can be controlled >>through >> > external data. In any case, I understand your hesitation with use of >> > reflection. I would love to have longer discussions on the F2F on what >> > approaches we could use to make this easier for Cordova developers. >> > >> > Joe: Could you add the appropriate engine tags in any case? That's how >> > Cordova currently handles versioning between plugins & platforms. >>Also, >> > does this imply that the plugins should have a major version bump as >>it >> is >> > a breaking change? Please create the 5.x branches and if you could >> submit a >> > PR - I had other minor code review comments on the diffs below. >> > >> > Carlos: I understand in the extreme case it can be a fairly >>complicated >> > implementation with lots of criteria to use to determine the ideal >>plugin >> > that might work given a set of platforms. However, trying a couple of >> > previous versions of the plugins might work 80% of the time and that >> might >> > be good enough. This requires more thought as there are quite a few >> > scenarios here. >> > >> > As for plugin search website helping you find the correct engine tags >>- I >> > like the idea. But this might requires us maintaining a backend for >> plugin >> > search as this is specified in plugin.xml (and not package.json - or >>did >> we >> > finally move this?). >> > >> > Thanks, >> > Nikhil >> > >> > -----Original Message----- >> > From: Carlos Santana [mailto:[email protected]] >> > Sent: Tuesday, September 22, 2015 6:14 PM >> > To: [email protected] >> > Subject: Re: [Android] 5.0.x release branch? >> > >> > +1 we should always use the engine tag to mark the minimum compatible >> > +version at least >> > >> > -1 for cordova CLI to automagically to install an older version. It >>will >> > be a pain to get this implemented right, we would need to download all >> the >> > package.json for multiple versions of the plugin and pick the lowest >> common >> > denominator based on engine tags and remember that one plugin support >> > multiple engine tags across different platform versions and >>CLI/plugman. >> > >> > This brings an interesting feature to implement In the plugin search >> > website, to display the engine tags for a specific plugin version. >> Allowing >> > a developer to search for a compatible plugin for their current app. >> > >> > - Carlos >> > Sent from my iPhone >> > >> > >> > -----Original Message----- >> > From: Joe Bowser [mailto:[email protected]] >> > Sent: Tuesday, September 22, 2015 6:17 PM >> > To: [email protected] >> > Subject: Re: [Android] 5.0.x release branch? >> > >> > I'm completely against using reflection for this purpose. Version >>codes >> > were invented for a reason and we don't have any mechanism in place to >> unit >> > test any Android code (or any other native code on any of the >>platforms). >> > >> > I will vote against any release that includes reflection for this >>purpose >> > since reflection has only brought us security issues and extreme >>WebView >> > breakage when used (Simon can tell you the tales of the HTC >>console.log >> > reflection code.). Reflection is a worst-case scenario tool like >>when a >> > method in WebView marked as deprecated completely disappears, not >> something >> > we should make a habit of using often. If we open the door for this, >> we'll >> > get reflection creeping elsewhere, like the Plugins API. >> > >> > Just say no to reflection. >> > >> > >> > On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal >><[email protected]> >> > wrote: >> > >> > > Thanks, Joe for the detailed explanation. I understand why we've >>taken >> > > this route. It's good that this is only a build failure. One of the >> > > complaints we commonly hear from Cordova developers is that "I have >>a >> > > cordova project with a certain version of the platform, I need to >>find >> > > the plugin that will work with it". Our CLI always defaults to add >>the >> > > latest released version of the plugin. >> > > >> > > After this breaking change, an existing cordova project with >> > > cordova-android < 5.x, cannot build with the latest version of the >> > > following plugins: >> > > - camera >> > > - geolocation >> > > - contacts. >> > > These are some of the most popular plugins in cordova plugin >>ecosystem >> > [1]. >> > > >> > > I propose that we should do our best to avoid disruptive breaking >> > > changes here. Some ideas that come to mind: >> > > - As Joe mentioned below - reflection. It has the downsides that Joe >> > > mentioned. No one likes to write code like this it but results in >> > > least grief for Cordova users. Some pain here for plugin developers >> > > will simplify the experience for large number of corodva JS >> > > developers. I know we are doing some of this in cordova-ios [2] and >> > > would love to find ways on how to make this manageable and not super >> > ugly. >> > > - Add an '<engine name="cordova-android" version=">=5.0.0" /> ' to >> > > the plugins - failure happens at plugin add in this scenario. >> > > Cordova-lib could be more intelligent to detect this error and >>resort >> > > to using an older version of the plugin. The downside of this is >>that >> > > these projects cannot use the latest and greatest of these plugins. >> > > >> > > Thanks, >> > > Nikhil >> > > >> > > [1] >> > > >>https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov >> > > >>a.apache.org%2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da >> > > >>ta=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a100510734c0605f508d2c3b4b9 >> > > >>c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46 >> > > kkRG%2bZp3KarDUTf2y0i7P5I%3d >> > > [2] >> > > >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu >> > > >>b.com%2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC >> > > >>DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a1005107 >> > > >>34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH >> > > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d >> > > >> > > Thanks, >> > > Nikhil >> > > >> > > >> > > -----Original Message----- >> > > From: Joe Bowser [mailto:[email protected]] >> > > Sent: Monday, September 21, 2015 6:32 PM >> > > To: [email protected] >> > > Subject: Re: [Android] 5.0.x release branch? >> > > >> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal >> > > <[email protected]> >> > > wrote: >> > > >> > > > Can you explain why latest plugins will not be compatible with >>older >> > > > versions of Cordova? >> > > >> > > >> > > They won't be compatible because Cordova-Android compiles against >>API >> > > 22, and these plugins will require API 23 so that they can detect >> > > permissions and support Marshmellow. >> > > >> > > >> > > > Can this be avoided by any means? >> > > >> > > >> > > Only with a lot of Java reflection, and I'd rather not subject >>plugin >> > > developers to that, or try to hide it under the hood in some awful >> > > utility class that everyone will want to see die. I'm very much a >>fan >> > > of if statements because they work, and they're easy to read and >> > > debug, unlike when bad things happen to things you reflect into. >> > > Plugins that require API 23 will only work with Cordova-Android 5.0 >> > > and up. This only impacts five of our core plugins, but any plugin >> > > that requires permissions from the Android Manifest will have to be >> > > updated. If we can avoid using advanced language tricks to make the >> > APKs compatible, we should do that. >> > > >> > > When you mean they would not be compatible - will it result in a >>build >> > > or >> > > > runtime failure? >> > > > >> > > > >> > > This will be a build failure, since API 22 does not have these >> > > permissions, nor does it have the code required for API 23. >> > > >> > > >> > > > For marshmallow, what is the guidance that we need to issue to the >> > > > larger Cordova plugin ecosystem? Joe you are ahead of the curve >>here >> > > > compared to most other plugin developers - a blot post explaining >> > > > what are known gotchas would be great. I really hope we can use >>our >> > > > Cordova blog to communicate these changes actively to the plugin >> > ecosystem. >> > > > This mailing list only gets 400+ subscribers. >> > > > >> > > > >> > > There will be a blog post once 5.0 is released. We're not forcing >> > > people to upgrade to 5.0, and we will be supporting the 4.x branch >>for >> > > six months. This does mean we're stuck supporting 3.x, 4.x and 5.x >> > > for a brief window, but I have no control over when Marshmallow is >> > > released, only whether we want to support it or not. I think we do, >> but >> > I could be wrong. >> > > >> > > At least this should be easier than the jump from 3.x to 4.x for >>most >> > > people, but the alternative is that your plugin just doesn't work at >> > > all on Marshmallow. We need to at least give plugin developers this >> > > option, since it'll roll out on all the Nexus devices in the next >>two >> > > weeks, and we'll hear more about it. >> > > >> > > >> > > > Can you re-base your cordova-android over the current master? It's >> > > > hard to see a diff in the current form: >> > > > >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit >> > > > hu >> > > > >>b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo >> > > > re >> > > > >>s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2 >> > > > c2 >> > > > >>edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ >> > > > lv >> > > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d >> > > > >> > > > >> > > I had to do a merge commit to get this to happen (boo), but it >>should >> > > be mostly cleaned up now. It seems some style cleanup creeped into >> > > the most recent changes, but this should be a bit more readable. >> > > >> > > >> > > > -Nikhil >> > > > >> > > > -----Original Message----- >> > > > From: Joe Bowser [mailto:[email protected]] >> > > > Sent: Monday, September 21, 2015 2:14 PM >> > > > To: dev <[email protected]> >> > > > Subject: [Android] 5.0.x release branch? >> > > > >> > > > Hey >> > > > >> > > > In the next two weeks, Marshmallow will most likely getting >>released >> > > > with the brand new Nexus 6P being released from Huawei. Given >>that >> > > > most of the Nexus devices will be getting this release, we should >> > > > probably release the 5.0.x branch of Android soon, and get the new >> > > plugins updated. >> > > > >> > > > It should be noted that the latest plugins will not be compatible >> > > > with older versions of Cordova, which is a big deal. This is due >>to >> > > > the use of various compatibility checks to make sure they support >> > > > Marshmallow and older versions of Android. >> > > > >> > > > So, if everyone can look over the smores branches of my GitHub >> > > > before I create the 5.0.x branch and pull the changes into it, >>that >> > > > would be >> > > awesome. >> > > > >> > > > >> > > > >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit >> > > > hu >> > > > >>b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni >> > > > kh >> > > > >>ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86 >> > > > f1 >> > > > >>41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07% >> > > > 2b >> > > > ve4PVcCE%3d >> > > > >> > > > >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit >> > > > hu >> > > > >>b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0 >> > > > 1% >> > > > >>7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7 >> > > > c7 >> > > > >>2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv >> > > > 6p >> > > > c5qbeY%2bdUxiP4bc%3d >> > > > >> > > > >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit >> > > > hu >> > > > >>b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0 >> > > > 1% >> > > > >>7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9 >> > > > 88 >> > > > >>bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG >> > > > Rb >> > > > 4zWC8maWpE%3d >> > > > >> > > > >>https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit >> > > > hu >> > > > >>b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7 >> > > > c0 >> > > > >>1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72 >> > > > f9 >> > > > >>88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2 >> > > > fe >> > > > EmqLOdU%2fwua2TbLU%3d >> > > > >> > > > Work on audio is still outstanding, BUT for some reason Audio >>broke >> > > > recently on both Lollipop and Marshmallow. I didn't test it out >>on >> > > > KitKat or Jellybean yet, but I'm wondering whether we should keep >> > > > maintaining this or support the standard HTML5 audio and deal with >> > > > the asset issue somehow (which isn't straight forward). >> > > > >> > > > I hopefully want to get a 5.0.x branch happening this week if we >>can. >> > > > >> > > > What do people think? >> > > > >> > > > Joe >> > > > >> > > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
