Miguel's OSX and iOS blog

Inside the Sausage Factory: Xamarin iOS/Mac 64 bit support

miguel@xamarin.com (Miguel de Icaza) — Mon, 11 Nov 2013 22:09:00 -0500

This blog post discusses Xamarin's current plans to support the 32 and 64 bit frameworks in our products.

When we first created the C# bridge to iOS with MonoTouch, we mapped the data types from Objective-C to their equivalent data types in C#. Since C# does not have an equivalent to "typedef" we also mapped type definitions into their underlying data types.

This means that we mapped C types like int to System.Int32 (short: int) float to System.Single (short: float). This is because on .NET the int data type is defined to be a 32 bit integer, and long is always a 64 bit integer.

We also chose to map things like CGRect to RectangleF at this point. But most importantly, we mapped things like NSInteger as int and CGFloat to float, since NSInteger was a 32 bit value and CGFloat was a 32 bit value. We later did the same work for the Mac and we continued doing these mappings.

We were living in a 32-bit world.

The 64 bit version of OSX had defined NSInteger and CGFloat to be 64 bit values, changing the assumptions that we had made.

The challenge to support 64 bits was that we would need to change the public API on our Mac APIs, stuff like:

class Xxx {
	[Export ("getRowCount")]
	public int GetRowCount () {...}
}

Would become:

class Xxx {
	[Export ("getRowCount")]
	public long GetRowCount () {...}
}

The above is problematic for two reasons. We would need to audit all of our APIs to do the proper type mapping and we would break source code compatibility, with code like this:

var foo = new Xxx ();
int count = foo.GetRowCount ();

// oops, can not cast a long into an int.

When we combined source code breakage with the fact that Apple had a 32-bit compatibility story and we had some legacy libraries that depended on 32-bit only APIs meant that we were in no rush to move to a 64-bit world.

OSX 64 bit frameworks

With Mountain Lion, Apple started to ship a handful of their new frameworks only as 64-bit frameworks. This means that for the first time, MonoMac was not able to provide bindings to some frameworks.

At this point, we realized that we had to get out of our 32-bit comfort zone. But we still needed to support 32-bits, since iOS was a 32-bit only API and OSX was turning into a 64-bit only API.

We needed some way of sharing code.

At this point we had a number of options in our plate, to make a very long story short, we decided to do two things:

Audit all of our APIs and annotate every use of NSInteger and provide tooling to ensure that we had both 32 and 64 bit APIs. This would allow us to produce both 32 and 64 bit bindings.
Build a tool to help Mac users migrate their applications and upgrade their uses of the narrower data types to the wider ones.

Our thinking was simple: every new Mac would be 64-bit capable. So this means that we could support the old 32 bit API for existing Mac users, but new APIs would require the source code to be upgraded to 64-bits, never to look back again.

There was little incentive to expand support for 32-bit only APis on the Mac. The world was going 64.

We were executing on this process when Apple introduced the iPhone5s with a 64 bit processor.

iOS goes 64 bit

The iPhone5s forced us to revisit our assumptions.

Apple introduced the 64-bit iPhone5s, but also introduced the iPhone5c which is a 32-bit processor.

This means that developers need to be able to target 32 bits for at least some five years.

We had two choices with the old strategy with regards to iOS: either stay in the 32 bit world for the next five years or force users to maintain two codebases (one for 32 and one for 64). Neither option was attractive.

So we resorted to a more sophisticated approach that we had originally dismissed.

Transparently Supporting 32 and 64 bit Code

Our goals shifted. While we could ask Mac users to do a one-time switch, we could not ask that from our iOS users.

We needed to support both 32 and 64 bit code from a single codebase, even if this required some magic beyond bindings. Compiler, linker and tooling would have to come together.

We are now going to keep our existing 32 bit APIs --for the sake of backwards compatibility for all of our iOS and Mac users-- and also introduce new APIs that are 32/64 bit ready.

We are doing this by introducing a few new data types: nint, nuint and nfloat which are 32-bit wide on 32 bit architectures, and 64-bit wide on 64-bit architectures.

We would also move from RectangleF, SizeF and PointF to CGRect, CGSize and CGPoint which would be defined not in terms of the C# float data type, but in terms of nfloat.

These data types will live in the System namespace inside the Xamarin.iOS.dll and Xamarin.Mac.dll.

These are defined roughly like this:

struct nint {
#if 64
	long value;
#else
	int value;
#endif
}

By defining these are plain structs, we ensure that any code using these data types is legal C#, compatible with Microsoft's C#.

But at runtime, depending on which platform you are running, you will get either 32 or 64 values.

This means that all of the Objective-C APIs using NSInteger that we originally had mapped to int will now take an nint but also that users can choose to stay on a 32-bit world, or have code that automatically compiles to both 32 and 64 bit at the same time.

This means that the original GetRowCount example would now be written like this:

class Xxx {
	[Export ("getRowCount")]
	public nint GetRowCount () {...}
}

// ...

var foo = new Xxx ();
nint count = foo.GetRowCount ();

In the above case, count will be a 32 bit value on 32 bit systems and 64 on 64 bit systems.

We added implicit and explicit operator conversions from and to the underlying data types. We follow the .NET Framework Design Guidelines for implicit and explicit operators, with an added twist: we only consider implicit conversions when there would be no data loss in the 32 and the 64 bit worlds. Otherwise you must use explicit conversions, like this:

public struct nint {
    // Implicit conversions
    static implicit operator nint  (Int32 v);
    static implicit operator Int64 (nint v);

    // Explicit conversions
    static explicit operator Int32  (nint v);
    static explicit operator nint   (Int64 v);
    static explicit operator UInt32 (nint v);
    static explicit operator UInt64 (nint v);

    // Explicit IntPtr conversions
    static explicit operator IntPtr (nint v);
    static explicit operator nint   (IntPtr v);
    static explicit operator nint   (IntPtr v);
}

This means that you can always go from an nint to a C# long. But going from a nint to an int requires a cast as there would be data loss in the case where the nint is a 64 bit value.

For example:

// valid, implicit conversion:
long count = foo.GetRowCount ();

// error:
int count = foo.GetRowCount ();

// use an explicit cast, valid:
int count = (int) foo.GetRowCount ();

Astute readers, or those familiar with .NET, will notice that:

int Add (int a, int b)
{
	return a+b;
}

int Add (nint a, nint b)
{
	return a+b;
}

Will compile down to drastically different IL.

The first uses native ECMA IL instructions to perform the addition, while the second compiles to a call op_Addition

We have taught our VM to understand these new data types and treat them in the same way that we would treat a native type. This means that there is no performance difference between the use of int vs nint. The call op_Addition ends up being the same as the native ECMA CIL add instructions. The IL might look scarier, but the native code is identical.

We chose the names nint, nuint over the built-in IntPtr and UIntPtr, because they felt natural "native integers" as opposed to the cultural association that IntPtr has with pointer or a native token. Additionally, we did not have the equivalent native floating point type.

We chose to stay away from using the names NSInteger and CGFloat for a couple of reasons: the functionality is general enough that it might be worth using in Mono in places beyond Mac and iOS and because it feels like these are real VM supported types as opposed to some type definition or alias. In an ideal world, these would eventually be part of the C# standard.

What will the world look like?

Users that are happy living in the pure 32 bit world will get to keep using their existing assemblies and project types (monotouch.dll and MonoMac.dll/XamMac.dll).

Users that want to adopt new 64-bit only APIs, or want to have their code automatically run on 32 or 64 depending on the target CPU will use the new Xamarin.iOS.dll and Xamarin.Mac.dll assemblies and a new project type that knows how to build dual 32/64 binaries transparently.

One added benefit of this new design is that third party components and libraries will automatically be 32/64 bit ready.

We will also distribute the same tools that we used to upgrade from 32 to 32/64 to assist our users that want to migrate existing codebases to the new 32/64 bit world.

Awaitable ShowAlert

miguel@xamarin.com (Miguel de Icaza) — Thu, 03 Oct 2013 14:50:00 -0500

Alex Corrado shared with me a trick to easily show UIAlertViews without ceremony.

You use it like this:

async void Demo ()
{
    switch (await ShowAlert ("Title", "Message", "Ok", "Cancel")){
	case 0: // Ok
	    ....
        case 1: // Cancel
            ....
    }
}

The beauty is being able to show alerts and linearly decide what to do with the result.

Here is the helper method:

// Displays a UIAlertView and returns the index of the button pressed.
public static Task ShowAlert (string title,
                                   string message,
                                   params string [] buttons)
{
    var tcs = new TaskCompletionSource ();
    var alert = new UIAlertView {
        Title = title,
        Message = message
    };
    foreach (var button in buttons)
        alert.AddButton (button);
    alert.Clicked += (s, e) => tcs.TrySetResult (e.ButtonIndex);
    alert.Show ();
    return tcs.Task;
}

