Re: How to organize an app (baffled with Accessor methods)
Re: How to organize an app (baffled with Accessor methods)
- Subject: Re: How to organize an app (baffled with Accessor methods)
- From: mw <email@hidden>
- Date: Thu, 03 Oct 2002 07:10:48 -0400
On 10/3/02 1:00 AM, "email@hidden"
<email@hidden> wrote:
>
I realize this is probably a trivial question, but I am wondering what
>
the best (i.e. proper) way to organize an app would be. For example,
>
imagine a simple app. It consists of a window, 2 buttons (labeled
>
'next' & 'prev'), and a custom view. When you start the app, the custom
>
view draws a '0'. Click 'next' and it draws a '1'... that's all it does.
>
>
OK, so, I have my custom view class and I have my controller for the
>
window/buttons. What I'm stumped with is how to have a separate class
>
for my data. In the app I'm trying to build, I want to draw a calendar
>
and have the data for each calendar held in an array, and thus be
>
accessible by both the window controller (i.e. the buttons), and the
>
custom view controller (so it knows what to draw). My aim is to have
>
the calendar code in it's own controller/class to make things nice and
>
tidy.
>
>
I'm sure I could use a global array, but I keep hearing that I should
>
use accessors. I've bought all the cocoa books, and am a bit stumped as
>
of yet as to how to get this to work.
>
>
If you can imagine what I'm trying to do, I would be most grateful for
>
any advice or sample code.
Actually, you have a very good questions which MIGHT seem trivial to expert
Cocoa programmers, but that's just because they have been doing it for so
long.
It seems that you already know that you need a custom NSWindowController
subclass to control each document window (only one document window per
document in your case, correct?), so I won't really get into that very much.
Now what you need to do is create a normal class; subclass of NSObject. So a
sample class declaration would be:
@interface CalendarData : NSObject
{
}
@end
Then of course you go about declaring your instance (and class, if
applicable) methods and variables (and this is all in your CalendarData.h
file, or whatever you named it, in case you aren't sure). So, here comes
the part that you seem confused about.
Since you are storing calendar data, you would probably want an array of
NSCalendarDates (or NSDates, whatever you prefer). So, simply declare a new
NSMutableArray in the class' interface. Now, I don't know what else you want
in there, but here is a sample (with accessor methods and everything)
completed class of what I am talking about.
@interface CalendarData : NSObject
{
NSMutableArray myDates;
}
- (NSMutableArray)myDates; // This is the accessor method for
// the array. The name should remain
// the same as the array so you can use
// keu-coding in the future.
- (NSCalendarDate)myDatesWithIndex:(NSNumber *)index; // for getting a
// single date.
- (void)changeDateAtIndex:(NSNumber *)index value:(NSCalendarDate*)newDate;
// for changing a date at an index in the array
@end
Keep in mind that the sample class above will only work correctly if you
only need to store and access a single NSMutableArray which contains
NSCalendarDate objects. But you can build your custom class' model off of
this.
Now, to be able to have this class accessed by objects in a window (in a nib
file), you would need to have the header file in the nib file (don't
instantiate it) too. Don't put outlets to nib file objects in this file.
Other than that, just #import it into all of the other class' .m and .h
files where the information is needed (in your case, that would probably be
in the class files for your custom view and for your document window).
I hope that help you! If you have any further questions... Well, go ahead
and ask! ;-)
mw
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.