Can not distinguish Amplify is already configured about amplify-flutter HOT 6 CLOSED

While reviewing some of the open PRs (and I forget which specifically) I also noticed that we, internally end up having to track this state with a boolean.

I agree that Amplify.isConfigured() is a reasonable API to add to the library, in a first-class way.

@palpatim @manueliglesias, what do you think about adding this to iOS, JavaScript, Android?

from amplify-flutter.

I'm OK with this proposal. It would be nice to make Amplify.configure() idempotent, but we didn't want to incorrectly give the impression that it was possible to override already-applied configurations. In iOS, we'd likely expose this as a property getter public static var isConfigured: Bool { get }. Android would presumably expose public static Boolean isConfigured() (or maybe boolean? I'm not sure what our standard is).

from amplify-flutter.

Hi @ininmm thanks for bringing this to our attention.

Currently, you can have the following code to easily track if Amplify is configured:

    await amplifyInstance.configure(amplifyconfig);
    _amplifyConfigured = true;

What additional benefits do you think you'll have if you can access this as a field in your code?

from amplify-flutter.

@fjnoyp isConfigured() is a good idea in that it stop you making every developer have to write the same code to store/check the state of the configuration. It is bad in that it makes isConfigured() part of the API.

You could also take a different approach and be a little bit more permissive by only throwing the error if the config you are trying to use the second time is different from the original otherwise silently ignoring the repetition.

from amplify-flutter.

While I agree it's not difficult to track the state of Amplify independently, if Amplify has the requirement that it should not be re-configured it seems reasonable for Amplify to expose its state.

Regarding additional benefits, hot restart (not reload) seems like it would benefit from this change. Currently I have the configuration status stored in state that is reset on hot restart, but Amplify remains configured.

This PR seems to fix the configuration issue itself: #113

Where this is the original issue: #94

But I'm getting this error when my plugin code runs because my local state has been reset:

AmplifyException{message=The client tried to add a plugin after calling configure()., cause=null, recoverySuggestion=Plugins may not be added or removed after configure(...) is called.}

I'm only getting this on the DataStore plugin, not the Cognito plugin I initialized on the line before.

Maybe my code could be arranged differently to allow hot restart to work, maybe there could be a fix for the DataStore plugin and not Amplify itself. Either way it seems a lot of complexity could be avoided if Amplify exposed its state.

from amplify-flutter.

To be able to tell Amplify is already configured will be perfect! For now I've implemented this extension method as a temporary workaround:

import 'package:amplify_core/amplify_core.dart';
import 'package:amplify_auth_cognito/amplify_auth_cognito.dart';
import 'package:amplify_analytics_pinpoint/amplify_analytics_pinpoint.dart';
import 'package:amplify_core_plugin_interface/amplify_core_plugin_interface.dart'; // <-- pulled this in

// The extension method
extension on Amplify {
  bool hasConfiguredAuth() => AuthCategory.plugins.isNotEmpty;
}

// and using like so:
if (!amplifyInstance.hasConfiguredAuth()) {
  amplifyInstance.addPlugin(
    authPlugins: [auth],
    analyticsPlugins: [analytics],
  );
}

from amplify-flutter.