XCode and Visual Studio go head to head
Brian Goldfarb's Blog : XCode and Visual Studio go head to head: ""
I've been using Visual Studio since version 4.0 (32-bit, not 16-bit thankyouverymuch
) and I've just recently started working with XCode 2.1. So I can chime in a bit.
Up until Visual Studio 2005, I'd have to say that Interface Builder, for all of the problems that these guys are reporting with it, wins hands-down over Visual Studio for helping me design a nice UI. It was interesting to NOT have to fight the designer while laying out controls. IB provided me with rules and snap-tos that complied with the Apple UI guidelines while Visual Studio made me try to line things up using by eyeball or using the clumsy "Format" menu.
This is how they describe adding a button to your app in Visual Studio.
1. Drag a button onto the window
2. Double click the button
3. Write code
Here's how it usually goes for me.
1. Drag a button onto the window
2. Double click the button
3. Write code
4. Remember that the buttons name is set to "buttonx" where x is the number of the last button with the name "buttonx".
5. Go find and replace all instances of "buttonx" with the new name in my code.
That being said, the experience they describe when using XCode is very similar to my own. Except that I had professional Cocoa/Mac developers teach me how to use XCode. Their advice was to set up all of your classes first, IBOutlets, methods, etc... Then go into Interface Builder, create your UI, and connect the buttons.
XCode itself provides intellisense...kind of. no where near what Visual Studio has for a while. But intellisense tends to annoy me. It always seems to be covering up code I want to see.
You can't even compare the debuggers. Visual Studio wins hands-down. Has there ever been a better debugger? I haven't used one yet.
My personal favorte anecdote is just how easy it is for them to do Web Serivces from Objective C -- all it took was re-writing the compiler for an open source solution called gSoap -- you know, simple stuff
![]()
Yeah, you'd have to talk to Joe Heck about consuming SOAP services in Objective-C, I think he's done some of that. But calling and consuming an XML-RPC service in Cocoa isn't as hard as the blog makes it out to be. And consuming wild SOAP services in .NET isn't as easy and it's made out to be. Mainly due to the strict definition of SOAP that Microsoft enforces and the variations of SOAP envelopes that you'll encounter in the wild.
Here's some example code straight from Brent Simmons example. (I can't find a link to the code, I'll try emailing Brent and asking him where he put it. update: Found it here. He also has some excellent examples of parsing OPML and RSS feeds in Objective-C and Cocoa/CF)
-
WSMethodInvocationRef rpcCall;
-
NSURL *rpcURL = [NSURL URLWithString: @"http://betty.userland.com/RPC2"];
-
NSString *methodName = @"examples.getStateName";
-
NSDictionary *params = [NSDictionary dictionaryWithObject: stateNum forKey: @"foo"];
-
NSDictionary *result;
(Also via Brent's Newsgator weblog, an XML-RPC client debugger for OS X.)
As I see it now, you have to roll your own classes when calling XML-RPC from within .NET. So the two frameworks are about equal. It's my understanding that this will change once Indigo hits the streets.
Here's the bottom line for me.
XCode price: free with free upgrades. So my cost of experimenting and exploring is nothing. I've stated before, the cost is the only reason I'm playing with Cocoa at all. How much did the Phanfare developers have to invest in creating their Mac client? Just their time. They didn't have to buy an expensive development environment.
update: I found some Apple sample code for consuming a SOAP web service using Cocoa
The implementation is pretty hair, but logical. Here is the entire header file. (at least the code part)
-
#import <Foundation/Foundation.h>
-
#import "MyURLConnection.h"
-
-
// A simple abstraction of some of the work that a SOAP
-
// client would have to do.
-
@interface SOAPClient : NSObject {
-
NSURL *url;
-
}
-
-
- (id)initWithServerName:(NSString *)name;
-
-
- (NSXMLDocument *)sendMessage:(NSXMLDocument *)xml waitForReply:(BOOL)b;
-
-
@end
-
-
-
and here is the implementation of the sendMessage method.
-
-
- (NSXMLDocument *)sendMessage:(NSXMLDocument *)xml waitForReply:(BOOL)b {
-
NSData *data = [xml XMLData];
-
-
NSMutableURLRequest *request = [[[NSMutableURLRequest alloc] initWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:60.0] autorelease];
-
[request setHTTPMethod:@"POST"];
-
[request setHTTPBody:data];
-
[request setValue:[NSString stringWithFormat:@"%d", [data length]] forHTTPHeaderField:@"Content-Length"];
-
MyURLConnection *conn = [[[MyURLConnection alloc] initWithRequest:request delegate:self] autorelease];
-
-
xml = nil;
-
if (b) {
-
while (![conn isFinished]) {
-
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
-
}
-
NSError *error = nil;
-
xml = [[[NSXMLDocument alloc] initWithData:[conn data] options:NSXMLNodeOptionsNone error:&error] autorelease];
-
}
-
-
return xml;
-
}
Still pretty hairy, but not overly complicated. I mean, Objective-C isn't BASIC. It's C. It has to be a little complicated.
-
http://blogs.msdn.com/bgold/ Brian Goldfarb
-
Timothy Strimple


