Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/interface changes #48

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

karivatj
Copy link
Contributor

@karivatj karivatj commented Dec 5, 2021

Hello,

And sorry for the long post.

I've been working on the refactoring of the android-gpgs module and I needed to make some interface changes to the code. This PR contains these proposed changes to the IGameService interface and all necessary changes to sub-modules which implement the interface. I've tested these changes locally and seems to work fine and builds ok too.

Here are the key changes of the PR:

  1. Add resultCode Integer into gsOnSessionActive and gsOnSessionInactive methods. I found it is important to know the reason code why these session changes occur. For example, considering the new way to handle logins in Google Play Services, one should consider a situation when the user asks to explicitly sign out from the service or cancel the sign in flow. When this happens, one shouldn't try to sign in after that until the user explicitly wants to sign in by pressing a sign in button in the application.

Thus, I figured I'd add a resultCode information in to the callback methods that deliver this information to the caller. This way the caller can persist the status and can make a informed decision whether to sign the user in during app startup or during resume. This is described in Google Play Games Checklist ID 1.6

  1. Add get player data method to IGameService interface and implement method stubs to sub-modules

This is used to fetch player data from the Game Service if it supports it. This was a missing feature, and I thought I'd implement it in android-gpgs module. This is purely optional feature but nice to have.

Add IPlayerData and IPlayerDataResponseListener interfaces, which define the data model and the callback methods when
new player data is received from the Game Service.

  1. Add timespan and collection parameters to fetchLeaderboardEntries in IGameService

If the Game Service supports it, these parameters can control how to refine the leaderboard
results.

  • Timespan declares if for example daily, weekly or all time results are fetched.
  • Collection defines if the results retrieved are in public or social context.

This feature is at least supported by Google Play Games and should be added to make more refined queries to leaderboards. Now it defaults to All Time scores and completely disables the possibility to fetch Daily or Weekly leaderboards.

  1. Add missing Javadoc stuff to get rid of warnings during compile time.

@MrStahlfelge
Copy link
Owner

  1. Add resultCode Integer into gsOnSessionActive and gsOnSessionInactive methods. I found it is important to know the reason code why these session changes occur. For example, considering the new way to handle logins in Google Play Services, one should consider a situation when the user asks to explicitly sign out from the service or cancel the sign in flow. When this happens, one shouldn't try to sign in after that until the user explicitly wants to sign in by pressing a sign in button in the application.

This was handled implicitely by GpgsClient before, the behaviour should be kept. It's the difference between calling resumeSession and logIn.
If it didn't work this way on one if the implementations, that was a bug. I know for sure it works on Gpgs Android though. :)

@karivatj
Copy link
Contributor Author

karivatj commented Dec 7, 2021

Thank you for the comments. I have made some fixes and will update the PR soon. I will look into the GPGS login stuff a bit more to figure out a way to handle explicit sign out situations within the client code. I had some problems dealing with that stuff when updating the code to use the newer API. For example the old connect() method does not exist anymore and is replaced by silentSignIn() which seems to sign in the user no matter what is the situation (even if the user explicitly signed out previously).

@karivatj
Copy link
Contributor Author

I've made the changes that were requested. I renamed one enum type GsErrorType to GsResultCode and added some success enums there also that can be used as session inactive / active resultcodes.

I will take a look at the sign in stuff discussed earlier a bit more thoroughly when I prepare the PR for the android-gpgs refactor.

@@ -267,17 +267,15 @@ private native void refreshDisplayname() /*-{

protected void onDisplayName(String displayName) {
this.displayName = displayName;
if (gsListener != null)
Copy link
Contributor Author

@karivatj karivatj Dec 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this OnSessionActive callback here? Seems weird when we receive a new displayname we trigger a session active event? Is this something that is needed in HTML GPGS stuff? I decided to remove this because I thought it is illogical for this to be here. Let me know if this needs to be reverted.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before your change, player display name was guarantueed to be available when game service was connected. Thus, the connection state was set to connected after the display name was received.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I will revert that change. Thanks for the clarification.


public enum GsErrorType {errorLoginFailed, errorUnknown, errorServiceUnreachable, errorLogoutFailed}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename GsErrorType to GsResultCode. Makes it usable in success cases also. Relevant to for example on session change events.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What different success types can we have?

Copy link
Contributor Author

@karivatj karivatj Dec 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of defining only some generic error types for example errorLoginFailed or errorLogoutFailed which we use to inform the client when an error occurs, we could define some other status codes as well like signedIn, signedOut, connectionPaused, connectionResumed etc and rename the enum type to GsResultCode. We could then use it with OnSessionAcrive and OnSessionInactive methods to inform the client of the reason the session state changed.

Does this idea sound reasonable or is this completely useless thing to consider? What do you think?

In my game project I needed this information to know if the user has cancelled the sign in process or signed out explicitly. With no result code present, there's no way to know why the session state change happened. And I believe there is other use cases for this kind of information as well. I don't see a reason there shouldn't be a specific reason code included in the callback when a session state change occurs.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not useless, but at the state GPGS was there was no reliable information what exactly happened, might have changed now.

@karivatj
Copy link
Contributor Author

karivatj commented Dec 15, 2021

I managed to figure out the sign in process. If the user explicitly signs out it is handled within the GPGS client like previously.

The reason I added the status code to session state changes was to inform the client about the explicit sign out event so the client could persist the choice and make a decision during app startup whether or not to sign in the user. This was wrong, so I made a fix to the gpgs client code which handles this scenario behind the scenes. The original use case is not valid anymore (for my case) and thus the resultCode in onSessionActive and onSessionInactive methods is not used (for the time being)

It is up to you if you see this as useful. Should the session state change include a reason code? If not, I can remove the commit from the Pull Request in order to get this approved.

Cheers,
Kari

@MrStahlfelge
Copy link
Owner

I think we should remove it, I can't see any use case and it breaks backwards compatibility (every game has to change the callbacks).

Ping me when the PR is ready to review.

If supported by the Game Service, this method is used to
invoke a call to fetch player related data.

Implement method stubs to submodules which just returns false when called.

Add IPlayerData interface which describes the PlayerData data model.

Add IPlayerDataResponseListener interface which declares a callback method
when player data is received from the Game Service.
Modification includes two extra int parameters timespan and collection

If supported, these integers can control how to refine the leaderboard
results.

Timespan declares if for example daily, weekly or all time results are fetched.

Collection defines if the results retrieved are in public or social context.
@karivatj
Copy link
Contributor Author

karivatj commented Dec 16, 2021

Alrighty, I modified the PR by removing the commit containing the result code stuff. @MrStahlfelge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants