Miguel's OSX and iOS blog

Key-Value-Observing on MonoTouch and MonoMac

miguel@gnome.org (Miguel de Icaza) — Thu, 19 Apr 2012 20:12:00 PDT

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@gnome.org (Miguel de Icaza) — Thu, 12 Apr 2012 19:06:00 PDT

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@gnome.org (Miguel de Icaza) — Tue, 06 Mar 2012 18:34:00 PST

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@gnome.org (Miguel de Icaza) — Mon, 30 Jan 2012 15:22:00 PST

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@gnome.org (Miguel de Icaza) — Fri, 14 Oct 2011 20:38:00 PDT

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@gnome.org (Miguel de Icaza) — Thu, 13 Oct 2011 14:28:00 PDT

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@gnome.org (Miguel de Icaza) — Thu, 29 Sep 2011 12:12:00 PDT

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@gnome.org (Miguel de Icaza) — Fri, 12 Aug 2011 18:28:00 PDT

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@gnome.org (Miguel de Icaza) — Wed, 03 Aug 2011 19:40:00 PDT

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@gnome.org (Miguel de Icaza) — Fri, 08 Apr 2011 12:19:00 PDT

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@gnome.org (Miguel de Icaza) — Wed, 06 Apr 2011 14:20:00 PDT

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@gnome.org (Miguel de Icaza) — Thu, 17 Mar 2011 17:16:00 PDT

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@gnome.org (Miguel de Icaza) — Sun, 06 Feb 2011 13:38:00 PST

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@gnome.org (Miguel de Icaza) — Wed, 02 Feb 2011 20:55:00 PST

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@gnome.org (Miguel de Icaza) — Mon, 31 Jan 2011 19:05:00 PST

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@gnome.org (Miguel de Icaza) — Tue, 18 Jan 2011 16:32:00 PST

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@gnome.org (Miguel de Icaza) — Mon, 10 Jan 2011 14:23:00 PST

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@gnome.org (Miguel de Icaza) — Mon, 10 Jan 2011 13:01:00 PST

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.

CorePlot Bindings for MonoMac and MonoTouch

miguel@gnome.org (Miguel de Icaza) — Sat, 01 Jan 2011 21:39:00 PST

Happy New Year!

Today I wrote the MonoMac and MonoTouch bindings for the open source CorePlot library.

The bindings are available from the binding collection module on GitHub and binaries for both MonoTouch and MonoMac are available there.

MonoMac Happy Holidays Edition is out!

miguel@gnome.org (Miguel de Icaza) — Wed, 15 Dec 2010 21:35:00 PST

Just in time for your holidays, we have baked a new version of MonoMac. As usual, installation is very easy, just follow these steps.

As for some stats: 224 developers downloaded the MonoMac 0.4 add-in for MonoDevelop in the previous release, not bad at all!

These are the changes since MonoMac 0.4

API Documentation!
- Built on JPobst's new documentation engine
- There are mostly automatically generated stubs now
New in CoreAnimation:
- Layout managers
- Constrained layout manager
- CATextLayer can now set its font with the WeakFont property, or the SetFont () strong types.
CoreGraphics:
- CGAffineTransform.Invert () method to obtain the inverse of an affine transformation
Foundation
- NSObject.FromObject method automatically boxes .NET types into NSValue, NSString or NSNumber objects.
- Convenience function to create NSArrays from object [] arrays and using the new NSObject boxing functionality.
- New NSIndexSet convenience factory method and ToArray method
- NSDictionary and NSMutableDictionary have convenience methods that take object [] arrays, and do the boxing automatically (using the new NSArray functionality described above)
AppKit:
- DoubleClick event on views that have support for double click actions (instead of using the DoubleAction selector + Target)
- NSTableView has a new Source property that can be used to blend both Delegate and the table view data source into one (NSTableViewSource which combines NSTableViewDataSource and NSTableViewDelegate)
- New: NSPredicate family of classes
- New: NSRuleEditor
AddressBook library:
- We used to ship the source, but now it is included in the binary library.
CoreImage:
- New in this release.
WebKit:
- Many events that were previously only exposed as Objective-C style delegates are now proper C# events.
Engine:
- Improved methods with return structures
- Improved string [] marshalling
- Now with INativeObject marshalling

