This repository has been archived by the owner on Jan 14, 2021. It is now read-only.
/
README
158 lines (113 loc) · 5.27 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
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
mono-osx@lists.ximian.com 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.