incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <purplecabb...@gmail.com>
Subject Re: Plan for device specific APIs?
Date Mon, 19 Mar 2012 17:39:06 GMT
I think the 2 iOS calls for compass can coexist peacefully if it is
refactored to use the filter value as an option in the original call
to watchHeading. Other platforms could ignore this option, or even
implement it and this could be considered a quirk.  Exposing another
method on compass, (and presumably possibly geolocation, and
accelerometer) for this makes no sense to me.

For contact picker functionality IMHO this should be a plugin, but
that does not mean it cannot augment the existing navigator.contact
object.

Cheers,
  Jesse

Sent from my iPhone5

On 2012-03-19, at 10:16 AM, Becky Gibson <gibson.becky@gmail.com> wrote:

>> No, the user would NEVER have to add the new modules/plugin, the build
>> would "make it so".  Is that what you mean by API?  Or do you mean the iOS
>> compass API is SUPPOSED to be different than the portable compass API?  I
>> thought the idea with the 'device-specific' APIs is that a platform could
>> provide an alternate implementation that had the exact same interface.  In
>> the iOS compass case, providing an alternate, closer-to-the-metal, more
>> performant implementation, that still matched the Cordova portable API for
>> compass.
>
> We are on the same page, here.   I guess I didn't explain it well enough.
> iOS DOES implement the 'portable' compass apis which request compass
> headings over time. People developing a cross platform application would
> want to use the portable apis.  However, iOS has additional apis that are
> better suited to reading the compass changes on iOS based on a distance
> filter rather than over time.  I want to add these device specific apis
> into the compass object so someone who is developing only for iOS OR who is
> willing to have divergence in their HTML/JS code could take advantage of
> the more efficient api for iOS.  I just don't understand what our mechanism
> is/will be for achieving this.  The same goes for Contacts - iOS has
> ADDITIONAL features that are currently implemented off of the contact
> object.
>
> I don't want to add them using our current plugin implementation because
> that creates a new JS api  -window.plugins.compass.watchHeadingFilter
> rather than the current navigator.compass.watchHeadingFilter.   But, I'm
> not sure if this type of extension is in our plans?
>
> -becky
>
> On Mon, Mar 19, 2012 at 12:37 PM, Patrick Mueller <pmuellr@gmail.com> wrote:
>
>> On Mon, Mar 19, 2012 at 12:16, Becky Gibson <gibson.becky@gmail.com>
>> wrote:
>>
>>> Ok, so I understand the desire for the JS to be "unified" for development
>>> and testing purposes however,  we still do have device specific versions
>> of
>>> the main Cordova javascript  file. Thus,  I don't see why we can't add
>> the
>>> device specific API's that were already there, back into the "main" JS?
>> If
>>> we do not, then we have broken the existing apis.  A person that was
>> using
>>> the iOS device specific contact apis, now has to add in a plugin and
>> modify
>>> their code to use a different namespace for these apis.
>>>
>>
>> There's a couple of thoughts here.  I DO want to allow for
>> 'platform-specific module implementations' for things like compass.  The
>> only question is how to easily integrate this into the existing source
>> directories, and the build.
>>
>> re: "we have broken the existing apis. A person that was using the iOS
>> device specific contact apis, now has to add in a plugin and modify their
>> code to use a different namespace for these apis."
>>
>> No, the user would NEVER have to add the new modules/plugin, the build
>> would "make it so".  Is that what you mean by API?  Or do you mean the iOS
>> compass API is SUPPOSED to be different than the portable compass API?  I
>> thought the idea with the 'device-specific' APIs is that a platform could
>> provide an alternate implementation that had the exact same interface.  In
>> the iOS compass case, providing an alternate, closer-to-the-metal, more
>> performant implementation, that still matched the Cordova portable API for
>> compass.
>>
>>> I continue to dream of the day when all our
>>>> existing "plugins" are structured as 3rd party plugins anyway.
>>>
>>> However, I don't believe we plan to get to this goal for 1.6. I also
>> don't
>>> believe we will have a mechanism for the user to modify a "standard" file
>>> to select just the features they want in the main cordova js file or to
>>> extend existing objects in the JS file for 1.6?   Thus, when this does
>> get
>>> implemented they will again have to modify their code to adjust the
>> api's.
>>> I think it would be best to mitigate as much of this churn as possible.
>>> IOW I'm advocating for adding the device specific api's into the 1.6 main
>>> cordova js file with the idea that eventually they could be removed when
>> we
>>> provide a user option to selectively add them back in.
>>
>>
>> I don't think that a user of a Cordova plugin, whether it's provided by us,
>> or someone else, in the long term, should even have a choice of whether
>> they get the 'device specific' or 'portable' implementation.  That's up to
>> the plugin provider to decide.  If some user REALLY, REALLY wants to
>> override the implementation of the provider of the plugin, now you're
>> venturing into "fork" territory.  Which is absolutely fine, assuming you
>> know what you're doing.
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
>>

Mime
View raw message