So I used Playfab about a year ago for a test project that never went public. I'm now wanting to implement it for a project I plan to publish on mobile and desktop platforms, but wanted to make sure the startup flow I used a year ago is still the best way to go. I have a number of questions to ask in order to get caught up, sorry in advance! So for the flow...
New User:
1) User enters app. 'AuthMethod' (a key saved locally in the user's encrypted PlayerPrefs) is null, so user never authenticated with our app before. Automatically make a new account for them using the appropriate device authentication API call (LoginWithAndroidDeviceIDRequest, LoginWithIOSDeviceIDRequest, LoginWithCustomIDRequest).
2) Set 'AuthMethod' to 'Device'.
3) Allow user to set their optional Display name if they want to be eligible for leaderboards and stuff. Also, now that they're actually in the app and experiencing it, we can notify them to consider linking a social account (facebook, etc) or a custom account, in case they ever want to log in from another device.
Returning User:
1) User enters app. 'AuthMethod' is not null and is either 'Device', 'Facebook', 'Custom', 'Steam', etc.
2) Authenticate them through the appropriate API call for the saved AuthMethod.
Questions:
1) Is the basic flow above still the best way to go, or are there changes/improvements I've missed in the past year (like does the SDK now save the last authentication method?).
2) A competitor service has a property called 'Authenticated' as part of their SDK. Checking this at the start of the game loading will tell you if the SDK has saved the user's last authentication. If this property is true, you can immediately query for the current user's Player info and load up the game, no need to actively authenticate first since they already are with the service. Does Playfab have anything similar to this, where the SDK maintains the last authenticated user for a period of time until it expires (i.e. after a few days of inactivity from the app) so we don't have to call one of the authentication API calls every session?
3) (this question assumes the answer to number 2 is No): With device authentication, there's no issue re-authenticating with device every time in the background for the user, without any prompt to them. They won't notice it's happening anyway. However for custom logins (username and password) it will annoy the user to prompt them to manually sign in every app session. Is there anyway to generate an access token when they successfully login, and supply that to Playfab for as long as it stays active in lieu of a username and password? This is how Facebook and Steam logins work with Playfab, only that the life of the access tokens in those instances are handled by the external platforms. Does Playfab do anything similar with their own custom logins?
4) Are the InvalidFacebookToken and InvalidSteamToken error codes returned when Playfab determines the access tokens from facebook and steam, respectively, are expired? If that's not the use of those error codes, how do we check this? Do we manually make a call to the respective services each session to check if the saved access token is still valid, or does Playfab handle that for us as part of the authentication method for each service?
5) Related to #4: Should I continue saving access tokens locally for users in encrypted player prefs, or is there something we can set in the SDK to handle this for us?
6) Regarding device auth: say a user plays one of my games but only ever plays it with device authentication. Now say they sell that device to a new user that so happens to also try my game. When they open the app for, what to them is the first time, they will automatically be logged on under the previous device owner's account. Now I know this is an extreme edge case where, unless you have an exceptionally large player base, you're unlikely to encounter. But I thought about this while reviewing my old code and didn't know how to 1) spot this is happening, and then 2) actually handle it.
7) Only question not related to authentication: The competitor service mentioned above has a 'SetDurable' flag on requests, which allows requests to be queued up while the user has no connection, then once a connection is established, the requests will be sent 1 by 1 in order. This essentially allowed for an offline mode with little effort. Upon reviewing my old code using PF, I noticed I made my own offline mode which led to a lot of extra properties and methods in different classes. Does Playfab have a similar flag to SetDurable, or any way to queue up requests when there's no connection? If not, can anyone think of a way to achieve this?
Feels good to be back with Playfab!