Joe, thank you for encouragement and the information you've provided! I do have the Objective-C Programming Language as a PDF and the printed book too, and I have a number of other books as well, which I'm kind of reading simultaneously, then re-reading until it sinks in. I'll go back and look over the MVC-model sections.
I have both editions of Aaron Hillgrass's book, and have read and re-read it many times. It wasn't until last week that things suddenly 'fell into place' and the code I was reading was making sense on a much deeper level. I have begun to simply play with Xcode, relying on the built-in documentation and the web to see if I could take an idea in my head and actually get it to work, rather than simply copy some code snippets from a book.
It's a good-sized project to start into Cocoa with, but I'm not a learner programmer... just a learner to Cocoa! I'd rather go into this with a goal that's challenging, yet brings great rewards when (I say 'when' not 'if'..!) I have managed to succeed at it.
My first goal (setting up a window in Interface Builder with controls, creating target/action links, then in XCode reading in a text file, and doing some simple search/replace on the text) has been a success! It's the first thing I've achieved in Cocoa without simply copying code from a book, and I'm so pleased and excited! I can see the reality of getting my project into Cocoa now and I don't want to look back!
You ask about the details of the application. I assume that attaching images to this list is a no no. If it's alright with you Joe, I was thinking of mocking up a diagram that shows the basic main elements of my program, and what it essentially does. Then I can list the few extra features that I'm expecting to add to the program once it's Cocoa-ized: things that I just can't get done in REALbasic. I thought I'd send this to you to have a look at. As I've said, I don't expect the answers, only some gentle nudging in the right direction.
I don't intend to burden the List with endless 'simple' questions and I'm very willing to work hard myself and not rely on the experience of others to provide answers: all I need is pointers to where to look and I'll do the work.
Thanks again for your help. I really appreciate it. Anyway enough rambling...
Welcome to Cocoa!
I trust you've read The Objective-C Programming Language and the
other relevant starter documentation on design? If not, now is a
great time to do so.
The best thing to do is not to design in terms of windows and
controls - Cocoa can be used for quick application development, but
it isn't a 'put the damn data on the damn screen' procedural RAD
tool. It uses a design paradigm called Model-View-Controller.
Further, Cocoa is an object-oriented framework which emphasizes
interactions between more-or-less autonomous objects, and not the
flow of data from one place to another. You program by sending
messages to objects. It's very easy for a new developer to start
shoving every bit of code into a "SomethingController"; stand guard
against that, and it was wise of you to notice the threat. But don't
make your divisions among arbitrary user interface lines.
That said, for each major mode of viewing your model data, you'll
likely want a separate controller. A controller is the part you've
seen already, the seemingly procedural part, that maps data from the
model to something a view can use, and input from the latter to
changes in the former. A controller is usually set to be the
'target' of various controls; when their actions fire, the
controller receives the message named by the selector set up in IB or
via setAction:.
Please remember that the GUI of a program is just one perspective on
its data, and GUI design should probably not drive the code's
design. (If you're looking for something that -should- drive you
wiki?TestDrivenDevelopment) can make for some excellent application
designs, especially when refactored post-facto towards various design
course want a unit testing framework like Sen:Te's OCUnit or ....
some other person's UnitKit{Sorry, author of UnitKit! I can't
remember your name!}.)
If you're at liberty to discuss particular details of your
application, that would be helpful for moving this discussion
someplace more concrete.
__joe
On Jun 2, 2005, at 08.29, Paul Harvey wrote:
<New Cocoa-developer alert!>
Hi all. I've been coding using REALbasic for years, and use PHP
with MySQL in my daily work. I'm all fired up to dig into Cocoa and
have been meaning to for a long time. Now i've started and seen
some positive results, I'm eager to build on my new-found knowledge.
I'm having difficulty working out where to place code. In
REALbasic, blocks of code usually sit with the relevant control.
For example, the Action method of a button holds the code that
would run when the button is clicked, or it would call a function
that did the work.
In Cocoa, controls send messages, so the method can know who called
it and ask the control/object for more info if required.
To the established Cocoa developers, how should I go about
organising my source code? I can see -- if I'm not careful -- one
file.m file becoming unmanageably long with all functions/methods
held in it. Should I just create different .h/.m files for
different parts of my application as I understand it? Or is it more
likely that each window created in Interface Builder has its
own .h/.m files so I should put the code in each of those?
Thanks for your help and patience.