Building a Native OS X Desktop App: First Impressions

Comment

Comment by Stuart Malin on October 16, 2009 at 5:37am

Google’s War Chest: Search Giant Now Has $22 Billion in Cash --> http://mashable.com/2009/10/15/google-earnings-3/

Comment by Pat Niemeyer on October 16, 2009 at 4:21am

I said the same thing when I first looked at Interface Builder for doing iPhone work... that it was the best WYSIWYG interface builder I'd used - and really the first want that I wanted to use in lieu of procedural setup. But after trying the Flex interface builder and environment I have to say that it's much much better... instead of having all of that UI serialized into NIBs and hooked up with code references you have MXML that you can read and edit and a really powerful and intuitive data binding framework that is so cool it's like magic. Also you get to work in Java (more or less) instead of C :)

I can't stress enough how cool MXML is... having a way to go seamlessly back and forth between procedural and declarative code is just incredibly powerful thing and the Flex Builder really takes advantage of it... Java and GWT should just steal all of this (as they stole the Java bits).

Comment by Stuart Malin on October 16, 2009 at 2:06am

Konstantin said:

Personally I am very picky about learning new things unless it really pays well (he he) or has a bright future to it :)

I agree! Yet there are so many things calling me, and I know their learning curves are deep. I wish I were younger and had my swifter mind, that there were more free hours in a day to explore, and that I knew of some compass for assessing true utility and potential in advance.

As for Google's expanding market share: they are ill-representational of an adoptable business case because their business model uses immense profits from one product area (online advertising) to fund initiatives in other areas... that have no revenue. Expanding market share without a revenue model is unsustainable. That said, Google has been exemplary for injecting advertising into other online services (e.g. maps). I do not know what their economic model might be for Android (other than an app store for developers), and whether that can become a self -sustaining activity.

Comment by Konstantin A Lukin on October 16, 2009 at 12:28am

That's why Google keeps expanding its market share.. It adheres to commonly accepted standards. If there is no standard, it tries to define one based on commonly accepted standards :) and keeps most of its API open source.

Personally I am very picky about learning new things unless it really pays well (he he) or has a bright future to it :)

Comment by Stuart Malin on October 15, 2009 at 9:49pm

The learning curve for a language is hours. The learning curve for a framework is years. A framework is a source of competitive advantage (and religious ideology). Never shall there be standardization on one. Apple isn't "forcing" any one to learn Objective-C -- programmers learns languages because languages are the medium of programming.

Comment by Alex Salkever on October 15, 2009 at 8:41pm

All I know, from the business side, is that more languages to manage for more platforms means more expensive software development. Apple may have an advantage with the strength of the iPhone and can force developers to learn Objective C but, in reality, you'd see a whole lot more interesting app development if we could standardize on languages. From a user standpoint, the differences are negligible. My two cents. :)

Comment by Daniel Leuck on October 12, 2009 at 4:39pm

Martin Pilkington:

    x.intersectsArc(35.0, 19.0, 23.0, 90.0, 120.0);

You can't tell what any of those values mean, you either need comments or to look up in documentation. Compare this to what such a method would be like in Obj-C:

[x intersectsArcWithRadius:35.0 centeredAtX:19.0 Y:23.0 fromAngle:90.0 toAngle:120.0];

Which is infinitely more self documented. Named parameters does help a bit, but you still need to look them up to enter them.

I agree regarding positional params/args vs. named or interspersed. Named and interspersed params are more perspicuous. I've long advocated adding named parameters to Java. If they are ever added, they almost certainly will have statically discoverable names, so you wouldn't have to look them up. Also note that any modern IDE picks up positional param info from the code docs and provides this information as you type the arguments, but its still not as clear as named or interspersed params.

Stuart Malin: To me, the language has two faces, its syntax, and its runtime. Yes, the syntax is "dated." The runtime has some nifty stuff. But I concur, not all so much that is any more remarkable. However, where I feel the love-of-Cocoa begins is with what the Foundation does with the runtime capabilities. As I wrote in an earlier post here in this thread, NSObject is quite a cool beast, and since most nearly everything inherits from NSObject, the power is dispersed to the masses. So, in a narrow sense, Objective-C is a tad tawdry. But what Cocoa does with it, and what Cocoa makes available, is powerful.

I agree. Cocoa is an elegant framework. It makes excellent use of UI best practice design patterns, and NSObject utilizes runtime features in some very interesting ways. I'm sure I will learn more about the details as I go.

Comment by Stuart Malin on October 12, 2009 at 1:24pm

- (id) init { if ( self = [super init] ) { [self setFirstName:@"Joe"];
[self setLastName:@"Smith"];
}
return self;
}

From a "good" coding perspective, it is advised to not invoke setter methods in your instantiator, but refer directly to your iVars. I happen to use an old convention of prefixing my iVars with an "m" for "member", so if I were to write that, I'd write:

- (id) init { if ( self = [super init] ) {
mFirstName = @"Joe";
mLastName = "Smith";
}
return self;
}

Nonetheless, your point is well made.

To me, the language has two faces, its syntax, and its runtime. Yes, the syntax is "dated." The runtime has some nifty stuff. But I concur, not all so much that is any more remarkable. However, where I feel the love-of-Cocoa begins is with what the Foundation does with the runtime capabilities. As I wrote in an earlier post here in this thread, NSObject is quite a cool beast, and since most nearly everything inherits from NSObject, the power is dispersed to the masses. So, in a narrow sense, Objective-C is a tad tawdry. But what Cocoa does with it, and what Cocoa makes available, is powerful.

btw: I always liked Perl :-)

Comment by Stuart Malin on October 12, 2009 at 1:16pm

That said, you can use [NSNumber numberWithFloat:1.0] to simplify it (technically you don't need the .0 either).

Be careful there -- that's an autoreleased number object in a retain/release environment. That's why the factory method is often called a "convenience" method.

Comment by Martin Pilkington on October 12, 2009 at 12:58pm

To use an example from a Cocoa book, it's not unusual in C++, Java, C# etc to see a method like:

x.intersectsArc(35.0, 19.0, 23.0, 90.0, 120.0);

You can't tell what any of those values mean, you either need comments or to look up in documentation. Compare this to what such a method would be like in Obj-C:

[x intersectsArcWithRadius:35.0 centeredAtX:19.0 Y:23.0 fromAngle:90.0 toAngle:120.0];

Which is infinitely more self documented. Named parameters does help a bit, but you still need to look them up to enter them. There's also the issue that the C++, Java, C# etc way allows for method overloading, where as the Obj-C way doesn't, again allowing for much better documenting code. Again, it comes down to personal preference and how you believe a language should work, but for me Obj-C has the best syntax of any language I've seen to date.

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page