Example app: why check login in FutureBuilder instead of initState?

[chris]

I'm new to Flutter, so wondering about the example app's use of FutureBuilder, and calling _getValues in the build method. It seems like you'd only need to setup the UserService once, in an initState, instead of re-creating this and doing the auth check on every build method invocation? Further, when the increment button is pressed, you will wind up doing a second fetch of the counter, which is needless and would just double your Lambda invocations. i.e. it's incremented in the _incrementCounter and gets the updated counter there, but then sets the state, causing a rebuild which then fetches the counter again in _getValues. I added debug printing to my own code that follows the pattern of the sample app, and I see that happen at least.

I realize that technically a user's account could be deleted or logged out of all tokens via some other use, and thus one could argue that checking their auth on every render is the most secure, but it seems excessive and in a case like this where you also call a Lambda, like you're doing more than you need. Can you thus shed some light on this design and why it is favored over using initState to set all this up instead - since I'm new to this, I'm wondering if I'm missing something or if it's just a choice for the example, or? Thanks for this flutter plugin, it's working well for me so far!

[furaiev]

@chris thank you for question, Yes, it seems like the example isn't good enough and it should be rewritten.

[chris]

@furaiev I don't know - I'm pretty new to Flutter, so I'm just unsure on all the different ways to approach this kind of thing. My other thought is that you may want to have all this info via provider, and set that up on app launch, then any view that needs the user/auth info can use the provider. And by provider, I'm talking about the "simple app state management" approach in the docs, as it seems to be sort of the standard/default now from Google (unless you need something more advanced, etc.). But I also know that you want your app to boot as fast as possible and maybe show a loading screen or whatever. I'm thinking though that with how this all works - either you have a session in the shared prefs (or whatever storage you're using) or not, so a check of that should be fast enough to do without having to be async, and could maybe be done on app launch and then all this put in a provider?

I'm going to play around with all this in my own app. If I get something I think is solid, I'll reply back here how I did it (and can look at helping do an alternative example app for this or whatever). Again, thanks for this library to begin with, made my life easier!

[erw13n]

I follow the example app, and implement it to my app. Once publish it, got an issue after create a release version. After the user session is over (1 hour after), user no longer able to access the app. the _getValues was throwing error : "error type '_onebytestring' is not a subtype of type 'int' of 'index'"

I though there's something wrong with my code. But when I try release the example, the same thing happen. Secure Counter page & Login page always show "Loading..."

When check it, the actual error came from _cognitoUser.getSession() method.

I honestly don't know what happen here (I'm new to Flutter) It seem, this issue not happen on debug mode, only when release.

[erw13n]

Its not working because I'm using Flutter Channel Dev 1.15 Its running well on Stable 1.12.13

[erw13n]

Flutter Channel Dev 1.15 will throw error : Attempt to execute code removed by Dart AOT compiler (TFA)

Its happen due : https://github.com/furaiev/amazon-cognito-identity-dart-2/blob/bba1cc964d3dd4fe44abb9db4bb0edead51dc547/lib/src/cognito_user.dart#L276

[chris]

@erw13n I think this is a separate issue? I'd suggest posting it as its own issue, as if I understand correctly, the only thing that's related to this issue is the sample app?

[chris]

Following up on this issue and the idea of using provider, I am doing that now. I honestly can't say I'll have time to provide a pull request or alternate sample app with that, but it seems decent. I wound up creating a UserModel (which is a ChangeNotifier) that essentially holds both a User and UserService reference, and then in my app I do:

ChangeNotifierProvider(
        create: (_) => UserModel(),
        lazy: false,
        child: MaterialApp( ...

My UserModel provides methods that call into UserService and/or use the User, etc. It's not quite an ideal design IMHO, but in terms of providing this data to all the places (pages/screens) in my app that need it, it is solving that.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.