Road Trip is Available!

Hooray! Road Trip is available in the App Store now for iPhone, iPod Touch, and iPad.

I don't know that I've ever really written down the story behind Road Trip so now is as good a time as any. Set the wayback machine to August 2008! Apple had just updated what was still known as iPhone OS into version 2.0 with the App Store allowing third party development. I had picked up an iPhone in March but had found at the time that iPhone development was limited. Apple considered it a beta and getting the keys that let you put an application on the hardware was at their discretion and I wasn't invited to the party. So around July or so I had acquired the necessary certificates and was trying to figure out what my "Hello World" learner app would be.

By this point the Big Honkin' Road Trip (BHRT) was well established. A group of friends from my Kesmai days would gather somewhere and we'd travel around hanging out and visiting various local HOOTERS. Usually we tried to find a state where there on the order of three – six restaurants and visit them all, thus completing the HOOTERS of (state) tour. Our process for handling this was a little complex. Sometimes there would be a car rental, sometimes we'd have somebody's vehicle(s). There would be hotel rooms, there would be gas costs, there would be bar/food tabs. As different people paid for different items we'd constantly be passing back and forth cash as we tried to pay for things evenly. Mind you, sometimes we'd have six people on the trip with one or two others showing up for one stop or another. Plus there was drinking. We'd have somebody staying sober to drive, but that wasn't always the person tracking the cash. There were always these crummy morning reconciliation sessions where we'd dig up receipts and try to reconstruct who owed whom what. The previous BHRT I had used an OmniOutliner document to track every receipt and all of the outstanding debts. It worked but it was still a pain.

For some reason while Karin and I were at PAX in August it hit me: I could put an app on my iPhone to do all of this. At this point I had one week to write the app. This was the first version of Road Trip. I worked on it at PAX a bit, and wrote the vast bulk of it on my flight from California to Dulles to start BHRT2K8. It wasn't quite ready that night and I have some humorous memories of frantically debugging the math in Tony's car on Saturday morning because we needed the app to work before I started drinking. We all agreed that after I had been drinking I wasn't allowed to tweak our key financial instrument – this was really a refinement of an old MAMBA Kings rule where we could code after drinking at Fridays After Five (a little civic party that would happen in the summer that was a couple of blocks from our offices) but we never committed code until a sober review. (Indeed, you can see my key observation about that debugging session in a post on this blog.)

The UI for that version of Road Trip was hideous. It had this tabbed interface with no graphics, the first version couldn't handle splitting things non-evenly, there was some terribly confusing debt/payment nomenclature that was overly complex, and it was ugly as sin. But it worked. You could tell it "Oh Tony paid for a hotel room that Tim and Tony are splitting" and it would tell you how much each person owed each other. The core idea was offsetting debts: if I owed Tony $90 for a hotel room and I picked up a lunch tab so Tony owed me $45 then I'd still owe Tony $45. Now if there's a third person in that mix the numbers got more complicated but the app didn't care. It would tell you who owed the most money and they picked up the next tab. That would likely change the "Deadbeat" and we'd rinse and repeat. On the last stop of the trip we'd settle up and that would be the only time cash would have to change hands. We usually didn't have anyone owe more than $50 or so.

We used that version of Road Trip for several BHRT's and it slowly got more features, but was still ugly as hell and complicated. I was busy doing other paying work so Road Trip never got a through work over and I was never convinced there was much market for the application. Our trip to PAX East last year wasn't technically a BHRT but we did use Road Trip for settling debts.

OK, so last year my paying work stopped and I didn't have a great lead for something new. I decided to do iOS work and at that point why not dust off Road Trip and ship it? Maybe it won't be a big hit, but it's mostly done right?

Well, no. iPad had happened between 2.0 and 4.x and it really ought to be a Universal app. And the UI was just awful. And it really should have a map view, and maybe something about photos? Really the only thing that salvageable was the core math crunching. So the ugly Road Trip became Road Trip Classic and I started a new project, using iOS 5.0 (then in beta) and embarked on learning storyboards, the new iPad UI elements, and generally modernizing it.

And here we are way too many months later! I like the new UI and it even has some pretty textures evoking the key conceits of the app: money and roads. Maybe somebody will find this app useful, and at the very least we'll have an easy–to–use version for the next BHRT …

If you (or somebody you know) would find the app useful please check it out!

Bring me your comments, yearning to be free!

