cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Homer, Tony" <tony.ho...@intel.com>
Subject Re: [Android] 5.0.x release branch?
Date Wed, 23 Sep 2015 18:22:53 GMT
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" <bowserj@gmail.com> wrote:

>On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana <csantana23@gmail.com>
>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
>><nikhilkh@microsoft.com
>> >
>> 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:csantana23@gmail.com]
>> > Sent: Tuesday, September 22, 2015 6:14 PM
>> > To: dev@cordova.apache.org
>> > 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:bowserj@gmail.com]
>> > Sent: Tuesday, September 22, 2015 6:17 PM
>> > To: dev@cordova.apache.org
>> > 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
>><nikhilkh@microsoft.com>
>> > 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:bowserj@gmail.com]
>> > > Sent: Monday, September 21, 2015 6:32 PM
>> > > To: dev@cordova.apache.org
>> > > Subject: Re: [Android] 5.0.x release branch?
>> > >
>> > > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
>> > > <nikhilkh@microsoft.com>
>> > > 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:bowserj@gmail.com]
>> > > > Sent: Monday, September 21, 2015 2:14 PM
>> > > > To: dev <dev@cordova.apache.org>
>> > > > 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: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message