Ios

So as promised here’s a post with more detail on the iOS designer provider that I presented as part of my talk at fsharpX 2017 The talk is entitled Expanding the Horizons of Mobile Development

Only a quick post this week. Last time we looked at SpriteKit and how to add some particle emmiters to simulate a star-field and exhaust on a spaceship, this time lets look at adding some touch based input to move the spaceship around.

The first thing we need to do is add a type of gesture recogniser, there are various built in gestures:

• UITapGestureRecognizer
• UIPinchGestureRecognizer
• UIRotationGestureRecognizer
• UISwipeGestureRecognizer
• UIPanGestureRecognizer
• UIScreenEdgePanGestureRecognizer
• UILongPressGestureRecognizer

From the names above it’s pretty easy to get a feel for how they should be used, you can create your own subclass of UIGestureRecognizer if you need a custom one.

I have been meaning to write this post for quite a while now. Since the first announcement of the iOS7 beta I immediately saw the list of new API’s and SpriteKit caught my eye straight away. I only managed to get time to briefly look over the API and saw that is wasn’t the usual trashy API with a million method overloads, internal mutation sucker punch type thing. It seems to be very declarative and intuitive, which makes for a nice change.

In this post weare going to look as async again, but from the perspective of F#.

Xamarin Evolve 2013

I was going to title this post as ‘Now for something completely different’ but felt that a little bit too Pythonesque, and when I thought about it a bit it isn’t really completely just slightly different, namely C# rather than my usual F# posts.

Right, enough of the waffling, this post is a little tour into the relatively unknown area of async on iOS. Xamarin announced the alpha preview of async await on March 11th this year (2013). There are a couple of blog post floating around on the net if you look around, Rodrigo Kumpera posted a small example here.

In the last post we left at the point where everything was running fine and dandy on the Simulator. So what happens if we compile for the real hardware?

Lets change the active configuration to Debug|iPhone and hit build, what do we get?

Boom!

Error MT2002: Could not resolve: FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a (MT2002) (singleview)

So I guess we need to tell it where the FSharp.Core.dll is, lets add a reference to it:

MonoTouch and F# that would be a cool duo right?

Well let me explain what needs to be done and why to get this pair working together.

I heard rumours a while ago that F# and MonoTouch would not play together nicely because of limitations in the ahead of time compilation (AOT). So I thought I would either prove or disprove this with some concentrated hacking. How hard can it be?

As my good friend and colleague Dr. Kewin would quote: