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:46:44 GMT
One more thing: the specific implementation changes to cordova-js (for
platform overrides and cleaning up the platform definition files) is being
tracked in that issue Pat linked to:
https://issues.apache.org/jira/browse/CB-280

On 3/19/12 10:43 AM, "Filip Maj" <fil@adobe.com> wrote:

>+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