Autolayout: Don’t Fight It

TaskLog is the first app I’ve developed which uses the new Cocoa Autolayout introduced in Mac OS 10.7 Lion.

I first used it in TaskLog’s log view, shown below:
Task Log screenshot

As you can see, there are quite a few UI elements in there. But all I did was put them where I wanted them, and Autolayout figured it all out. I didn’t have to configure a single thing, it all Just Worked™.

Now at some point I decided to make TaskLog’s main view resizable (so that the entire window resizes to perfectly fit the text of the current task). And that’s where Autolayout became a real headache. In this view, there are actually a lot of overlapping UI elements which are shown or hidden depending on what the state of the UI. For example, when you hit “Start a new task”, a bunch of the UI is hidden, and a text entry field and Start/Cancel buttons are displayed.

TaskLog main view screenshot2

Then when you hit Start, those are hidden and a bunch of other views are displayed.

TaskLog Main window screenshot

I wanted some of the views to be anchored to the bottom of the window, some to be anchored to the top, and a few to be anchored to both top and bottom and resize vertically. More importantly, Autolayout was having none of this. I spent an entire day adding my own constraints to try to get the behavior I was after, and in the end I wasn’t able to get it to work the way I wanted.

Then I had an epiphany: give up. It turns out that springs and struts can totally do what I needed to do in the main view UI; there was no compelling reason to use Autolayout. I turned it off, set up some springs and struts, and went on my merry way.

Now, don’t get me wrong, Autolayout is amazing. It allows you to do incredibly complicated layout with little to no effort. However, my advice is this: if you find yourself fighting Autolayout, stop and think about what you’re trying to do. If what you’re trying to accomplish can be done with springs/struts, and/or Autolayout isn’t making your life better, simply turn it off for that view.

The Autolayout session from last year’s WWDC is an awesome intro to Autolayout. I’d definitely recommend giving that a view if you haven’t already.

If you want to follow me, I’m @zpasternack on Twitter and on app.net.

VideoBuffet 1.0.2 released on the Mac App Store

This is a minor update, basically bug fixes. However, we did take the opportunity to convert it to Automatic Reference Counting (ARC). It really was as easy as it looked in the ARC WWDC session.

I highly recommend watching that video if you’re considering moving to ARC, as well as reading the Transitioning to ARC Release Notes, and the llvm ARC page. Bookmark that last page, because though it might be rough reading all the way through, it’s a very handy reference.

I had planned on posting some tips and tricks regarding converting to ARC, but truthfully, I don’t have any. It was simple, and pretty much just worked.

Don’t invalidate your NSTimer in dealloc

Seasoned Cocoa developers may snicker at the title of this post, because it’s probably obvious to them. It should have been obvious to me, but it wasn’t. Maybe I can save someone some head-scratching by relaying my tale.

NSTimers retain their target. Now, I’ve been around the Cocoa block a few times, so I knew this to be the case (the docs state it explicitly), but I clearly hadn’t thought through the ramifications. Walk with me for a minute.

Let’s say you have a window, MainWindow, and a controller class for it, MainWindowController. You put a timer on it to periodically do some stuff. It might look like this:

@interface MainWindowController : NSWindowController
{
    NSTimer* myTimer;
}
- (void) doSomeStuff;
@end

@implementation MainWindowController

- (id) initWithWindow:(NSWindow*)window
{
    self = [super initWithWindow:window];
    if( self ) {
        const NSTimeInterval timerInterval = 10.0f;
        myTimer = [NSTimer scheduledTimerWithTimeInterval:timerInterval
                    target:self
                  selector:@selector(doSomeStuff)
                  userInfo:nil
                   repeats:YES];
    }
    return self;
}

- (void) dealloc
{
    [myTimer invalidate], myTimer = nil;
    [super dealloc];
}

- (void) doSomeStuff
{
    NSLog( @"doing stuff" );
}

@end

Seems reasonable, no? It did to me. The problem is that, as the docs state, NSTimers retain their target. When you create that timer in initWithWindow:, it retains the window controller, which means dealloc will never be called. dealloc isn’t called until the controller’s retain count is zero, and until the timer invalidates (which will be never, on a repeating timer), the controller’s retain count will never be zero.

