Sample app provisioning

[ikurek]

This should resolve #316, as this PR is a rework of Ably SDK key provisioning system. Previously, only the integration testing was using provisioning endpoints, an now they're also utilized in the sample application, to make it work without the SDK key. The most important changes are:

• Provisioning was moved from test_integration to ably_flutter base package. This makes provisioning system available to all sub-packages of ably_flutter including test_integration and example.
• Static provision() and getTokenRequest() methods were moved to a AppProvisioning class, which instance can be configured with additional parameters to extend provisioning capabilities
• Example application initialization was changed to request API key before the app is started. Sadly, this can't be done in a different way, because AblyService in the example app has to be initialized before the app UI is ran
• A small ApiKeyService utility class was created to manage API key, so it's possible to check the key source at runtime
• Sample app UI was updated to show a warning message if currently used key comes from automatic provisioning system.

After that, we only need #318 to make the sample app run without any configuration from user's side 🙂

[QuintinWillison]

Actually, why is app_provisioning.dart appearing in the main SDK sources? It's not in the client library features specification, as far as I'm aware, so shouldn't be part of the SDK unless we have strong reasons why it's required for the Flutter platform. If it's a utility that you need to share between example/ and test_integration/ projects, then is there a way to share it without adding to the API surface area of the core SDK?

[ikurek]

Actually, why is app_provisioning.dart appearing in the main SDK sources? It's not in the client library features specification, as far as I'm aware, so shouldn't be part of the SDK unless we have strong reasons why it's required for the Flutter platform. If it's a utility that you need to share between example/ and test_integration/ projects, then is there a way to share it without adding to the API surface area of the core SDK?

I don't think it's possible to share it between test_integration and example - these two are on the same level in the dependency tree, and they both are dependent on ably_flutter. With the approach I proposed in this PR:

1. Both sub-packages can use a single provisioning system
2. Users can use the provisioning methods easily for their own needs

But as you noticed, the main drawback is the fact that this class has to be in the base package. If we'd like to keep the codebase of the library as clean as possible, there are alternative approaches that I can take with this:

1. Move the provisioning system to a separate repository - probably too much work, but we can make the provisioning system a completely separate module, with a separate codebase and repository. Then we can use that repository as a dependency in both subpackages of this repository
2. Duplicate the provisioning class in both subpackages - it's fairly easy to do, but we'll have to remember to introduce changes to both of them in the future

If extending the base package like I've done it is not a correct direction, I suggest we take the approach 2, and simply put a copy of the class I created for provisioning in example and test_integration 🙂

[QuintinWillison]

@ikurek Thanks for your detailed reply. It's worth us avoiding adding APIs to the base package because we've seen elsewhere that customer's can come to rely upon such unofficial (public, not public) APIs - and, in turn, we then have to support them going forwards. In the same vein, while your alternative approach 1 is a good suggestion, it only takes us further down the road of this becoming a supported public API.

So, on balance, I think go with your alternative approach 2 - duplicated code - and just ensure to put a comment in both locations that points to the other to help maintainers out. Perhaps also explaining why.

[ikurek]

@QuintinWillison I've removed provisioning from base ably_flutter and moved it to both example and test_integration separately in 9dc9664

[ikbalkaya]

Looks good to me except a small typo which Quintin already suggested a change. So I'm going to assume it's going to be fixed