Using RevealApp with MonoTouch

miguel@xamarin.com (Miguel de Icaza) — Sun, 29 Sep 2013 15:43:00 -0500

To use RevealApp with Xamarin.iOS, this is all you have to do:

Download the Reveal Beta
Use the Finder to go to the location where Reveal was downloaded to, and use the Finder's "Show Package Contents".
Open the contents and drag the file "Reveal" from the iOS-Libraries directory into your Xamarin Studio project.
Change the properties in Xamarin Studio for the file and set "Build Action" to None:
Tell Xamarin Studio to link the library:

Run your app, and it should then show up on the Reveal UI

Adopting iOS7 Dynamic Type in Your App

miguel@xamarin.com (Miguel de Icaza) — Wed, 25 Sep 2013 21:45:00 -0500

Before iOS7, developers could either get the system font in regular, italic or bold and a small font, using APIs like this:

static UIFont SystemFontOfSize     (float size);
static UIFont BoldSystemFontOfSize (float size);

Developers could use the SystemFontSize to get the system font size, but beyond this single number there was no guidance as to what font sizes to use. It was every-man-for-himself kind of place, not too different from the wild west, where people like me would pick 14 because we need glasses, and avant garde designers would pick 11 points.

It was madness!

Guidance

To assist making applications more consistent, developers now have acces a series of pre-configured fonts that can be used in various scenarios, these are available first as properties directly on UIFont:

static UIFont UIFont.PreferredHeadline    { get; }
static UIFont UIFont.PreferredSubheadline { get; }
static UIFont UIFont.PreferredBody        { get; }
static UIFont UIFont.PreferredCaption1 { get; }
static UIFont UIFont.PreferredCaption2 { get; }
static UIFont UIFont.PreferredFootnote { get; }

Apple's documentation states that the fonts returned have their properties adjusted to be optimized for reading. The most noticeable attribute those fonts have is the default font and their font sizes.

This is how they look like at the default size:

And this is how they look when the text size in the system is set to the largest size (my default):

Merely accessing the UIFont properties will return the properly sized font depending on the user settings.

Responding to User's settings

With iOS7, the user can change the desired size for his fonts in the Settings application. Applications in turns should respond by adjusting their contents. They do this by using the freshly minted fonts that the system has created for them in the UIFont properties and respond to the system notification that the user has made a font size change.

To do this, you register a UIApplication.Notification, like this:


UIApplication.Notifications.ObserveContentSizeCategoryChanged (delegate {
    // text size has changed, reconfigure any UIViews's font here

    // Simple:
    exampleLabel.font = UIFont.PreferredBody;
});

Customizing the Fonts

UIKit Developers now have access to all of the advanced typographic control available in CoreText. The interface to customize fonts is provided by the UIFontDescriptor class. You can fetch a UIFontDescriptor a UIFont by accessing its FontDescriptor property, and you can in turn create UIFonts by configuring a UIFontDescriptor and requesting that a font be created for you.

This is what you do to create a bold or italic fonts:


UIFont MakeBold (UIFont font)
{
    var desc = font.FontDescriptor;

    // create a new descriptor based on the baseline, with
    // the requested Bold trait
    var bold = desc.CreateWithTraits (UIFontDescriptorSymbolicTraits.Bold);

    // Create font from the bold descriptor
    return UIFont.FromDescriptor (bold);
}

You use UIFontDescriptorSymbolicTraits.Italic for creating an italic font, this is what text looks like for the PreferredBody by default:

Other simple traits that you can apply to a font include the interline spacing. Something that was not possible previously:

To achieve the above, all you have to do is pass the UIFontDescriptorSymbolicTraits.TightLeading or UIFontDescriptorSymbolicTraits.LooseLeading parameters to the CreateWithTraits method.

Using CoreText Font Features

While the above will be enough for many applications, CoreText provides comprehensive access to many features of underlying fonts.

You can use the UIFontDescriptor.CreateWithAttributes method to pass your detailed list of UIFontAttributes that you want to set on your font.

The following example shows how to request the use of proportional numbers in the default font:


public UIFont ResizeProportional (UIFont font)
{
    var attributes = new UIFontAttributes (
	new UIFontFeature (
	   CTFontFeatureNumberSpacing.Selector.ProportionalNumbers));
    var newDesc = font.FontDescriptor.CreateWithAttributes (attributes);
    return UIFont.FromDescriptor (newDesc, 40);	
}

The nice thing about these strong types is that code-completion in the editor basically provides you with a visual guide of which attributes are available for you to use. This is the result of the above code when rendering numbers:

The above is just a sample, you can use any of the CoreText Font Features to customize the rendering of your font.

Some other variations:

The entire sample showing these features is available in the ios7fonts directory.

CFNetwork-powered HttpClient

miguel@xamarin.com (Miguel de Icaza) — Fri, 07 Jun 2013 19:52:00 -0500

Newer versions of .NET introduced a new Http client API: HttpClient. This new API is designed to integrate naturally with C# async language extension. Some of its virtues are described in Henrik's blog post.

While HttpClient by default uses the .NET framework's HttpWebRequest for actually connecting to the server, the API was designed to allow other implementations of the HTTP stack to be used instead.

With both the beta versions of MonoTouch and the upcoming Xamarin.Mac, you can now use CFNetwork as your HTTP transport. To do this, all you have to do is change your instantiation from:

var client = new HttpClient ();

To:

var client = new HttpClient (CFNetworkHandler ());

Using CFNetwork for your http client has the following differences from HttpWebRequest:

On iOS, CFNetwork will automatically turn on the phone's radio if it is off before starting the HTTP request. This means that you no longer need to manually use the StartWWAN methods.
Connection pooling is managed by CFNetwork as opposed to the settings in .NET's stack.
Will automatically track proxy and network settings done to iOS.
Operations are performed on the CFNetwork dispatch queues/threads instead of consuming threads from Mono's own managed thread pool.

In both cases, you will be able to continue using the same APIs, the only difference is in how you construct your HttpClient.

Contribute Your Storyboard Files for Humanity

miguel@xamarin.com (Miguel de Icaza) — Mon, 11 Mar 2013 15:33:00 -0500

Ok, ok, not quite for humanity.

We are trying to improve our support for Xamarin Studio integration with Storyboard files, and we would like to collect a bunch of different samples.

If you can share your .storyboard file with us, please email alan at xamarin.com just the .storyboard file

Using Instruments to profile Mac apps built with Mono

miguel@xamarin.com (Miguel de Icaza) — Thu, 03 Jan 2013 18:50:00 -0500

On most platforms, Mono generates code dynamically as your software runs. The Instruments profiler does not have the ability to map a memory address of the generated code back to the name of your function being executed. This makes it pretty hard to find the hot spots in your code, or the bit of code responsible for a memory leak.

To solve this problem, you can use Mono's ahead of time compiler to precompile your code to native code. This will improve startup performance and also give you symbols in stack traces in Instruments.

To do this, run mono with the --aot flag over all of the assemblies that your project uses. This is the script that I ran to precompile all of my system libraries:

cd /mono/lib/mono
for i in `find gac -name '*dll'` */mscorlib.dll; do
   mono --aot $i
done

This precompiles all of the assemblies from the Global Assembly Cache (GAC) and also takes care of all of my mscorlib libraries (these are not loaded from the GAC).

