MonoTouch for iPhone - C# bindings for native APIs
monotouch.net
monotouch.net
Still, if it lets me avoid Objective C, I think I'll give this a shot.
MonoTouch's site has a tutorial on how to use XCode + Monotouch: http://monotouch.net/Documentation/XCode
MonoDevelop fires up interface builder, and then quietly rebuilds the backing code when you're done editing. So they haven't completely reinvented the wheel, it is using standard NIB files.
If you have already tried it out and hate it, then I'm glad there is a new option!
1) Declare the instance variable in your header file: NSString * var;
2) Declare the property that matches the ivar in your header file: @property(nonatomic, retain) NSString * var;
3) Add the synthesize line to your implementation file: @synthesize var;
I mean, seriously Apple? Seriously? You couldn't compress that down to a single @property declaration?
That said, Apple has now added closures, which provides a highly effective tool for cutting through the usually highly repetitive, verbose code of Obj-C (except, perhaps, for property declarations :) and writing something a quite bit more palatable.
My only remaining complaint is the lack of GC. It's not that I mind reference counting (it's not very hard to get it right), but that cyclic references cause leaks, and there's lots of places where it's easy and beneficial to create cyclic references -- especially with closures.
If MonoTouch means I can write well-performing native applications for the iPhone in F#, god damn! I'm there.
The equivalent ObjC code is:
IBOutlet UIWindow *window;
IBOutlet UILabel *label;
@interface Foo : NSObject {
// id bar; // Only required on Mac runtime or if you want to use the iPhone Simulator
}
@property (nonatomic, retain) id bar;
@end
@implementation Foo
@synthesize bar;
- (void) doSomethingWithBar {
self.bar = @"baz";
NSLog (@"%@", self.bar);
}
@end
As for the rest of the verbosity? To take a canonical example,
string = [someString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]];
string.strip();
And I like that it has a tendency to have explicit method names: I can actually read my code months later when I need to go fix a bug. But thats my personal preference. If you disagree, its not my place to tell you otherwise.
When you discuss the @property compiler directive, you did not show the generated code, instead you opted to show the shortcut.
With MonoTouch there is no need for any shortcuts; The entire backing store to any outlets are compiler generated.
MonoTouch appears to support Interface Builder as well.
Also, your example isn't quite accurate. With the iPhone runtime, you only have to make the @property declaration in your interface and then @synthesize the variable in your implementation. However, the Mac runtime doesn't support this ...
The reduction of three duplicate entries to two is admirable, but still ridiculous. Moreover, "However, the Mac runtime doesn't support this ..." is the key point here. You can't use them on the simulator or the Mac 32-bit runtime (which are the same).
Additionally, prior to being corrected in 10.6, you couldn't access the synthesized ivars directly.
@synthesize is useful to have because, well, what if you want @dynamic?
Set an attribute on the @property declaration.
Or is there another example of its verbosity that you don't like? I don't find myself writing code that repeats itself very often. If I do, I'll refactor the code out to its own method. Just like I would with any other language.
I've never had trouble reading my Java, OCaml, or F# code years after I wrote it, but YMMV. In addition to the syntax, which stands on its own as a testament to monstrous verbosity, here are a few more off the top of my head:
1) Delegate/target pattern -- alerts, timers, etc. Your classes become a morass of delegate methods and hinky hijinks to pass what should be closure-captured state across disparate method calls. I don't want to make a mess of my classes by refactoring code to a distinct method if it doesn't belong in a distinct method.
2) Initializers. You wind up writing 3-6 different init methods, and then have to write 3-6 different class method short-cuts so you don't have to write '[[[Class alloc] initWithEverything: everything] autorelease]' everywhere.
3) Repeating myself. All the time. Why do I have to write header files? Java, C#, F#, OCaml, Python, Ruby -- none of them require me to duplicate my interface and implementation in two places. I understand that this is Objective-C, but in 2009, perhaps Apple should reconsider the C part?
There is actually a hole in the other half of my earlier statement. Java has essentially the same quality IDE available (since IntelliJ IDEA =~ VS.NET + ReSharper), and yet I don't find myself compelled to use it for anything.
I'm also more than a little concerned that you have to pay for the dev environment itself (with an evaluation version on the way). I really hate this model. They should've gone the route of giving away to tools themselves for free, but charging upon the need to deploy. This allows developers like me to vet the platform before spending hard-earned dollars.
I don't understand this argument. If you're already familiar with object oriented programming, it should only take you a day or two to learn Objective-C. This won't save you from having to learn Cocoa Touch, which is where the real time investment is.
It's the libraries! Takes a long time to learn them all...
The GUI library issue is the same on all platforms really. No matter what language you're using, the interface is going to be a wrapper for the underlying System API, which is either a C, C++, or Objective-C library.
There will be a free eval that will not require you to buy until you are ready to test/deploy on the device.