Allow passing parameters for navigation signals

[kkostov]

When the Flutter SDK invokes the native SDK on each platform, it includes additional default parameters to describe the SDK version. For example, it would replace the following:

TelemetryDeck.SDK.name
TelemetryDeck.SDK.version
TelemetryDeck.SDK.nameAndVersion

and append the following:

TelemetryDeck.SDK.dartVersion

Currently, this is not possible for navigation related events as they don't have a parameters options (TelemetryDeck/FlutterSDK#22).

Please expand the API to allow parameters to be passed for such functions. As an alternative, the parameter overrides may also be provided as part of the start configuration (whichever makes more sense and feels better as an API).

This applies to all managed methods which generate signals internally.

[Jeehut]

@kkostov In #196 (released with version 2.5.0) we added a way to provide default parameters to be sent with every request. If you're sending TelemetryDeck.SDK.dartVersion and other parameters with every single request, then I believe that's the best way to achieve that. The API looks like this in Swift:

config.defaultParameters = {
   [
      "TelemetryDeck.SDK.dartVersion": "<your value>",
      "TelemetryDeck.SDK.name": "<your value>",
      "TelemetryDeck.SDK.version": "<your value>",
      "TelemetryDeck.SDK.nameAndVersion": "<your value>",
   ]
}

The internal sending logic overrides any default parameters with user-provided values, so overriding existing fields should work as expected. And since it's implemented as a closure, it's also great to pass dynamic values inside, such as the users purchase state or anything that might change after app start. This should be a flexible solution covering above use case. By the way something you might want to consider introducing in other SDKs, too as a convenience method (if you don't have something similar already).

Does that work for you?
Let me know if you need anything else and you still need custom parameters for the navigation API.

[kkostov]

Oh this is perfect! I will make use of that approach (and also add support for default parameters in the other two SDKs!)