Then you need to add your own software:

	 $ mono --aot bin/Debug/*.{exe,dll}

Now, when you use Instruments, you will get nice symbolic stack traces for your process.

Thanks to Alan McGovern for showing me this trick.

Translating Objective-C adopts-protocol idioms to C#

miguel@xamarin.com (Miguel de Icaza) — Tue, 27 Nov 2012 16:00:00 -0500

Sometimes when looking at Objective-C samples, you might run into code that adopts protocols and you wonder how to port that code to C#. It typically looks like this:

@interface TransparentOverlay : UIView <UITableViewDelegate, UITableViewDataSource>
{
}

The above means that the "TransparentOverlay" object subclasses UIView and adopts two protocols: UITableViewDataSource and UITableViewDelegate.

The above does not really work with MonoMac or MonoTouch, since we mapped protocols into classes. In both bindings UITableViewDelegate and UITableViewDataSource are "model" classes.

The real meat of this is that somewhere in the implementation of TransparentOverlay, a UITableView will be created, and both its delegate and its data source will be configured to point to the TransparentOverlay source, something like this:

- (void) setup
{
	myTableView = [[UITableView alloc] initWithFrame:...];
	myTableView.delegate = self;
	myTableView.dataSource = self;
}

The adopted protocol allows you to perform the assignemnt there.

The equivalent code in C# needs to create a helper class that derives from the model. This is the full implementation:

class TransparentOverlay : UIView {
    UITableView tableview;

    class MySources : UITableViewSource {
        TrasparentOverlay container;

        public MySources (TrasparentOverlay container)
        {
            this.container = container;
        }

	override void MethodOne ()
	{
            container.DoSomething ();
	}
    }

    void Setup ()
    {
        tableview = new UITableView (....);

        var mySource = new MySources (this);
        tableView.Delegate = mySource;
        tableView.DataSource = mySource;
    }
}

Note that the UITableViewSource is an aggregated version of UITableViewDataSource and UITableViewDelegate, it is just a convenience Model for a very common idiom.

As you can see, instead of using "self" to point to the "TransparentOverlay" instance, you need to make it point to the mySource instance.

The methods in MySource can get access to the content of their container by using the "container" property as illustrated by the MethodOne method.

CoreMIDI in MonoTouch/MonoMac

miguel@xamarin.com (Miguel de Icaza) — Tue, 11 Sep 2012 22:07:00 -0500

This new release of MonoTouch (and MonoMac) come with our new CoreMidi bindings. In the same spirit of the work that we did for AudioToolbox and other frameworks, we created a C# bindings that follows the .NET framework guidelines for the API.

When I started these bindings, I knew close to nothing about MIDI. It is a framework that is not exactly well documented for people new to MIDI, but posts like this helped me get these bindings sorted out.

MonoTouch/MonoMac binding resembles in many ways the object-oriented bindings that developers have created to make CoreMIDI easier to digest. At its core, it is still an object oriented framework, that happens to be exposed with a fairly hostile C interface.

Our interface surfaces the underlying object oriented system with a strongly typed C# interface. Unlike the C interface that exposes a general property querying system that applies to all midi objects (MidiDevice, MidiEndpoint, MidiEntity, MidiPort), the binding ensures that only the available properties for each main class are exposed. This is a convenient way of avoiding a trip to the docs and to google to find samples.

To save developers some pain, as I developed the binding, I documented my findings in the MonoTouch.CoreMIDI documentation and added various samples to our API docs:

Our CoreMidiSample is a tiny program that replicates most of the funcionality of the MIDI sample apps, and is an easy starting point for people that want to get started with MIDI on iOS.

Interesting CoreMidi events are turned into C# events, so you can listen to changes like this:

client = new MidiClient ("CoreMidiSample MIDI CLient");
client.ObjectAdded += delegate(object sender, ObjectAddedOrRemovedEventArgs e) {
	Console.WriteLine ("Object {0} added to {1}", e.Child, e.Parent);
};
client.ObjectRemoved += delegate(object sender, ObjectAddedOrRemovedEventArgs e) {
	Console.WriteLine ("Object {0} removed to {1}", e.Child, e.Parent);
};
client.PropertyChanged += delegate(object sender, ObjectPropertyChangedEventArgs e) {
	Console.WriteLine ("Property {0} changed on {1}", e.PropertyName, e.MidiObject);
};
client.ThruConnectionsChanged += delegate {
	Console.WriteLine ("Thru connections changed");
};
client.SerialPortOwnerChanged += delegate {
	Console.WriteLine ("Serial port changed");
};

//
// Create your input and output ports
//
outputPort = client.CreateOutputPort ("CoreMidiSample Output Port");
inputPort = client.CreateInputPort ("CoreMidiSample Input Port");

// Print out packets when we receive them
inputPort.MessageReceived += delegate(object sender, MidiPacketsEventArgs e) {
    Console.WriteLine ("Got {0} packets", e.Packets.Length);
};

MonoTouch and UIKit Thread Safety

miguel@xamarin.com (Miguel de Icaza) — Mon, 10 Sep 2012 17:03:00 -0500

No major UI toolkit is thread safe.

This means that these toolkits are not designed to have their exposed methods be invoked by multiple threads at the same time from multiple threads. The main reason is that building thread safe toolkits is both a very hard problem and can have very complicated semantics for the consumer of the toolkit.

Developers typically use multiple threads in UI applications to offload tasks that would otherwise block the user interface. The work is offloaded to a background thread that can take as long as it wants or can perform various blocking operations like disk or network operations without affecting the interactive nature of the application.

When the background code completes its work, it queues an operation to be executed on the main thread to perform any required UI updates.

In MonoTouch and MonoMac the queuing of the operation from the background thread to the main thread is done using the InvokeOnMainThread or BeginInvokeOnMainThread methods.

The rule among toolkits is: do not access any toolkit APIs from the background thread since there is nothing in the toolkit API to defend against internal state corruption caused by multiple threads updating internals at the same time. Failure to follow this rule can lead to subtle bugs or crashes. The offending code is typically very hard to track down since the problem is timing sensitive and the corruption can vary from run to run.

Helping Developers Write Better Code

In theory, it is very easy to avoid making UIKit calls from a background thread, it only takes discipline. But some developers are not even aware that they are making UIKit calls from a background thread because their code so far has not crashed (they have been mostly luck). Another problem is that software is continuously evolving, and it is possible for developers to accidentally use UIKit APIs from a background thread during a refactoring pass, or when new features are introduced by a team members that was not aware of the clean split.

With MonoTouch 5.4 we have introduced a feature that will help you track incorrect uses of UIKit from a background thread.

Starting with this release, debug builds of your application will throw a UIKitThreadAccessException exception if you try to invoke a UIKit method from a background thread.

This is what the exception will look like:

MonoTouch.UIKit.UIKitThreadAccessException:
    UIKit Consistency error: you are calling a UIKit method that can only
    be invoked from the UI thread.

  at MonoTouch.UIKit.UIApplication.EnsureUIThread
  at MonoTouch.UIKit.UIView.get_Subviews
  at Sample.AppDelegate.m__0

This is a fabulous tool. It founds bugs in my own code within a few seconds of me using my own software. Sometimes the bug is right there for you to see, but do not notice the mistake.

The Whitelist

Over time, Apple has made some of UIKit APIs thread safe. This means that there are certain APIs that can safely be used concurrently by both the main thread and background threads. Those are documented in MonoTouch's documentation

Our list is based on what Apple has publicly documented as thread safe in different forums. It is likely that more types and methods will become thread safe in the future, and when that happens, MonoTouch will will remove the particular check for debug builds for it.

Controlling The Thread Safety Check

By default MonoTouch is configured to perform the thread checks only on debug builds of your software. If you want to have these checks performed also during release builds, you can pass the --force-thread-check to the mtouch compiler.

You might want to disable this check for a couple of reasons. You might have a big infringing codebase that is mostly working for you now, and can not afford to go fix these bugs right away. Or you could get confirmation from Apple that it is safe to call an API from a background thread. With MonoTouch, we have opted to be conservative and go by what is documented, but it is very possible that there are some APIs that are thread safe and just have not been documented as such.

You can disable the feature for debug builds by passing the --disable-thread-check flag to the compiler, or you can do this at runtime by changing the value of UIApplication.CheckForIllegalCrossThreadCalls, like this:

//
// Disable UIKit thread checks for a couple of methods
//
var previous = UIApplication.CheckForIllegalCrossThreadCalls;
UIApplication.CheckForIllegalCrossThreadCall = false;

// Perform some UIKit calls here
foo.Bar = 1;

// Restore
UIApplication.CheckForIllegalCrossThreadCalls = previous;

Adding Your Own Checks

If are building a library that wants to enforce the same kind of checks, you should call the new UIApplication.EnsureUIThread from your code to perform these checks.

Feedback Requested: Binding NSAttributedString

miguel@xamarin.com (Miguel de Icaza) — Fri, 24 Aug 2012 17:47:00 -0500

As NSAttributedString plays a big role, I have been trying to figure out a way of improving the process by which NSAttributedString are created from C#.

Status Today

While we support the NSDictionary-based approach of creating the attributed needed for an attributed string, like this:

var attrs = new NSMutableDictionary () {
  { NSAttributedString.FontAttributeName,
    UIFont.FromName ("Heletica 14") },

  { NSAttributedString.ForegroundColorAttributeName,
    UIColor.Black }
};

var myString = new NSAttributedString ("Hello", attrs);

If you ignore the fact that Helvetica 14 is an uninspiring and inconsequential font, the example above is error prone.

Developers can pass a UIColor where a UIFont was required, or a number or anything else. They also have no idea what values are acceptable unless they take a trip to the documentation and find out which values are allowed, and the types of their values.

The Standard Choice

What we have historicallly in situations like this is to create a helper, strongly typed class. This allows the IDE to provide intellisense for this situation, explicitly listing the types allowed and ensuring that only the correct values are set. If we use this approach, we would introduce a new class, let us say "NSStringAttributes":

var attrs = new NSStringAttributes () {
  Font = UIFont.FromName ("Heletica 14"),
  ForegroundColor = UIColor.Black
};

var myString = new NSAttributedString ("Hello", attrs);

The only problem that I have with this approach is that now we have two classes: NSAttributedString which is the actual string with the given attribute and a class that has a name that resembles too much NSAttributedString.

My concern is not that seasoned developers would be confused between NSAttributedString and NSStringAttributes, but that developers new to the platform would rightfully ask why they need to know the differences about this.

The upside is that it follows the existing pattern in MonoTouch and MonoMac: use a strongly typed class, which internally produces the NSDictionary on demand.

Giving NSAttributedString special powers

Another option is to give NSAttributedString special powers. This would allow NSAttributedString instances to be configured like this:

var myString = new NSAttributedString ("Hello") {
  Font = UIFont.FromName ("Helvetica 14"),
  ForegroundColor = UIColor.Black
}

To support the above configuration, we would have to delay the actual creation of the NSAttributedString from the constructor time until the object is actually used.

This would allow the user to set the Font, ForegroundColor and other properties up until the point of creation. This would require the NSAttributedString type to be treated specially by the MonoTouch/MonoMac bindings.

It would also make the NSMutableAttributedString feel a bit better to use: users could make changes to the attributed string all day long, and apply changes to the various properties for the entire span of the text with a simple property value:

var myString = new NSMutableAttributedString ("Hello");

// This:
myString.AddAttribute (
	NSAttributedString.ForegroundColorAttributeName,
	UIColor.Red,
	new NSRange (0, myString.Length));

// Would become:
myString.ForegroundColor = UIColor.Red;

There are a couple of downsides with the above approach. The actual attributes used for this string configuration would not be shared across different NSAttributedStrings, so for some code patterns, you would be better off not using this syntax and instead using the NSStringAttributes class.

The other downside is that NSAttributedString properties could be set only up to the point of the string being used. Once the string is used, the values would be set in stone, and any attempt to change them would throw an exception, or issue a strongly worded message on the console.

And of course, the improved NSMutableAttributedString API improvements could be done independently of the property setters existing in the base class.

Others?

Can anyone think of other strongly typed approaches to simplify the use of NSAttributedStrings that are not listed here?

Update

Thanks for your excellent feedback! It helped us clarify what we wanted to do with the API. We are going to go with the "Standard Choice", but with a small twist.

We came to realize that NSAttributedString is just a string with attributes, but the attributes are not set in stone. It is really up to the consumer of the API to determine what the meaning of the attributes are.

We had a constructor that took a CTStringAttributes parameter which is used when you render text with CoreText.

What we are going to do is introduce a UIStringAttributes for iOS to set UIKit attributes and an NSStringAttributes for AppKit that will have the same behavior: they will be strongly typed classes that can be passed as a parameter to the NSAttributedString constructor.

So we will have basically three convenience and type safe constructors based on what you will be using the NSAttributedString with as well as the standard NSDictionary constructor for your own use:

public class NSAttributedString : NSObject {
  public NSAttributedString (string str, NSDictionary attrs);
  public NSAttributedString (string str, CTStringAttributes attrs);

  // iOS only
  public NSAttributedString (string str, UIStringAttributes attrs);

  // OSX only
  public NSAttributedString (string str, NSStringAttributes attrs);
}

We will also provide convenience "GetAttributes" methods for all platforms:

public class NSAttributedString : NSObject {
  public CTStringAttributes GetUIKitAttributes ();

  // Only on iOS
  public UIStringAttributes GetUIKitAttributes ();

  // Only on OSX
  public NSStringAttributes GetUIKitAttributes ();
}

Finally, we loved Mark Rendle's proposal of using default parameters and named parameters for C#. This actually opened our eyes to a whole new set of convenience constructors that we can use to improve both the MonoTouch and MonoMac APIs.

This comes from a Sample I was working on:

var text = new NSAttributedString (
    "Hello world",
    font: GetFont ("HoeflerText-Regular", 24.0f),
    foregroundColor: GetRandomColor (),
    backgroundColor: GetRandomColor (),
    ligatures: NSLigatureType.All, 
    kerning: 10, // Very classy!
    underlineStyle: NSUnderlineStyle.Single,
    shadow: new NSShadow () {
        ShadowColor = GetRandomColor (),
        ShadowOffset = new System.Drawing.SizeF (2, 2)
    },
    strokeWidth: 5);
#endif

The only open question is whether the parameter names in this case should be camelCase, or start with an uppercase letter (font vs Font and foregroundColor vs ForegroundColor).

The result on screen are beautiful!

MonoMac Updates

miguel@xamarin.com (Miguel de Icaza) — Fri, 27 Jul 2012 13:49:00 -0500

Over the last couple of months we have been silently updating both the MonoMac APIs as well as the IDE support for it. All of the features that I talked back in March are now publicly available.

More code is now shared with the MonoTouch infrastructure, which means that every time that we improve our MonoTouch IDE support, MonoMac will be improved as well.

MonoDevelop Improvements for MonoMac

The latest version of MonoDevelop that we released contains a significant update for developers. In the past, you had to use a one-off dialog box to create packages, installers and prepare an app for AppStore distribution.

With the latest release, we have now turned these configuration options into settings that are part of the project. This means that you can now configure these based on your selected project configuration, you can automate the builds, save your settings and most importantly, you have many more options at your disposal:

MonoMac packaging settings.

Plenty of the settings that go into Info.plist are now available directly in the project settings as well as the support for maintaining your iCloud keys and sandbox requirements:

MacOS Project Settings.

We also brought the MonoTouch Info.plist editor into the IDE, this allows you to maintain your Info.plist directly from the IDE. It is also a convenient place to declare which file types your application exports and consumes:

Info.plist Editor.

New Launcher

In the past we used a shell script to start your program, the shell script would set a few environment variables and invoke Mono with your initial assembly.

We now ship a binary launcher that links with the Mono runtime and fixes several long standing issues involving application launching.

Getting the latest MonoMac

To get the latest support for MonoMac, merely download MonoDevelop 3.0.4.1 (our latest build available from monodevelop.com and you will get the entire package for Mac development.

Samples

New samples in MonoMac show how to use CoreAnimation to animate custom C# properties. Our own MacDoc sample which was supposed to be just a simple demo of WebKit, MonoMac and MonoDoc has turned into a full fledged documentation browser which is now part of our own products (MonoTouch).

Key-Value-Observing on MonoTouch and MonoMac

miguel@xamarin.com (Miguel de Icaza) — Thu, 19 Apr 2012 22:12:00 -0500

This morning Andres came by IRC asking questions about Key Value Observing, and I could not point him to a blog post that would discuss the details on how to use this on C#.

Apple's Key-Value Observing document contains the basics on how to observe changes in properties done to objects.

To implement Key-Value-Observing using MonoTouch or MonoMac all you have to do is pick the object that you want to observe properties on, and invoke the "AddObserver" method.

This method takes a couple of parameters: an object that will be notified of the changes, the key-path to the property that you want to observe, the observing options and a context object (optional).

For example, to observe changes to the "bounds" property on a UIView, you can use this code:

view.AddObserver (
	observer: this, 
	keyPath:  new NSString ("bounds"), 
	options:  NSKeyValueObservingOptions.New, 
	context:  IntPtr.Zero);

In this example, I am using the C# syntax that uses the Objective-C style to highlight what we are doing, but you could just have written this as:

view.AddObserver (
	this, new NSString ("bounds"),
	NSKeyValueObservingOptions.New, IntPtr.Zero);

What the above code does is to add an observer on the "view" object, and instructs it to notify this object when the "bounds" property changes.

To receive notifications, you need to override the ObserveValue method in your class:

public override
void ObserveValue (NSString keyPath, NSObject ofObject,
			NSDictionary change, IntPtr context)
{
    var str = String.Format (
	"The {0} property on {1}, the change is: {2}",
        keyPath, ofObject, change.Description);

    label.Text = str;
    label.Frame = ComputeLabelRect ();
}

This is what the app shows if you rotate your phone:

The complete sample has been uploaded to GitHub.

Call for Comments: Strongly Typed Notifications

miguel@xamarin.com (Miguel de Icaza) — Thu, 12 Apr 2012 21:06:00 -0500

I am adding support for strongly typed notifications to MonoTouch and MonoMac. The idea behind this is to take guesswork, trips to the documentation and trial and error from using notifications on iOS and MacOS.

The process is usually: (a) find the right notification; (b) look up apple docs to see when the notification is posted; (c) look up each of the keys used to retrieve the data from the dictionary.

Currently, listening to a notification for a keyboard-will-be-shown notification looks like this in MonoTouch:

void DoSomething (
	UIViewAnimationCurve curve,
	double               duration,
	RectangleF           frame)
{
	// do something with the above
}

var center = NSNotificationCenter.DefaultCenter;
center.AddObserver (UIKeyboard.WillShowNotification, PlaceKeyboard);

[...]

void PlaceKeyboard (NSNotification notification)
{
    // Get the dictionary with the interesting values:
    var dict = notification.UserInfo;

    // Extract the individual values
    var animationCurve = (UIViewAnimationCurve)
	(dict [UIKeyboard.AnimationCurveUserInfoKey] as NSNumber).Int32Value;
    double duration =
	(dict [UIKeyboard.AnimationDurationUserInfoKey] as NSNumber).DoubleValue;
    RectangleF endFrame =
	(dict [UIKeyboard.FrameEndUserInfoKey] as NSValue).RectangleFValue;

    DoSomething (animationCurve, duration, endFrame)
}

Currently we map the Objective-C constant "FooClassNameNotification" into the C# class "Foo" as the member "NameNotification" of type NSString.

What we want to do is to expose the notifications as strongly typed C# events. This will provide auto-complete support in the IDE to produce the lambdas or helper methods, auto-complete for all the possible properties of the notification, strong types for the data provided and live documentation for the values in the notification.

This means that the above code would instead be written like this:

var center = NSNotificationCenter.DefaultCenter;
center.Keyboard.WillShowNotification += PlaceKeyboard;

void PlaceKeyboard (object sender, KeyboardShownEventArgs args)
{
    DoSomething (args.AnimationCurve, args.Duration, args.EndFrame);
}

The question is where should these notifications be exposed in the API? In the example above we do this by the event "WillShowNotification" on a class "Keyboard" inside the "NSNotificationCenter". We have a few options for this.

We could host the notification in the class that defines the notification, but we would have to come up with a naming scheme to avoid the name clash with the existing NSString constant:

class UIKeyboard {
    public NSString WillShowNotification { get; }

    // replace "Notification" with the class name:
    public event EventHandler WillShowKeyboard;

    // prefix the event:
    public event EventHandler KeyboardWillShow;

    // plain, does not work on all types though:
    public event EventHandler WillShow;
}

// Consumer code would be one of:

UIKeyboard.WillShowKeyboard += handler;
UIKeyboard.KeyboardWillShow += handler;
UIKeyboard.WillShow += handler;

Another option is to add everything into NSNotificationCenter:

class NSNotificationCenter {
	// Existing implementation

    public event EventHandler UIKeyboardWillShow;

    // Another 141 events are inserted here.
}

// Consumer code would be:

NSNotificationCenter.DefaultCenter.UIKeyboardWillShow += handler;

Another option is to partition the notifications based on their natural host, this is my personal favorite, but could be harder to find with the IDE using code completion:

class NSNotificationCenter {
    public static class Keyboard {
        public static event EventHandler WillShow;
    }
}

// Consumer code would be:
NSNotificationCenter.Keyboard.WillShow += handler;

All of these proposals have one potential problem: they would all assume that all of these interesting notifications are always posted into the NSNotificationCenter.DefaultCenter.

Apple's documentation does not seem to suggest that any of the iOS notifications are posted anywhere but the DefaultCenter. I could not find on GitHub any code that would use anything but the DefaultCenter.

On MacOS the InstantMessage framework posts notifications to its own notification center. We could just bind those events to this specific NSNotificationCenter.

Thoughts?

MonoMac Updates

miguel@xamarin.com (Miguel de Icaza) — Tue, 06 Mar 2012 21:34:00 -0500

We have been hard at work at improving the MonoMac API to allow .NET developers to create native Mac applications using C#, F#, IronPython or their favorite .NET language.

There are couple of goodies coming on our next release of MonoMac: our Lion support is shapping up and we have been dogfooding this ourselves with our own apps.

One of our sample apps, a simple front-end to the Mono Documentation backend is now complete enough that we are going to deprecate the Gtk+ version of it and replace it with the native version of it.

MacDoc now has several new features

Apple documentation integration: MacDoc will now download the Apple docs if they are not available and blend its contents with our documentation and replace the Objective-C samples with C# samples. Amazing!

Full text indexing: the documentation browser is using Lucene to index all of the contents and allow you to quickly find the materials that you are looking for.

Conceptual Index: in addition to the full text search, we generate a curated version of the APIs that are useful for performing search-as-you-type in the documentation browser. This is useful to find APIs by class, by method name and also by Objective-C selector. This means that you can now search for Objetive-C selectors in our documentation, and you will get the actual mapping to the C# method.

Supports Lion documents, saved state and bookmarks.

We extended the ECMA XML format so it now renders images for our docs:

The source code is available now in GitHub and will be shipping in the upcoming MonoDevelop 2.8.8 release.

Bubbles

miguel@xamarin.com (Miguel de Icaza) — Mon, 30 Jan 2012 18:22:00 -0500

Recently one of our customers asked about how to implement a conversation display similar to the iOS SMS/Messages display. You can find the BubbleCell sample in our Github repository.

This is what the conversation looks like:

To implement this, I used iOS's UITableView as it already provides a lot of the functionality that we need for this. What I did was to write a custom UITableViewCell that can render bubbles with their text.

I wrote both a MonoTouch.Dialog Element that you can host in your DialogViewController as well as a custom UITableCellView which can be reused by those using UITableViews directly.

This is how you could populate the initial discussion inside MonoTouch.Dialog:

Section chat;
var root = new RootElement ("Chat Sample") {
  (chat = new Section () {
    new ChatBubble (true, "This is the text on the left, what I find fascinating about this is how many lines can fit!"),
    new ChatBubble (false, "This is some text on the right"),
    new ChatBubble (true, "Wow, you are very intense!"),
    new ChatBubble (false, "oops"),
    new ChatBubble (true, "yes"),
  })
};

And this is how you would add a new element to the conversation:

chat.Section.Add (
  new ChatBubble (false, "I want more cat facts"));

Implementation

Bubble rendering is implemented in Bubble.cs and contains both the UITableViewCell as well as the element. It follows the pattern for creating UITableViewCells that I documented before.

Each cell is made up of two views: one contains a UIImageView that paints the bubble and the other one contains the text to render inside the bubble.

This is what the two bubbles images look like:

We load these using UIImage.FromFile and then use the iOS 5.0 UIImage.CreateResizableImage method to create a UIImage that can be stretched on demand. To create the resizable image we need to tell CreateResizableImage the region of the image that can be stretched. Anything outside of the UIEdgeInset will be kept as-is:

left = bleft.CreateResizableImage (new UIEdgeInsets (10, 16, 18, 26));
right = bright.CreateResizableImage (new UIEdgeInsets (11, 11, 17, 18));

This will stretch the region highlighted in red, while rendering the external border as-is:

With the above code, the image will be rendered in a variety ways depending on the Frame that is assigned to the UIImageView that hosts our resizable UIImage:

The only remaining interesting bit in the code is to configure our UILabel properly. We want to set its BackgroundColor to UIColor.Clear to avoid painting the background in a solid color and we also specify that the text should be word-wrapped if it does not fit in a single line:

label = new UILabel (rect) {
  LineBreakMode = UILineBreakMode.WordWrap,
  Lines = 0,
  Font = font,
  BackgroundColor = UIColor.Clear
};

Finally in our LayoutSubViews method we must compute the proper sizes for the bubbles and the text that goes in them. I made it so the bubbles did not take the entire space in a row. Instead they take 70% of the row to give a similar effect to the rendering of the iOS messages UI. The code is pretty straight-forward:

public override void LayoutSubviews ()
{
  base.LayoutSubviews ();
  var frame = ContentView.Frame;
  var size = GetSizeForText (this, label.Text) + BubblePadding;
  imageView.Frame = new RectangleF (new PointF (isLeft ? 10 : frame.Width-size.Width-10, frame.Y), size);
  view.SetNeedsDisplay ();
  frame = imageView.Frame;
  label.Frame = new RectangleF (new PointF (frame.X + (isLeft ? 12 : 8), frame.Y + 6), size-BubblePadding);
}

Styling your controls in MonoTouch on iOS 5

miguel@xamarin.com (Miguel de Icaza) — Fri, 14 Oct 2011 22:38:00 -0500

Starting with iOS 5 it is possible to more easily style your UIViews. Apple did this by exposing a new set of properties on most views that can be tuned. For example, to configure the TintColor of a UISlider, you would write:


var mySlider = new UISlider (rect);
mySlider.ThumbTintColor = UIColor.Red;

You can also set the color globally for all instances of UISlider, you do this by assigning the styling attributes on the special property "Appearance" from the class you want to style.

The following example shows how to set the Tint color for all UISliders:


	UISlider.Appearance.ThumbTintColor = UIColor.Red;

It is of course possible to set this on a per-view way,

The first time that you access the "Appearance" static property on a stylable class a UIAppearance proxy will be created to host the style changes that you have requested and will apply to your views.

In Objective-C the Appearance property is untyped. With MonoTouch we took a different approach, we created a strongly typed UIXxxxAppearance class for each class that supports styling. Our generated UIXxxxxAppearance class is strongly typed, which allows users to use intellisense to easily discover which properties are avaialble for styling.

We also created a hierarchy that reflects the inherited appearance properties, this is the class hierarchy for the UISLider.UISliderAppearance class:

The properties exposed by UISlider for example are:

public class UISliderAppearance {
	public virtual UIColor BackgroundColor {
		get;
		set;
	}
	public virtual UIColor MaximumTrackTintColor {
		get;
		set;
	}
	public virtual UIColor MinimumTrackTintColor {
		get;
		set;
	}
	public virtual UIColor ThumbTintColor {
		get;
		set;
	}
}

MonoTouch also introduced support for styling your controls only when they are hosted in a particular part of the hierarchy. You do this by calling the static method AppearanceWhenContainedIn which takes a variable list of types, it works like this:

var style = UISlider.AppearanceWhenContainedIn (typeof (SalesPane), typeof (ProductDetail));
style.ThumbTintColor = UIColor.Red;

In the above sample the style for the ThumbTintColor will be red, but only for the UISliders contained in ProductDetail view controllers when those view controllers are being hosted by a SalesPane view controller. Other UISliders will not be affected.

Both the Appearance static property and the AppearanceWhenContainedIn static method have been surfaced on every UIView that supports configuring its style. Both of them return strongly typed classes that derive from UIAppearance and expose the exact set of properties that can be set.

This is different from the weakly typed Objective-C API which makes it hard to discover what can be styled.

MonoTouch 5.0 is out

miguel@xamarin.com (Miguel de Icaza) — Thu, 13 Oct 2011 16:28:00 -0500

Yesterday we released MonoTouch 5.0, the companion to Apple's iOS 5.0 release.

Apple tends to ship Objective-C APIs that are configured through an NSDictionary instance containing configuration keys. With MonoTouch 5.0, we continued our work to improve over NSDictionary-based bindings by creating strongly-typed versions of those APIs.

In the next couple of days, I will be sharing some of the new features in iOS 5.0 and how to take advantage of those using C#.

Meanwhile, our documentation team has produced an amazing Introduction to iOS 5.0 for C# developers and put together some samples showing how to use some of the new features in iOS 5:

Storyboard: shows how to use Storyboards from C# and showcases the integration between Xcode 4 and MonoDevelop 2.8
CoreImage: shows our bubilicious strongly-typed API for CIFilters, it is in my opinion, a huge usability upgrade over the NSDictionary-based approach.
iCloud: Basic iCloud use.
Twitter: Post new tweets and query twitter for data.
Newsstand: A complete sample showing how you can integrate with the new Newsstand APIs to publish your own periodicals. We wont be submitting this sample for the Apple Design Awards, but it shows how to use the framework.

TestFlight support in MonoDevelop

miguel@xamarin.com (Miguel de Icaza) — Thu, 29 Sep 2011 14:12:00 -0500

We have just released for TestFlight support in MonoDevelop.

This makes it simpler for developers to deploy their Ad-Hoc builds directly to Testflight, we added a "Publish to TestFlight" option:

The first time you upload to TestFlight you must provide your authentication tokens:

And after that, the IDE takes care of the rest:

This is built on top of our enhanced IPA Packaging support in the same release.

Sales Force app built with MonoTouch

miguel@xamarin.com (Miguel de Icaza) — Fri, 12 Aug 2011 20:28:00 -0500

I do not blog very often about apps built with MonoTouch, but this application is drop-dead gorgeous.

It is a tool designed to be used by the sales force of a company.

You can download the app from the Apple AppStore and try it on "demo" mode. What I love about this application is how they took advantage of UIKit and CoreAnimation to create a beautiful enterprise app. It does not stop there, they use everything iOS has to offer:

Enterprise software has a reputation for being hostile to end-users. This shows that you can create great end-user software for users in the enterprise. If you were looking for inspiration for your own enterprise apps, this is the app to look for.

MonoMac add-in for MonoDevelop

miguel@xamarin.com (Miguel de Icaza) — Wed, 03 Aug 2011 21:40:00 -0500

After a small hiatus we are back.

If you have been using MonoMac to build MacOS applications, we have just released an update to the MonoDevelop.MonoMac add-in that should fix the problem with packaging your applications on Lion.

This update just contains a critical fix and delivers the add-in to all three MonoDevelop platforms in use today: our stable MonoDevelop 2.4, the 2.6beta3 and for the fearless among you MonoDevelop/master.

This was just the first step in maintaining the add-in. I had to sort out the build setup for all three branches and the pipeline to deliver the updates. Now that I got things in place, I will be able to fix some of the other problems that have been reported.

If you are running into problems with MonoMac, please file your bugs at the new home for the Mono bug reports at http://bugzilla.xamarin.com.

Glass button for iPhone

miguel@xamarin.com (Miguel de Icaza) — Fri, 08 Apr 2011 14:19:00 -0500

Since iOS does not provide a default glossy button implementation I wrote my own, based mostly on looking at a screenshot of Apple's own.

Some folks have been using the UIGlassButton generator, but I have wanted for a while to have this functionality avaialble at runtime, and not depend on pre-generated images, these are created at runtime, and behave just like a regular button:

You can find my implementation as part of MonoTouch.Dialog on github.

This is how you would use it, and how you can customize some of its elements:

	var b = new GlassButton (bounds) {
		Font = UIFont.BoldSystemFontOfSize (22),
		NormalColor = UIColor.Green,
		HighlightedColor = UIColor.Red
	};
	b.SetTitle ("Dismiss", UIControlState.Normal);

	container.AddSubview (b);

MonoTouch 4.0

miguel@xamarin.com (Miguel de Icaza) — Wed, 06 Apr 2011 16:20:00 -0500

We just released MonoTouch 4.0, a product to build iOS applications using C# and .NET. We also released our new Mono for Android product.

New in MonoTouch 4.0

MonoTouch 4.0 is a major upgrade to our product as it upgrades the Mono runtime engine from the old, trusted and friendly Mono 2.6 to the latest and greatest Mono 2.10 core, these are some of the new features available as part of this upgrade:

Parallel Frameworks for C#: Great APIs for building multi-threaded software. Not only this is great for iPad 2 users and developers, but it also simplifies just plain multi-threaded programming by exposing Futures, Tasks and Parallel LINQ to the developer.
LLVM Compiler Support: In addition to the fast Mono compilation engine, MonoTouch can now also use LLVM to create optimized builds. When you build MonoTouch applications using LLVM your executables will run faster, they will be smaller, and you can optionally opt into generating the nimbler ARMv7 or Thumb code (fat binaries are also supported).
Example: My own TweetStation distribution went from 8 megs to 6 megs using Thumb + ARMv7 support. A very significant gain.
C# 4.0 and .NET 4.0: This release comes with the latest incarnation of the C# language as well as exposing the new .NET 4.0 APIs (many new functional constructs make for nicer looking code, like all the IEnumerable enabled-methods in System.IO).
There is one important limitation: C# 4.0 dynamic support is not functional, since it requires dynamic code generation to work.
Upgraded WCF stack: We still consider this a preview of the full WCF but has been expanded significantly.
All new iOS 4.3 APIs have been exposed.
NSDecimal, NSDecimalNumber are now exposed (mostly for the sake of CorePlot :-)
Many new convenience APIs have been introduced.

For a full detailed list of changes, see our MonoTouch 4.0 Release Notes.

Resources

The best source of information on parallel programming with Parallel FX is the free Patterns for Parallel Programming: Understanding and Applying Parallel Patterns with the .NET Framework 4.

This is a brilliant document. Whether you use .NET or not, this is a recommended reading for everyone.

In addition to the Programming iPhone with MonoTouch book there are two new books about to hit the shelves Developing C# Apps for iPhone and iPad using MonoTouch: iOS Apps Development for .NET Developers: an incredibly in-depth book from Brian Costanich that I have had the privilege to read in advance. This book will come out in only 3 weeks.

If you are more of a hands-on kind of guy, later in the year, Mike Bluestein's Learning MonoTouch: A Hands-On Guide to Building iPhone and iPad Applications with C# and .NET is coming out.

Next Steps

We are currently hard at work to add support to MonoDevelop to work with the new XCode 4.

With XCode 4, Apple removed Interface Builder as a standalone tool. We should have a beta in a couple of weeks of the solution we came up with.

MonoMac 1.0 is out

miguel@xamarin.com (Miguel de Icaza) — Thu, 17 Mar 2011 19:16:00 -0500

Almost a year ago we started building a set of Mono bindings for building native MacOS X applications.

Our original goals were modest: bind enough of AppKit that you could build native desktop applications for OSX using C# or your favorite .NET language. We leveraged a lot of the code that we built for MonoTouch our binding to the CocoaTouch APIs.

During the year, the project picked up steam, we got plenty of contributions to MonoMac and grew beyond the original conservative goals.

In a year we:

Created a beautiful library that blends the worlds of C# and MacOS X APIs.
Created a MonoDevelop add-in that helps developers get started with Mac development in minutes.
Integrated the MonoDoc system into MonoDevelop, to provide developers with documentation on the flight as they type their code. Detailed method information, parameter use and type information is available as you type your code in unobtrusive windows.
Created a packager that turns your programs into self-contained OSX Packages with no external dependencies on Mono and can be deployed to the Apple App Store.
Created a linker that lets you strip out any functionality your application might not need to reduce your executable size.
Created a great community of developers that love C#, .NET and MacOS. For some of us, this is a step closer to heaven.
Created a big pool of samples for developers to learn from, and for us to exercise the API and ensure that the resulting library was a delight to use.
Created various tutorials on how to build applications with C# on the Mac.
Built an online documentation mash-up between our API and Apple's web documentation

Some statistics about the MonoMac binding:

1,155 C# classes and 31 C# structures
376 enumerations
123 C# delegate data types
16,556 methods, properties and events exposed

In addition to that, MonoMac bundles a modified version of the amazing OpenTK 1.0. We took the liberty (and by "we" I mean, the amazing Kenneth Pouncey) of fine-tuning the implementation for MonoMac use.

Getting MonoMac 1.0

If you already have MonoDevelop installed, just update your MonoMac Add-In. If you do not have MonoDevelop installed, follow our friendly instructions.

Contributors

MonoMac would not have been possible without the help of our great contributors, this is the team:

Main bindings:

Geoff Norton
Miguel de Icaza
Jonathan Pryor
Michael Hutchinson

Contributors:

Alexander Shulgin (WebKit DOM)
James Clancey (AppKit contributions)
Kenneth Pouncey (API, samples)
Maxi Combina (WebKit events, sample)
Regan Sarwas (PdfKit, ImageKit, NSColor, NSGradient, NSBezierPath, samples)
Ashok Gelal (CoreWlan)

Next Steps

What is great about doing a 1.0 release is that you know that there will be a 1.1 release, and a 1.2 release and a 2.0 release.

This is our way of saying "thank you for waiting" and giving our users a chance to start building applications, knowing that we have battle tested MonoMac and it is being used in our own products now [1].

We obviously will continue improving the API, adding more frameworks as time goes by, but we will also be working with other communities to expand MonoDevelop's language support, create more templates for languages like F#, IronRuby, IronPython and UnityScript.

Although we have a great start for documentation, we hope that contributors will take advantage of a new web-based wiki and collaboration tool that we are building to improve the docs and help us make MonoMac's documentation the best.

Hopefully, we will also get more samples contributed to MonoMac and we will see a new wave of tutorials and we will see fascinating discussions on how to build better software while enjoying every second of it.

[1] (MonoDevelop 2.6 will be using MonoMac for its native dialog boxes).

MonoMac hotfix

miguel@xamarin.com (Miguel de Icaza) — Sun, 06 Feb 2011 16:38:00 -0500

Hylke Bons warned us of a limitation in our MonoMac packager so we are issuing a new MonoMac refresh that fixes various bugs:

Supports using Mono.Posix.dll in packaged bundles.
Supports using System.Drawing in packaged bundles.
Fixes various BCL P/Invokes problems (we forgot to ship the config file :-)
No longer requires Mono 2.8.1, works with any mono 2.8+

Follow the standard instructions to update your MonoMac add-in.

Hylke then got his native Mac client for SparkleShare (a DropBox-like system, but backed up by Git or any Git hosting sit) working as a bundle on OSX.

MonoMac Refresh!

miguel@xamarin.com (Miguel de Icaza) — Wed, 02 Feb 2011 23:55:00 -0500

We just pushed a new refresh of MonoMac. This release contains:

New complete bindings: QuartzComposer, CoreWlan, PdfKit, ImageKit and Addresbook.
AppKit: new classes: NSBezierPath, NSGradient; convenience methods for NSColor, NSTableView, NSMenuItem, and NSPasteboard.
CoreImage's CIVector and support in AppKit for CoreImage.
WebKit indexers and support for reporting user decisions.

In our shared core with MOnoTouch, these are the changes:

CoreGraphics: Support for transparency layers.
Foundation: API helpers to make NSIndexSet more pleasant to use; new methods to control the NSRunLoop; NSUrlProtocol and NSUrlProtocolClient classes.
ObjCRuntime: Exposed the shared library loading code and convenience methods to pull constants from shared libraries.
KeyChain: expose new methods for common operations (managing internet passwords)
CoreAnimation: bound a few missing constants.
OpenGL: new CAOpenGLLayer type.

Many new samples are now included with MonoTouch. Kenneth has contributed various ported samples from the CoreAnimation book exercising the API, fixing it, and providing many samples for developers to get started. We now ship 32 samples covering a wide range of Mac APIs.

Contributors to this release include: Geoff Norton, Alexander Shulgin, James Clancey, Maxi Combina, Regan Sarwas, Michael Hutchinson, Ashok Gelal and Miguel de Icaza.

Additionally, the first MonoMac app has hit the Mac AppStore!

Some small stats: MonoMac 0.4 was installed by 263 developers, MonoMac 0.5 by 369 developers, and MonoMac 0.6 (our last release) by 588.

First MonoMac App Hits the Apple AppStore

miguel@xamarin.com (Miguel de Icaza) — Mon, 31 Jan 2011 22:05:00 -0500

Yvan Janssens (@yvanjanssens) just wrote to let me know that iProxify Plush, his MonoMac-powered application, has been accepted for distribution on Apple's Mac AppStore.

This is an important development in the history of MonoMac, as someone has actually published a full executable based on the tools that we built (we have not tested this ourselves as we did not really have anything to publish).

It also means that we got all the details right to let people use C# to publish to the Mac AppStore: we do not take external dependencies, we bundle all of the Mono dependencies with the app and we follow all the relevant Apple rules for distribution.

Congratulations to Yvan for his published app!

Patterns for Creating UITableViewCells

miguel@xamarin.com (Miguel de Icaza) — Tue, 18 Jan 2011 19:32:00 -0500

At one point or another, every UITableView programmer will outgrow the default set of UITableViewCells styles available to them, and they will be forced to customize the cells to provide a better user experience.

The initial temptation of every lazy programmer like myself is to do the bare minimum amount of work to obtain the desired effect. This path typically starts by realizing that you can add a subview to your cell, like this:

static UIImage logo = UIImage.FromFile ("logo.png");
UITableViewCell CreateCell ()
{
	var cell = new UITableViewCell (UITableViewCellStyle.Default, "key");
	var imageView = new UIImageView (logo) {
		Frame = new RectangleF (10, 10, 20, 20);
	};
	cell.ContentView.Add (imageView);
	return cell;
}

Although the above code works, and you can get away with it for simple tasks, it does not take into consideration cell reuse. UITableViews like to recycle cells on the screen which is fine as long as you do not need to use a different image on each cell, as all of a sudden, you will need to keep track of the imageView value.

In other cases, your GetCell method will get bloated with a lot of inside information about all possible customizations that you might have done in a previous instance, and you will have to undo those. Apple's UICatalog sample is packed with code like that, and so is my port of the same code.

And that is just not a decent way of living.

You are miserable, your users are miserable and everyone around you is miserable.

My preferred pattern, which has worked better for me is to create a derived cell class that tracks all of my properties, and centralizes the management of updating the properties of my cell.

Assuming that my cell will render the contents of an object called "MyData", this is what my pattern looks like for custom UITableViewCells:

//
// I create a view that renders my data, as this allows me to reuse
// the data rendering outside of a UITableViewCell context as well
//
public class MyDataView : UIView {
	MyData myData;

	public MyDataView (MyData myData)
	{
		Update (myData);
	}

	// Public method, that allows the code to externally update
	// what we are rendering.   
	public void Update (MyData myData)
	{
		this.myData = myData;
		SetNeedsDisplay ();
	}
}

//
// This is the actual UITableViewCell class
//
public class MyDataCell : UITableViewCell {
	MyDataView myDataView;

	public MyDataCell (MyData myData, NSString identKey) : base (UITableViewCellStyle.Default, identKey)
	{
		// Configure your cell here: selection style, colors, properties
		myDataView = new MyDataView (myData);
		ContentView.Add (myDataView);
	}

	public override void LayoutSubviews ()
	{
		base.LayoutSubviews ();
		myDataView.Frame = ContentView.Bounds;
		myDataView.SetNeedsDisplay ();
	}

	// Called by our client code when we get new data.
	public void UpdateCell (MyData newData)
	{
		myDataView.Update (newData);
	}
}

With the above pattern implemented, I can now add all of my view specific gadgetry into the MyDataView class, images, helper labels, or other views.

Then, the Update method needs to make sure that all of those extra views are updated when this method is invoked. All of the configuration for your cell needs to take place in this method, and nowhere else.

The client code that uses these views then looks like this:

class MyTableViewDataSource : UITableViewDataSource {
	public override UITableViewCell GetCell (UITableView tableView, NSIndexPath indexPath)
	{
		MyData myData = Lookup (indexPath);

		var cell = tableView.DequeueReusableCell (key);
		if (cell == null)
			cell = new MyDataCell (myData);
		else 
			cell.UpdateCell (myData);
		return cell;
	}

The Extra UIView

You might be thinking that creating the extra UIView is not really worth the effort, as you likely only need to apply a few customizations, and you got already most of your bang for the buck by creating your custom UITableViewCell.

You would be right.

The reason for creating a custom UIView, is that there might come a time when you want to do some custom drawing in your cell. Perhaps add a nice gradient on the background, or perhaps draw some shadows, or mix large fonts with small fonts.

It might be just a couple of small touch-ups, nothing too complicated, but just a little extra polish. By using a custom UIView, you can now spice up your view just a tiny bit, by overriding the Draw method:

public override void Draw (RectangleF rect)
{
	var context = UIGraphics.GetCurrentContext ();
	UIColor.White.SetColor ();
	context.FillRect (Bounds);
	context.DrawLinearGradient (myGradient, start, end, 0);
}

Creating a MonoTouch.Dialog Element

If you are like me, lazy, you would likely not be writing a lot of GetCell methods and large dispatch tables for your UITableViews, and instead you are using MonoTouch.Dialog.

MonoTouch.Dialog is an API that takes away the administrivia out of building UITableViews and lets you focus on the content. I discussed MonoTouch.Dialog last year on my old blog.

Once you have your own UITableViewCell, it is trivial to turn that into a MonoTouch.Dialog Element. You would do it like this:

public class MyDataElement : Element {
	static NSString key = new NSString ("myDataElement");
	public MyData MyData;

	public MyDataElement (MyData myData) : base (null)
	{
		MyData = myData;
	}

	public override UITableViewCell GetCell (UITableView tv)
	{
		var cell = tv.DequeueReusableCell (key) as MyDataCell;
		if (cell == null)
			cell = new MyDataCell (MyData, key);
		else
			cell.UpdateCell (MyData);
		return cell;
	}
}

With the code above, you have everything you need to make your custom cell to be used with MonoTouch.Dialog.

You can see the entire pattern in action in TweetStation's source code. The 300 or so lines of code in that file are responsible for rendering a tweet in TweetStation.

Mono Packager and the Apple AppStore

miguel@xamarin.com (Miguel de Icaza) — Mon, 10 Jan 2011 17:23:00 -0500

We are happy to announce the Mono Packager for OSX.

MonoDevelop UI for Mac Packages and Installers.

The Mono Packager for OSX makes it possible to create self-contained Mono applications that will run on OSX without requiring the Mono.framework to be previously installed on the system. In combination with the MonoMac project you can build fully native MacOS X applications using your favorite .NET technologies. From your choice of Mono/.NET languages, to your choice of Mono/.NET library.

The packager can create both signed applications for distribution on the Mac AppStore, as well as creating installers for your software.

Mono on the Mac: Some Background

Mono on OSX has historically been distributed as an image that installed itself in /Library/Frameworks/Mono.framework. Once Mono was installed, users could write code in C# or their favorite .NET/Mono language and run the resulting executable.

The problem is that Mono.framework contains an entire development stack: compilers, GUI tools, command line tools, libraries, documentation which is convenient for developers, but most of the time, not very useful for end-users.

This meant that developers would typically ask users to first install the Mono.framework (a big download) and then they could install their applications.

To work around that problem, some developers have chosen to manually embed Mono in their applications. This has always been possible, but it was error-prone as developers would have to manually assemble Mono into their application bundle, configure Mono properly, and initialize the Mono runtime themselves. Doable, but not pleasant.

With today's release, we have taken the burden of creating self-contained Mono applications out of developer's hands and added it as a standard feature for developers to use.

The Mac AppStore

The Mac AppStore requires that applications submitted to it are completely self-contained and they do not depend on third-party frameworks to be installed on the system. It also requires that your application and installer be signed.

Both of those features are supported in our MonoMac Packager. Developers can now create Mac AppStore ready applications using MonoDevelop and MonoMac. We have integrated the package creation, installer creation, and signing processes into our MonoDevelop IDE.

All that developers have to do is sign up for Apple's Mac developer program, get their distribution certificates, build a fabulous application and upload the application using the Application Loader to Apple.com.

Upcoming: Linking

In this version of the Mac bundler, we include all of the dependencies that your program takes. For example, if you use the System.Xml library, the entire System.Xml library will be bundled with the application.

In our next release, we will add support for Mono's linker, the same technology we used in MonoTouch to reduce the executable size.

When you choose to use use the linker, the granularity of distribute changes from the library-level to the type level. For example, if you only use one type from System.Xml, the linker will strip out all of the unused classes and generate a new System.Xml library that only contains the one type that you used.

We did not want to wait for the linker to be ready before shipping our packager, but we should have it ready soon.

MonoMac Refresh

As part of this release we have also issued a refresh to the MonoMac library and templates.

From now on, MonoMac binaries will default to be 4.0 profile, allowing users to leverage all of the new features in the C# 4.0 language (like dynamic) as well as the new .NET 4.0 APIs that we introduced with Mono 2.8.

The updates to the MonoMac API are described in my other blog post.

New MonoMac Refresh!

miguel@xamarin.com (Miguel de Icaza) — Mon, 10 Jan 2011 16:01:00 -0500

As part of today's release of the Mono Packager for OSX we have issued a new MonoMac refresh.

As we create more sample code, and start to write real applications with MonoMac, we have updated the API to be simpler, cleaner and more comprehensive. This release is all about small incremental improvements to the MonoMac API.

As usual, we have updated the our MonoMac API documentation MonoMac API documentation. If you are thinking about getting started with MonoMac, we strongly recommend you read our MonoMac page for some useful links and tutorials.

Statistics

MonoMac 0.4 was installed by 263 developers, MonoMac 0.5 by 369 developers. Interesting considering that the holidays are a slow season:

Apps!

Frank Krueger the creator of iCircuit a real-time circuit emulator and editor for the iPad/iPhone has started a port of iCircuit to MacOS X using MonoMac:

Pretty amazing, considering that Frank only learned to use MonoMac yesterday (although he does have extensive MonoTouch experience). Update: He posted and updated screenshot "now in technicolor".

MacDoc Sample

During the holidays, I wrote MacDoc a native front-end for the MonoDoc documentation engine. I also took Jonathan Pobst's fabulous style sheets from Kipunji to spice up the UI a little bit.

This is the result:

I still have to integrate the index and search features of MonoDoc into the UI, and I am struggling as to how to surface them in the UI.

The Index is supposed to have an alphabetical listing of classes, method, properties, fields, similar to the index at the end of a book. I always found this to be very useful when developing with .NET. The search functionality on the other hand uses Lucene to search in the documentation body.

At this point, I believe that I should add a tabbed widgets, and let the user pick between the tree view on the left and the index (with a new text-entry to do the incremental search). But if the users uses the search on the toolbar, I should replace the tree and the index with a list of results.

Does the above make sense, or you think it is a terrible UI idea and completely unacceptable for OSX users?

I thought about merging the index and the body search, but it would render the index search a bit useless. Anyways, if you are a Mac expert, please send feedback my way.