We have also updated the samples and added a few more.

The @" syntax in Objective-C vs C#

miguel@gnome.org (Miguel de Icaza) — Tue, 14 Dec 2010 21:33:00 PST

A common mistake that I see in some of the code from our customers, or from contributed samples to the MonoMac repository is the use of the @"string" syntax in C# programs. Summary: do not use the @"..." when porting Objective-C samples to C#.

String Syntax in Objective-C and C#

Objective-C supports two kinds of string literals in your source code, strings that are surrounded by double-quotes and strings that are prefixed with the at-sign and then double quotes.

The first kind are zero-terminated C-style strings. For example the string "foo" is encoded by the compiler as the following four bytes: 'f', 'o', 'o' and zero plus the address of the string at the location where this is referenced.

The second kind, for example @"Hello World" is a CoreFoundation string, and the compiler has to encode by creating a static instance of a CoreFoundation CFString object: it has a class identifier, some object flags, a pointer to the data ('foo' in this case) and the length of the string.

In both the c-string style and the CFString style, escape sequences are processed by the compiler. This means that if you use "1\n2" or @"1\n2" this will produce in both cases a string consisting of the '1' character followed by a newline (byte value 10) and the '2' character.

In C# the syntax @"string" does not mean "encode as a CFString" object. Instead it is a quoted-string literal, and it instructs the compiler to avoid performing escape sequence processing. In C# the strings "1\n2" and @"1\n2" have respectively lengths 3 and 4. The former one consists of the characters '1', newline (byte value 10) and character '2'. While the latter consists of the characters '1', '\', 'n' and '2'.

System.String vs Foundation.NSString in MonoMac/MonoTouch

In the MonoTouch/MonoMac binding strings are almost always exposed in the binding with the native C# string type (System.String). Any conversions between the C# string and the Objective-C string type are done by the runtime.

There are a handful of places where we must expose NSString values instead of strings. This is usually necessary when the underlying Objective-C code performs reference comparisons instead of content comparisons for strings. Some Objective-C APIs for example use these strings as special "tokens" that you must pass verbatim in your application to a method.

We typically use those for notification names, keys in dictionaries and a handful of other places. You will notice in those handful of cases that Mono's API's expose an NSString parameter or return value instead of a string parameter or return value.

For example if you have a AddNotification (NSString key) API, you would typically use it like this:

	// example class exposing a notificatin as an NSString:
	// class SomeClass {
	//        NSString WakeUpNotification { get; }
	// }
	
	AddNotification (SomeClass.WakeUpNotification);

Conversions

Converting from a C# string to an NSString is easy, all you have to do is call new NSString ("mystring").

To go the other way around from an NSString to a string, you can either use an explicit cast (this is the recommended design pattern from the Framework Design Guidelines) or you can use the ToString () method on an NSString.

NSNumbers, NSValues, Dictionaries and Arrays

miguel@gnome.org (Miguel de Icaza) — Thu, 09 Dec 2010 21:33:00 PST

A couple of days ago, Jackson pointed out that one of the samples in this blog could be further simplified if we took advantage of C#'s params arguments. The sample in question was this code snippet from QTRecorder, used to return an NSSet:

[Export]
public static NSSet keyPathsForValuesAffectingHasRecordingDevice ()
{
    return new NSSet (new string [] {"SelectedVideoDevice", "SelectedAudioDevice"});
}

In the above example, we have to manually construct the string array, so that we can call the NSSet (string [] args) constructor. Jackson correctly pointed out that the above could be simplified if we introduced an NSSet (params string [] args) constructor. This lets the compiler do the work for us, so the sample above can be written like this instead:

[Export]
public static NSSet keyPathsForValuesAffectingHasRecordingDevice ()
{
    return new NSSet ("SelectedVideoDevice", "SelectedAudioDevice");
}

This got me thinking about another possible improvement to the API. In a number of places in the MonoMac/MonoTouch API it is necessary to pass numbers, strings, booleans, points, rectangles, affine transforms and 3D transforms in NSDictionary and NSArray objects.