The solution would be to invalidate the timer elsewhere, perhaps in windowWillClose: (of course, your controller must also be the window’s delegate for that to happen).

- (void) windowWillClose:(NSNotification*)notification
{
    [myTimer invalidate], myTimer = nil;
}

Another thing I’d like to mention is the use of retainCount for debugging purposes. I’ve found that brand new Cocoa programmers tend to rely way too much on retainCount to try to figure out their memory management issues. Cocoa pros, on the other hand, will tell you to never ever call retainCount. You can’t get any useful information from it, some say, because you can’t know who’s retaining your objects.

I think the truth lies somewhere in between. The truth is, you should know who’s retaining your objects, and why. Though retainCount shouldn’t be the first thing you look to, it can be useful on occasion if it seems like things aren’t working as you expect.

In my case, I observed that calling initWithWindowNibName: on my window controller was returning an object with a retainCount of 2, when I was expecting 1. From there it was a pretty short walk to get to “ok, my timer is created here, but it’s invalidated in dealloc… oh, wait.”

If you want to follow me, I’m @zpasternack on Twitter and on app.net.

Regarding first responders: make, don’t become

Things That Were Not Immediately Obvious To Me, #27:

If you have a view which you wish to become first responder, do NOT call becomeFirstResponder on it; it doesn’t actually make the view first responder. Instead, call NSWindow’s makeFirstResponder:.

The NSResponder doc says (emphasis mine):

Use the NSWindow makeFirstResponder: method, not this method, to make an object the first responder. Never invoke this method directly.

This was not immediately obvious to me. Moral of the story: always read the damn docs.

Recapping:
[self becomeFirstResponder]; // Nope, never do that.
[[self window] makeFirstResponder:self]; // That’ll do, pig.

As a side note, the description of becomeFirstResponder says:

Notifies the receiver that it’s about to become first responder in its NSWindow.

and

The default implementation returns YES, accepting first responder status. Subclasses can override this method to update state or perform some action such as highlighting the selection, or to return NO, refusing first responder status.

OK, so can someone tell me why this method wasn’t named shouldBecomeFirstResponder? Had that been the case, I wouldn’t have had to resort to the docs to figure out why it wasn’t doing what I thought it should do. Just sayin’.

If you want to follow me, I’m @zpasternack on Twitter and on app.net.

Adventures in Redirection III: The Revenge

After the last two entries on output redirection (here and here, if you missed them), a few folks said, “Zach, this is a Cocoa blog; what’s up with all the crazy C++ junk?” Fair enough. The main reason is that this was what I needed for the particular project I’m working on. Another reason is that C++ is what I did (a lot) in my previous life, so hopefully you’ll forgive me if I occasionally run home to mama. :)

In any case, the core code is plain ole C, so I thought, why not make a Cocoa version also? So here we go. The walkthrough is basically the same as the original C++ version, so I won’t repeat it here.

@interface StandardOutputRedirector : NSObject
{
    int redirectionPipe[2];
    int oldStandardOutput;
    int oldStandardError;
    BOOL redirecting;
    NSMutableString* redirectedOutput;
}
- (void) startRedirecting;
- (void) stopRedirecting;
- (NSString*) output;
- (void) clearOutput;
@end

@implementation StandardOutputRedirector

enum { READ, WRITE };

#pragma mark - Memory Management

- (id) init
{
    if( (self = [super init]) ) {
        redirectedOutput = [[NSMutableString alloc] init];

        if( pipe( redirectionPipe ) != -1 ) {
            oldStandardOutput = dup( fileno(stdout) );
            oldStandardError = dup( fileno(stderr) );
        }
        setbuf( stdout, NULL );
        setbuf( stderr, NULL );
    }

    return self;
}

- (void) dealloc
{
    if( redirecting  ) {
        [self stopRedirecting];
    }

    if( oldStandardOutput > 0 ) {
        close( oldStandardOutput );
    }
    if( oldStandardError > 0 ) {
        close( oldStandardError );
    }
    if( redirectionPipe[READ] > 0 ) {
        close( redirectionPipe[READ] );
    }
    if( redirectionPipe[WRITE] > 0 ) {
        close( redirectionPipe[WRITE] );
    }

    [redirectedOutput release];

    [super dealloc];
}

#pragma mark - Public methods

