Well this week I’m a bit under the weather, but definitely getting better and still managing to get some coding done so I thought I’d indulge you with this bit of commentary that's been on my mind for a while. Before I do so I want you to know that Im working on a small something that mostly beginner Cocoa programmers may find very useful, though veterans may find it useful as well. I was amazed as I searched in Google to see if someone had already done this project and I couldn’t find one result that matched this. Then I searched Yahoo! just to make sure... nothing. Anyway I’ll reveal this once it’s done so keep tuned. The Cocoa Strategy One thing Im surprised i’ve never heard anybody discuss, or at least never seen it discussed anywhere (feel free to correct me if I’m wrong) is the strategy Apple has for the Cocoa (and related) Frameworks. For me learning Cocoa on Mac OS X 10.0.4 (on my first Mac a 733Mhz Quicksilver PowerMac G4) through 10.2 you got mostly a sense of... well this could be a great kit, it definitely has potential, but mostly you got the feeling that things were being fixed and brought up to standards. It wasn’t till Panther ( Mac OS X 10.3) that I saw something in the SDK that made me really say wow (after everything you already saw wow at when being introduced to Cocoa.) That was Cocoa Bindings, it was like Apple saying “hey you remember writting all that code just to display data in a NSTableView? Forget it! Just bind it!” At the time I was hugely impressed by this because this was a totally different style of programming. I had never conceived of not programmatically setting the data in a table. At first it feels like setting up some sort of intricate laser setup using precision angles with mirrors and saying “just trust me if you set this up like so it’ll connect.” So now we have Cocoa Bindings. “Great!” you say. Then 10.4 Tiger came out and so did Core Data. More than this Core Data felt like a perfect extension of Cocoa Bindings. In bindings you got a huge reduction in code by letting Apple manage all this for you on the back end and all you had to do was make your Instance Classes Key-Value Coding/Observing ( KVC/KVO ) Compliant which was (and still really is unless you’ve become really lazy after Core Data) nothing hard to do at all. In Core Data you got data persistence, database-like querying and the ability to save data in 3 different formats with barely any effort. When Tiger came out I thought to myself “Wow is this a grand strategy Apple has? Or are they just following up on the next logical step to make Cocoa better?” Looking at this you could easily make arguments one way or another. Wikipedia makes a comparsion of Core Data against an earlier NeXT Product called Enterprise Objects Framework. Now I’ve never used EOF, nor have I used WebObjects (which you use with EOF), but it does seem from the description that EOF and Core Data are definitely different in design, though somewhat similar in some of their functionality. Could you say that Apple had a goal of one day of brining the functionality that now is Core Data to the Cocoa Framework? Maybe. This technology has obviously stuck around for years and years so Apple, or at least some part of Apple, has believed in it. However even if you think they really wanted this, surely there must be a grand strategy for Cocoa? If you think this, then Leopard surely must put it to the test. We’ve put in a system (Bindings) to make some tasks which required a decent amount of code easy, then we put in a system to add data persistence and some SQL-like queries amongst other things. So what could be the next logical step? Now because I went to WWDC 06 this gets slightly fuzzy in what I can and can’t tell you so I shall err on the side of caution when speaking of Leopard improvements. However I can say in this context that I didn’t see anything that spoke to me (strongly at least) that this is the next logical addtion to Core Data. There were some brand spanking new classes that were very impressive and used Cocoa Bindings (obviously.) The thing that spoke to me the most was the vastly improved Developer tools like Interface Builder (especially), Xcode and Xray. These new tools are practically like having a new framework which makes you vastly more productive. So im curious what everybody thinks. Do you think Apple has somewhat of a grand strategy in mind for Cocoa? Or do you think Apple is more short sighted in this respect of just performing a great analysis of the framework after each Mac OS X release and giving the developers what they are trying to reach for? More or less what do you think should be included in Cocoa for Mac OS X 10.6? One interesting trend I see repeating itself over and over is that of Apple coming up with some great custom control (usually used in iLife) and then Cocoa developers working on their own custom implementation of that control, then Apple releases it officially in the next SDK for Mac OS X. I wonder how long that will continue?
Wednesday, December 06, 2006
Subscribe to:
Post Comments (Atom)
5 comments:
The way I see it, the obvious Grand Strategy for Cocoa is to provide an extremely enticing framework for developers to make them develop Mac-only applications. As it isn't easy to port Objective-C/Cocoa code to other platforms, the more developers use Cocoa, the more Mac-only apps Apple has in its software landscape.
Thus, all enhancements towards Cocoa must fit this goal. The upcoming CoreAnimation API fits this goal perfectly. Once you write an app using this API, its going to be really difficult for you to bring this experience to any other platform. Thus, the entire Mac software landscape post Leopard might have a distinctive CoreAnimation look-and-feel to it, whilst other platforms will look rather... static? ;-)
This might also explain why Java support was dropped for Cocoa. Its just another step towards making it harder for you as a developer to switch from making Mac-only applications, or continue doing it the Microsoft Mac Business Unit way at least; have two seperate teams for each platform, both writing native code.
I don't know how well that strategy will work for Apple in the long run. It might serve to scare more people away from the platform than it captures with Cocoa's blinding presence. That is, if it's what they are actually trying to do.
I really don't think that Apple is trying to subdue developers only to trap them on the platform. Apple realized they had inherited a great thing from NEXT and decided to run with it. Unfortunately, this meant supporting a language that few developers are familiar with. Despite what the developer documentation says Objective-C is a rare bird and generally resembles C only in it's guts.
I think that they also realized that supporting the Cocoa design paradigms in another language would be difficult or impossible. Bindings, Core Data, etc. They all work great with objective-c because of how objective-c works. Implementing the same design patterns in Java, for instance, is workable but hardly clean.
I also think that this was the driving force behind their decision to drop support for the Cocoa-Java bridge. They saw alot of work (implementing Core Data, Bindings in Java) for very little gain (how many people rely on the bridge). And not some form of entrapment.
You could be right though. What you suggest is hardly unheard of.
Apple is really in a bind with Objective-C, in the sense that it's clearly a great language--fully dynamic in all senses, really just Smalltalk in C minus blocks--but no one's ever heard of it in the wider development community.
From what I can tell from talking with higher-ups at WWDC, they have no intention of moving on to a new language, and in fact see the general "failure" of C#/CLR at MS (which, eg, is not being used by anything core in Vista) as a vindication of their choice to stay the course.
I was the Leopard Tech-talks in Toronto and sat through the talk about Xcode and Interface Builder 3.0. And i was impressed with the changes but i would hardly call it a grand strategy. The improvements make programming in Xcode seem even more convenient but it doesn't change, as mentioned in other comments, that objective-c is not a widely known language.
That said, i'm trying my hardest to learn it quickly...I am a Java programmer and i got to say i was disappointed that Apple dropped support for the java-bridge :( It was my quick start into cocoa programming and the easiest way to learn for me...
My life is alittle harder, but CoreData + Interface Builder are making my learning experience a pleasent one. I think that might be Apple's Strategy...make coding pleasent as opposed to completely mind-numbing, and tedious... :)
What were you expecting as the next logical step? Cheetah gave us the zero-code View, Panther the zero-code controller, and Tiger completed the zero-code MVC with the zero-code model.
So Apple moved on to other technologies to make developer's lives easier. Just as you don't have to write table controllers before, now you don't have to write controllers for animation.
You don't have to do your own memory management any more (either in Objective-C, or in Python or Ruby). As you mentioned, the developer tools are getting better all the time (which was the only thing Microsoft were really doing better).
I think Apple's strategy is "If you build it, they will come".
Post a Comment