Re: [TFUI] Re: UI Guidelines and Acceptance Testing

On Jul 24, 2004, at 11:56 AM, Phlip wrote:
> Chris Hanson wrote:
>
>> You don't need to bother with event-driven
>> programming in Cocoa.
>
> What do you hear when I say "event driven"?

Well, in the past, I've heard you talk about "not running your main 
event loop" and "sending events to the window yourself."  And I've also 
done extensive development for both the Mac Toolbox and Carbon, which 
are entirely event-driven.

In Toolbox code, you have a main loop that calls WaitNextEvent and then 
handles whatever event comes in, dispatching it appropriately; you 
might have a framework like PowerPlant or MacApp doing this for you, 
but it's still being done.

In Carbon you can work like that for compatibility purposes or you can 
use Carbon Events.  These are higher-level events generated by 
interface components that you install handlers for; they're similar to 
Windows messages in that respect.  You still install handlers for 
events like "user clicked this button" and "user input this character" 
though -- relatively low-level events.

In Cocoa, you define action methods in your controller classes and wire 
up the in Interface Builder.  The controls themselves handle clicks, 
typing, etc. and invoke your action methods as appropriate.  You can 
also wire actions to the First Responder, in which case the responder 
chain will be automatically searched for the first object that can 
actually handle a particular action at the time the action is invoked.

>> Most people writing Cocoa applications use Interface
>> Builder -- the
>> "form painter" as you call it -- to build most of
>> their application's
>> interface.  That's because it's really a system for
>> wiring up,
>> archiving, and unarchiving fully wired-up object
>> graphs.  It's not a
>> code generator, it saves you from writing reams of
>> boring code just to
>> put up windows, connect controls to controllers,
>> etc.
>
> To review esthetic details of run-time generated
> behavior, don't run the finished app. Put another way,
> don't let a healthy and full-featured form painter
> detract from the importance of your reveal() test
> fixture.

I'm not sure what you mean by this.  Can you please explain it more 
fully?

It's trivial to instantiate (say) an NSWindowController subclass, get 
the window associated with it (which will load the controller's nib -- 
interface definition -- file, if it has one, and wire that up), and 
examine the window and the controls within it.  All without displaying 
a thing.

   - (void)testWindowLayout {
       MyWindowController *controller = [[[MyWindowController alloc]
                        initWithWindowNibName:@"MyWindow"] autorelease];

       NSWindow *window = [controller window];
       STAssertNotNil(window,
                      @"Window must not be nil.");

       textField = [controller myTextField];
       STAssertNotNil(textField,
                      @"Text field outlet must be connected.");
       STAssertEquals([textField target], controller,
                      @"Text field must have the controller as its 
target.");
       STAssertEquals([textField action], @selector(doSomething:),
                      @"Text field must have the -doSomething: aciton.");
   }

And so on.  That will cause everything to be loaded and wired up, and 
nothing to be displayed.  The STAssert... calls are from one of the 
Cocoa testing frameworks I've used, OCUnit; once set up, it will run 
all the test... methods in every subclass of SenTestCase every time you 
build.

>> The Cocoa tutorials lead people to Interface Builder
>> quickly because
>> Interface Builder is what professional Cocoa
>> developers use to lay out
>> their applications' interfaces.  It's not a newbie
>> tool that gets
>> outgrown.  You can of course write code to generate
>> interfaces.
>> Interface Builder isn't doing anything that you
>> can't do in your own
>> code.
>
> The majority of esthetic details - the ones not
> generated by internal logic - should be painted.

By "painted" do you mean "created in an interface design tool" rather 
than "hard-coded"?

   -- Chris

-- 
Chris Hanson <[email protected]>
http://www.livejournal.com/users/chanson/



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
    TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/