Hack iOS for fun and profit
Michael Bayne
consumable by people that aren't me.
There are a few moving parts to the new iOS backend, which I'll summarize:
1. The playn.ios package itself, which is currently only in OOO's
PlayN repository. You can check that out here:
git://github.com/threerings/playn.git
2. The Java "bindings" to the CLR and MonoTouch C# libraries. I put
bindings in quotes because they're not bindings per se, they are Java
class files that allow one to write Java code that references the C#
assemblies, and when everything is later run through IKVM, those
references are turned into direct references to the C# assembles, so
the Java "bindings" disappear. These are published to the ForPlay
legacy Maven repository, so you don't need to do anything to obtain
them. The standard Maven build process will download them.
3. The Silverlight-profile-compatible build of IKVM. This can be
obtained here: http://dl.dropbox.com/u/404021/ikvm-monotouch.zip
4. Mono and MonoTouch (http://xamarin.com/monotouch). I'm using a Mac,
though in theory all of this will work on Linux or Windows, but I'm
making no promises to provide technical support on that front. If you
want to try this stuff out currently, you may need to expend some
effort. You also need to install MonoDevelop
(http://monodevelop.com/).
Now on to the actual building and testing:
Having cloned the OOO PlayN, you'll need to run "mvn install" therein.
Then "git pull" your playn-samples repository and you'll see that the
iOS bootstrap has been added to the playn-samples/hello project (in
hello/ios).
In playn/samples/hello run "mvn package".
Then "cd ios" and run build-dll.sh (you will need to edit the script
and change IKVM_HOME to wherever you unpacked ikvm-monotouch.zip).
This will run IKVM on the PlayN and hello-core jar files to generate
hello-core.dll.
Now edit the hello.csproj MonoDevelop project file and update the path
to ikvm-monotouch so that the project can find the
IKVM.OpenJDK.Core.dll.
Finally, open the hello.sln file in MonoDevelop. Then press the little
build button in the tool bar, followed by the debug button, which
should launch your simulator, running the Hello sample. This will just
show you the rainbow background, since that's what the sample does by
default. Touch input isn't working yet, so you can't add peas, but you
can modify HelloGame.java thusly if you want to see something move:
diff --git i/hello/core/src/main/java/playn/sample/hello/core/HelloGame.java
w/hello/core/src/main/java/playn/sample/hello/core/Hell
index d2155bc5cf..bdc01a1343 100644
--- i/hello/core/src/main/java/playn/sample/hello/core/HelloGame.java
+++ w/hello/core/src/main/java/playn/sample/hello/core/HelloGame.java
@@ -52,6 +52,9 @@ public class HelloGame implements Game {
peas.add(pea);
}
});
+
+ Pea pea = new Pea(peaLayer, graphics().screenWidth()/2,
graphics().screenHeight()/2);
+ peas.add(pea);
}
@Override
That's about the size of it. I'll be working on fleshing out the iOS
backend, though I'm already sidetracked because IKVM doesn't fully
support C# delegates that take ref parameters. Damn C# for adding all
this useful stuff whilst Java sat on its committee-laden ass for the
last half-decade.
Michael Bayne
> I'm using a Mac,
> though in theory all of this will work on Linux or Windows
Oh duh. MonoTouch certainly isn't going to work on Linux or Windows
because you can't run the iPhone simulator. So I guess that simplifies
things. You need to use a Mac!
Michael Bayne
> backend, though I'm already sidetracked because IKVM doesn't fully
> support C# delegates that take ref parameters.
It turned out not to be that difficult to remove said limitation from
IKVM. Fortunately, the change only impacted the binding generator, so
there's no need to update ikvm-monotouch.zip. I did update the
monotouch.jar in the Maven repo, but since that's a SNAPSHOT artifact,
it should automatically be downloaded by anyone speedy enough to
already be playing with this stuff.
With that fixed, I was able to implement IOSPointer and IOSTouch, so
now you can click on the Hello demo and place rotating peas on the
screen. No longer is it necessary to visualize whirled peas, you can
see them for yourself.
Christopher Östlund
Evans
>>obtained here: http://dl.dropbox.com/u/404021/ikvm-monotouch.zip
Michael Bayne
> Is there a separate open source project for this, or is this something you
> built on your own?
It's something I built on my own:
Evans Thomas
Evans Thomas
Michael Bayne
> What am I missing here?
I don't know. I hacked my NAnt installation to point to the MonoTouch
DLLs and had to do a lot of fiddling to get everything to reference
the correct version of the system DLLs.
If you're building with NAnt, I don't think MONO_PATH is used for
anything. NAnt sets up the paths to the system DLLs based on the -t
argument. NAnt.exe.config contains the settings for all of the
possible -t arguments. I modified the NAnt installed by Mono to point
the moonglight-2.0 framework at the MonoTouch DLLs.
I don't know what the right DLLs are for Windows phone, but you'll
need to configure NAnt to use them.
Evans Thomas
Michael Bayne
> No, I'm not using NAnt. It's just a simple batch file. It directly
> invokes ikvmc.
Are you running ikvmc from my ikvm-monotouch.zip? You won't be able to
just use that out of the box, because it is built against the 2.0.5.0
versions of the CLR core DLLs that ship with MonoTouch.
If you want to use my modified IKVM for Windows Phone, you'll need to
rebuild my modified IKVM against the Windows Phone CLR core DLLs.
Evans Thomas
Michael Bayne
> Your comments in the readme kinda scared me away from building it :)
Yeah, unfortunately I don't think there's anyway to avoid diving into
the deep end.
kshush...@gmail.com
Michael Bayne
> Is there is a way to generate the following files for my
> project: Info.plist, Main.cs, mygame.csproj, mygame.sln ...?
> or should i create them manually?
Currently they have to be created manually.
Simen S.
Darrin Thompson
> I have been tinkering a bit to see if I can get our game running on ios. So
> far everything has worked surprisingly well, I got everything compiling, but
> I get errors at runtime in the simulator. It seems to be due to our use of
> Guice, and its annotations, especially @Inject on constructors. Do you have
> any experience with this? I assume they are lost in the void at some stage?
> ("Classes must have either one (and only one) constructor annotated with
> @Inject or a zero-argument constructor that is not private." ). Not sure if
> there is any good solution here, or if I should take the painful route of
> manually wiring up everything to see if I get further.
>
What platform was working before?
--
Darrin
Michael Bayne
> It seems to be due to our use of Guice, and its annotations, especially
> @Inject on constructors. Do you have any experience with this?
device. What errors are you getting?
-- m...@samskivert.com
Michael Bayne
> @Inject on constructors.
constructors working in IKVM until fairly recently. So you should try
downloading the lastest ikvm-monotouch.zip from here and see if it
works:
http://dl.dropbox.com/u/404021/ikvm-monotouch.zip
-- m...@samskivert.com
Simen S.
Michael Bayne
> "Unhandled Exception: com.google.inject.CreationException: Guice creation
> errors:
>
> 1) Could not find a suitable constructor in ClassThatInjects. Classes must
> have either one (and only one) constructor annotated with @Inject or a
> zero-argument constructor that is not private.
> at ClassThatInjects.class(Unknown Source)
> at GuiceModule.configure(GuiceModule.java:12)
>
> 1 error
> [ERROR] FATAL UNHANDLED EXCEPTION: com.google.inject.CreationException:
> Guice creation errors:
>
> 1) Could not find a suitable constructor in ClassThatInjects. Classes must
> have either one (and only one) constructor annotated with @Inject or a
> zero-argument constructor that is not private.
> at ClassThatInjects.class(Unknown Source)
> at GuiceModule.configure(GuiceModule.java:12)
>
> 1 error"
I looked into this a little, but it's pushing the deep magic that
makes the iOS backend work beyond its limits. It's frankly a small
miracle that enough of Java is supported that this could even work at
all, and I'm by no means certain that you wouldn't run into another
major roadblock once the time came to compile your app for the device
using the AOT compiler.
In theory all of Java annotations and reflection are supported by IKVM
and turned into CLR annotations and reflection, which are in theory
supported in both the desktop CLR (which runs the simulator) and on
the device (which uses the AOT compiler to generate ARM assembly from
the CLR bytecodes). However, that's already a lot of theory. Combine
that with the fact that Guice is pushing Java's reflection
capabilities to the limit and doing lots of crazy stuff (c.f. your
having to avoid using the AOP bytecode rewriting version of Guice).
I tried to find out whether the @Inject annotation is making it
through into the CLR bytecodes, but the DLL generated by IKVM causes
monodis (the javap equivalent on Mono) to segfault. I don't have any
other easy way to inspect the CLR bytecodes, and I certainly don't
have time to debug monodis. It's also possible that reflection is
failing to find the constructor in question, I think that enumeration
of constructors should work fine but maybe something is going wrong
there.
I've given you the moon (silverlight -> moonlight -> moon, ha ha...),
I'm afraid that if you want the asteroid belt as well, you're going to
have to put on your spacesuit and go get it yourself.
If you want to dig into things, I'd suggest making a test app that
uses reflection directly to enumerate the constructors of
ClassThatInjects, and make sure they show up. Then manually check to
see if the @Inject annotation is showing up. If one of those things is
failing, then you at least know where to look if you choose to go
spelunking in the ikvm-monotouch code.
Darrin Thompson
> In theory all of Java annotations and reflection are supported by IKVM
> and turned into CLR annotations and reflection, which are in theory
> supported in both the desktop CLR (which runs the simulator) and on
> the device (which uses the AOT compiler to generate ARM assembly from
> the CLR bytecodes). However, that's already a lot of theory. Combine
> that with the fact that Guice is pushing Java's reflection
> capabilities to the limit and doing lots of crazy stuff (c.f. your
> having to avoid using the AOP bytecode rewriting version of Guice).
>
Probably this is new to no one here but Gin is supposed to provide a
subset of Guice features but in a way that works with GWT. Basically
all the injection stuff is figured out at compile time. Is Gin's dark
magic likely to be compatible with the rest of the PlayN backends?
Michael Bayne
> Probably this is new to no one here but Gin is supposed to provide a
> subset of Guice features but in a way that works with GWT. Basically
> all the injection stuff is figured out at compile time. Is Gin's dark
> magic likely to be compatible with the rest of the PlayN backends?
I haven't looked at Gin, but I suspect they'll be wildly incompatible.
I expect that Gin will make use of GWT's generator infrastructure to
evaluate all of the metadata bits at compile time and hardwire the
dependencies then.
A working Guice on iOS would ostensibly use the same mechanisms that
Java's Guice does (reflection), but it's currently suffering from
"translate joke into Russian, then into French, then back into
English" difficulties.
Christopher
Michael Bayne
<christophe...@gmail.com> wrote:
> I just wanted check if there has been any more debugging or new versions of
> the different parts that might have fixed this.
reflective constructor invocation. So you'll want to download the most
recent build of ikvm-monotouch or build it yourself from source:
https://dl.dropbox.com/u/404021/ikvm-monotouch.zip
https://github.com/samskivert/ikvm-monotouch
-- m...@samskivert.com
Christopher Östlund
--
Christopher Östlund
pauli.sa...@rovio.com
I was wondering if you ever got the Playn+Guice+iOS combination working? I'm about to experiment with this in the near future and this seems to be the only thing that might prevent me from creating an iOS game. I depend too much on Guice. So much in fact that I don't know how to program without it anymore.