+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" <[email protected]> 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 <[email protected]> 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 <[email protected]> >>wrote: >> >>> On Mon, Mar 19, 2012 at 12:16, Becky Gibson <[email protected]> >>> 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 >>>
