Re-created PR since I messed up a rebase. Sorry about that.

@ditman This is an internal request. I am not sure how to review it since I am used to reviewing end to end implementations of plugin code. This is just a change on interface. Could you please advise?

@mehmetf This looks good, the only thing "missing" (which I'm assuming is on a separate PR for the google_sign_in package) are the changes to the native code to implement the new MethodChannel messages (hasGrantedScope and requestScope ), in case they're new?

My only comment may be that this methods seem to be called hasPermissions and requestPermissions on the android side, and maybe you want to keep that name on the method channel call as well.

(This also seems implementable on web through the hasGrantedScopes and grant methods?)

@ditman, the implementations for Android/iOS/web are in #2562. I split them out since it seemed like the build failed due to the 1.1.0 not being in pub?

Happy to swap out the method names, I went with 'scope' since that seemed to be what was used in the plugin (i.e. constructor).

@emerssso re: naming: whatever makes more sense when using the plugin is fine, no need to rename.

Re: splitting the PR: yes, it is needed to publish the packages in the correct order. Thanks for the link!

Suggested offline that this would be improved by allowing multiple new scopes to be requested at once so the user doesn't potentially have to be prompted multiple times in that case.

I'll work on that and add the changes needed to each PR.

Updated both methods to allow the caller to pass multiple scopes. The flow I'm envisioning is

final missingScopes = await googleSignIn.listMissingScopes(newScopes);
// handle missing scopes, i.e. showing justifications,etc

final granted = await googleSignIn.requestScopes(missingScopes);
if(granted) doStuff();

Still working on updating the implementations; wanted to get feedback on this change to the API.

wanted to get feedback on this change to the API.

@emerssso Can we do the "missingScopes" check internally, so the user doesn't have to care about the ones that are already granted? I think that'd make the API slightly easier to use.

Can we do the "missingScopes" check internally, so the user doesn't have to care about the ones that are already granted? I think that'd make the API slightly easier to use.

That would meet my immediate needs. I've seen uses of the "missingScopes" flow, but it's not necessary.

@emerssso just trying to keep the API surface of the plugin as small as possible (and as close as possible to the Google Sign In API itself; the closest thing I've seen there is getGrantedScopes, but nothing similar to getMissingScopes)

@ditman Makes sense. I'll consolidate them to just requestScopes.

This makes sense to me, but please seek approval from @cyanglaz since this affects all platforms, not only web!

(PS: Thanks for the web implementation!)