Ben Scheirman

These fickle bits...


When viewWillAppear: Isn’t Called

The UIViewController lifecycle is pretty simple. viewDidLoad is called when the view is loaded (usually from a XIB) and when the view controller’s view is about to be displayed viewWillAppear: gets called (and viewWillDisappear: when it goes away).

The problem is, when you have a non-standard view hierarchy (like my current app) these methods don’t get called. The Apple docs have this to say about the problem:

Warning: If the view belonging to a view controller is added to a view hierarchy directly, the view controller will not receive this message. If you insert or add a view to the view hierarchy, and it has a view controller, you should send the associated view controller this message directly. Failing to send the view controller this message will prevent any associated animation from being displayed.

In my application I have a persistent bar at the bottom of the screen, so my UINavigationController only owns a portion of the screen. Thus, my RootViewController (which owns these 2 portions) is always active.

I recently came upon a requirement that needed to leverage viewWillAppear: and viewWillDisappear: in order to decorate the bottom bar with some additional information. Since this is a view controller a few layers deep in the hierarchy, the methods weren’t being called.

Luckly, there is a fix to this. The navigation controller can notify its delegate when it changes view controllers.

Start off in the view controller that is the root of the navigation controller hierarchy. Make it conform to the UINavigationControllerDelegate protocol. We’ll also need an ivar to store the last view controller that appeared so that we can notify when it disappears.

