Posted by admin on Sep 2, 2010 in iPod / iPhone

In an iPhone app I’m working on which uses an MKOverlayView subclass, I found that the lines I was drawing were thinner on iPhone 4 than on iPhone. Simple math to the rescue so the line has the same thickness on both platforms (e. g. I want a uniform lineWidth of 3.0):

overlayView.lineWidth = 3.0 * [[UIScreen mainScreen] scale];


Proof that iPhone Development is Macho

Posted by admin on Dec 30, 2009 in iPod / iPhone, Xcode

In Xcode when I just recently launched an app on the device:

0x2fe0104c <+0036>  blx 0x2fe01564 <__dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl>


Toll-free Bridged and NULL v. nil

Posted by admin on Dec 4, 2009 in iPod / iPhone, Mac OS X

I always wondered if NULL got toll-free bridged to nil.  I figured that NULL is a pointer value of all zeroes and nil is actually a pointer to a special object.  So my hypothesis was they weren’t interchangeable.  I was wrong.

  // Check to see what happens to a toll-free bridged ptr when it gets set to NULL.
  CFStringRef stringRef = NULL;
  NSString *str = (NSString *) stringRef;
  if (str == nil)
    NSLog(@"str is nil");
    NSLog(@"str is NOT nil!!!");

  NSLog(@"The object value of nil is %@", nil);
  NSLog(@"The numeric value of nil is %d", nil);

Yields the following output:

2009-12-04 10:51:58.532 TollFreeBridging[18053:a0f] str is nil
2009-12-04 10:51:58.535 TollFreeBridging[18053:a0f] The object value of nil is (null)
2009-12-04 10:51:58.536 TollFreeBridging[18053:a0f] The numeric value of nil is 0

And then there’s NSNull….


Accented Characters on iPhone

Posted by admin on Jul 31, 2009 in iPod / iPhone

In case you haven’t stumbled across this yet, you can easily enter accented characters using the iPhone keyboard, simply by tapping and holding on the character you want to accent.  In this example, I tapped and held on the E in order to choose and enter an é:


Outlining a UIView

Posted by admin on Jun 7, 2009 in iPod / iPhone, Mac OS X

I recently was having some difficulty with some drawing in a UIView and decided that outlining the bounds of the view itself would help me to debug the problem.  (It did.  Instantly.)  All you have to do is to stroke the bounds rectangle of the view you’re in (this assumes you have already subclassed UIView for your custom view).  Add the following code to your drawRect: method:

  CGContextRef context = UIGraphicsGetCurrentContext();
  CGContextSetStrokeColorWithColor(context, [UIColor redColor].CGColor);
  CGContextStrokeRect(context, self.bounds);

Update 17-Feb-2010:

This can be done without subclassing (or with, if you prefer) very easily. Simply access the view’s CA layer and set the border on it:

[[aView layer] setBorderWidth:1.0];


CruiseControl.rb+git (+xcodebuild!) on Mac OS X

Posted by admin on Apr 27, 2009 in iPod / iPhone, Mac OS X, Rails, Ruby, Testing, Unix, Xcode

With some encouragement from my colleagues, I expanded the original post here to be a more soup-to-nuts recipe for setting up CC.rb with git and xcodebuild on Mac OS X. Thanks, guys!

I am currently working on a cross-platform project which has multiple targets that need to build on Mac OS X. On my previous project, we were using CruiseControl.rb on linux to watch a Subversion repository for a Rails project and run all the associated tests upon checkin. Since we wanted to be like the Cool Kids on this new project, we of course decided to use git for source code management.  We use gitosis to manage multiple remote git repositories under a single user.  However, you can use any approach you want for the remote repository management as long as you can compose a git URL that points to it.


  • You have a Mac that is probably not your development machine that will serve as a Continuous Integration (CI) server.
  • You have a remote git repository that the CI machine can monitor and pull changes from.