- (void) startRedirecting
{
    if( redirecting ) return;

    dup2( redirectionPipe[WRITE], fileno(stdout) );
    dup2( redirectionPipe[WRITE], fileno(stderr) );
    redirecting = true;
}

- (void) stopRedirecting
{
    if( !redirecting ) return;

    dup2( oldStandardOutput, fileno(stdout) );
    dup2( oldStandardError, fileno(stderr) );
    redirecting = false;
}

- (NSString*) output
{
    const size_t bufferSize = 4096;
    char buffer[bufferSize];
    fcntl( redirectionPipe[READ], F_SETFL, O_NONBLOCK );
    ssize_t bytesRead = read( redirectionPipe[READ], buffer, bufferSize - 1 );
    while( bytesRead > 0 ) {
        buffer[bytesRead] = 0;
        NSString* tempString = [NSString stringWithCString:buffer encoding:NSUTF8StringEncoding];
        [redirectedOutput appendString:tempString];
        bytesRead = read( redirectionPipe[READ], buffer, bufferSize );
    }

    return [NSString stringWithFormat:@"%@", redirectedOutput];
}

- (void) clearOutput
{
    [redirectedOutput setString:@""];
}

@end

One thing I would note on the Cocoa version is that, this is intended for Mac OS X. I’ve not tried it on iOS, I’ve no idea if it would work, and I actually can’t think of a reason why you’d want to do it on iOS.

This Cocoa version (along with the original C++ implementation) is included with the sample project on github, here.

Adventures in Redirection, Part Deux

In the previous chapter, I showed how to redirect cout and cerr, and how it turns out that doing so does not also redirect stdout and stderr. As this turned out not to meet my requirements, I went in search of other methods.

In Googling around, the most common way to redirect stdout/stderr involves calling freopen on them. However, this didn’t work for me, for a few reasons. For one thing, freopen is really geared toward redirecting to a file. You can engage in a bit of trickery to redirect to memory instead, but I wasn’t really interested in going down that path. Worse, it’s completely irreversible; there’s no portable way to restore stdout/stderr once you redirect them via freopen. The ability to arbitrarily redirect and restore output was a must-have for me, so freopen couldn’t cut it.

I finally settled on a method which involves calling dup2 to duplicate the stdout/stderr file descriptors. In this way, you can redirect to one end of a pipe, then read from the other end whenever it’s convenient. More importantly, you can save off the old file descriptors so that you can restore them. Let’s get right to it. You might remember the IOutputRedirector interface from last time:

class IOutputRedirector
{
public:
            IOutputRedirector() {}
    virtual ~IOutputRedirector(){}

    virtual void StartRedirecting() = 0;
    virtual void StopRedirecting() = 0;

    virtual std::string GetOutput() = 0;
    virtual void        ClearOutput() = 0;
};

For our new class, we just need a couple of ints to hold our pipe file numbers, a couple of ints for the saved stdout/stderr file numbers, a bool to indicate that we’re redirecting, and a std::string which we redirect into.

class CStdoutRedirector : public IOutputRedirector
{
public:
            CStdoutRedirector();
    virtual ~CStdoutRedirector();

    virtual void StartRedirecting();
    virtual void StopRedirecting();

    virtual std::string GetOutput();
    virtual void        ClearOutput();

private:
    int    _pipe[2];
    int    _oldStdOut;
    int    _oldStdErr;
    bool   _redirecting;
    std::string _redirectedOutput;
};

In the constructor we create a pipe, and call dup to copy the stdout and stderr file descriptors, so that we can restore them later. The setbuf calls are there to disable buffering. stdout is typically line-buffered whilst stderr is typically unbuffered, resulting in the combined output not being properly interleaved otherwise.

CStdoutRedirector::CStdoutRedirector()
: IOutputRedirector()
, _oldStdOut( 0 )
, _oldStdErr( 0 )
, _redirecting( false )
{
    _pipe[READ] = 0;
    _pipe[WRITE] = 0;
    if( pipe( _pipe ) != -1 ) {
        _oldStdOut = dup( fileno(stdout) );
        _oldStdErr = dup( fileno(stderr) );
    }

    setbuf( stdout, NULL );
    setbuf( stderr, NULL );
}