In the comments thread over on the X-Com post Tony mentioned that there was an annoying CAPTCHA that you had to pass in order to post a comment. I don't see that because I have an account on the site so I'm not considered an anonymous commenter. I can't find a setting to turn off the CAPTCHA but I can have up to 250 accounts on my current plan. I can make accounts that let you login and post comments without hassling about who you are. Tony beta–tested this and it seems to work well. However, what I can't provide on my current plan is a form where you sign up for an account. So. We don't' see a ton of traffic on this blog and I suspect I can keep up with requests for accounts. If you'd like to post a comment drop me a line and I'll get you squared away. If you don't have an email address for me there's a form in the sidebar on the right that you can use to contact me.

I should note that I'm not doing anything to remove the old "anonymous" comment system, so if you're posting a one-off comment and would prefer to use that go ahead. It just turns out that if you're likely to make multiple comments over time that it's a bit friendlier to get an account here and avoid the rigamarole. It's a new option, not a replacement of the old system.

Obtaining your iOS Device Unique Device ID (UDID)

So you've got a friend who has written an iOS app and he or she wants you to beta test it. (Hint: if you're reading this, I'm that friend!) What do you need to do?

You need to provide that friend with your iOS device's "Unique Device ID" or UDID. Your friend can then generate a certificate that tells your device that it is allowed to run the beta app. You can drop this certificate and the app itself on iTunes and iTunes can then install the app on your device. All well and good but UDID's are long numerical strings and are a pain to find and type in anywhere. Apple provides an interface for getting them but it works a bit unusually and I thought it was worth writing some notes.

Here's an image of the Apple instructions. Everything you need to know is here but you have to read it carefully.

So here are step-by-step instructions:

1. Launch iTunes.

2. If you have Wi-Fi Sync enabled your device should already be in the sidebar. If you don't have Wi-Fi Sync turned on then you'll need to connect the device with a cable.

3. Select the device in the sidebar and make sure you have the Summary Tab displayed. You'll probably see the Serial Number displayed.

4. Click the Serial Number itself (or the text label that says "Serial Number") and it will toggle to displaying Identifier (UDID): and the actual UDID string.

5. OK, this is the weird part. Even though you have no text selected if you hit Ctrl-C right now iTunes will copy the UDID onto the clipboard. You can't select the text in any way (since a click will change the display back to Serial Number) but trust me, this should work.

6. Paste the UDID from the clipboard into an email and send it to your developer friend. He or she will thank you!

MKMapView is a Naughty Minx

OK, that was nasty to find. I've been plagued on and off by a crash bug that I only seem to see on the iPad and it's never been very reproducible. Today I was putting textures in the background of the iPad screens and found a reproducible crash. Hooray! Except as soon as I put a breakpoint in the crash would go away so there's some sort of race condition/multithreading going on. Mumble grumble.

