Google Play Game Services [Android/iOS]

[qberty]

I believe the new Google Play Game Services API would be an extremely amazing and useful system to be implemented for both available mobile platforms. The API is available for Android, iOS and web platforms and give access to the same exact features universally so I figured it would be a great addition. It allows apps/games to have leaderboards, real-time multiplayer environments, achievements etc.

Getting them integrated is actually pretty easy if you're dealing with a normal IDE for either platforms, but since LiveCode doesn't actually offer any real Java or ObjC, this would be better to be the engine instead of an external.

For Android you simply add a couple things to the AndroidManifest and a couple other objects and libraries and allow some generic calls. All available code to integrate is here: https://developers.google.com/games/ser ... quickstart

For iOS it's actually pretty much a similar thing here: https://developers.google.com/games/ser ... quickstart

I wanted to know how plausible this would be to fuse in with LiveCode without using externals. I figured I get a professional opinion from someone who deals with the engines code before I setup a Linux box to deal with it.

[monte]

I think this would be better as an external simply because not every livecode app is a game. Actually few of them are. While a lot of people around here tend to think the engine should be everything to everyone I take a different approach and think the engine should offer a cross platform core and a smorgasbord of externals offer features that are either OS specific or edge case enough to warrant keeping them separate. I don't imagine it would be much more complicated to integrate as an external than in the engine... possibly less complicated. I've looked at google play services for doing mergMK for Android. I just wish it was available on amazon devices...

[qberty]

Well technically the entire Google Play Game Services is already available to apps that support newer versions of android. It wouldn't be much of an external since it's simply adding a couple lines to the manifest and a couple lines of code. There's more done setting it up in the developer console than actual code for a typical android app in eclipse.

What will be included in mergMK for Android? Taking requests if you're going to make an external anyway?

[monte]

I suspect it would be significantly less trivial than the getting started tutorial suggests.

mergMK will hopefully be functionally equivalent on both platforms. I probably won't get to it for a while though.

[qberty]

Well that's true, though livecode itself should allow to store the source code when compiling before it does a full compile straight to a mobile app. There's no easy way of getting the source code of the app you compile without having to quickly snag it out of the temp directory before LiveCode takes the converted code and compiles it into an app.

[monte]

Not sure what you mean there. There's no java code generation step if that's what you're thinking... I think there might be a class or two generated for namespace reasons but the rest of the app is engine + stacks.

[qberty]

Sorry, what I meant was the source code as in the classes that LiveCode compiles before packaging it into an APK (In androids case).

If you're quick enough, you could catch the code it compiles in a systems temp directory. It'd contain normal classes like the AppReciever and mblandroid class files. The LiveCode.jar file is just a zip file that can be extracted that IS java code obviously. Now in a normal scenario one can just take all the source code and toss it in to eclipse and just make edits on their own straight with Java. Which I've done, and failed at mainly because it doesn't compile in eclipse for obvious reasons.

The compilation for Android at least is minimally template driven java code after it's compiled then packaged. In essence you could (as an end user) edit the Classes file and xml's to include your own classes or functions. Of course it's practically useless without livecode being able to interact with it. Hence the need for this particular type of integration to not be on the external level.

The engine and all that jazz will always be separate. Has there even been any documentation for Android Externals by now?

[monte]

Ah.. I thought you were suggesting everything became java.

There's no docs yet about android externals but other than that I can't see why this couldn't be implemented as an external.