Posts by Tim Bedford

Apple asks judge to axe ebook price-fixing watchdog

Re: Monopoly vs Cartel

Except that the average book price went down during the period Apple is accused of anti-trust violations. The Library and Book Trade Almanac figures show this. The almanac is compiled by an old an respected company in the publishing field, R. R. Bowker.

Amazon had a monopoly on online book sales. Having a monopoly is not illegal, only abusing that position is. However entering a market against and entrenched competitor is hard. Apple sought to break into the market and provide competition. Something that can only help consumers.

We can't blame Amazon for fighting to maintain their position, but we can blame the American government for being hoodwinked by them.

Uncle Mac takes A Cup of Cold Cocoa...

Controls

>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.

Um why are you doing this the hard way?

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.