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: | Becky Gibson (gibs...@gmail.com) | |
| Date: | Mar 19, 2012 12:08:55 pm | |
| List: | org.apache.incubator.callback-dev | |
Not to belabor the point but I want to make sure we all understand the details.
The whole idea behind changing the iOS implementation is to make it more efficient and NOT use a timer to request the heading. However, the watchHeading Javascript is written to repeatedly call the device getHeading api based on a timer. In order to implement the more iOS specific version with a filter option I will need iOS specific JavaScript code. This code would use the standard timer implementation if no filter parameter if provided but would call out to the iOS watchHeadingFilter device implementation if one is provided.
Thus, there are no additional JavaScript apis for iOS, the optional implementation is hidden in the existing watchFilter api. However, it does have the implication that iOS will now have a device specific implementation of the JavaScript watchHeading definition. I assume folks are comfortable with that?
-becky
On Mon, Mar 19, 2012 at 2:10 PM, Patrick Mueller <pmue...@gmail.com> wrote:
Ah, I see what you're talking about now Becky.
On Mon, Mar 19, 2012 at 13:39, 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.
+1 on enabling additional functionality via 'options' passed to an API +1 on not adding additional methods to enable additional functionality in an API
-- Patrick Mueller http://muellerware.org