@interface MyRootViewController : UIViewController
    <UINavigationControllerDelegate> {
      UIViewController *_lastViewController;
// methods


In the implementation, in do the following:

    @implementation MyRootViewController

    // other stuff

    - (void)viewDidLoad {
        [super viewDidLoad];

        self.navigationController.delegate = self;
        // ...

    - (void)navigationController:(UINavigationController *)navigationController
          willShowViewController:(UIViewController *)viewController animated:(BOOL)animated {
        if (_lastViewController) {
            [_lastViewController viewWillDisappear:animated];

        [viewController viewWillAppear:animated];
        _lastViewController = viewController;

If you need support for viewDidAppear and viewDidDisappear then you’d have to implement this method as well:

- (void)navigationController:(UINavigationController *)navigationController
       didShowViewController:(UIViewController *)viewController

After doing this, your view controllers should start receiving the viewWillAppear: and viewWillDisappear: methods successfully.

Moving My Blog

I’ve decided to transition over to a new blog.

The reasons? Mostly because I’m questioning more & more the need to have a dynamic blog that I need to maintain. Static HTML blog generators are very interesting and I thought I’d give one a try.

I’ll leave this one around for historical reasons. It gets a decent amount of traffic and has content going back to 2004.

So without further ado I present my new blog, Fickle Bits.

(Note to RSS readers, your feeds will not auto-update. Subscribe to the new blog here: Subscribe )

My Vim Journey

For my Rails work, I’ve largely leaned on TextMate. It’s used by many Rubyists, looks sexy, and is easily extended.

I still use TextMate frequently, but I’ve been ramping up on my Vim skills and I’ve recently come to a point where I think I’m pretty productive in it.

My initial frustrations with Vim were that it was too configurable. Talk to any Vim power-user and you’ll find a completely different set of plugins & keyboard shortcuts. If you snag a friend’s set of Vim configuration files (like I did) you might find yourself frustrated that there’s too much to learn and it’s difficult to know where various behaviors are coming from.

In this post, I’ll attempt to demonstrate a very sane Vim setup that newcomers can use to get started and not be too overwhelmed.

Why Vim?

Before I get started with the basics of Vim, why would you use it in the first place?

For me it boils down to this: I love staying on the keyboard. Vim may not make you faster (in fact initially you’ll be a lot slower) but it can fit your workflow better.

Another big differentiator of Vim is Command Mode. The notion here is that you spend more time wrangling text rather than creating it from scratch. That’s certainly true of my code.

It is important, however, that in the larger software ecosystem, typing is not the bottleneck. Don’t expect Vim to make you build the right software faster.

Vim enables a keyboard-optimized workflow that may make you faster. YMMV. If you’re fast with TextMate or Emacs or don’t want to spend the time to learn something new, then Vim may very well not be for you.

Lastly, Vim is ubiquitous. It’s on every platform and you can carry your configuration (or a very large set of it) everywhere. People frequently put their vim configurations on Github for themselves and others to utilize.

Getting MacVim

Almost all Unix-based systems (like Mac) include a terminal version of Vim. The version included on OS X isn’t compiled with Ruby support, so some plugins won’t work. In addition, it doesn’t have OS-level integration like Copy & Paste in the same buffer.

Most Vim users I know use MacVim, which comes pre-compiled with Ruby support, has tabs, and more.

If you have homebrew installed, just type:

brew install  macvim

If you’d rather grab a pre-built binary, then head on over here.

You’ll also want to make sure that the mvim binary is in your path.

Basic Vim Navigation

I won’t cover everything you can do in Vim here, but here’s just enough to get you started:

In Command Mode:

  • Press h, j, k, l to move the cursor around. It will feel weird, but you start to appreciate not lifting your hand off of the home row to reach for the arrow keys.
  • Press G to go to the end of a document, gg to go to the top of the document.
  • Press i to go to insert mode at the current position
  • Press I to insert at the beginning of the line
  • Press a to “append” content after the cursor
  • Press A to “append” content at the end of a line
  • Type cw (“change word”) to replace the current word and go into insert mode
  • Type dta to (“delete ‘til the letter a”) in a line

In Insert Mode:

  • Press esc to go back to command mode.


  • In Command Mode, you can type commands by prefixing them with :.
  • To write the changes to the current buffer (save) type :w and hit enter. Often times you’ll write & quit in one command, with :wq.

Feel free to use the mouse & arrow-keys while you’re getting used to everything. It will feel weird.

For more Vim-fu, definitely check out this PeepCode screencast.

Installing a Base Set of Plugins with Janus

The real power of Vim is in the plugins, and fortunately Yehuda Katz & Carl Lerche have put together an opinionated and useful set of plugins that are pre-configured and work well together. Take a look at the plugins it includes here.

Getting Janus installed is easy. If you are super trust-worthy and don’t mind running a script blindly (I don’t recommend it) you can simply run:

curl -o - | sh

More explicit instructions for the paranoid can be found on the github page.

Once you have Janus installed, your Vim will be on steroids. Don’t worry though, I’ll try to cover the most important things you’ll be using.

Getting a Decent Theme installed

MacVim installs a hundred nasty looking themes, but a few of them are worth taking a look at. Here are some that I like:

  • molokai
  • railscasts
  • vividchalk
  • vibrantink

If you want to install other themes (like this nice github one) then you simply download it & copy the theme.vim (or whatever the theme is called) to ~/.vim/colors.

To switch between the themes that are installed, you can use the menu, or you can type :colorscheme <scheme>.

To set defaults for your installation, you’d normally add commands to ~/.vimrc however Janus has taken that file over. It instead reads your settings from ~/.vimrc.local. In order to provide settings for graphical Vim installations (like MacVim) there’s also a ~/.gvimrc file.

Open up that file (:edit ~/.gvimrc) and add the following commands:

colorscheme github
set guifont=Menlo:h14

Feel free to tweak this to contain your favorite color scheme & font. In order to see these changes you have to “source” the file:

:source %

(% here means “current file”)

You should see the changes take effect immediately.

Opening MacVim with a “Project”

One common thing in TextMate is to cd into a project and then type mate . which will open TextMate’s project drawer with all of the files in that directory loaded up.

In MacVim, you can do the same. Navigate to a folder with some content (like a Rails app) and type: mvim .

You should see something resembling a file navigator. You can navigate these with the same movement commands from above.

Once you’ve chosen a file, press enter to open it in the buffer.

Janus comes with NERDTree, which has similar behavior to TextMate’s Project Drawer. Open up the NERDTree pane by typing <leader>-n or \n. By default the leader key is set to backslash. The leader key is a special, configurable key used to create quick shortcut combinations.

The NERDTree window can be collapsed by typing <leader>-n again.

You might want to instead find the file by searching for it by name. For that, the aptly-named Command-T plugin can be hepful.

Command-T can be activated (by default) with <leader>-t. Start typing and it will auto complete the results.

Scared Yet?

Writing this reminds me of how hard it was to get started. I can only offer some encouragement that with practice, Vim does start to feel like you can leverage your fast typing skills to really.

Practice only a couple of commands at a time. Really learn what they are doing and then move one to the next command. Print out a cheet sheet. Pair with someone else who uses Vim.

I hope you found this intro useful. I’ll cover some more Vim tricks as time goes on.

A Fresh Start?

So I’ve been thinking of ditching the traditional blog for a while now. My current blog is powered by WordPress, which is powerful enough, however it always seems like a hassle to maintain. There are also no fantastic blog editors for the Mac (still).

This time I’m going in a completely new direction. This blog is powered by Octopress (which uses Jekyll as the engine. I’m not going to import old posts and I’m not going to worry about integrating a lot of features. Just epic content, that’s it!

Posts are composed in Markdown (I’m using vim to write this), static HTML is generated and the blog is then deployed to a git repository.

Will it make me blog more? I hope so, but only time will tell!

Houston Code Camp Registration Is Now Open

Houston Code Camp 2011

August 20th, 2011

Houston Code Camp is a free day of sessions relating to software development. The event is free to attend, but registration is required.

A Code Camp follows these rules:

  • They are a organized by developers and for developers to come and learn from their peers. Topics are always based on community interest and never determined by anyone other than the community.
  • Code Camps are always FREE for attendees
  • The success of the Code Camp is determined by the community. All content that is delivered is original and voted for by you! Make sure your vote counts, and vote for the sessions you’d like to see at our speaker submission site.
  • No Fluff - Code Camps are about Code, not slides. You won’t find any marketing heavy powerpoint decks here
  • All are welcome to attend and speak and do so without expectation of payment. Learn more about speaking on our speaking page.
  • The beauty of the Code Camp is that they always occur on weekends.

The schedule is still being formed. Take a look at the list of submissions here. You can still get your session proposal in if you’re interested in speaking!

Space is limited, so make sure and snag your ticket today. It’s FREE!.

What are you waiting for? Go register!

Fixing Xcode 4’s Broken Code Completion

In my continued quest to actually use Xcode 4 full time, I’ve run into yet another major issue: Xcode 4’s code index sometimes gets borked and syntax highlighting & code completion stop working.

In the past, this has been fixed (temporarily) by deleting the Derived Data folder in Organizer, restarting Xcode, changing the compiler from LLVM to GCC & back again or some random combination of the 3. This doesn’t always work, and today I sat down to figure out what the cause was and how to fix it.

In searching stackoverflow and the developer forums, I found that Xcode’s code index can hang on recursive and/or relative search paths.

My project utilizes 2 static libraries, so I must provide proper header search paths, otherwise the compiler doesn’t recognize any of the symbols.

So if you have a Header Search Path setting of ../lib/MyAwesomeLib or ../lib/MyAwesomeLib/** then you might be having this problem too.

Step 1: Correcting relative paths

You might be tempted to hard code the path to the file. Don’t! This will break on somebody else’s machine, and most of the time you’re not working on this stuff alone. You can utilize the $(SOURCE_ROOT) build variable to construct a dynamic path relative to the Xcode project directory.

This step might be all you need, but in my case I needed to follow the next step as well…

Step 2: Remove the need for recursive searches

I have two subprojects, each of which symlink their build output to a build/current folder. This makes it easy to add a non-recursive library search path reference for similar reasons. I also want to copy headers into this folder so there’s always a deterministic location to find the headers, regardless of the platform & configuration we’re building for.
So I added a Run Script build phase to do this work for me:

# Symlink build output to a common directory for easy referencing in other projects
rm -rf "$BUILD_DIR/current"
ln -s "$BUILT_PRODUCTS_DIR" "$BUILD_DIR/current"

# Copy headers to a shared location
mkdir -p "$BUILD_DIR/current/headers"
for file in `find . -name "*.h"`; do cp $file "$BUILD_DIR/current/headers/"; done;

The line is a bash for loop that copies all the header files in any subfolder & flattens it out for a single headers folder reference.

Step 3: Add the new common header search paths

In my case I exchanged a relative, recursive search path of:


to the more explicit, and more Xcode 4 friendly:

As soon as I did that, my code lit up like a Christmas tree! Symbols were recognized, code was highlighted, and best of all… code completion resumed.
Here’s to hoping the Xcode 4 continues to be improved. In the meantime, hope this fix saves you the headache I’ve been having.

Creating Proper IPA Files in Xcode 4

Xcode 4 has changed a lot of things. Most of those things are ok, but occasionally I find that I just cannot do something any other way than to use Xcode 3.

Until today, I was creating Ad-hoc builds for my current project with Xcode 3, then selecting Share & saving the resulting IPA file to disk.

Xcode 4 has the new “Build -> Archive” menu option, but every time I’d try to share this file, I’d presented with this lovely restricted dialog box:


With the errors No Packager exists for the type of archive and This kind of archive cannot be signed.

As it turns out, if you have static libraries that you’re linking in, your Archive step actually outputs those as well. Xcode doesn’t know how to create an IPA out of 1 .app file and a handful of .a files, so it gives up.

You can tell that Xcode 4 is doing this if your Organizer -> Applications list shows an icon like this:


If you right-click on this build, and select “Reveal in Finder” you’ll see the files are .xcarchive files. Right click on that and select “Show Package Contents” to see what I’m talking about. If you see a usr/lib/mystaticlibary.a file, then read on for the fix.

You need to tell Xcode 4 not to “install” the static libraries. For each of the static library targets, select them in Xcode 4, and under Build Settings, search for “Skip Install”. Set that flag to YES. I had to do this to both of the static libraries I include in my project.


Once that’s done, your app should show a normal icon again & have the ability to export to IPA just like before. Yay!


Huge thanks to this stackoverflow question for pointing me in the right direction.

Rails Intrigue Video at NHDNUG

I gave a presentation at the North Houston .NET User Group a couple weeks ago entitled “Rails Intrigue”. My friend, Claudio Lassala recorded it and posted the video on YouTube.

In the presentation, I tried to give a little glimpse of what it feels like to build an application with Rails. I also tried to convey a little of why I think Rails is just Fun.

I think it went pretty well, for being mostly off the cuff. Give it a watch, and let me know what you think.

Houston Code Camp - Call for Speakers

I’m excited to announce the first annual Houston Code Camp 2011, happening on August 20th! The code camp is a one day conference on Saturday, held by developers - for developers. Here you’ll find sessions on a multitude of platforms and of varying skill levels. Best of all? It’s FREE.


Call for speakers

We’re currently looking for speakers, so if you are interested in speaking please feel free to submit a session. We’re interested in both veteran & novice speakers alike, as a code camp is the perfect opportunity to start speaking if it’s something you’ve been wanting to do.

Community Voting of Sessions

We want this conference to be valuable to the community, so we’re letting you vote for the sessions you’d like to see most. As registration draws near I’ll announce more details on how this work.

Registration will open soon, but for now…. save the date!

Dry Up Your Rspec Files With Subject & Let Blocks

Rspec is pretty awesome, however due to its flexibility, often times I find that people write specs in ways that either a) aren’t structured very well, or b) use the wrong terminology to group up common contexts & behaviors.

Update: Be sure to read David Chelimsky’s suggestions in the comments.

A friend of mine who is fairly new to Rspec, and asked me to provide some feedback on some tests that he wrote.

Here is the before:

The only real problems here are:

  • Lots of duplicated setup code. If the initialization aspect of the Card design ever called for something other than a string, we’d have a lot of test code to fix.
  • Lots of “extra” code to test a simple value. If it smells like duplication to type “it ‘has a value of 13’” and then type the same thing, only in ruby code, then you’re right.

The rspec constructs I recommend to deal with this are `subject,` `let, and` `its` blocks.

  • Subject blocks allow you to control the initialization of the subject under test. If you don’t have any custom initialization required, then you’re given a default `subject` method already. All it does is call `new` on the class you’re testing.
  • Let blocks allow you to provide some input to the subject block that change in various contexts. This way you can simply provide an alternative `let` block for a given value and not have to duplicate the setup code for the subject over again. Let blocks also work inside of `before :each` blocks if you need them.
  • Its blocks allow you to test methods on the subject that return a simple value. The benefit of using this over the more wordy version above is that it can actually format the test output for you.

Here is the same example above, using the above techniques to clean things up a bit.

And here is the output of the above spec:

    Two of Hearts
        should == 2
    Face Cards
      King of Clubs
          should == 13
      Queen of Clubs
          should == 12
      Jack of Hearts
          should == 11
    Bad Value
      should raise StandardError

I think that’s a big improvement.

Note: The code in this post is delivered via Github Gists, which unfortunately don’t render in Google Reader. Click through to see the code.