Tip: Going from a Universal to Single Device App

posted April 20th, 2012 in Development

We were recently asked to release the iPhone portion of a universal iOS app ahead of the full iPad part. This really isn’t difficult to do providing that you know the trick; however, judging from other posts that I’ve read, there seems to be some confusion surrounding this process.

The first and most obvious thing you need to change is a build setting. Select your project or target then go to build settings and search for the term “family”. You’ll be left with a setting called Targeted Device Family. Here you select the family you want. In our case we chose iPhone.

Now, if you run this on the iPad simulator the window will appear as though it is an iPhone app but your iPad application delegate will be executed. This probably isn’t what you were expecting. The less obvious change you need to make is this: Go into your applications info.plist and there you will see two rows named Main nib file base name. One will be for the iPhone and the other for the iPad. To get the proper application delegate to execute you need to remove the line for the iPad (in our case).

Now when you run your app on the iPad simulator the iPhone application delegate will run.

ZoneIn Goes Live

posted April 26th, 2011 in Development, Open Source

We’re pleased to announce ZoneIn, an iPhone app representing our contribution to the Vancouver’s Open Data Framework initiative. Click here to find and download it from the iTunes App Store, or search for it by name in iTunes.


This app was born out of necessity. In fact, I never thought I’d care about zoning information until last year while looking for an office space. I was about to sub-lease some space from a company that was eager to move out East to Washington, DC. While checking out the place, the current tenant commented that I should make sure that my business category was compatible with the city’s zoning by-laws for the office. He continued to explain how he had failed to do this before signing the lease and was shocked when he went in to apply for a business license only to be rejected. After an afternoon of negotiating, he was given conditional approval to do business – in his office.

This place was my first office space and I would have made the same mistake had it not been for his sound advice (Thanks Nick).  Later, while trolling the City of Vancouver’s Open Data catalogue I came across thezoning data and immediately saw an opportunity: an app that enables people check property zoning by-laws by location.

How it Works

The app brings together three key systems: the iPhone app, Fullboar Spatial Services, and Google API. To better understand how it works I’ll take you through the app’s workflow: First, you enter an address and hit ‘lookup’ – pretty straightforward so far. The app will take the address and run it through Google’s Geocoding API to `clean up’ the address and get the associated coordinates (latitude and longitude). Next, the address and coordinates are looked up in our spatial database that contains the city’s data. The address is first checked against the City of Vancouver’s Zoning Districts and Labelsdata. If a match is found then the polygon (property) coordinates and the URL for the district schedule are sent back to the app for display. However, if the address is not found then a backup method of reverse geocoding is used to determine the zoning details. This method takes the coordinates supplied earlier by Google and searches all of the properties to find a match. If thezone details are found by either of the above-mentioned methods, then the app drops a pin on the coordinates and provides you with an annotation detailing the zone type and description. Tapping on the annotation brings up the complete schedule (PDF) for that zone type.

Known Limitations

The address matching is not perfect – yet. While Google does a good job of `cleaning’ the address, it does not necessarily match the format used by the City of Vancouver. This may cause an address lookup to fail and the fallback method of reverse geocoding to be used. I don’t find the fallback method to be as accurate as I’d like.

Zone information is only available for addresses within Vancouver’s boundary.

When the drop pin is placed at the specified address coordinates it does not always look like it’s in the right place. A good example of this is `321 Railway St.’ For this example, the zoning information is correct, however, the drop pin is placed across the street at Two Chefs and a Table restaurant.

Going Forward

In the future we’ll expand the app to include more property data (community suggestions are welcome). In addition, we will continue to improve the address matching capabilities, as well as add the city’s boundary in order to alert you when a address is not part of Vancouver.


The thin edge of the mobile money wedge: NFC

posted May 11th, 2010 in Business

This year at the CTIA Wireless 2010 conference in Las Vegas I attended a seminar on mobile money. The overarching theme of the seminar was the desire to break the payment duopoly of VISA and MasterCard and the technology required to facilitate this. A consensus emerged that micro-payment was the thin edge of the wedge for breaking the duopoly and Near Field Communication (NFC) is the champion technology to deliver this.

Micro-payment is generally understood as a transaction under $10 that is primarily used for “convenience purchases”. Ten-dollars is the magic number because it marks the threshold below which consumers will make spontaneous purchases and because it is not risky for underwriting purposes. In addition, people generally do not begrudge paying a small fee for the convenience. For example, most people faced with a situation where they didn’t have change to plug a parking meter would be willing to pay a $0.30 transaction fee for $3.00 worth of parking rather than risk getting a $45.00 ticket. The best example – and the proverbial `killer app’ for micro-payment – is transportation ticketing. It’s worth mentioning that both the parking industry and transit authorities recognize these opportunities and are working to capitalize on them.

The mechanism used to deliver micro-payment capabilities to the end users is contact-less technology integrated into a mobile phone – specifically, Near Field Communication enabled smart phones. NFC has been the next-big-thing in this industry for years; however, the consensus at the mobile money seminars was that the technology would gain traction in the late 2010s. This is, in no small part, attributed to a commitment by VIVOtech and Nokia to get the technology to both the merchant (through the VIVOtech terminal) and the customer (through the mobile phone); this solves the chicken-and-egg problem that has been plaguing the industry for years. Apple has also staked a claim to NFC based on some recent patent applications. NFC is absolutely essential to mobile money because it provides everyone with a common, standardized technology to work with. Without it, the convenience factor would evaporate and customers would face the nightmare of different smart cards for every application from ticketing and parking to loyalty programs.

So what does this mean to you, your business, and your mobile app? It means that right now is the time to be strategizing about how you are going to leverage NFC for your payment solution, your loyalty program, or your coupon/marketing campaign. If you don’t use NFC, mobile money will blaze in on the next iPhone release and you will not only be scrambling to understand mobile-money, but frantic to regain a competitive advantage and implement NFC.


Going Git

posted December 27th, 2009 in Uncategorized

was never a big fan of distributed source code management – I was perfectly happy delivering our projects through Subversion. Then, shortly after ourTransDrive project was completed, we went to the 2009 Qt Developer Days conference and my opinions changed. Our client asked for some last minute changes and what followed was no surprise – Murphy’s law taught me something the hard way.

My source code was out of sync on my laptop, and, due to high US data roaming rates, I could not tether to sync it with the main server. We went straight to our flight where I spent several hours being less productive than I would have liked. On the second day of the conference, the Internet connection flaked out and I could not sync with the main server; once again, I was not as productive as I could have been.

When we returned from the trip I promptly started researching distributed source code management (DSCM). What I learnt from my research is this: All the main DSCM applications are more-or-less the same and the differences that do exist are more important to the developer’s workflow than the application’s technical merit. While we love and use Python regularly, out of Mercurial and git we went with the latter. After much reading and testing gitand Mercurial we eventually settled on git for a few reasons:

  • Used by projects we are heavily dependant on: Qt and Linux;
  • Branching and merging techniques align with our workflow;
  • Great Linux and OS X support;
  • Very good Subversion integration.

For me, the second and last points were key. The branching and merging in git worked according to my beliefs and workflow and was therefore a natural transition for me. The last point is important because we need to continue work on TransDrive and thus integrate with Subversion.

The take away points here are: Expect the best but prepare for the worst – don’t let technical issues block your business. The second point is to go with what’s right for you – don’t decide on software because of trivial technical differences.