Re: User Interface linked to two classes
Re: User Interface linked to two classes
- Subject: Re: User Interface linked to two classes
- From: Conrad Shultz <email@hidden>
- Date: Fri, 09 Dec 2011 12:53:52 -0800
On 12/9/11 12:25 PM, Geoffrey Holden wrote:
> Thanks for this, Graham. I'll give this a go. To clarify though,
> I've got two classes - one which handles the view for a game, and the
> other which handles the scoring (amongst other things, this involves
> displaying a timer which shows how long game play has lasted).
>
> The game class updates its UI elements correctly. The scoring class
> (which uses the following code. timeElapsedField is only linked to
> the scoring class:
How are you instantiating the scoring class (which, as structured, could
be viewed as a controller)?
One mistake could be to instantiate a scoring class in IB (which is then
linked to timeElapsedField), but to create a different instance in code
(using [[alloc] init]), to which you are sending initializeCounters
(which in turn is firing updates that are going nowhere). One simple
test: in debug mode, when updateClock: runs, can you verify that
timeElapsedField is not nil? (Remember: sending a message to nil is
perfectly valid in Objective-C, but can mask all sorts of issues.)
Also, is it possible that updateClock: is running on a secondary thread?
This, too, will depend on how you instantiated your scoring class.
> - (void)updateClock:(NSTimer *)timer { NSCalendarDate *now =
> [NSCalendarDate calendarDate]; int hours, minutes, seconds; [now
> years:NULL months:NULL days:NULL hours:&hours minutes:&minutes
> seconds:&seconds sinceDate:startDate];
>
> [timeElapsedField setStringValue:[NSString
> stringWithFormat:@"%d:%d:%d", hours,minutes,seconds]]; }
As an aside, you are making a lot of assumptions about formatting here.
While I don't think that time formats vary across locales nearly as
much as date formats do, you still probably ought to be using an
NSDateFormatter to get localized strings for display. (If nothing else,
you gain forward compatibility for future changes will undoubtedly
implement.)
> If I understand you correctly, I need to have a controller class
> which handles updating the screen. That's fine for the simple timer,
> but could be rather tricky for the game view! I'm sure I didn't do
> it this way in the past - although, as you say, my technique might be
> (probably is, actually) very wrong.
A controller is just glue that connects the actual drawing mechanics
(typically drawRect: implemented in your own custom NSView subclass or
by Apple in one of the framework classes) and event handling to the
underlying model code (documents, game settings, etc.). As such, the
"scoring class" you excerpted IS a form of controller (though it does
look like it's storing some state - the start time - but arguably the
start time isn't really part of the model anyway).
Don't mix up the concept of a controller class with a concrete
NSxxxController subclass. To be sure, Apple has some self-described
controller classes (e.g. NSViewController, UIViewController, etc.) that
can be useful to subclass, but you certainly don't HAVE to do that to
implement a controller. (OK, it's probably foolish to implement a view
controller on iOS without using UIViewController, but I digress.)
> In debug, I can see that the updateClock code is getting executed.
Please see my comment about testing for nil above.
--
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden