Professional Web Applications Themes

Considering Cocoa Books - Mac Programming

I'm not doing well with the existing doentation that comes with Xcode. I've also found the currency converter app tutorial to be too trivial as a how to get started for writing cocoa apps in Objective-C. I'm wondering if it would be worth my money to invest in some books. Here are some: http://www.oreilly.com/catalog/buildcocoa/ http://www.oreilly.com/catalog/learncocoa2/ I am running Panther and Xcode 1.1. Back in the day, I learned Win16 programming from Petzold's book. Once I had the basics down, it was no huge deal to learn Win32. I never got into MFC. The Apple doentation is probably just fine as ...

  1. #1

    Default Considering Cocoa Books

    I'm not doing well with the existing doentation that comes with
    Xcode. I've also found the currency converter app tutorial to be too
    trivial as a how to get started for writing cocoa apps in
    Objective-C. I'm wondering if it would be worth my money to invest
    in some books. Here are some:

    http://www.oreilly.com/catalog/buildcocoa/
    http://www.oreilly.com/catalog/learncocoa2/

    I am running Panther and Xcode 1.1.

    Back in the day, I learned Win16 programming from Petzold's book.
    Once I had the basics down, it was no huge deal to learn Win32. I
    never got into MFC.

    The Apple doentation is probably just fine as a reference. It
    just doesn't seem to be helpful as a getting started guide. It is
    too scattered.

    Any recomendations?

    Thanks.

    --
    One Emacs to rule them all. One Emacs to find them,
    One Emacs to take commands and to the keystrokes bind them,

    All other programming languages wish they were Lisp.
    David Guest

  2. #2

    Default Re: Considering Cocoa Books

    There will be lots of preferences but my personal favorite for learning
    Cocoa well is Cocoa Recipes For Mac OS X: The Vermont Recipes by Bill
    Cheeseman. When I got done using his book like a tutorial, I felt like
    I had a pretty good handle on cocoa programming and had learned a fair
    amount about program struturing to boot.

    Another book that will get a lot of recommendations is Anguish, Buck,
    and Yacktman's Cocoa Programming which is more of a reference; it is
    not a tutorial. Garfinkel and Mahoney's book (the first of the two you
    list below) has also been reviewed well.

    I would also pick up a copy of Cocoa in a Nutshell from O'Reilly. This
    is just a quick reference listing the classes and methods but it makes
    wandering through the doentation easier. There is no non-electronic
    complete reference and probably cannot be; Cocoa is simply too fluid
    and too large. However, I would put a copy of Cocoa Browser on my
    system for use while coding rather than relying soley on xCode's
    doentation viewer.

    Note that all of the books will be based on using ProjectBuilder but
    that really isn't a problem.

    Spence

    In article <com>, David Steuber
    <net> wrote:
     
    James Guest

  3. #3

    Default Re: Considering Cocoa Books

    In article <060120040659262093%net>,
    James Spencer <net> wrote:
     

    I'm reading an early version of The Vermont Recipes now. He says
    (paraphrased):

    ---------

    To add a control to a window is a 12 step process (and this doesn't
    include appleScript support):

    * Use Interface Builder to draw the control

    * Add outlet variables and accessor methods to the window controller

    * Add a data object and accessors methods to your model object so the
    value represented by the control can be accessed. The set method will
    also register a change with the undo manager.

    * Declare a notification variable in the model object so it can notify
    the window controller when the data changes

    * Add a GUI update method to the window controller to update the visible
    state of the control in response to a notification that the model has
    changed

    * Register the window controller as a notificaton observer so it will
    receive notification that the data has changed.

    * Add an action method to the window controller to change the data in
    the model when the user clicks the control

    * Update the file "localizable.strings" with the ne undo and redo menu
    commands.

    * Initialize the model object member to a default value in the model
    object's preferred initializer

    * Add keys and revise methods to save and retieve the data to the
    doent or the preferences

    * Add an invocation of the control updater to the window controller's
    updateWindow method

    * In Interface Builder, re-read the revised header files and draw
    connections for the new outlets and actions, and any required delegat
    connections.

    ---------


    To me, this seems like a lot of manual steps just to add a control to a
    program, and that still doesn't cover properly adding the appropriate
    text to the program's appleScript dictionary. Is the above just
    old-fashioned, and is there now an easier way to do it?

    In MFC (Microsoft Foundation Class Library on MS-Windows), you'd draw
    the control with drawing tools integrated in to the IDE, then with the
    "ClassWizard" menu command, you select the controls ID from a popup
    menu. Class Wizard names the control with an enum (you can override the
    name), names a variable for you (you can override), and edits your .h &
    ..cpp files for you to declare, define, and wire it up. Add the lines ar [/ref]
    i/o. Three steps, not twelve.

    If there is no good way to make this easy, what would it take to extend
    Interface Builder/XCode (or for that matter Constructor/Metrowerks) to
    make it easy?
    David Guest

  4. #4

    Default Re: Considering Cocoa Books

    It's actually much simpler. The vermont recipes book lists a lot of
    stuff that isn't needed for every case (or most of them, actually).

    For example, to add a button to a window:
    1. Draw the button
    2. Add a method to call when the button's clicked (you can add these,
    called "actions", via the GUI) to the class backing the NIB.
    3. Control-drag from the button to the class backing the nib. Select
    the method you just added.

    That's about it.

    David Phillip Oster <org> wrote in message news:<sf.sbcglobal.net>... 
    >
    > I'm reading an early version of The Vermont Recipes now. He says
    > (paraphrased):
    >
    > ---------
    >
    > To add a control to a window is a 12 step process (and this doesn't
    > include appleScript support):
    >
    > * Use Interface Builder to draw the control
    >
    > * Add outlet variables and accessor methods to the window controller
    >
    > * Add a data object and accessors methods to your model object so the
    > value represented by the control can be accessed. The set method will
    > also register a change with the undo manager.
    >
    > * Declare a notification variable in the model object so it can notify
    > the window controller when the data changes
    >
    > * Add a GUI update method to the window controller to update the visible
    > state of the control in response to a notification that the model has
    > changed
    >
    > * Register the window controller as a notificaton observer so it will
    > receive notification that the data has changed.
    >
    > * Add an action method to the window controller to change the data in
    > the model when the user clicks the control
    >
    > * Update the file "localizable.strings" with the ne undo and redo menu
    > commands.
    >
    > * Initialize the model object member to a default value in the model
    > object's preferred initializer
    >
    > * Add keys and revise methods to save and retieve the data to the
    > doent or the preferences
    >
    > * Add an invocation of the control updater to the window controller's
    > updateWindow method
    >
    > * In Interface Builder, re-read the revised header files and draw
    > connections for the new outlets and actions, and any required delegat
    > connections.
    >
    > ---------
    >
    >
    > To me, this seems like a lot of manual steps just to add a control to a
    > program, and that still doesn't cover properly adding the appropriate
    > text to the program's appleScript dictionary. Is the above just
    > old-fashioned, and is there now an easier way to do it?
    >
    > In MFC (Microsoft Foundation Class Library on MS-Windows), you'd draw
    > the control with drawing tools integrated in to the IDE, then with the
    > "ClassWizard" menu command, you select the controls ID from a popup
    > menu. Class Wizard names the control with an enum (you can override the
    > name), names a variable for you (you can override), and edits your .h &
    > .cpp files for you to declare, define, and wire it up. Add the lines ar [/ref]
    > i/o. Three steps, not twelve.
    >
    > If there is no good way to make this easy, what would it take to extend
    > Interface Builder/XCode (or for that matter Constructor/Metrowerks) to
    > make it easy?[/ref]
    Lally Guest

  5. #5

    Default Re: Considering Cocoa Books

    To be more precise, the Vermont Recipes book makes you do all these
    steps when you not only want to add a control to a window but also want
    to have that control change the data in the model and have the
    interface reflect changes in the model. The long list includes not
    only what you have to do add a control to the interface but what you
    have to do to add a new data element to the model and to read and write
    that data element to a file.

    There are a lot of examples in the book which don't require all of the
    steps. The point here is that while your three steps add a working
    button to the interface, you aren't comparing apples and apples in that
    your button certainly won't do much to anything more than the most
    trivial of data models. Cocoa Recipes gives you a complete outline of
    what you need to do in the generalized case where you actually want to
    change the data.

    Spence

    In article <google.com>, Lally
    Singh <com> wrote:
     
    > >
    > > I'm reading an early version of The Vermont Recipes now. He says
    > > (paraphrased):
    > >
    > > ---------
    > >
    > > To add a control to a window is a 12 step process (and this doesn't
    > > include appleScript support):
    > >
    > > * Use Interface Builder to draw the control
    > >
    > > * Add outlet variables and accessor methods to the window controller
    > >
    > > * Add a data object and accessors methods to your model object so the
    > > value represented by the control can be accessed. The set method will
    > > also register a change with the undo manager.
    > >
    > > * Declare a notification variable in the model object so it can notify
    > > the window controller when the data changes
    > >
    > > * Add a GUI update method to the window controller to update the visible
    > > state of the control in response to a notification that the model has
    > > changed
    > >
    > > * Register the window controller as a notificaton observer so it will
    > > receive notification that the data has changed.
    > >
    > > * Add an action method to the window controller to change the data in
    > > the model when the user clicks the control
    > >
    > > * Update the file "localizable.strings" with the ne undo and redo menu
    > > commands.
    > >
    > > * Initialize the model object member to a default value in the model
    > > object's preferred initializer
    > >
    > > * Add keys and revise methods to save and retieve the data to the
    > > doent or the preferences
    > >
    > > * Add an invocation of the control updater to the window controller's
    > > updateWindow method
    > >
    > > * In Interface Builder, re-read the revised header files and draw
    > > connections for the new outlets and actions, and any required delegat
    > > connections.
    > >
    > > ---------
    > >
    > >
    > > To me, this seems like a lot of manual steps just to add a control to a
    > > program, and that still doesn't cover properly adding the appropriate
    > > text to the program's appleScript dictionary. Is the above just
    > > old-fashioned, and is there now an easier way to do it?
    > >
    > > In MFC (Microsoft Foundation Class Library on MS-Windows), you'd draw
    > > the control with drawing tools integrated in to the IDE, then with the
    > > "ClassWizard" menu command, you select the controls ID from a popup
    > > menu. Class Wizard names the control with an enum (you can override the
    > > name), names a variable for you (you can override), and edits your .h &
    > > .cpp files for you to declare, define, and wire it up. Add the lines ar 
    > > i/o. Three steps, not twelve.
    > >
    > > If there is no good way to make this easy, what would it take to extend
    > > Interface Builder/XCode (or for that matter Constructor/Metrowerks) to
    > > make it easy?[/ref][/ref]
    James Guest

  6. #6

    Default Re: Considering Cocoa Books

    I get the feeling I'm going to be spending a lot of time in the
    debugger to find out what things are called and when (or if they are
    not called at all).

    A basic do nothing app built with Xcode is very good at hiding the
    details of the event loop and how message/event dispatching works.

    I've copied all the examples to my home directory so that I can look
    at them as needed. Is there one that comes close to something like
    this:

    Open the main window
    Create an image (NSImage?) to be drawn on by the program
    Spawn off a seperate thread to draw individual pixels
    Use a timer to update the display in the main window every few
    seconds or so to show progress of the drawing
    grab the pixel coordinates of a mouse click of the displayed image.

    I do not know what if any thread synchronization has to be done
    between the slave thread that is drawing on the same image that is
    being displayed by the main thread. I want the second thread because
    the computation is lengthy and I want it to run as fast as possible
    without interfering with user events like clicking on a button to
    stop the process.

    What I really need is a big picture of Cocoa so that I know why I am
    doing what I am doing. A cook book may feel too much like casting
    spells.

    --
    One Emacs to rule them all. One Emacs to find them,
    One Emacs to take commands and to the keystrokes bind them,

    All other programming languages wish they were Lisp.
    David Guest

  7. #7

    Default Re: Considering Cocoa Books

    The first step is to actually learn the framework. Cocoa Recipes is a
    tutorial more than a cookbook despite it's name (it works fairly well
    as a cookbook afterwards but that's still not what I would describe it
    as).

    If you work through it it will give you the big picture but in the end,
    using a framework like Cocoa is like casting spells. You are not going
    to know how all of this works and frankly don't need to do so. In your
    case, you need to become familiar with certain classes that do certain
    things like threads.

    In article <com>, David Steuber
    <net> wrote:
     
    James Guest

  8. #8

    Default Re: Considering Cocoa Books

    David Steuber wrote: 

    I'm currently working my way through "Cocoa Programming
    for Mac OS X" and I'm finding it very good and useful.
    It was written for OS X 10.2 and Project Builder (which is
    what I'm using.) See:

    http://www.bignerdranch.com/products/cocoa1.shtml

    Ashley.

    Ashley Guest

  9. #9

    Default Re: Considering Cocoa Books

    James Spencer <net> writes:
     

    Ok. Put this way, this does indeed sound like a book to look at.
     

    The big picture is what is most important to me. Once I have that
    down, I can always divine the spell components if I do turn out to
    need them ;-)

    There is some balance between knowing how to write a program quickly
    and not needlessly burning up compute cycles when it runs. It's like
    knowing to use a quick sort rather than a bubble sort. You don't
    need to know how the quick sort really works (although you should).
    It is often enough to know that it is the faster approach.

    In Cocoa terms, some classes are better suited for X than others
    while others may be better suited for Y given that the classes are
    similar enough that you can pick several to do X or Y.

    Thanks for the advice.

    --
    One Emacs to rule them all. One Emacs to find them,
    One Emacs to take commands and to the keystrokes bind them,

    All other programming languages wish they were Lisp.
    David Guest

  10. #10

    Default Re: Considering Cocoa Books

    I have both the Vermont Recipes and the Anguish book. I recommend them
    both. But if you can only buy one, I'd get the Vermont book.

    I started this about a month ago. I am an experienced Mac and Java
    programmer, but had avoided Cocoa for a while due to productivity
    concerns (didn't "have time" to learn yet-another-class-library).

    Anyway, current contract required Cocoa. I had a very specific app
    that I needed (which is nothing like the Vermont demo), and was able
    to apply virtually everything in the book in 125 pages. Very clear on
    all the "magic incantations" to get a project actually done. All the
    stuff I had learned the hard way with ResEdit & Codewarrior & Visual
    Studio in 125 pages. Not too bad, actually.

    There is one thing you might not understand - I sure didn't - and that
    is as you're putting the application together, you "code" just as much
    in Interface Builder ("IB") as you do in source code. To really get
    the hang of it, you need to create the classes in IB, and link them
    together with the interfaces and other parts. You can have IB generate
    code, if you wish.

    There are still a few things I don't get, but my app is largely done
    except printing (ARGH!), and works quite well.

    Also, if you have Java experience, you will feel right at home. It is
    quite clear that JFC and Swing were "inspired" by NExtStep. If you
    don't understand the MVC paradigm, your job will be harder.

    Hope this helps.

    Neil

    nlexcom
    Neil Guest

  11. #11

    Default Re: Considering Cocoa Books

    On 2004-01-07 14:23:42 +0000, Ashley Sanders
    <acy.ukz.notvalid> said:
     
    >
    > I'm currently working my way through "Cocoa Programming
    > for Mac OS X" and I'm finding it very good and useful.
    > It was written for OS X 10.2 and Project Builder (which is
    > what I'm using.) See:
    >
    > http://www.bignerdranch.com/products/cocoa1.shtml
    >
    > Ashley.
    >
    >[/ref]

    I too am reading this book; "Cocoa Programming for Mac OS X"

    I'm totally new to Cocoa and programming for Mac. I've done simple C++
    Console Applications before on Windows as well as some basic VB stuff.

    I've also programmed some more advanced PHP/MySQL programs.

    After reading this book for a few hours, I've already managed to port over
    one of my old College programs from VB. Although a simple program, by
    porting it over, it's let me see how Cocoa works in comparison to VB and
    therefore I now know how to work with it.

    It seems hopeful that this will be the book that gets me through Cocoa.
    Dave Guest

Similar Threads

  1. Cocoa + Xcode + GMP = What the?
    By M in forum Mac Programming
    Replies: 11
    Last Post: November 22nd, 11:46 PM
  2. Bit shifts in Cocoa
    By Korbin Meiser in forum Mac Programming
    Replies: 2
    Last Post: September 11th, 01:11 AM
  3. Q About Cocoa & CF Prefs..
    By David Phillip Oster in forum Mac Programming
    Replies: 2
    Last Post: July 31st, 12:04 PM
  4. Cocoa Filemaker
    By Olly Groves in forum FileMaker
    Replies: 2
    Last Post: July 25th, 01:55 AM
  5. [Cocoa] Bug with NSTableView?
    By Mark Bee in forum Mac Programming
    Replies: 1
    Last Post: July 7th, 07:38 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139