Xamarin

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

So today was my last day at Xamarin.

For any of you that are aware of the newly updated Xamarin Web site, you may have seen the following:

Objective-C was ahead of its time 30 years ago. C# is ahead of its time today. Anything you can do in Objective-C or Java, you can do in C# with Xamarin—usually more succinctly and with fewer bugs.

What is also true is that F# is way ahead of its time, and you can produce even more succinct code with even fewer bugs than C#!

With the release of Xamarin 3 there is a swathe of new features to the platform, but obviously the most important one is obviously F# support is now included by default in Xamarin Studio so there is no escape from the awesomeness of F#!

So what else have we got, well loads of other goodies too like Xamarin Designer for iOS, Xamarin.Forms, Major IDE enhancements, Improved code sharing with PCL and Shared projects, and BCL Documentation. You can see the release blog post here: announcing Xamarin 3

Over the last year a lot of work has been done on the F# addin for Xamarin Studio. Lots of great new features have been added and a lot of bugs have been squashed. I want to talk a bit about whats been happening and the evolution of the F# addin.

The F# addin for MonoDevelop / Xamarin Studio hasn’t always been as stable and pretty as it is now. When I first started working on it I went through a rocky phase of just trying to get it to compile and install. There were a whole host of changes going on in MonoDevelop which caused a lot of head scratching and late nights. Of all the issues encountered tooltips were the absolute bane of my life, they were often horribly mangled like this:

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 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: