ArbiterGames/Unity-SDK — pull request #42 by VelociCopter (2014-09-13 21:11:04+00:00)
Title: Partial fix for pivtoal #78771578

Pivotal Link
https://www.pivotaltracker.com/story/show/78771578

This branch should not be merged into master as is. Posting it here for discussion.

The old way (as it is right now in master) has the SDK calling out to the server to update the wallet, waiting for a response, and THEN showing the dashboard. This can be a problem when the C# side also resets the poller, as the 2 fetchWallet response handlers smash each other.

Just commenting out the fetch in the objC eliminates the bug mentioned above, however it widens the window for a race condition. To see this race condition, tap the "send 10 promo credits" and then "view wallet" in rapid succession. The old way (currently in master) won't be a problem due to the extra fetch right beforehand. But this doesn't completely eliminate similar race conditions. For example, let your opponent lose a match right before you show your dashboard. If timed properly, you'll get the dashboard up with the old total and won't see the new total (with your winnings) until you close and re-open the wallet dashboard.

Also note that if we don't wait for a server round trip (as in the code in my branch) the wallet dashboard comes up much more quickly, greatly improving the UX.

Thus I propose:
1: We clean up this branch and do it this way (with no fetch right before showing the dashboard--just use what's already cached in objC) for a better UX.
2: We add the ability for wallet update responses (usually initiated by the wallet poller, but generally any fetch wallet response) to update the wallet dashboard even if it's already visible to mitigate race conditions, including the one that the old way (fetch then show) patched.

Furthermore:
If relying on the C# wallet poller doesn't seem like a good idea especially in regards to point #2, then I'd say that indicates we should also remove the wallet poller all together in C#.