incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plan for device specific APIs?
Date Mon, 19 Mar 2012 17:43:19 GMT
+1 from me in everything turning into a plugin down the road.
+1 for refactoring the filter method into a "quirk" property of the
Compass Options that is iOS-specific

And yes, currently the overriding/merging implementation in the JS is not
optimized. As Pat says, we are wasting bytes every time we do a
platform-specific merge or override. That being said, putting a bit more
love into the build process and platform definition files can solve that
problem.

On 3/19/12 10:39 AM, "Jesse MacFadyen" <purplecabbage@gmail.com> wrote:

>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