feat(amplify_flutter): allow customers to override AmplifyClass methods

[Jordan-Nelson]

Issue #, if available: n/a

Goal:

• Allow Amplify Auth to be stubbed for use in the browser, so that a live Amplify Authenticator demo (with a stubbed backend) can be imbedded in the docs website.

Issue description:

AmplifyClass has a setter for the private _instance field. This allows a customer to pass in their own AmplifyClass implementation. However, the instance they pass in isn't used (except in one location, where a private method is invoked, and private methods can't be overridden from outside the lib anyway). This means that customers can technically create their own AmplifyClass implementation, but they can't override any of the methods, which defeats the whole point.

Description of changes:

• Move all implementations from AmplifyClass to MethodChannelAmplify.
  • Note: I think it is debatable if all of the methods belong in the method channel class. We could create a new class, which would be the default implementation of AmplifyClass, and this class could call through to the method channel class when needed. The pattern of putting all of the implementations in the method channel class is consistent with the other plugins though. I think it is worth revisiting this possibly in the future, but for now we just move them all over.
• Replace all implementation with calls to the appropriate method on the instance

Example:

Here is an example where AmplifyClass is stubbed for the purpose of running a (mocked) demo of the Amplify Authenticator in the browser. The implementation here is similar to the implementation in the real class. The key difference is that the method channel is never invoked. This is important because the method channel will not be available in the browser.

A similar stub could be used to allow Amplify.configure() and Amplify.addPlugin() to be called from within a widget/unit tests. Right now those methods can only be called from within integ tests. We had an issue opened in the past related to this.

This also would in theory allow a custom to write their own implementation for a platform we don't currently support, although I think that is an unlikely use case.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[dnys1]

I can't leave a comment on the line for some reason but this:

/// Top level singleton Amplify object.
final AmplifyClass Amplify = AmplifyClass.protected();

should become this:

/// Top level singleton Amplify object.
AmplifyClass get Amplify => AmplifyClass.instance;

[dnys1]

Also maybe a setter as well?

[Jordan-Nelson]

Good call. Updated and added a setter.