[Feature request]: Add the ability to show custom UI for Google's Terms and Conditions

[IvelinKrastev]

Is there an existing issue for this?

• I have searched the existing issues

Use case

Currently, the Google Maps Navigation SDK for Flutter requires users to accept the Terms and Conditions through a separate dialog initiated by NavigationApi.showTermsAndConditionsDialog. This process is not integrated into the registration flow, leading to a fragmented user experience.

Proposal

Allow developers to:

• Integrate a custom Terms and Conditions acceptance UI, such as a checkbox or a dedicated screen, into the app's registration or onboarding process. As far as I am informed, this is permitted by Google's requirements for using the Navigation SDK in the EEA.
• Programmatically set the areTermsAccepted flag for the GoogleMapsNavigator to true upon user acceptance.

Benefits:

• Streamlines the user journey by consolidating the acceptance process within the app's registration flow.
• Enhances flexibility, allowing developers to design a user experience that aligns with their app's branding and UI guidelines.
• Improves compliance by ensuring that users are presented with and acknowledge the Terms and Conditions before proceeding with registration and app use.

[IvelinKrastev]

@jokerttu, I was thinking about something like setTermsAccepted, which of course has to be used explicitly when the user accepts the custom dialog/checkbox/whatever. Otherwise, it would be a violation of Google's requirements.

And maybe one that can fetch the content shown in the currently available dialog, as displayed by showTermsAndConditionsDialog. Therefore, if the user wants to read the full Terms and Conditions, they can click a link under the checkbox to access the entire legal document.

[jokerttu]

Hi @IvelinKrastev
this package serves as a wrapper around the native SDKs for Android and iOS, which means that customization of the ToS dialog is constrained by the capabilities provided by those SDKs.

At the moment, the package does not include the most recent customization parameters for the Terms and Conditions dialog. Adding support for these parameters would provide developers with greater flexibility in adapting the dialog’s design to their needs.

See https://developers.google.com/maps/documentation/navigation/android-sdk/reference/com/google/android/libraries/navigation/TermsAndConditionsUIParams

[IvelinKrastev]

Hey @jokerttu, thanks for the fast response!

So two questions:

1. Would I be able to make it with a checkbox, or would I have to show the dialog in any case?
2. When do you plan to include the most recent customization parameters for the Terms and Conditions dialog?

[IvelinKrastev]

Hey @jokerttu

When do you plan to include the most recent customization parameters for the Terms and Conditions dialog?

[Samo8]

@jokerttu @IvelinKrastev I can have a look on this

[jokerttu]

@Samo8
Thanks a lot for offering to help! Yes, you’re welcome to take a look. This feature is on our roadmap, but it’s not at the top of the priority list right now, so any contribution that helps improve the API coverage would be greatly appreciated.

On API design, we try to avoid platform-specific APIs and properties as much as possible, since a unified API between Android and iOS provides a better developer experience. That said, this is not always possible if configurations cannot be matched in a reasonable way between platforms.

In this case, it looks like both Android and iOS expose a similar set of parameters for the Terms & Conditions dialog:

• Android: background color, title color, main text color, button text colors
• iOS: backgroundColor, titleColor, mainTextColor, cancelButtonTextColor, acceptButtonTextColor

Because of that, it should be straightforward to introduce a Dart API that at least covers the color configuration on both platforms. For example, a common buttonTextColor could act as the default for both platforms, with an optional iOS-specific cancelButtonTextColor override if needed.

For the Dart side, there are two main directions we could take:

1. Single configuration object (preferred if it stays clean)
   Aim for a single TermsAndConditionsUIParams object passed as one uiParams argument in the API. This object would define the common color fields (background, title, main text, button text, etc.), and we could later extend it with optional platform-specific sections (e.g. android / ios sub-objects) if we need to support things like fonts or additional platform-only options.

2. Separate configuration objects per platform (if unification is too awkward)
   If during api planning it turns out that a unified object becomes too constrained or confusing, we can introduce platform-specific configuration types such as TermsAndConditionsUIParamsAndroid (uiParamsAndroid api param) and TermsAndConditionsUIParamsIOS (uiParamsIOS api param). This gives more flexibility for things like font configuration and platform-specific options. This would also give easier way to configure fonts as platform specific manner.

A separate, platform-specific configuration object for fonts (and other platform-specific options) could be a better fit for a later iteration and would also give us more flexibility to accommodate future native SDK changes on each platform. Font-related options add quite a bit of complexity to both the public API and the implementation, so it would be good to keep the initial scope focused on color configuration only, therefore I suggest leaving font configuration out if it appears to be harder to implement, test and document.

If you feel strongly about including font configuration in the initial PR, that’s also possible. In that case, it would be important to design and document the font-related parameters in a way that keeps the API easy to understand and use for developers (for example, clearly separating cross-platform options from platform-specific ones, or using platform-specific sub-objects).

I’d recommend proposing an API design here in the issue comments (e.g., the Dart types and example usage) before proceeding with the implementation, so we can review it and make sure it fits well with the rest of the plugin.

Documentation

Android:

• TermsAndConditionsUIParams
• showTermsAndConditionsDialog

iOS:

• showTermsAndConditionsDialogIfNeededWithOptions
• uiParams
• GMSNavigationTermsDialogUIParams