Which, by the way, is probably the most brilliantly conceived
event-driven MVC framework I’ve ever had the pleasure of using. The very
fact that you play by it’s rules by doing things “it’s way” is much of
what makes it so.
Mostly agreed. It’s very much like Rails, or C++ template
metaprogramming, in the sense that convention is leveraged to define
program structure. Restrictions aren’t necessarily a bad thing. The
one aspect of Cocoa development that does really bother me is that it’s
only really meant to be done in XCode, with which I am not thrilled.
Which, by the way, is probably the most brilliantly conceived
event-driven MVC framework I’ve ever had the pleasure of using. The very
fact that you play by it’s rules by doing things “it’s way” is much of
what makes it so.
program structure. Restrictions aren’t necessarily a bad thing. The
one aspect of Cocoa development that does really bother me is that it’s
only really meant to be done in XCode, with which I am not thrilled.
You can do Cocoa development in any editor you wish to use. I edit
code in TextMate, and only use Xcode to manage the project overall,
open the xibs in Interface Builder, etc. It would be easily possible
for anyone else to build an IDE for developing with Cocoa. The
problem is that Xcode doesn’t suck too bad, and it’s free, so it would
be difficult to sell another IDE to support the development costs.
Several years ago, Codewarrior supported Cocoa development. As Xcode
was improved more and more, less and less people bought and upgraded
CW and therefore it eventually went away, unable to compete with
Apple’s free offering.
Cocoa also doesn’t lock you into following strict MVC. In fact, it’s
even easier than Rails to merge model logic into the controller. It’s
also even easier than Rails to end up with what should be view code in
the controller. In fact, simple apps may end up almost entirely
contained within a single controller if you’re not careful.
Robert W. wrote:
Mostly agreed. It’s very much like Rails, or C++ template
This seems to me to be a gross oversimplification. While there may be
some similarities, in that they both implement the basic MVC design
pattern, Cocoa development involves design patterns that are rarely seen
in Rails, or any other web framework. Patterns such as chain of
responsibility, decorator/delegation, command, composite/view hierarchy,
key value code/key value observing.
My only real point here is that any similarities with Rails falls away
very quickly when you get into the inner workings of the Cocoa
framework.
metaprogramming, in the sense that convention is leveraged to define
program structure. Restrictions aren’t necessarily a bad thing. The
one aspect of Cocoa development that does really bother me is that it’s
only really meant to be done in XCode, with which I am not thrilled.
I do admit that Xcode’s text editor could use some work. However, I’d
rather use Xcode’s integrated editor over many of the other IDEs I’ve
used like Eclipse, NetBeans, JDeveloper, etc.
However, as Jim stated, you don’t have to use it. You can use whatever
editor you want.
The fact is though, that there is much more focus placed on features for
dealing with the complexities of desktop application development, which
don’t apply to web based frameworks like Rails. All you really need to
develop a Rails application is a text editor and a command line. Xcode
is, by necessity, much more that a simple text editor.