The breakpoint was everyone's friend EXC_BAD_ACCESS. Of course this means the bad code wasn't anywhere near the actual crash. (And as an aside, surprising to me because I use ARC and therefore I don't write the retain and release code. So there's probably an ARC bug in here as well. Later I'll try to make a test app and submit a Radar.)

How did I find it? That in and of itself is a convoluted story and maybe worth relaying. I turned on NSZombieEnabled (in Xcode 4 you go to the Edit Scheme window and there's a checkbox in the Run/Diagnostics panel for Enable Zombie Objects) and discovered it was my TripMapViewController class receiving a respondsToSelector: message after it had been deallocated (and after the view wasn't onscreen anymore). This is a bit of a red herring because I use respondsToSelector: a fair amount so I scrubbed through all of my code and verified that I wasn't the culprit.

OK, I have to admit that stumped me for a moment. So it would appear that some other system thread is calling respondsToSelector with a pointer that it snuck past ARC. I did something hacky just to confirm the situation: I stashed a copy of the TripMapViewController in a static pointer, which should mean ARC no longer released the object. That worked and the crash stopped. Now what? After that I realized my object was still around and that I could overload respondsToSelector: and at least see the damn callstack. Turns out this controller gets a lot of respondsToSelector: messages; enough that you can't just stick a breakpoint in there. I did some more clunky things so that I could turn on a breakpoint after viewWillDisappear had been called. Sure enough, this big pile o' hacks worked for me: I could see the callstack of a bogus call. Problem is that it was all system stuff, with several calls just labeled "MKLongHash". If you Google MKLongHash you only get one hit which turns out to be a Stack Overflow thread about ARC and messages to zombie MKMapViews. Oh really?

---

Sure enough that's it. If you set the delegate of a MKMapView to a controller it is possible that ARC will incorrectly release the controller while some MKMap thing is still messing about. The solution provided in the article is to explicitly set and clear the delegate on viewWillAppear/viewWillDisappear. This worked for me. Maybe the next person who Googles for MKLongHash will find this helpful :-)

Legally Getting and Running X-Com UFO Defense on OS X

I've been reading a bit about the upcoming Firaxis XCom update and I've been getting a hankering to play the original X-Com. Well, I played it on the Playstation 1, I don't know if I have the disc anymore and even if I do, that's going to be annoying. I had a mouse for the original PS1, but who knows where that is, and who knows if I can even connect it to my PS3. I don't think I've got anything to connect a PS1/PS2 controller to my the PS3. (I know I did have a gizmo for moving Memory Cards over but I don't recall if it had a controller port.) And even if I got a mouse to work somehow … I don't want to play it in my living room with a mouse on the coffee table.

Anyway, a big hat tip here to my friend Tony who had mentioned to me at some point in the past that if you buy X-Com on Steam that it just ships inside an open source project called DOSBox. And you can download a version of DOSBox for OS X. So this morning while I was watching the Apple liveblogs I did all this. It works, but there are a few tweaks I had to make to make things convenient. Here's what you do.

1. Buy X-Com on Steam. You can get the first game for $5 or a whole bunch of them for $15. I don't know if you can actually do this from the Mac Steam client, I did it in a Windows 7 virtual machine.
2. Install DOSBox. Download it, and then put DOSBox.app in your Applications folder.
3. Copy the files from Windows to somewhere useful on your Mac. I made a DOSBox folder in my Documents, but wherever works for you. Assuming your Steam is working in the default place you want to copy the folder C:\Program Files\Steam\Steamapps\common\XCom UFO Defense.
4. When you get into DOS that long file name is going to be a pain. I renamed the folder to just XCom – so I have ~/Documents/DOSBox/XCom.
5. At this point you could just run DOSBox manually, mount the folder, and run the stuff, but there's a better way and that involves a dosbox.conf file. The folder already contains one but you need to pass that to dosbox, and that's a pain as well. Here's the whole command that I use:

   /Applications/DOSBox.app/contents/macos/dosbox -conf /Users/tsanders/Documents/DOSBox/XCom/dosbox.conf

6. This file didn't completely work for me. There was something not right about fullscreen mode but I didn't want the app in fullscreen on my 27" monitor anyway. The conf file also defaults to a 2x interpolation and I wanted to use the 3x. Lastly the volume was way too loud for me. So here's a list of changes I made:
   • Comment out fullscreen=true (so #fullscreen=true)
   • Change scaler=advinterp2x to scaler=advinterp3x
   • At the bottom in the [autoexec] section change the mount command to the proper path. Mine is mount c /Users/tsanders/Documents/DOSBox/XCom -freesize 1024
   • Add the line "mixer master 25:25" to set the volume levels 25% of maximum
7. OK, so far so good but that command line is a pain in the rear to enter. That's easy to fix! Run Automator, select the Application type, then in Utilities pick a "Run Shell Script" action. Paste the command over the line that says "cat". You probably don't want Automator to wait for the command to complete, so be sure to add " &" at the end of the line.

   /Applications/DOSBox.app/contents/macos/dosbox -conf /Users/tsanders/Documents/DOSBox/XCom/dosbox.conf &

8. Save the resulting Automator action in your Applications folder and you're done!
9. Optional bonus step: Go to images.google.com and get a nice icon image - I just looked for "x-com ufo defense box". Find the app you made in the last step, select it in the Finder and hit cmd-I. In the info window that comes up you can select the icon (it should be the little Automator robot) and just paste an image from the clipboard.

At this point you have an icon in Finder you can double-click, or something you can launch from Spotlight. No more opening Terminal, navigating to the proper directory, or remembering the syntax of the DOSBox commands. Pretty cool.

In theory this ought to work for a large number of DOS games. Of course, the devil is really in figuring out the proper settings for that DOSBox config file. That's where the cool part is that the Steam file is already mostly correctly configured. (I didn't chase the fullscreen problem but I suspect it's related to having two monitors, it might work fine with a single monitor.)

Edited to add March 7, 2012 10:21 PM:When I was working on this I had Automator open and I didn't notice this but the first version of the Automator app continued to run until I quit the game, resulting in a turning gear icon in the menubar. The fix is simple: just put the command line into the background with a simple & at the end. I adjusted step 7 to reflect this.