cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Contacts API, iOS
Date Wed, 25 Jun 2014 02:14:00 GMT
On Tue, Jun 24, 2014 at 4:45 PM, Carlos Santana <csantana23@gmail.com>
wrote:

> I don't have a problem having a new signature. But I think the old
> signature should still work.
>
> If you decide to support both signatures, I would like to see first  unit
> test running in mobile spec it should test that both ways work.
>

This is definitely important. Not doing this is a major breaking change,
meaning we'd need to increment the major version, and inconvenience every
app developer who has already implemented this API, just so that we can
break compatibility with a spec.


>
> I don't mind to have a new signature added since the w3c contacts spec api
> is dead from what I can tell here [1]
>


The contacts spec *is* really out of date, and the whole thing should
probably be overhauled. If we're going to go as far as bumping the major
version, and pushing something like "Contacts2", then we might as well look
at implementing a better API completely. I wouldn't do it just to switch
arguments around.

Ian


> I guess it was implemented this way following the w3c spec api [2] had the
> signature having filter first [3]
>
> [1]:http://www.w3.org/TR/contacts-api
>
> [2]: http://www.w3.org/TR/2011/WD-contacts-api-20110616/#methods-1
>
> [3]:caller void find
> <
> http://www.w3.org/TR/2011/WD-contacts-api-20110616/#widl-Contacts-find-caller-void-DOMStringArray-fields-ContactFindCB-successCB-ContactErrorCB-errorCB-ContactFindOptions-options
> >
> (DOMString[] fields, ContactFindCB
> <http://www.w3.org/TR/2011/WD-contacts-api-20110616/#idl-def-ContactFindCB
> >
> successCB, optional ContactErrorCB
> <
> http://www.w3.org/TR/2011/WD-contacts-api-20110616/#idl-def-ContactErrorCB
> >
> errorCB, optional ContactFindOptions
> <
> http://www.w3.org/TR/2011/WD-contacts-api-20110616/#idl-def-ContactFindOptions
> >
> options);
>
>
> On Tue, Jun 24, 2014 at 4:15 PM, Sergey Grebnov (Akvelon) <
> v-segreb@microsoft.com> wrote:
>
> > The signature change was made by me to be compliant with the rest of
> > cordova core plugins where we always have callbacks first and then call
> > parameters.
> >
> > The important note is that I used special check for the args type to work
> > correctly in case old method signature is used. I will see when it was
> > missed.
> >
> > Do you like the idea of changing method signature and making it work for
> > old version or it is better just to revert it back? - Thoughts?
> >
> > Thx!
> > Sergey
> > -----Original Message-----
> > From: Carlos Santana [mailto:csantana23@gmail.com]
> > Sent: Tuesday, June 24, 2014 11:55 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Contacts API, iOS
> >
> > I took a few minutes to look deeper on what's going on with Contacts
> > Plugin.
> > Here are my findings:
> >
> > Back in April [1] when navigator.contacts.pickContact() was added the
> > signature for navigator.contacts.find() was changed
> > From:
> > navigator.contacts.find:function(fields, successCB, errorCB, options) {
> > To:
> > navigator.contacts.find:function(successCB, errorCB, fields, options) {
> >
> > I think this is a braking change and the reason why mobilespec is
> failing.
> >
> > If there are no objections I think the find method should be put back as
> > it was before publishing a new version with a different api signature. I
> > created an issue [2] to track
> >
> > Or if the consensus is for find function to have a new signature, then
> the
> > version of the plugin needs to be increase to reflect the api break, and
> > maybe a note in the doc.
> >
> > I also created another issue [3] to create tests for pickContact in
> > mobilespec
> >
> > [1]:
> >
> >
> https://github.com/apache/cordova-plugin-contacts/commit/d656191c4072cbef0bf5b3b5f5eb4dfe4817d25b#diff-6a72b46d7f0c34e1070ce85b959f30fcR46
> >
> > [2]: https://issues.apache.org/jira/browse/CB-7020
> >
> > [3]: https://issues.apache.org/jira/browse/CB-7021
> >
> > --Carlos
> >
> >
> >
> > On Mon, Jun 23, 2014 at 4:21 PM, Sergey Grebnov (Akvelon) <
> > v-segreb@microsoft.com> wrote:
> >
> > > As a note - pickContact functionality exists in repo/master only and
> > > has not been released to plugins registry yet.
> > >
> > > Thx!
> > > Sergey
> > > -----Original Message-----
> > > From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of
> > > Andrew Grieve
> > > Sent: Monday, June 23, 2014 9:42 PM
> > > To: dev
> > > Subject: Re: Contacts API, iOS
> > >
> > > Yes - meant plugins registry.
> > >
> > > right now the plugin links point to github, so you always see master
> > >
> > > I don't think we should concern ourselves with correcting docs for old
> > > versions of plugins. It's a similar argument to fix bugs in old
> > > versions of plugins (any changes create a new version).
> > >
> > >
> > > On Mon, Jun 23, 2014 at 11:37 AM, Ray Camden <raycamde@adobe.com>
> wrote:
> > >
> > > > 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 <csantana23@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.
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <csantana23@gmail.com>
> >
>
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message