High Order Blog

You’ll end up doing it eventually, anyway. Here’s the situation: you need a modal view with a standard navigation bar, much like the “Log In” view in Twitbit:

It’s really easy to convince yourself that you just need this view to collect some basic info and be done with it. It won’t need to push other views onto a stack; it will always be the root of the modal view controller. So what do you do? You manually throw a navigation bar in your nib file, slap some buttons and a title on there and you’re done right?

No, you’re not done. You were wrong — you’ll need this view to appear in a stack of views, and sometimes it won’t be at the root of the modal view controller. In this case, I needed to add a help view. Save yourself the trouble and just wrap your view in a navigation controller from the get-go. Set its navigation item (why can’t you do this in Interface Builder, by the way?) and always put your view in a UINavigationController and you’ll have a more portable view. You win.

While I’m on the topic, does anybody else build just about every interface in IB only to redo it in code? Don’t get me wrong, I like the idea of IB, but it seems like there’s always something, whether that’s optimizing drawing, controlling initialization, or realizing everything is a table view cell, anyway, and you don’t need to lay anything out.

I’m going to be giving a presentation at the Boulder CocoaHeads meeting tonight. If you’re going to be in Boulder, I encourage you to come say hello.

The meeting will be at InspiringApps’ office from 7 – 9 PM.

We spend the vast majority of our time writing code in Objective-C for our iPhone applications. In my opinion, one of the biggest problems with iPhone or Mac development is Xcode. Yeah, it’s gotten progressively better over the years, but I still wonder how any developer can use it productively as their full-time development environment.

My weapon of choice for day-to-day iPhone development is Vim. Of course, at its core Vim is a text editor, not an IDE, so those looking to duplicate the functionality of more modern development environments in Vim have to either look to Vim’s rich plug-in ecosystem, or roll their own.

One of the first problems I wanted solved was to build my programs and fix compiler errors in Vim. I’m trying to minimize the number of times I need to switch between Vim and Xcode (in other words, reduce my Xcode use) as much as possible.

Xcode helpfully ships with a command line build tool called xcodebuild. It should be in your $PATH by default once you’ve installed the Xcode tools:

$ xcodebuild -help
    Usage: xcodebuild [-project <projectname>] [-activetarget]
          [-alltargets] [-target <targetname>]... [-parallelizeTargets]
          [-activeconfiguration] [-configuration <configurationname>]
          [-sdk <sdkfullpath>|<sdkname>] [<buildsetting>=<value>]...
          [<buildaction>]...
        xcodebuild [-version [-sdk [<sdkfullpath>|<sdkname>] [<item>] ]
        xcodebuild [-showsdks]
        xcodebuild [-find <binary> -sdk <sdkfullpath>|<sdkname>]
        xcodebuild [-list]

Vim includes the ability to build programs via make, and, more importantly for me, supports customizing the command-line builder is uses as its make program. All that’s needed is to configure Vim to use xcodebuild as our make program, instead of make, and we should be in business.

For xcodebuild to work properly, the command needs to be run from within the same directory as your .xcodeproj file, or it needs to be told where that file is located via the -project command line option. This is a problem for me, since I like Vim to set its working directory to the directory of the file I’m editing, which is never the same directory that contains my .xcodeproj file. Since my current directory can’t be relied upon, I needed to find a way to dynamically locate the .xcodeproj file in order to correctly trigger a build.

Enter Rake. Anyone whose ever done any Ruby programming is probably familiar with it, and if you’ve never heard of it, I encourage you to check it out. I like to use Rake for simple project automation, including updating my tags file and performing certain git operations.

One feature of Rake that came in handy for solving this particular problem is that when rake is typed at the command line, it will recursively search up your directory tree looking for a Rakefile. That means if I execute Rake from within foo/bar/baz, and my Rakefile is in foo, Rake will find it and run it correctly.

Taking advantage of this, I’ve set up a build task within my project’s Rakefile that will perform the default Xcode build (which is configured within the Xcode project itself) via xcodebuild. The relevant Rakefile snippets looks something like this:

def project_file(root_dir='.')
  Find.find(root_dir) do |f|
    if f =~ /\.xcodeproj$/
      return f
    end
  end
  nil
end

def xcodebuild
  "xcodebuild -project #{project_file}"
end

desc 'Build the default target using the default configuration'
task :build do |t|
  puts %x{
    #{xcodebuild} |
    grep -v "note: This view overlaps one of its siblings ."
  }
end

task :default => [ :build ]

Note that I have to search for my .xcodeproj file because our project structure conventions have it living in a subdirectory of the project root, and I don’t want to hardcode the path or the project file name for project portability reasons. Note also that piping the output through grep is a hack to suppress annoying Interface Builder warnings that I can’t figure out how to shut off in IB or Xcode. If anyone knows how to do this, please share.

Now all you have to do is invoke your Rakefile from within Vim by setting Rake to be your make program by typing:

:set makeprg=rake

Now when you type :make from within Vim, it’ll invoke Rake. If your working directory is within your project’s root directory, Rake will search for your Rakefile, and, when it’s found, invoke the build task. You can also pass arguments to the make command within Vim, so you’re not restricted to running a single Rake task with no arguments.

Since Xcode uses GCC to compile iPhone programs, Vim can already parse the compiler’s output and make sense of compiler warnings and errors. This allows you to navigate to those warnings and errors From within Vim using the standard cnext and cprevious commands.

To load the build output as a Vim window that spans the width of the frame underneath any other windows (important for me as I like to run Vim with two vertically split editor windows and a NERDTree window to the left of those), just type :botright cwindow.

I also set this configuration automatically whenever I edit an Objective-C file via my .vimrc file:

autocmd FileType objc set makeprg=rake

That’s my setup. I hope it helps more people get out of the swamp of Xcode and into an environment that’s actually productive. And of course, any suggestions for improvements, or other tips or tricks, are always welcome.

Twitbit 1.1.1 is now available on the App Store! It’s primarily a bug fix release. More details about what’s new can be found in the release notes.

Meanwhile, we’re hard at work on getting Twitbit 2.0 out the door. We’re getting close to the end of our feature list, and we’ll be sharing more details soon.