The destructor does some cleanup (stopping the redirection and closing files).

CStdoutRedirector::~CStdoutRedirector()
{
    if( _redirecting ) {
        StopRedirecting();
    }

    if( _oldStdOut > 0 ) {
        close( _oldStdOut );
    }
    if( _oldStdErr > 0 ) {
        close( _oldStdErr );
    }
    if( _pipe[READ] > 0 ) {
        close( _pipe[READ] );
    }
    if( _pipe[WRITE] > 0 ) {
        close( _pipe[WRITE] );
    }
}

StartRedirecting is where part of the magic is. We call dup2 to copy the stdout and stderr file descriptors to the write end of our pipe. This is how the redirection works: after the dup2 calls, any writes to stdout/stderr go instead to the write end of our pipe.

void
CStdoutRedirector::StartRedirecting()
{
    if( _redirecting ) return;

    dup2( _pipe[WRITE], fileno(stdout) );
    dup2( _pipe[WRITE], fileno(stderr) );
    _redirecting = true;
}

StopRedirecting copies the stdout and stderr file descriptors back to the ones we saved in the constructor, resulting in restoring stdout/stderr.

void
CStdoutRedirector::StopRedirecting()
{
    if( !_redirecting ) return;

    dup2( _oldStdOut, fileno(stdout) );
    dup2( _oldStdErr, fileno(stderr) );
    _redirecting = false;
}

GetOutput is where the rest of the magic lies. We call fcntl to set the read end of our pipe to nonblocking mode (otherwise the read call will block if the pipe is empty). Then we call read in a loop into a little temporary buffer, NULL terminate it, and append it to a string, which we then return.

string
CStdoutRedirector::GetOutput()
{
    const size_t bufSize = 4096;
    char buf[bufSize];
    fcntl( _pipe[READ], F_SETFL, O_NONBLOCK );
    ssize_t bytesRead = read( _pipe[READ], buf, bufSize - 1 );
    while( bytesRead > 0 ) {
        buf[bytesRead] = 0;
        _redirectedOutput += buf;
        bytesRead = read( _pipe[READ], buf, bufSize );
    }

    return _redirectedOutput;
}

ClearOutput simply clears out the string.

void
CStdoutRedirector::ClearOutput()
{
    _redirectedOutput.clear();
}

There is one caveat to this method: if the internal buffer fills up, subsequent output (printf, for example) will block until space is freed up in the buffer. This buffer appears to be 16k in size, though I imagine it varies depending on OS. So basically, if you intend to redirect more than 16k at once. well… that won’t work. Calling GetOutput clears the buffer out, so call it often, if you can.

I was thinking that supplying my own larger buffer via setvbuf() would help, but it turns out not to. If anyone has any ideas on how to make this better, let me know. I would also point out that I’ve not used this in production code (I am using it in the project I’m working on now, and it seems to be working perfectly; we just haven’t shipped it yet).

I’ll put the full source and sample project up on github when I have a spare few minutes. Update: Full source and sample project are on github, here.

If you want to follow me, I’m @zpasternack on Twitter and on app.net.

The rest of us need to be smarter

This made me simultaneously amused and angered. There’s probably nothing more to be said that hasn’t already been so in comments there and on Reddit. Still, I can’t help but put my $0.02 in.

I don’t know anything about construction, except that it’s hard. To build a house, you need to pour concrete, nail boards together, put up drywall, and a bunch of other things. That’s all hard. If only I had a robot that could do all those things for me… I still couldn’t build a house. Why? Because I also don’t know anything about architecture or structural engineering, or plumbing, or electrical engineering. I’d be lucky to build something that didn’t fall down, and it almost certainly wouldn’t be fit for habitation.

When people say “programming”, they think of the mechanical act of typing stuff into a computer. But that’s really only a tiny fraction of what a programmer does. If you don’t have a reasonable understanding of the innerworkings of computers; if you don’t have the capacity to break a large problem down into ever smaller problems; if you don’t have the ability to visualize every minute detail of a solution; no programming language will enable you to write decent software. That’s all there is to it.

Do you guys remember HyperCard? AppleScript? Prograph CPX? Dare I say it, Visual BASIC? All attempts to make a programming language for non-programmers. And every time one of these hot new “languages for the rest of us” come out, I polish up my résumé. Because once everyone realizes that’s programming is still hard, I get a bunch of new job offers. Best case, all it means is we’re momentarily awash in software written by people who have no business doing so.

