mono/monomac

MonoMac - .NET/C# Bindings to the Cocoa API


DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED 
DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED 
DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED DEPRECATED 

	WARNING: MonoMac is not actively maintained, and it has design mistakes
	that prevent it from properly managing memory.   You should use the
	open source Xamarin.Mac instead which is actively maintained, and
	has none of these design problems.
	
https://github.com/xamarin/xamarin-macios.

OLD NOTES:

	MonoMac provides a new set of C# bindings to the Cocoa APIs on
	OSX and can be used to create applications that use the native
	OSX APIs using Mono and C#.

	The code is licensed under the terms of the open source Apache
	License version 2 or the MIT X11 license, at your own choice.

Building:

	To build MonoMac, you need to get two packages:

	   * maccore
	   * monomac

	The first contains the code that is shared between MonoMac and
	MonoTouch.  MonoMac contains the actual bindings that are
	OSX-specific.

	You MUST check out both modules side by side currently.
	To build monomac type "make" which will create the monomac.dll

	MonoMac requires Mono v2.6.4 or higher, you can find a RC for
	2.6.4 at http://mono.ximian.com/monobuild/preview/download-preview/

Using:

	Download the MonoDevelop IDE from www.monodevelop.com for MacOS X,
	it comes with both MonoMac templates and project types that will
	help you get started.

More Information:

	http://www.mono-project.com/MonoMac

Discussion:

	The discussion of the development of MonoMac is taking place
	on irc.gnome.org in channel #monodev and on the
	[email protected] mailing list:

	http://lists.ximian.com/mailman/listinfo/mono-osx

Pending Tasks

	We are looking for contributors to these areas:

	* API binding for the rest of the Frameworks

	* We need samples to be written

	* We need tutorials to be written (like the ones we did for
          MonoTouch)

	* We need to port existing Cocoa samples to C#:
	  * To exercise the binding
	  * To serve as reference for new developers
	  * To identify missing frameworks
	  * To prioritize bindings

Binding APIs

	Information on how to bind new APIs can be found on the MonoTouch web site: 

	http://monotouch.net/Documentation/Binding_New_Objective-C_Types

Goals

	  We had two main requirements: the binding should just work
	  and the code should be MIT X11 licensed.  For the binding to
	  just work, we turned to the .NET Framework Design Guidelines
	  book as it captures years of design decisions, programming
	  idioms and advise that would help C# and .NET developers.  By
	  following the Design Guidelines we:

		Avoid surprises
		Blend with other C# and .NET libraries
		Reduce the room for errors
		Increase developer joy
		Minimizes time for the developer to be productive
		Every bit of existing .NET knowledge translates

	Luckily for us, .NET was designed from the start to be an
	interoperability framework.  A framework that supports the
	most advanced requirements to make multiple runtimes and
	frameworks to communicate seamlessly with each other.  We used
	these features to create our bindings.

	The above goals turned into the following technical
	requirements:

	  * Developers should be able to consume Cocoa APIs as C# APIs
	  * Allow developers to subclass Objective-C classes
	  	* Subclass should work with C# standard constructs
	  	* Derive from an existing class
	  	* Call base constructor
	  	* Overriding methods should be done with C#'s override system
	  	* Do not expose developers to Objective-C selectors
	  * Provide a mechanism to call arbitrary Objective-C libraries
	  * Make common Objective-C tasks easy, and hard Objective-C tasks possible
	  * Expose Objective-C properties as C# properties
	
	  * Expose a strongly typed API, for example instead of
	    exposing the generic-container NSArray or individual
	    NSObjects.  This means that developers get a few benefits:

	  	* MonoDevelop can flag errors as you write the code

	  	* MonoDevelop can present documentation popups on
	  	  types, methods, properties and parameters as you type them.

	  	* Minimize runtime errors by catching invalid casts at
	  	  compile time.
	  	  

	  	* Encourage in-IDE API exploration without rebuilding,
	  	  and without having to look up the types in the
	  	  documentation.

	  * Turn int and uint parameters that should have been enums
	    as C# enumerations and C# enumerations with [Flags] attributes
	  
	  * Expose the basic Foundation as C# native types:
	  	* NSString becomes string
	  	* NSArray becomes strongly-typed array
	  * Events and notifications, give users a choice
	    between:
	  	* Support the Objective-C delegate pattern:
	  		* Strongly typed version is the default
	  		* Weakly typed version for advance
	  		use cases
	  	* C# event system
	  * Class libraries should be MIT X11 licensed, like the rest
	    of Mono's class libraries.

	  * Expose C# delegates (lambdas, anonymous methods and
	    System.Delegate) to Objective-C APIs as "blocks".

	  * Curated APIs: there is no point in binding every UNIX or
	    CoreFoundation C API available, as those are not very
	    useful in practice.  Bind only those that are required to
	    build applications or get access to mandatory
	    functionality.