It took a little doing to make CC.rb play nice on Mac OS X.  In addition to the typical CC.rb installation, getting CC.rb to launch at system startup using launchd took the proper file in the proper location. Nevertheless, the whole setup is pretty darned straightforward.  Here’s how I did it:

  1. I created a user named “continuousintegration.”  You can name yours anything you like, or use an existing user.  Log in as this user.
  2. Download and install CruiseControl.rb.  I unpacked it into the the home directory of the continuousintegration user.  So, the absolute path to the CC.rb installation directory in my case is:  /Users/continuousintegration/cruisecontrol.rb.
  3. Create the work directory for CC.rb.  In my case, I use /var/cruise as the work directory.  This required admin privileges to create; just make sure that your CI user has access to this directory.
    sudo mkdir /var/cruise
    sudo chown continuousintegration /var/cruise


  4. Add your git repository to CC.rb.
    cd ~/cruisecontrol.rb
    ./cruise add <project name> --url <git repository url> -s git


  5. At the root level of your git repository, add a file named cruise_config.rb. This provides some useful configuration information so that CC.rb knows what to do in order to build your project as well as whom to notify when the build fails. You provide the build command for CC.rb in cruise_config.rb by assigning to project.build_command. I actually made my build command point to ./ci_build.sh so that I can do anything I want for the build in a separate shell script named ci_build.sh in the git repository root. In my case, I am actually running xcodebuild to build a target I created in my Xcode project; you can do literally anything you want here, e. g. make check, rake… whatever! Witness my cruise_config.rb and ci_build.sh files. (If you create a ci_build.sh or equivalent file, be sure you make it executable.) Make sure you git push your changes to add the cruise_config.rb (and ci_build.sh if you choose to do so).
  6. You should now be able to start up CC.rb and look at the dashboard to see your project.
    ./cruise start

    Browse to http://localhost:3333

  7. Wait! You’re not finished yet! There’s one more step: setting up CC.rb to start every time the system starts up. This is accomplished by creating a plist file in /Library/LaunchDaemons which starts up CC.rb. (For more information on what’s going on here, see the Apple documentation or man launchd.)
    Download this plist file and copy it into /Library/LaunchDaemons
    sudo cp localcruisecontrol.plist.txt /Library/LaunchDaemons/local.cruisecontrol.plist

    Now when you restart the CI machine, CC.rb should start up automatically.

Setting up CC.rb all by itself tends to be pretty easy; it’s getting the daemon to run at system startup as well as getting your build to work properly that tend to be the problems. If you’re having trouble getting things running after following these directions, or if you find errors in these directions, please let me know.


Retain/Release, Properties, and ‘self’

Posted by admin on Dec 22, 2008 in iPod / iPhone, Mac OS X

I think I learned something today about Objective C properties and retain.  It seems that in a method where you reference a property, you need to use the form “self.property_name” if you want the assigned object to be automagically retained.  If you simply say “property_name = some_object” it doesn’t retain some_object!

Witness the source code and the associated results:

Source: Retain Release main.m


2008-12-22 20:52:18.824 RetainRelease[3623:10b] Before assignment: [a retainCount] = 1
2008-12-22 20:52:18.837 RetainRelease[3623:10b] After assignment: [a retainCount] = 1
2008-12-22 20:52:18.838 RetainRelease[3623:10b] Before assignment: [b retainCount] = 1
2008-12-22 20:52:18.839 RetainRelease[3623:10b] After assignment: [b retainCount] = 2
2008-12-22 20:52:18.842 RetainRelease[3623:10b] Final [oo retainCount] = 2

Seems to me proof that when you’re assigning to them, you should always reference properties on an object by prefixing them with “self“.

Caveat: Inside of the setter method for a property, do NOT use the “self.property” syntax. Otherwise, you end up in a infinite loop. Ask me how I know. :-) This is the best (and only) argument I can see for having a different behavior between the “self.property =” and “property =” usages.


Excellent summary of retain/release/autorelease

Posted by admin on Dec 22, 2008 in iPod / iPhone, Mac OS X

From this page on wikipedia:

In practice, retain, release and autorelease are straightforward. Some people seem to find it confusing but perhaps they think it’s more complicated than it is. To keep an object you’re given, retain it. Objects you make are already retained. To throw it away and refer to it no more, release it. If you write a factory method, autorelease it. If you are simply making use of an object returned by a factory method for a short while, do nothing.



Posted by admin on Nov 30, 2008 in iPod / iPhone

My first iPhone application — Bullistic — was released to the iTunes App Store on Nov 20, 2008. Thank you to everyone who was involved for your continuing support, feedback, and mostly patience!



New Blog Location

Posted by admin on Nov 30, 2008 in BMW, Business, iPod / iPhone, Java, Mac OS X, nginx, Rails, Ruby, Testing, TextMate, Uncategorized, Unix, Xcode

I finally made an honest blog out of this thing.

Copyright © 2017 Standalone Code LLC All rights reserved. Theme by Laptop Geek.