search

dpa99c / phonegap-launch-navigator

Phonegap/Cordova plugin which launches native route navigation apps for Android, iOS and Windows
369 stars 131 forks source link

appSelectionCallback question (dev talk, not bug) #95

Closed jvjvjv closed 8 years ago

jvjvjv commented 8 years ago

In reference to #88, I'd like to know why a new option appSelectionCallback to tell you what app as opened instead of using the existing successCallback and returning the app that was launched? Existing apps would have to be modified anyway to support it, and success callback currently returns nothing, so placing it there would not have broken backward compatibility.

I'll offer my opinion. To me, making the plugin easier to use would be to not add option upon option when updating an existing one would suffice.

Ultimately you're the developer, and I didn't take initiative to fork this and create teh functionality I was suggesting, and maybe this isn't even the right place for discussing coding and one's own best practices. I am curious, nonetheless.

dpa99c commented 8 years ago

In short: the two callbacks are semantically different and it was far easier to implement this way. I would suggest looking at the JS-native code interface in the plugin source code to understand exactly why this is:

appSelectionCallback is invoked in response to a user selection in the native picker UI which is generated by cordova-plugin-actionsheet. The invocation occurs on the thread created by the native success callback by cordova-plugin-actionsheet and where the selected app is determined by the button index passed by the native callback. In contrast, successCallback is invoked in response to the successful launching of a navigation app. The app may either be specified as an option when calling the navigate() method, or it may determined by the user selection in the native picker. The value indicating the app passed to appSelectionCallback is a constant in the launchnavigator.APP list. Currently, there is a one-way mapping of launchnavigator.APP to the native app constants used by the platform-specific implementations. So in order for successCallback to return a constant in the form of launchnavigator.APP, the app value passed in to the native layer would have to be funnelled back out again to successCallback, either by a reverse mapping or via some global state, for each platform implementation.

jvjvjv commented 8 years ago

Our app essentially would receive two callbacks from this, one when the navi app has successfully launched, and a second saying which had successfully launched, and they could happen at different times in the workflow, right? (I'm talking like seconds at worst, here.)

Thanks for helping the lot of us by making this plugin and continuing to support it.

dpa99c commented 8 years ago

appSelectionCallback will only be invoked if the user is asked to choose which app to use via the native picker (i.e. options.app = null). If an app is specified (e.g options.app = launchnavigator.APP.GOOGLE_MAPS) it won't be called.

successCallback will always be called once the native part of the plugin has successfully launched the specific app via its URL scheme. The time difference between these operations is probably negligible, but will mostly be down to waiting for the asynchronous geocoding operations to complete.

So, yeah, seconds at worst on a terrible internet connection...