As discussed here : http://www.badlogicgames.com/forum/viewtopic.php?f=17&t=26608&p=104851&hilit=gamesvcs#p104851 I'm working on GPGS Desktop implementation and I have something working pretty well. I'll PR you when all will be clean.
You can have a look at my dev branch https://github.com/mgsx-dev/gdx-gamesvcs/tree/desktop-gpgs
there is a test GUI (GpgsClientTest) if you want.
If you don't mind, I will use this issue to ask some questions about how to implements it correctly and make some suggestions about current API and other implementations.
Threading
I understand your concept of "fire and forget" : user code call a methods and get result in listener but ...
Questions :
- Is IGameServiceClient implementations have to be thread safe ? my opinion is it don't have to be.
- Is IGameServiceClient implementations have to be called in GLThread ? my opinion is it don't have to be.
- Is IGameServiceClient implementations have to be non blocking ? that is process things in background. My opinion is it shouldn't (see below).
While underlying library may do things in background (activity intent in android...), I think GameServiceClient should never spawn threads itself, it is the user code responsibility to do it, to not doing it, to parallelize some tasks or chaining multiple calls in a single background thread and synchronize things if needed.
It is not really clear what implementation is supposed to do. I looked your android-gpgs implementation and most of methods are blocking except the load/save game state. I don't understand why mixing up blocking and non blocking parts.
I need more information on this before continue my implementation.
Packaging
I saw all implementation in the same package (de.golfgl.gdxgamesvcs) which may conflicts if you use multiple implementations in the same app (I may want to use both GPGS android and GPGS REST in my application).
I suggest to use the convention : de.golfgl.gdxgamesvcs.[service].[platform]
Versionning
I saw that android-gpgs-0.0.1 depends on android-0.0.1-SNAPSHOT ... have to wait the next release to be solved :-/
I see also that next release is 0.1.1 and not 0.1.0 ... maybe a mistake ?
and another quick question : what VCS stand for ? :-)
Features
In my original implementation, I have features that i can't implements with your API like :
- listing all achievements
- fetching leaderboards
- list game states
- delete game state
I understand that android implementation delegates a lot to google play activity but it won't be the case for other implementations. Maybe API is too tight to GPGS concepts and workflow ... It could be a little more abstract in my opinion, what do you think ?
I hope you dont't take all my remarks too badly because even if there is some things to fix up, current API is globally usable.