That’s not me being elitist. I want to live in a world where everyone has the capacity to create great software, I truly do. I just don’t see it happening in my lifetime.

those who know it have little interest in simplifying it as it devalues their own knowledge.

Bitch, please. The guy that’s able to engineer a programming language which enables non-programmers to create great software will instantly become ludicrously rich, not to mention ushering in a golden era of information technology. If you believe for one second that some of the smartest people on the planet aren’t working on this right now – haven’t been working on this for decades – you are sorely mistaken.

Do you have any musician friends? Go up to one and tell him you tried to play guitar today, and it was hard. Why don’t they make instruments that are easier to play? Let me know how that works out for you.

Any four-year-old of even average intellect has sufficient command of their native language to successfully convey any idea of which they conceive. That no four-year-old has ever won the Pulitzer Prize is proof of the failure of the English language. Clearly what is needed is an easier to use spoken language.

If you want to follow me, I’m @zpasternack on Twitter and on app.net.

stdout and stderr: Adventures in Redirection, Part 1

For a project I’m working on, I needed to redirect the standard output and standard error of a subprocess I’m launching. While it’s trivial to do this with NSTask (just send it setStandardOutput: and setStandardError:), I had some unique requirements that precluded this. Mainly, I didn’t want the process’ stdout/stderr redirected for its entire lifespan. Rather, I wanted it to redirect only certain parts, and return that data to the GUI through a separate mechanism (a named pipe).

So, what I wanted was to be able to was:

  1. Enable/disable the redirection at any point, while the process is running (this more or less precludes freopen– based solutions, as there’s no portable way to restore the streams once they’re reopened).

  2. Be able to retrieve and clear the redirected output at any time, regardless of whether redirection is enabled or not.

  3. stdout and stderr must both be redirected to the same buffer, and properly interleaved.

  4. The helper app (the app that has this code) is written in C++; no Cocoa, no Objective-C.

Based on those requirements, I wrote the following unit test to determine what my interface should look like.

int RedirectorTest()
{
    IOutputRedirector theRedirector;
    std::cout << "This is not redirected" << std::endl;

    theRedirector.StartRedirecting();
    std::cout << "This is redirected";
    assert( theRedirector.GetOutput() == "This is redirected"
        && "cout not redirected!" );
    theRedirector.ClearOutput();
    assert( theRedirector.GetOutput().length() == 0
        && "redirector not cleared" );

    std::cerr << "Redirected Error";
    assert( theRedirector.GetOutput() == "Redirected Error"
        && "cerr not redirected" );
    theRedirector.ClearOutput();
    assert( theRedirector.GetOutput().length() == 0
        && "redirector not cleared" );

    theRedirector.StopRedirecting();
    std::cout << "This is also not redirected";
    assert( theRedirector.GetOutput().length() == 0
        && "redirection not stopped!" );

    theRedirector.StartRedirecting();
    std::cout << "cout";
    std::cerr << "cerr";
    std::cout << "cout again";
    std::string output = theRedirector.GetOutput();
    assert( theRedirector.GetOutput() == "coutcerrcout again"
        && "cout, err not interleaved properly" );

    return 0;
}

Based on that test I wrote the following interface I’d use for my test class:

class IOutputRedirector
{
public:
               IOutputRedirector() {}
    virtual    ~IOutputRedirector(){}

    virtual void    StartRedirecting() = 0;
    virtual void    StopRedirecting()  = 0;

    virtual std::string GetOutput()    = 0;
    virtual void        ClearOutput()  = 0;
};

I Googled around for various techniques on how to do this, and the most promising one involved calling rdbuf on the cout and cerr streams. In this way, you can specify a different streambuf, and I use that of an ostringstream. It looks a little somethin’ like this:

class CCoutRedirector : public IOutputRedirector
{
public:
            CCoutRedirector();
    virtual ~CCoutRedirector();

    virtual void    StartRedirecting();
    virtual void    StopRedirecting();

    virtual std::string GetOutput();
    virtual void        ClearOutput();

private:
    std::streambuf* m_pOldCoutStreamBuf;
    std::streambuf* m_pOldCerrStreamBuf;
    std::ostringstream m_stream;
};

