It's all about monkeys

Yesterday evening, May 7, two belgian user groups,  MADN and DotNetHub invited me to give a 2 hour introduction session on creating multi-platforms mobile applications in c# with Xamarin 2.0.

Microsoft Belgium was hosting the session, and the room was packed !

I really enjoyed that evening, and just wanted to thank you all: attendees for their presence and interactions, MADN and DNH for the invite and the bottle of wine, Microsoft Belgium for the place, food and drinks, and Xamarin for the give away licences, monkeys and t-shirts.

Decorating your Xamarin.iOS code with Behaviors

Note: this is the post in which I'm getting out of the closet and make it clear that I had an affair with Silverlight. I'm still thinking about it sometimes, and when I do, this is what happens...

Every time you have to ask your user "What's your favourite colour" or "What is the air-speed velocity of an unladen swallow?" from within your iOS application, you have to ask yourself "Wait, will the field still be visible with the virtual keyboard displayed ?"

I don't know how you do it (experience sharing is welcome), but me, I do it this way:

public override void ViewDidLoad ()
{
 base.ViewDidLoad ();

 //Set Bindings and Commands
 placeField.Bind (ViewModel, "Place");
 sendButton.Command (ViewModel.SendCommand);
 busyIndicator.Bind (ViewModel, "IsBusy");

 //Slide the view on keyboard show/hide
 placeField.EditingDidBegin += (sender, e) => {
  UIView.BeginAnimations ("keyboardslide");
  UIView.SetAnimationCurve (UIViewAnimationCurve.EaseInOut);
  UIView.SetAnimationDuration (.3f);
  var frame = View.Frame;
  frame.Y = -100;
  View.Frame = frame;
  UIView.CommitAnimations();
 };

 placeField.EditingDidEnd += (sender, e) => {
  UIView.BeginAnimations ("keyboardslide");
  UIView.SetAnimationCurve (UIViewAnimationCurve.EaseInOut);
  UIView.SetAnimationDuration (.3f);
  var frame = View.Frame;
  frame.Y = 20;
  View.Frame = frame;
  UIView.CommitAnimations();
 };

}

Blogging on topic

A pile of reblochon (get closer, you can smell them)

Producing Better Bindings: Completeness

Note: like the previous post, this one is a follow-up on a series written by someone else. We're all building on top of giant's shoulders. My giant today is Sébastien Pouliot from Xamarin. Read his series Producing Better Bindings.

Second Note: if you're reading this from a news aggregator, you might miss the embedded gists. Read the original there.

I'm lately enjoying writing bindings for Xamarin.iOS and Xamarin.Mac, a lot for the fun, very little for profit. The biggest project by far was creating a managed bindings for cocos2d (v2). This library is huge (~2500 public methods), and the API is far from being fixed in stone. The library is so big that at some point I just gave up, until Miguel resumed the effort during end-of-year break.

Await in the Land of iOS - Collisions in Chipmunk

Note: this blog post follows the ones of Frank Krueger about the alpha release of mono 3.x for Xamarin.iOS bringing .NET 4.5 features to the mobile world: Drag-n-drop and Scripting Users. Read that first, it's worth it.

The old way!

If you're using the Chipmunk bindings, the correct way to handle collisions between shapes is to register 4 (FOUR!) handlers for the different steps: begin, preSolve, postSolve and separate. Your collision handling logic is then spread in 4 different functions. All of that for the same collision.

Working around the reverse callback limitation on Xamarin.iOS

There's one annoying technical limitation of Xamarin.iOS if you have to pass a C# delegate instance to unmanaged code. It's not new, and it's well documented.

But still, having to flag the callback with an attribute and no instance method makes an API hard to use if you don't care that much about the internals of the library you're consuming.

I'm currently polishing the Chipmunk binding for Xamarin.iOS, and the cpSpace has some functions taking callbacks, like cpSpaceEachBody or cpSpaceAddPostStepCallback.

Chipmunk bindings for MonoTouch

(c) S. Delcroix 2013

I'm quite pleased to announce the availability of Chipmunk bindings for monotouch. I started that last year, and bound just enough of it to get a sample working, added some constraints lately in order to place labels, and completed it since for the beauty of the task. The image next to this is a screenshot from a system using a motor, a gear joint, pivot joints and some more.

At this point in time, the ~2000 lines of manually crafted lines of code can be found in this pull request, but you probably won't have to wait long before it's merged in the monotouch-bindings repository.

Our business app doesn't need your game development skills (using damped springs to place labels on a map)

The problem

Positioning labels on a map, a chart, a plan is a problem every UI developer face at one time or another if he has the chance to work on rich business app. This problem is NP-Hard for non-trivial cases. I faced that issue twice. First while building a silverlight charting library, and then very recently for positioning labels around a pin on a plan. This post isn't about how we solved those two cases. For the charting problem, we went for an algorithmic solution which was working but not optimal. For the second, I don't know how they solved it as I didn't took the job.