Since Objective-C does not have language-assisted auto-boxing like C# does, programmers have to manually box those in either NSValue types or NSNumber types. An NSNumber can contain booleans, 16, 32 and 64 bit integers and unsigned integers as well as floats and doubles. NSValues are typically used to box points, rectangles, sizes and 2D and 3D affine transformations.

In a few of the current samples we have code like this:

var objects = new NSObject [] { 
    new NSNumber (13),
    new NSNumber ((float) 0.5) };
var keys = new NSObject [] {
    new NSString ("speed"),
    new NSString ("volume") };
var dict = NSDictionary.FromObjectsAndKeys (objects, keys);

The above clearly is too verbose for no good reason. We have now introduced methods that take general purpose object [] arrays, containing regular C# data types and will do the automatic boxing:

var objects = new NSObject [] { 13, 0.5 };
var keys = new NSObject [] { "speed", "volume" };
var dict = NSDictionary.FromObjectsAndKeys (objects, keys);

The method that does the object to NSObject conversion is a convenience static method in the NSObject class, with the following signature:

public static NSObject FromObject (object obj);

The function can be used to convert nulls, booleans, numbers, strings, IntPtrs, SizeF, RectangleF, PointF on both MonoMac and MonoTouch and in MonoTouch it additionally supports CGAffineTransform, CATransform3D and UIEdgeInsets.

Using Key-Value Coding with MonoMac

miguel@gnome.org (Miguel de Icaza) — Tue, 07 Dec 2010 21:33:00 PST

Key-Value Coding is a set of practices that allow applications to access object properties using strings. This is similar to Binding Expressions in Silverlight. In both cases the purpose is to allow tooling that does not directly have access to your native code to access properties from your program.

You would typically use this from a tool like Interface Builder, where you can use the Binding Inspector (⌘4 from Interface Builder) to explore the possible values of the component that you can data bind. In Interface Builder you would use string to describe the name of the property that you want to access. For example, consider the options available for the NSPopUpButton component show on the right. All of those properties of the NSPopUpButton can be pulled directly from your code from Interface Builder without having to manually hook things up.

To use this with MonoMac, all you have to do is make sure that any property that you want to access from Interface Builder is flagged with the [Export] attribute. If you apply the Export attribute without any parameters, it will expose the C# name of your property for Key-Value access. You can change the name that is exposed by passing a parameter, for example: [Export ("myIndex")].

The QTRecorder sample shows how various elements in the UI are connected to the code: [caption id="attachment_38" align="alignnone" width="583" caption="MonoMac port of QTRecorder sample"][/caption]

In that sample, the class QTRecorder, a class derived from NSDocument exposes properties that are hooked up directly to the Enabled properties in various buttons in the UI and properties to populate and control the contents of the various popups in the application. All of these bindings are configured by setting the target of the binding to be the "File's Owner", in this case the QTRecorder class, as it happens to load the QTRecorder.nib file. You can see the complete list of bindings in the screenshot on the left.

Let us explore what happens in the application. The Video Devices popup is controlled through three bindings: the Content, the Content Values and the Selected Object. This is what the binding are configured to in Interface Builder for all three properties:

The Content is bound to the VideoDevices property in the source code, this is a property that merely returns the strongly typed QTCaptureDevice array of the available devices. The Content Values is bound to the VideoDevices.localizedDisplayName. The first part of the key matches our VideDevices array, and the second part of the key happens to be the Objective-C name of a property exposed by the QTCaptureDevice that provides the name of the device to display. The actual item selected on the screen is controlled by the Selected Object binding. In this case, a new property, the SelectedVideoDevice property. At this point, the NSPopUpButton will populate its contents using these bindings. Additionally, when the user selects a different item, the property bound to the Selected Object will be invoked with the new value. Our code responds by configuring the QTCaptureSession accordingly.

Another interesting binding takes place with the recording button. The recording button hasits Enabled property bound to the HasRecordingDevice C# property and has its Value bound to the C# Recording property. When we change the video source in the popup, the button responds by either getting grayed out or becoming active. Although this could have been done programmatically in response to the new value set in the SelectedVideoDevice property, the code takes advantage of the built-in notification system and instead reacts to changes to the SelectedVideoDevice automatically.

This is done by using the dependency keys feature a feature of Key-Value Coding. It requires that the code exports a specially-named method which is prefixed with the string "keyPathsForValuesAffecting". These methods are are meant to return an NSSet containing the names of the properties that depend on that particular property. In our case this is:

[Export]
public static NSSet keyPathsForValuesAffectingHasRecordingDevice ()
{
    return new NSSet ("SelectedVideoDevice", "SelectedAudioDevice");
}

Once that is done, the runtime knows that when either one of the SelectedVideoDevice or SelectedAudioDevice change, it has to query the value for HasRecordingDevice again.

Error Reporting Pattern in MonoMac

miguel@gnome.org (Miguel de Icaza) — Sun, 05 Dec 2010 21:33:00 PST

When writing code that reports errors to the user, usually when I get back an NSError result, I use the following code snippet to show it:

if (err != null){
   NSAlert.WithError (err).BeginSheet (Window, delegate {
       // Any needed cleanup code can go here,
       // it is invoked when the Sheet goes away.
   });
   return;
}

The above creates an NSAlert object using the WithError factory method, and then invokes the BeginSheet method to present this modally to the user. Usually you can put any cleanup code in the body of the provided delegate.

MonoMac 0.4 is out

miguel@gnome.org (Miguel de Icaza) — Fri, 03 Dec 2010 21:33:00 PST

We have just released MonoMac 0.4. Installation is very easy, just follow the steps in our MonoMac site.

StillMotion C# sample

We are very happy with this release as this is the first time that MonoMac can be used to build real applications for OSX. There are three major reasons for this:

Our API coverage for all core Mac APIs is in place.
We have completed many of the gaps in the MonoMac engine.
With our community, we have been porting various samples that have helped us polish the API and make sure that it is natural and usable for C# programmers.

In addition to those fundamental changes, MonoDevelop now also sports a new NSDocument-based template for new projects which will come in very handy for many developers.

The major changes in MonoMac 0.4 from version 0.2 released in early November are:

MacCore (code shared with MonoTouch):
- Support for Key Value Observing with C#
- Foundation extensions:
  - C# friendly NSNotificationCenter APIs
  - NSPredicate support
  - NSMetadata support
  - Strongly typed NSRunLoop
  - Extended NSError, NSMutableData,
- CoreVideo framework bindings
- Security framework bindings
- CoreGraphics support for PDF files
MonoMac:
- QTKit framework bindings
- NSDocument templates in MonoDevelop
- WebKit DOM APIs
- CoreImage APIs
- ECMA XML Documentation stubs are now in place
- Lots of samples!

Michael Hutchinson has a walk through on using MonoMac with MonoDevelop that will get you up and running quickly.

We are still looking for contributors to help us bring more samples to MonoMac, create more MonoDevelop templates and help us add more of the system libraries to MonoMac. If you want to join us, check out the mono-osx mailing list and we are on the IRC channel #monomac on the server irc.gnome.org.

MonoTouch for iOS 4.2 is out.

miguel@gnome.org (Miguel de Icaza) — Thu, 02 Dec 2010 21:33:00 PST

We have graduated our MonoTouch 3.2 into the stable channel and is now available for all of our MonoTouch users in the stable channel. To update, just go to the Help menu on MonoDevelop, select the stable channel and check for updates.

In addition to adding support for the new APIs introduced in iOS 4.2 for the iPhone and the iPad in the core libraries, we have bound many more frameworks that our users have requested, in particular the horrifying Security framework API now has a nice C# binding that regular humans can consume.

Enjoy!

Improving upon dictionary bindings.

miguel@gnome.org (Miguel de Icaza) — Wed, 01 Dec 2010 21:33:00 PST

iOS and OSX expose many of their APIs as dictionaries. This means that instead of having properties or methods to configure a particular object, the configuration takes place by creating dictionaries that use some special keys with their associated values. These APIs are not well suited for exploration from the IDE or from our REPL. The APIs typically look like this:

CFStringRef keys[] = {
    kCTFontAttributeName,
    kCTForegroundColorAttributeName
};
CFTypeRef  bval[] = {
    cfListLineCTFontRef,
    CGColorGetConstantColor(kCGColorBlack)
},

attr = CFDictionaryCreate (kCFAllocatorDefault,
        (const void **) &keys, (const void **) &bval,
        sizeof(keys) / sizeof(keys[0]), &kCFTypeDictionaryKeyCallBacks,
        &kCFTypeDictionaryValueCallBacks);

