Uncle Mac takes A Cup of Cold Cocoa... 'Twas the night after Christmas. The left-over turkey had been stuffed into the freezer, the surplus mince pies stuffed into the dog, and my thoughts turned once more to programming – Mac programming. Seduced, as ever, by the Aqua interface, I decided it was time to write that killer Mac utility, the proceeds from which would …
I remember at the 2000 Developer conference, "Frameworks" were being spun as this wondrous new way to program for OS/X, conveniently forgetting the existence of application frameworks such as PowerPlant and MacApp, from, uhh, Apple.
The Nexties definitely arrived at Apple in their own RDF and have shown little signs of looking outside since to realise the rest of the world has moved on a bit in the last decade.
> Nexties definitely arrived at Apple in their own RDF and have shown little signs of looking outside
NeXt people were always a bit like that, IME. I once worked for the biggest purchaser of NeXT workstations in the City and NeXT was very strategic (according to the IT director, all our mainframe stuff was soon going to be running on NeXT - obviously he hadn't looked at the source code, as far as there was any, or the viability of NeXT itself).
But when I met it, NeXT technology was unable to integrate with any of the existing communications/email systems effectively, which hardly worried any of the NeXT enthusiasts. You couldn't, AIRI, actually get an email from the London back-office to someone with a NeXT workstation in London unless you knew about an undocumented little back-door in Chicago...
> The Nexties definitely arrived at Apple in their own
> RDF and have shown little signs of looking outside
> since to realise the rest of the world has moved on
> a bit in the last decade.
Very true. I'm a huge fan of Delphi and their VCL framework which effectively puts an elegant, OOP wrapper around the bizarre Win32 API. Apple need something similar.
I suppose you could say that Carbon equates to the Win32 API, but in my opinion, Cocoa is no match for the VCL library or the .NET frameworks.
Uncle Mac
Sure you can use the documentation for NSTableView and suporting classes to work out how to populate a table with data and sort it. But it would be a whole lot easier to use Cocoa Bindings.
Create an NSArrayController in your NIB and link that to either your own model, or that created with CoreData visual tool within XCode. Bind the table to the array controller. You will get a populated table view, with column sorting, reordering and selection mechanism for free.
These exist in 10.4 too so no need to wait for Leopard.
You don't need properties. Allowing direct access to object data breaks the concept of encapsulation. Otherwise they are just accessor methods to the data. Why do you need to mark them as something special in code? Document/comment on them sure, but why does the compiler/runtime need to know that setFuel:id and fuel are a property, where as ventTheCore is not?
The inspector palette is the equivalent of a property palette. If you create your own custom controls then you can also create a IBPalette plug-in so others can easily configure and use it within IB.
As you state IB is a tool for creating interfaces, the Cocoa frameworks and tools pretty much force you to develop your application following the MVC pattern. Not a bad thing.
IB has many shortcomings, it hasn't had the major overhaul that ProjectBuilder -> XCode had, but I'd still take the Apple supplied controls over the Windows ones. Try creating a table view that has ruler bars in Visual Studio/.Net.
I've not used Delphi so I can't comment on that, but .Net and Visual Studio I do use regularly. Personally I prefer the NeXT way. Using Visual Studio in the way you describe results in disorganised code and duplication. Two buttons that perform ultimately the same action must still have their own handler, even if it's only a wrapper to a worker method.
If you create the buttons in code you can specifically set the handlers to point elsewhere. If you use the UI to do it you're wrapping a call to your controller in a couple of lines of code. The point is, why should I have to use code to do this? IB doesn't force me to. Read in the header file for the object I want to target. Target the first responder or a specific object instance in the NIB and select an action message to send.
If I really want to sub-class NSWindow and put lots of handler methods and other things in there that really should be in a specialised controller class, and not a view class then I can, just like VS organises it.
ProjectBuilder and InterfaceBuilder were way ahead of the times when they were produced in 1986. Since then other tools caught up, and even bettered them in some areas. Now the old NeXT tools are again being actively being developed we have CoreData, key/value observing and key/value binding that makes most of what you refer to in your artical redundant. Those were released in Mac OS 10.4 Tiger.
XCode 2.0 will make live even easier for the developer to do cool stuff. CoreAnimation is amazing. If you want to have a play with the precursor in Tiger, open up the Quartz Compositor app installed as part of the Dev tools and play.
Garbage collection is added to Objective-C, if you like that sort of thing.
In all I think Cocoa is still strong in all the areas it was originally. Other advances have happened in the developer world and XCode will have to play catch up. But I feel better working with a very well designed framework with tools that aren't the best in every way, than working with an inferior framework in better tools. After all it's much easier for Apple to add features to the tools than it is for Microsoft to fix their framework.
From what I know of Delphi, it's basically object pascal. I can't imagine any of the magic implemented in the Cocoa frameworks being implemented in such a strongly typed language.
Some hopefully useful linkies:
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/CocoaBindings.html
http://developer.apple.com/macosx/coredata.html
Standard disclaimer: I'm a falible human, feel free to point out mistakes, etc. that make me look n00bish.
I think Tim has hit the nail squarely on the bonce there. Most of these points would have been true a few years ago but Apple have put a lot of stuff in place to make all this a lot less painful.
Also worth remembering that Objective-C and Cocoa aren't the only frameworks that you can use to develop OS X apps. Java, Ruby and Python are all valid options you can still use Interface Builder for all of them (part of the reason it's kind of separate from XCode itself.)
For my money XCode/IB is probably the most productive environment I've worked in (and, yes, I have done some C# in the past - although I don't like to talk about it...)
http://wiredupandfiredup.co.uk/blog/files/8b5c03da4c60d78b4d0859ec436dfcda-41.html
Thanks for that, Tim - lots of good comments there.
> Sure you can use the documentation for NSTableView
> and suporting classes to work out how to populate
> a table with data and sort it. But it would be a
> whole lot easier to use Cocoa Bindings.
Briefly, I'm deliberately *not* using Cocoa Bindings because I want to get to grips with 'barefoot Cocoa' itself first. I appreciate that some of this stuff can be simplified with CB, but - on a personal level - I want to thoroughly understand Cocoa itself, and how it's built on top of Carbon, before introducing an additional level of abstraction.
> You don't need properties. Allowing direct access
> to object data breaks the concept of encapsulation.
> Otherwise they are just accessor methods to the data.
Properties don't break encapsulation. But they are a more convenient way of doing things, if only from a syntactic sugar point of view. This is why Apple are introducing properties in ObjC 2.0 with Leopard. That said, I doubt that Apple will retrospectively "propertize" (for want of a better word!) the existing Appkit framework.
> The inspector palette is the equivalent of a
> property palette. If you create your own custom
> controls then you can also create a IBPalette plug-in
> so others can easily configure and use it within IB.
Yes - that's all understood. My point was that XCode/IB are not oriented towards component-based design. With Delphi or C# (for example), you create your new custom control and the job is done. With XCode/IB, you create your control, and you then *THEN* have to go through the completely separate process of creating an IB plug-in for it.
Why is this extra step needed? In one word, metadata. XCode/IB does not have a reflection mechanism whereby the properties/events of a new control can be interrogated and automatically displayed on the component palette. It is incredibly crude compared to .NET or VCL technologies.
> IB has many shortcomings, it hasn't had the major
> overhaul that ProjectBuilder -> XCode had, but I'd
> still take the Apple supplied controls over the
> Windows ones. Try creating a table view that has
> ruler bars in Visual Studio/.Net.
IB is being overhauled (somewhat) in Leopard. But it is still miles away from what it should be. When you say "Windows controls", which ones are you talking about? Check out the stuff available from www.devexpress.com (both VCL and .NET) and then try implementing that under Cocoa. You may be gone some time! :-)
> I've not used Delphi so I can't comment on that, but
> .Net and Visual Studio I do use regularly. Personally
> I prefer the NeXT way.
Personally, I don't. ;-)
> Using Visual Studio in the way you describe results
> in disorganised code and duplication. Two buttons
> that perform ultimately the same action must still
> have their own handler, even if it's only a wrapper
> to a worker method.
It sounds like you need to get deeper into VS.NET. It is actually dead easy with .NET and Delphi to have multiple buttons pointing at the same handler, and use the sender method to perform disambiguation in the code.
> ProjectBuilder and InterfaceBuilder were way ahead
> of the times when they were produced in 1986. Since
> then other tools caught up, and even bettered
> them in some areas.
I'd agree with that, though I'd tend to replace "some" with "many". ;-)
> XCode 2.0 will make live even easier for the developer
> to do cool stuff. CoreAnimation is amazing. If you
> want to have a play with the precursor in Tiger,
> open up the Quartz Compositor app installed as part
> of the Dev tools and play.
No disagreement that Quartz and CoreAnimation are awesome compared to what's on the PC. I already have Leopard, by the way :- I have ADC membership.
> Garbage collection is added to Objective-C, if you
> like that sort of thing.
I do. ;-)
> In all I think Cocoa is still strong in all the areas
> it was originally. Other advances have happened in the
> developer world and XCode will have to play catch up.
Agreed.
> But I feel better working with a very well designed
> framework with tools that aren't the best in every way,
> than working with an inferior framework in better tools.
I don't believe that .NET and VCL are inferior frameworks to Cocoa. Quite the reverse. I would prefer to use the best tools with the best framework but unfortunately, neither is available for the Mac right now. Hopefully, that will change....
> From what I know of Delphi, it's basically object pascal. > I can't imagine any of the magic implemented in the
> Cocoa frameworks being implemented in such a strongly
> typed language.
Strongly-typed languages are not necessarily a bad thing - you would be surprised how much magic can be achieved. ;-)
Uncle Mac
>When you say "Windows controls", which ones are you talking about?
I mean the default widget set provided by Microsoft. If I need to go to a 3rd party web site to download an extra control just to achieve a very common task then that highlights an omission in the framework.
.Net makes it easy to create a scrollable content area. But it's hard to create a scrollable content area that has syncronised views to act as a header, or rulers to the main scroll view. I shouldn't have to roll my own solution or buy in someone elses.
The functionality and flexibility of the Apple provided controls far exceeds that of .Net and it's precursors. That said there is a huge 3rd party market for ActiveX controls covering the major omissions and more. Some are free, some aren't, some come with strange licensing agreements that need to be taken into account.
So for the want of a set of ruler bars, I spent a morning trawling the Internet looking for other's saying the needed the same thing. Hours looking through code snippets that didn't work properly. More time looking for appropriate ready made control, then looking at licenses.
Maybe there's a better way of doing this stuff, but I sure didn't feel at all productive while doing this. Considering I was just creating a simple graphical profiling tool for a multi-threaded VBScript engine we use so I could see how the various scripts were interacting, I just gave up and stuck the heading info in tooltips as you moused over sections.
I think in part a software engineer's take on software design and frameworks is going to be shaped by their route to learning OO development. My first formal education in object orientated development was in Smalltalk. I've found a home with Objective-C and Cocoa and find it comfortable. C++/MFC+GDI, Java/Swing and C#/.Net just aren't to me.
My personal peeve with Obj-C is it's lack of operator overloading.
I also have an ADC account, but not a dual layer DVD burner. So I can't burn the Leopard disc image to DVD to try it out. The only thing I've done with Leopard so far is read through some of the docs on the ADC site.
> I mean the default widget set provided by Microsoft.
> If I need to go to a 3rd party web site to download
> an extra control just to achieve a very common task
> then that highlights an omission in the framework.
hi Tim. I'd agree with that. But equally, I think that some of the issues I've outlined also point to omissions in the Cocoa framework. Richy's great tutorial on the wiredupandfiredup web site highlighted that even with an NSArrayController, automatic sorting of new entries doesn't happen for free. With Delphi (for instance), I can create a
TStringList object, set its Sorted property to True, and anything I throw into it is sorted automatically. Why is this so klunky with Cocoa?
> My personal peeve with Obj-C is it's lack of
> operator overloading.
I agree with that. Because ObjC isn't C++, it misses out on goodies such as operator overloading which I think is a shame.
> I also have an ADC account, but not a dual layer DVD
> burner. So I can't burn the Leopard disc image to
> DVD to try it out. The only thing I've done with
> Leopard so far is read through some of the docs on
> the ADC site.
Actually, you *can* install Leopard without a dual-layer burner. There are instructions on how to do this on the ADC web site. Download "Leopard Client 9A321 Seed Note" and read it carefully. Basically you need to create a couple of partitions on your HD, use Disk Utility to restore the Install DVD into a small partition, boot from that, and then install Leopard onto whichever other parition you want to use. I use this method all the time: it's slightly long-winded, but it means you're not forever burning expensive dual-layered media.
Hope that helps,
Uncle Mac
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
