views:

65

answers:

2

I am familiar with iOS programming, but I don't know where to put my logic when I start a Cocoa project for OS X. Are there any good online resources for transitioning to OS X from iOS?

EDIT:

Thanks for the help so far. My main question is where my code goes in the default template.

+1  A: 

Dive in.

Seriously just jump in with both feet. Find something that you want to make and just make it.

From what you've said you've already got a fair bit of experience with Objective-C and Cocoa and most things carry straight across.

James Raybould
He has experience with Cocoa Touch, not Cocoa, but yeah, most concepts seem (at least to me, as someone who doesn't use Cocoa Touch) pretty similar. The big difference is in table views.
Peter Hosey
@Peter I'd say the big difference is wrapping your brain around `NSCell` and friends...
Dave DeLong
+1  A: 

My main question is where my code goes in the default template.

Assuming a single-window app, I make a separate custom controller to own that window, and I have my app delegate own that controller.

So:

The app delegate

  • Owns the custom controller.
  • Creates it in applicationWillFinishLaunching: (note: not Did; I change this).
  • Releases it (and nils out the instance variable) in applicationWillTerminate:.
  • Does not own the primary window (I remove that ivar and all references to it).
  • Responds to applicationShouldTerminateAfterLastWindowClosed: with YES, so that the user can quit the application either by specifically quitting or by closing the primary window.
  • May also respond to application:openFile: or application:openFiles:, typically by passing the file(s) along to the controller to import or something.

The MainMenu nib

  • Owns the app delegate.
  • Does not contain the primary window (I remove the blank one).

The primary-window controller

  • Owns the primary window.
  • Owns the model displayed in the window.
  • Creates initial/empty model in init.
  • Loads the primary-window nib with itself as owner in init.
  • Closes and releases window (first) and releases model (second) and subordinate controllers (third) in dealloc.

The primary-window nib

  • Named similarly to the controller; e.g., “SnippetListController” for the controller and “SnippetList” for the nib.
  • Contains the primary window.
  • Primary window has “visible on launch” (really on nib load) turned on and “release when closed” turned off.

The advantage of all of this is that the lifetime of every object but the app delegate is clear and explicit, as is the area of responsibility. My app delegate is little more than that; the only thing it does that isn't specifically an app-delegate job is owning the primary-window controller. Likewise, the primary-window controller does nothing but own the primary window and whatever model I have to show in that window. And at quit time, everything but the app delegate gets deallocked.

For document-based apps, I stick pretty close to the template. I delete any template methods I don't need to customize, and I may switch one or both of the I/O methods to one of the other versions (e.g., from readFromData:ofType:error: to readFromURL:ofType:error:), and maybe delete the write method if I'm writing a viewer only; that's about it.

Peter Hosey
Thanks! I'll try this when I get back to my iMac on Monday.
Moshe
Sorry, I haven't had time yet. I will try to get to this soon.
Moshe