Profile photo of marc

by

Life after Prism (1.0) – Part 2

December 13, 2008 in Elements

In the first post of this blog series, we’ve taken a look at the new Add Reference pane for Mono that will be coming to a future prism release. Today, i want to talk about a feature that, technically, already ships in the current 3.0.15 release, but simply is not exposed via a nicely wrapped up template, yet.

When i was at PDC, i had the chance to catch up with Geoff Norton, who is the driving force behind the Mac OS X support in Mono. We talked a bit about the future of Cocoa# and Geoff suggested i should have a look at a third party library called Monobjc, which tries to solve the same problem as Cocoa# – making the Objective-C classes that form the basic of Mac OS X’s APIs available to managed code – but is at a much more complete state and provides better performance.

I liked a lot what i saw when i first looked at Monobjc in early November. From a user (read: developer) perspective, the library works very similar to Cocoa#, seems to be more stable and exposes a lot more functionality. The main differences for developers using Monobjc is that it maintains the original class names from Objective-C (Cocoa# dropped the NS prefixes, which i always thought was a mistake and caused a lot of confusion, not to mention duplicate class names that forced you to use System. or Cocoa. namespace prefixes all the time), and that it uses slightly different attributes to define the mapping between managed and unmanaged code.

So i set out to adjust the IDE support for Cocoa# development we have in Prism, to provide similar functionality for Monobjc. Basically, the development process will be the same as outlined in our wiki article on Cocoa#, but:

  • A new Custom Tool (MonobjcNibGenerator) is provided to generate code from the elements in your NIB file to match what Monobjc expects. As explained above, this mainly constitutes of using different class names and different attributes; NSObject instead of Cocoa.Object, etc.
  • Secondly, our MacPack MSBuild extension was updated to provide a new Monobjc option, because Monobjc expects the application bundles to be packed up slightly differently.

All of this is present in the current Prism release, if you know how to use it. What’s missing is a nice template that wraps everything up and gets you going with one click, as our current Cocoa# templates do. I would have loved to include that, but by the time the above features were going into SVN, we were less than a handful of days from RTM, so i could not really justify adding a new official feature and get it thru QA ;).

So what’s missing – and coming with the next feature release of Prism – is this:

a nice template that brings it all together and makes using Monobjc in Prism as easy as using Cocoa# is now!

I’ve been using Monobjc myself over the last few weeks, building a Mac OS X user interface for our upcoming DAServer6 (which will be part of Data Abstract later in 2009), and so far i must say i’m very happy with what i’m seeing. Cocoa# has numerous known bugs where applications would just crash if you pressed the wrong key or button, and severe performance problems when lots of round trips between managed and unmanaged code (such as when populating an NSTableView) happened. With Monobjc, i have seen no such problems; it runs stable and speedily, and the running application is literally indistinguishable from a “native” app.

I would certainly recommend giving Monobjc a try if you are doing Mac development with Prism.

6 responses to Life after Prism (1.0) – Part 2

  1. See NObjective bridge.
    http://code.google.com/p/objcmapper/

    It provides more safe and faster way to deal with objc world. For example monobjc can’t catch Objective-C exceptions. Also it automatically generates all proxies. For example there is no problem to generate proxies for iPhone for few seconds.

  2. @Eugene: it may well be that NObjective is great. i haven’t looked at it in detail because the license has been GPL until few days ago, which made it pretty much a no-g- for us and most of our customers.

    The main problem, though, is that imho there are way too many people trying to create competing wrappers for Obj-C in the Mono space. the result is that all the know-how is fragmented and every solution has its advantages and disadvantages. it would be great if rather then doing this, the different parties could collaborate on creating *one* great library that works for everyone.

    the current situation makes it very hard (for our users even more so then for us as tool vendors – although i too don’t like supporting/recommending five different solutions to the same problem to our customers) to just start developing a project and committing to a given framework, as every other week there seams to be a new endeavor, or the status changes on what’s “the best” way to do Cocoa in Mono. While it may be fun for the five parties competing, it’s not a good situation for those who just wanna get busy writing apps… :(

  3. I agree 100% with Marc — please start working *together* on these wrapper frameworks. It may be hard, but please consider standing on someone else’s shoulders rather than reinventing high heels (what an awful metaphor but you get what I mean).

    Marc, when are we likely to see the “one click” MonObjc support in Prism — or put another way — we won;t have to wait 12 months for a new release of RAD Studio from Embarcadero, will we?

  4. Hi,

    Now library contains over than 2300 automatically generated proxies for Objective-C classes – it’s more than in monobjc, mobjc, Cocoa# in sum =) NObjective is my diploma project and I want to do it better than others can (I have 10 years of programming experience with modern high- and low-level languages and modern tools). Currently NObjective internally uses my own Objective-C lexer/parser to retrieve all information from Cocoa header files. All other projects fullfilled by hand-written wrappers but my approach provides ability to regenerate ALL proxies in few seconds. Other projects can’t do that coz there is no available Objective-C lexer/parser (like NRefactory for C#) written for .NET. Also my library works faster and more reliably coz it catches Objective-C exceptions. Using such facilities I can easily add new features that Apple will introduce for Objective-C (such as properties in 2.0 version).

    About licensing – I spoked with two commercial developers three weeks ago and downgrade source’s licence to LGPL to enable commercial apps link with NObjective (but tools – like NObjectiveAST and others still GPLed).

  5. Hi marc, as MonoMac just goes out of door, do you have a chance to blog about it? :)

    • not yet. we’re certainly looking at it and planning to support it, nice released, but right now we’re approaching the upcoming release of Delphi Prism 2011 in ~2 weeks, which will be focused on Monobjc for Mac development.