Category Archives: Methods

Multiple Build Targets For Fun and Profit

This month Mindgrub and Wheelhouse Analytics released Salesbag 1.0, a sales presentation tool geared at the financial services industry. The project represents somewhat of departure for Mindgrub as a consultancy. Most previous projects have been a once-and-done kind of project. For Salesbag we’ll be working long-term with Wheelhouse to release frequent updates to the app.

This presented numerous challenges as 1.0 got out the door and we started work on the first set of updates. Aside from our internal testing team, Wheelhouse has a team of their own. They want to be able to show the app store version off while still testing our updated builds to them. To keep the development and live builds totally separate we decided the best course was to create separate target for the dev version that they would use for their testing. To iPad, these would look like entirely different apps, so we’d never run the chance of damaging the live data during testing. In the rest of this post I’ll detail how to create a separate development target for testing purposes some of the added benefits you’ll get out of doing this.

Step 1 – Create a new app id and provisioning profile.

In the provisioning portal, create a new app id and ad hoc provisioning portal. I assume that everyone reading knows how to do this. For Salesbag we created a com.wheelhouse.salesbagDev app id.

Step 2 – Create a duplicate target

Duplicating the target is simple. Simply right click the build target in the project details and select “duplicate”.

Step 3 – Create a duplicate info plist

In order to use the new app id, we’ll need to duplicate and modify the info.plist to include the new app id.

You can also change other build settings like the bundle display name to make your dev version distinguishable from the production app.

Step 4 – Modify the target build settings to include the new plist

The new target must know to use the new the info.plist. Open the build settings for the target, search for info, and change the name of the info.plist.

Step 5 – Create a new scheme to build the new target

The last thing to do is to create a new scheme to build the new target. Under the schemes drop down at the top of the Xcode window and select manage schemes to bring up the scheme manager. You select duplicate from the actions (gear) menu at the bottom of the window.

Once your new scheme is created, click edit to open the new scheme. All you need to do next is replace the old target with your dev target and hit ok (this is in the “build” section).

You should now see the new scheme in the schemes drop down.

BONUS – Setup target specific code

In the dev version of salesbag we added some features for testers to be able to wipe out old data from previous iterations of Salesbag (in our case local eventkit calendars from development on the earlier versions). With your new target you can easily create custom preprocessor directives to dynamically include code in dev versions that you give to your testers.

Step 1 – Create a new preprocessor macro

In the build settings for the dev target search for preprocessor and double click the section called Preprocessor Macros under the target. Add a new parameter in here. We chose “DEV_VERSION=1”.

Step 2 – Use your new macro in code

To include code specifically for your dev version, simply use the macro you created in step 1:

#if DEV_VERSION
NSLog(@"cool testing feature");
#endif

That’s it!

Hopefully the process above will help some other developers in their longer term projects.  Also be sure to drop a comment if you have any feedback.  Happy coding!

Advertisements

This? You just need to watch this.

Greg Wilson – What We Actually Know About Software Development, and Why We Believe It’s True from CUSEC on Vimeo.

Parsing Sucks

The developers of Hipmunk posted a recent blog article detailing their post-mortem thoughts on the creation of their iPhone client.  It’s a good read top-to-bottom, but I thought the most interesting bit was regarding the performance and data transfer between the Hipmunk servers and the client.  This quote I think sums it up aptly:

Parsing large amounts of JSON sucks.

I think that can hold true whether you’re talking about JSON or XML. In fact, I find that parsing a given XML feed into business objects eats up a sizable chunk of time on any project. Their solution was to send compiled plists rather than big chunks of JSON, which cut the import time down by more than an order of magnitude. Not too shabby.

Compiling a plist server side doesn’t seem to be as big of a chore as you’d think. In fact, there’s a github project that will do the server side compilation for you. We have a couple of end-to-end products developed here at Mindgrub that we’re going to look at implementing using compiled plists over the XML we’re using now.