astr = CFAttributedStringCreate(kCFAllocatorDefault, CFSTR("FFFFFF"), attr);[/sourcecode]

To make the API more easy to discover through intellisense, and our assembly browser, we try to turn all of the Dictionary-based APIs into strongly typed classes that hide the dictionary, the names of the keys, and the types of the keys required. The responsibility for getting the types right, to get the encoding working and to figure out which keys are valid or required in a dictionary are shifted from the programmer to the framework developers (in this case, MonoTouch and MonoMac developers).

What we typically do is we create a type that exposes all of the properties that might be supported by the dictionary, and we provide nullable version of them, for example, in the above case, Mono's implementation lives in the CFStringAttributes class, and the properties that we expose are these:

public class CFStringAttributes ()
{
    public CTFont Font { get; set; }
    public CGColor ForegroundColor { get; set; }
    [...]
}

Our users then instantiate configuration objects like this:

var attrs = new CFStringAttributes () {
    Font = listLineCTFont,
    ForegroundColor = UIColor.Black.CGColor
};
var astr = new NSAttributedString ("FFFFFF"), attrs);

When you create your CFStringAttribute and start a new-line to enter properties, MonoDevelop knows the possible property values that you can initialize in the constructor, avoiding an entire trip to the documentation to figure out what is the key that you should use, the value and its encoding. It is all kept on type-safe datatypes.

There is a second class of APIs, mostly in the Audio and Video APIs that exposes a whole set of properties behind fooGetProperty and fooSetProperty APIs. Those APIs tend to be weakly typed, and take both a key, and depending on the key, a pointer to some value. If you feed the wrong values to the program, your application could crash or corrupt its heap. In these cases we have also walked away from exposing the low-level GetProperty/SetProperty methods, and instead exposed strongly-typed C# properties.

This is an example from the AudioFile API:

        AudioFileGetProperty (
                audioFileID,
                kAudioFilePropertyPacketSizeUpperBound,
                &propertySize,
                &maxPacketSize
        );

In the above case, we are probing for the maximum packet size for the file. The user has to find and pass the proper constant (kAudioFilePropertyPacketSizeUpperBound), the size of the object (this is a simple validation system to eliminate a certain class of memory corruption erors), the address of the variable that will get the result back, and then determine the proper type for the property (maxPacketSize).

What we have tried to do with MonoTouch/MonoMac is hide all of that complexity, and instead we expose strongly typed properties, in this case the equivalent code is:

var maxPacketSize = audioFile.PacketSizeUpperBound;

The property is available as well for intellisense, so it is a lot simpler to see what is going on behind the scenes, shows up on the debugger window, on the interactive shell and means that scripting languages can access it without having to resort to reading C API documentation.

My own iOS and OSX centric blog

miguel@gnome.org (Miguel de Icaza) — Tue, 30 Nov 2010 21:33:00 PST

In the past 18 months I started to spend a lot of time on OSX and iOS due to our MonoTouch project. MonoTouch was our effort to blend seamlessly the iOS Objective-C APIs with the C# and ECMA CLI APIs. This is probably one of our nicest bindings that we have ever done for a native API, and it build on the experience from previous attempts like CocoaSharp, MonoObjc and other bindings that were created for the Mac in the past seven years.

The MonoTouch design and binding patterns proved to be very useful, and Geoff Norton and myself decided to bring the same design and patterns from iOS to OSX. This is how the new MonoMac bindings were created. While MonoTouch is a proprietary and commercial produce, MonoMac is open source and licensed under the MIT X11 license.

Building MonoMac has been a very fun experience, as the scope of the APIs is larger and also as it seems to have filled a void in the space. As the binding bootstraps, we are starting to see both users and contributors that have helped us move MonoMac faster by providing help with the bindings, polishing the API or writing samples that show how to use MonoMac.

My personal blog did not feel like the right place to share tips and tricks on iOS and OSX development for two main reasons: (a) tips and tricks were bound to be fairly boring for people interested in other topics that I blog about, and (b) because both of these operating environments are proprietary and I feel that sites that have historically aggregated my blog did so for its open source content.