14 messages in org.apache.incubator.callback-devRe: Plan for device specific APIs?| From | Sent On | Attachments |
|---|---|---|
| Becky Gibson | Mar 19, 2012 7:45 am | |
| Drew Walters | Mar 19, 2012 7:54 am | |
| Gord Tanner | Mar 19, 2012 7:58 am | |
| Patrick Mueller | Mar 19, 2012 8:23 am | |
| Becky Gibson | Mar 19, 2012 9:16 am | |
| Patrick Mueller | Mar 19, 2012 9:37 am | |
| Becky Gibson | Mar 19, 2012 10:15 am | |
| Jesse MacFadyen | Mar 19, 2012 10:37 am | |
| Filip Maj | Mar 19, 2012 10:42 am | |
| Filip Maj | Mar 19, 2012 10:46 am | |
| Patrick Mueller | Mar 19, 2012 11:09 am | |
| Becky Gibson | Mar 19, 2012 12:08 pm | |
| Filip Maj | Mar 19, 2012 12:15 pm | |
| Patrick Mueller | Mar 19, 2012 1:45 pm |
| Subject: | Re: Plan for device specific APIs? | |
|---|---|---|
| From: | Filip Maj (fi...@adobe.com) | |
| Date: | Mar 19, 2012 10:46:21 am | |
| List: | org.apache.incubator.callback-dev | |
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" <fi...@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" <purp...@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 <gibs...@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 <pmue...@gmail.com> wrote:
On Mon, Mar 19, 2012 at 12:16, Becky Gibson <gibs...@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