Mapbox-navigation-android: Expose Nav Native options via NavigationOptions

[LukasPaczos]

There are a bunch of options in the NavigatorConfig class that we can and should expose via the NavigationOptions. This includes number of uncertain points, off-route threshold and other. We can take the legacy MapboxNavigationOptions for comparison.

/cc @mapbox/navigation-android

[Guardiola31337]

Thanks for cutting this ticket @LukasPaczos 🙇 this is definitely needed.

One thing to mention here is that not all the options from NavigatorConfig should be exposed, so we should probably create a wrapper around NavigatorConfig and expose only some options instead of including NavigatorConfig as part of NavigationOptions.

[LukasPaczos]

Yes agreed. We possibly don't need a wrapper, just expose the required options (using primitives or regular Java types), map them in the MapboxNavigation or MapboxTripSession to the NavigatorConfig class and push to NN.

[Guardiola31337]

Yeah, that works too 🚀 although don't want to run into Primitive Obsession 😅

[vmihaylenko]

@mapbox/navigation-android Hey folks! Could you prioritize this issue? The nav-native team would like to check some cases with the useEKF option turned off.

[zugaldia]

@kmadsen will be running with implementation per team standup today.

[Guardiola31337]

Refs. https://github.com/mapbox/mapbox-navigation-android/pull/2600#issuecomment-600252408

[SiarheiFedartsou]

I think the best solution is to think about setConfig as if it is a part of constructor. I believe at some point we will move it to constructor as well as configureRouter.

[Guardiola31337]

Cross posting from https://github.com/mapbox/mapbox-navigation-android/pull/2600#issuecomment-600529354

@SiarheiFedartsou: I think the best solution is to think about setConfig as if it is a part of constructor. I believe at some point we will move it to constructor as well as configureRouter.

@LukasPaczos: This would mean that the implementation from this PR is already semi-deprecated and will require breaking changes in the near future to remove the introduced here mutability.

In this case, I think we should refactor this option and pass it only in the NavigationOption when the MapboxNavigation is first created.

cc @LukasPaczos @kmadsen

[zugaldia]

@kmadsen @Guardiola31337 @LukasPaczos @SiarheiFedartsou could you set up 15 min to voice and debate/decide/commit on an API design for the options object?

[kmadsen]

I don't want to expose the raw native configuration. We actually lose flexibility by doing that

https://mapbox.slack.com/archives/CMY3Y5SQM/p1584555497462800?thread_ts=1584543950.447900&cid=CMY3Y5SQM
we spend hours tuning each value in this huge list of parameters(and also it can be automated at some moment I think).

Things like "number of uncertain points and off-route threshold" are numbers that can be automated. If we set those types of things during initialization, we make it unclear why they'd change during runtime. They are also different based on what region you're in.

[kmadsen]

We're already talking about bucketing all these configurations under a mobile/auto umbrella.

I think we want something in between. Not quite as broad as mobile vs auto, and not as specific as uncertain points.

I like the feature based configurations, such as enable/disable kalman filter. All the fine tuning of a kalman filter can be done by nav native.