High Order Blog

One of my favorite uses of Twitter is as a means for sharing photos. That’s one of the reasons why we’ve included the best photo previews of any Twitter app on the App Store. I also love to post my own photos on Twitter, but I prefer Flickr to host all pictures I keep online. I’m finicky about the software I use, and I dislike all of the dedicated Twitter photo sharing sites like TwitPic and Yfrog. That’s not a knock on them or the people that use and love those service. They just don’t appeal to me personally.

Since the vast majority of Twitter users use those sites, we worked to support those first and well in Twitbit. But soon I was itching to post my pictures directly to Flickr from Twitbit, and one of the great things about building software that you use yourself is that you get to add the features you want. We added Flickr integration into Twitbit 2.0, and it’s one of the features that’s only available in the pro version.

Flickr photo sharing in Twitbit includes an extra feature that some people may not be aware of: automatic tagging of Flickr photos uploaded with Twitbit. Once you’re able to tag photos automatically, the door opens to some fun integration with other web services.

I use Tumblr to host my personal blog. If you haven’t tried Tumblr, I highly recomnend it. It’s free, dead simple, there’s tons of great themes, and you don’t have to get into any of the hassle of hosting your weblog yourself.

One of Tumblr’s great features is its built-in integration with other services. You can configure Tumblr to include content you send to other sites into your Tumblr blog automatically.

Using these two features — automatic tagging of Flickr photos with Twitbit and automatic import of content with Tumblr — you can automatically post all photos you upload from Twitbit to your Tumblr blog.

Let’s set it up.

Say you want to tag all photos uploaded with Twitbit with “toshare”. In Twitbit, tap your account name in the top of the Timeline tab, tap the “Photo & Video” section. Add Flickr as a photo service if you haven’t already by tapping “Add a New Service…” (Remember, Flickr is only available in Twitbit Pro.)

Once Flickr is installed as a service, tap “Flickr” under the list of available services, and in the Settings section tap “Tag Photos & Video”. Twitbit will download the list of tags currently associated with your Flickr account. Tags selected here will automatically be applied to any photos or videos you upload with Twitbit. You can select as many as you would like, or scroll to the bottom of the list and tap “Add a New Tag” to add a tag you haven’t used before.

Now log into Flickr and navigate to a photo page that includes the “toshare” tag. Click the “toshare” tag link on the right (or whatever tag you’ve chosen), which will take you to a page of all your photos that include that tag. In your browser’s address bar, on the far right, will be an RSS icon. In Safari, click that RSS icon, and choose the RSS feed (the Atom feed probably works, too, but I haven’t tried it so I don’t know for sure). Your browser may be slightly different but the workflow should be roughly the same. Copy the URL of the RSS feed to your clipboard.

Finally, navigate to your Tumblr dashboard and click the “Customize” link for your blog. Click the Services button at the top. Where it says “Automatically import my…”, select “RSS Feed” and “Photos” as the content type. Finally, paste the URL in the text field where it says “Field URL”.

That’s it! You’ll see this automatic import listed at the bottom of the Services list. Tumblr will start to check this RSS feed periodically. Anything you post from Twitbit will be automatically tagged on your Flickr site and posted to your Tumblr blog!

Enjoy!

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.

One of the first things many users of Xcode want to do is customize the file templates used to generate stubs for classes and other items in your project. We’re spending most of our time building iPhone applications, so we’re interested in customizing the Cocoa Touch templates.

Losing __MyCompanyName__

Getting rid of the __MyCompanyName__ placeholder is almost always the first thing people want changed when they start using Xcode. This can be done in one of two ways.

Set Your Company in Address Book

Definitely the simplest method: just set the company field for your personal card in Address Book.

Set Your Company Manually

You can set your company manually by running the following command in your terminal:

$ defaults write com.apple.Xcode PBXCustomTemplateMacroDefinitions \
  '{"ORGANIZATIONNAME"="High Order Bit";}'

Customizing Cocoa Touch Templates

You’ll save a lot of time over the long term with a bit of up-front investment configuring Xcode with your own templates.

You can find the standard Xcode Cocoa Touch plugins here:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/
    File Templates/Cocoa Touch Classes/

Each directory with the extension .pbfiletemplate is its own template.

You don’t want to edit these files. While doing so will work, the next time you install Xcode, your changes will be overwritten. Instead, you should place your custom templates within your home directory (create these folders if they don’t already exist):

~/Library/Application Support/Developer/Shared/Xcode/File Templates

Inside the File Templates directory, your templates must be placed in a Cocoa Touch Classes directory. This directory can either sit directly within File Templates, or you can create subfolders to further group your templates. For example, I’ve created a High Order Bit subfolder where the templates include our standard comment header and the boilerplate code is formatted per our coding conventions.

We’ve also added to the list of available templates, adding one for creating new protocols and another for creating class categories. Creating new templates is pretty self-explanatory once you crack open the .pbfiletemplate folder contents.

We keep these templates in source control. I want Xcode to pick up changes automatically when I pull from our repository, and I want to easily share any local changes I make. I could just clone the repository into the Xcode File Template directory, but I prefer to keep them in the directory where I keep the rest of my source code and create a symbolic link to this location where Xcode expects it:

$ ln -s $HOME/src/xcode-configuration/File\ Templates/Cocoa\ Touch\ Classes \
  ~/Library/Application\ Support/Developer/Shared/Xcode/\
  File\ Templates/High\ Order\ Bit/Cocoa\ Touch\ Classes

Done! Your own custom Xcode Cocoa Touch templates, tracked and shared in source control.