CCoutRedirector::CCoutRedirector()
: IOutputRedirector()
, m_pOldCoutStreamBuf( NULL )
, m_pOldCerrStreamBuf( NULL )
{
}

CCoutRedirector::~CCoutRedirector()
{
    StopRedirecting();
}

void
CCoutRedirector::StartRedirecting()
{
    if( m_pOldCoutStreamBuf != NULL ||
        m_pOldCerrStreamBuf != NULL )
    {
        return;
    }

    m_pOldCoutStreamBuf = std::cout.rdbuf();
    m_pOldCerrStreamBuf = std::cerr.rdbuf();

    streambuf* newOutbuf = m_stream.rdbuf();
    cout.rdbuf( newOutbuf );
    cerr.rdbuf( newOutbuf );
}

void
CCoutRedirector::StopRedirecting()
{
    if( m_pOldCoutStreamBuf != NULL )
    {
        cout.rdbuf( m_pOldCoutStreamBuf );
        m_pOldCoutStreamBuf = NULL;
    }

    if( m_pOldCerrStreamBuf != NULL )
    {
        cerr.rdbuf( m_pOldCerrStreamBuf );
        m_pOldCerrStreamBuf = NULL;
    }
}

string
CCoutRedirector::GetOutput()
{
    return m_stream.str();
}

void
CCoutRedirector::ClearOutput()
{
    m_stream.str("");
}

It’s pretty self explanatory. StartRedirecting saves off the old cout and cerr’s streambufs, and replaces them with that of our own ostringstream. GetOutput returns the string from that stream; ClearOutput clears it, and finally, StopRedirecting restores the previous streambufs. Easy as pi.

With the test I wrote above this works flawlessly. There’s only one major issue, as I later discovered: while this works for cout and cerr, it does NOT work for stdout and stderr in general. Meaning, calls to printf will not be redirected. I’d not realized that stdout and cout weren’t synonymous. For me this was a deal-breaker, but perhaps others will find it useful.

In the next post I’ll show the technique I ended up using, that works for stdout/stderr as well as cout/cerr.

If you want to follow me, I’m @zpasternack on Twitter and on app.net.

Stuff I Can’t Live Without Part I: conditional NSLogging

I spend a great deal of time watching my code. By that I mean either stepping through it in the debugger, or reading logs generated by it to see what it’s done. You might think you know exactly what your software is doing, but the truth is, if you don’t watch it run, you don’t know.

During the course of development, I usually end up adding a fair amount of logging code, and of course I don’t want that in my production builds. So a while back I went a-Googling for some conditional NSLog calls, and found these great macros, courtesy of Nick Dalton’s iPhoneIncubator. I use them (and repeat them below) nearly verbatim. This is the first thing I add to any project I’m working on. I’m naked without my DebugLog (and not in the good way).

// DebugLog is almost a drop-in replacement for NSLog
// DebugLog();
// DebugLog(@“here”);
// DebugLog(@“value: %d”, x);
// Unfortunately this doesn’t work: DebugLog(aStringVariable); you have to do this instead: DebugLog(@“%@“, aStringVariable);
// Shamelessly stolen (and edited) from http://iphoneincubator.com/blog/debugging/the-evolution-of-a-replacement-for-nslog

#ifdef DEBUG
    #define DebugLog(fmt, ...) NSLog((@“%s:%d “ fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
    #define DebugLogFunc() NSLog( @“%s:%d”, __PRETTY_FUNCTION__, __LINE__ );
#else
    #define DebugLog(...)
    #define DebugLogFunc()
#endif

// AlwaysLog always displays output regardless of the DEBUG setting
#define AlwaysLog(fmt, ...) NSLog((@“%s:%d “ fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);

Of course this assumes you have DEBUG #defined in your debug builds somewhere (in Xcode 4 do this in Preprocessor Macros in Build Settings).

The only changes I made over Nick’s is renaming them (I prefer clarity over brevity), minor formatting, and adding the …Func macros for the common (for me) case of simply outputting the function name with no further description. This is useful for making sure the functions you expect to get called, really are.

If you want to follow me, I’m @zpasternack on Twitter and on app.net.