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