Fix/android/view builder and speed json

[Archdoog]

• Converts Demo's ViewModel to extend DefaultNavigationViewModel
• Fixes "speed" vs "value" key in SpeedUnit
• Internalizes view builder params so that you can't accidentally try to customize them.
• Adds a public get for custom view (used in maplibreui).

[Archdoog]

@ahmedre I believe the actual key should be "speed" when there's a value. E.g.

{
  "speed": 56,
  "unit": "km/h"
},

Let me know if there are additional cases. Definitely a bit of an obnoxious json object 😄.

Also, do we want to try catch the annotations parsing? On iOS we just convert a json parsing error to nil/null for annotations and an onError callback so that developers can log the failure. We figured better to let navigation succeed even in the case of a degraded/malformed annotations. See

ferrostar/apple/Sources/FerrostarCore/Annotations/AnnotationPublisher.swift

Lines 70 to 75 in 61e299a

	do {
	return try decoder.decode(Annotation.self, from: data)
	} catch {
	onError(error)
	return nil
	}

[ahmedre]

yes, you are right - my mistake! agree re: try/catching the parsing with an error callback 👍

[Archdoog]

This avoids users accidentally trying to do:

NavigationViewComponentBuilder.Default()
    .instructionsView { }

Which is very easy to do and highly problematic.

[Archdoog]

@ianthetechie now that this view model uses the DefaultNavigationViewModel. We should be able to refactor it to use the existing uiState from ferrostar and implement its own additional state for things like route loading, etc. Just to highlight how easy it is to customize without interrupting the default navigation behavior.

[ianthetechie]

Looks good to me but I'll wait for @ahmedre to comment since he may have an opinion based on what they're building 👍

[ahmedre]

On the DemoNavigationViewModel usage of DefaultNavigationViewModel - I think it is a step forward, but I think it is not as flexible as we have with just using FerrostarCore directly, because in this case, for example, both need to emit a NavigationUiState object.

We can swap NavigationUiState for a sealed class to solve this problem specifically for the demo use case of additional states like "not navigating" (which is what we also did in our implementation, but using FerrostarCore directly), but if we want to add lane support or speed limit support later, we'll need to either add these to NavigationUiState for everyone, or have our own ui state, or have two flows (in which case are we sure they're in sync, or would someone just need to combine them together to get a combination).

If we want to go this route, should we consider making NavigationUiState an interface with some required fields and let the return type be any instance? The downside of this approach though is that people would need an instance of check, and/or we'd need to do something with generics to avoid that. Alternatively, should we consider a single ViewModel for the demo app demoing the types of things you can do using FerrostarCore - it'd be opinionated and you could use it or use the formula from the ViewModel for building your own?