Timeout deference between iOS and Android

[kumo01GitHub]

Which is the way this Cordova plugin should be for Timeout?

• iOS behavior: Timeout start before requesting permission
• Android behavior: Timeout start after requesting permission

I think iOS behavior is more reflective W3C, but Android behavior is intuitively useful.

[breautek]

It does seem like iOS implementation is more correct. The plugin handles geolocation implementation end-to-end for iOS. For Android, we only handle the permissions, not the actual implementation of geolocation. Instead we delegate to the webview implementation.

cordova-plugin-geolocation/src/android/Geolocation.java

Line 49 in 543fff4

if(action.equals("getPermission"))

The fact that we have a getPermission "API" for android leads me to believe that we are likely checking for and calling on this API before we call on the native browser's geolocation API. This would cause android to not start timeouts until after permissions is resolved.WebChromeClient has an overridable onPermissionRequest hook that I believe is called via JS features, like geolocation to request permissions when required... which if used would probably bring the Android implementation closer to W3C spec but I think there is a couple of caveats:

1. Not sure if cordova plugins has a means to provide an implementation or get notified of when the webview is requesting permissions
2. I assume it produces a webview permission request + a native permission request (so you end up getting like 2 permission request prompts)

I think iOS behavior is more reflective W3C, but Android behavior is intuitively useful.

I agree that Android is more intuitive... I'd think timeouts are for acquiring the location point, and not because the user is taking their sweet time to accept or deny a permission prompt. But Apache aims to follow the W3C in hopes that eventually a plugin wouldn't be needed at all and can simply be removed without changing any app code, once the webview provides a suitable implementation. So Android (and iOS) implementations should be following W3C, and it sounds like Android implementation is in the wrong here. But I'm not sure if it's feasible to bring Android closer to W3C without providing a full e2e implementation, given the 2 noted caveats above. It would need to be investigated to be confirmed but if doing it the "proper" way leads to two permission requests, then I'd be more inclined to keep current behavior and document Android's behavior has an Android quirk.

Also implementing the geolocation API directly in Android is going to be detrimental unless if we force google play services and use the google play location services API. The pure AOSP location API is not great and rather difficult to use since you have to manage different providers yourself. This is one of the main benefits of relying on the webview implementation on Android.

[kumo01GitHub]

Thank you for your kind reply. For workaround, iOS implementation (measure timeout in JavaScript) can be solution?:

example for getCurrentPosition:

1. Start measuring timeout in JavaScript
2. getPermission
3. Override success callback to check timeout. If already timeout, ignore response (I'm not sure if this step is necessary.)
4. The permission is granted, start navigator.geolocation.getCurrentPosition
5. return timeout error if time out while processing above steps

I think that measurement timeout in JS should be workaround for Android. There are 2 timeouts that generated in step 1 and passed in step 4, but step 5 uses only step 1 timeout because step 1 must be timeout before step 4. This is not comfortable to read code.

[kumo01GitHub]

This is sample (not tested yet) : master...kumo01GitHub:cordova-plugin-geolocation:fix/issues-285