clever/you - thoughts about mobile

There’s a lot of debate over the best way to interview and screen developers. It turns out that many people claiming to be software engineers - particularly those pushed upon you by recruiters - tend to be unable to write code in any shape or form. This sounds hard to believe, but it’s absolutely true. You wouldn’t believe how many interviews I’ve had to cut short because it became rapidly apparent the candidate wasn’t able to write code (depressingly, some of those candidates had masters from reputable UK computer science departments, but more on that another time).

About six years ago, the FizzBuzz test - a simple screening question for programmers - was highly publicised by Jeff Atwood on his blog. Programming questions in interviews are not new. But whilst Google, Facebook, and the like might ask you complex graphing problems, FizzBuzz just tests one thing: do you know how to write a loop, and how to write a conditional. Here’s the question:

Write a program that prints the numbers from 1 to 100. However, for multiples of three print “Fizz” instead, and for multiples of five print “Buzz”. If a number is a multiple of both three and five print “FizzBuzz”.

One problem I’ve always had with FizzBuzz is that although it weeds out the really bad candidates, it’s both a little clichéd, and also has very little scope for further discussion. Instead, when I interview people - for both full time and contract roles - I ask them my own ‘FizzBuzz’ like test, but with a key difference. Here it is:

Write a program that prints out the prime numbers from 1 to 100.

I really like this question as an interview screener. Why? Because it’s only marginally more complex than FizzBuzz (you need to know what a prime number is), but it’s also far more flexible. It tests:

• Knowledge of for loops
• Knowledge of conditionals
• Integer math

If a candidate solves it immediately, you can start talking about ways to increase efficiency when dealing with an increasingly large range (say, all the prime numbers from 1 to 1,000,000). This could range from really straightforward optimizations through a full sieve implementation.

And before you say “wait, that’s far too simple”: perhaps you haven’t had the pleasure of interviewing in the wild. I’ve had candidates who didn’t know what a prime number was, who implemented it by working out the prime numbers up to 100 by hand and pre-populating an array with them…seriously mad stuff. It’s a great question, and I’ll be sticking to it (…or will I? I probably will, but if you ever interview with me and have read this post I’ll expect something pretty impressive!)

This week I put up an AdSense banner on the right hand side of the blog. I did this for a couple of reasons - firstly, the Twitter feed is currently broken since it used to old V1 API, so there was a lot of blank space. Secondly, I’m going to try a little App Vs Blog experiment over the next few months to see what the difference in income is.

If you weren’t aware, I write a rather niche UK law app that sells for £2.99 (currently undergoing some love and attention while I update it for iOS 7. But more on that another time). As you might expect, there’s a limited audience for such things. This month, I made £20 from it. Will the ad do any better? I’ll let you know next month.

Last month I posted about three timesaving debugging tools, among them DCIntrospect and PonyDebugger. Both of these tools are free, but for those who don’t mind forking over some hard earned cash there are some paid options that could be just as useful when delving into the mysterious world of iOS app debugging.

Spark Inspector has two main features - like PonyDebugger, it allows for view hierarchy inspection, but in a much more graphical way (akin to Firefox’s ‘tilt’ 3D view). In addition, it lets you view all notifications (of the NSNotification kind) being sent through your app, again in a very friendly tablular format. Here’s what it looks like whilst running one of my apps:

As you can see, it’s easy to both dive into a view layout and modify parameters ‘on the fly’. Spark Inspector works thanks to something called ‘method swizzling’, a way of replacing or patching methods you don’t have access to. It’s simple to integrate, requiring a framework and a few lines of code (mainly to ensure you don’t accidentally include the library in your production releases).

The app is $39.99 - whether it’s worth it to you or not depends how often you find yourself debugging complex view layouts (or notifications). For an app teeming with NSNotifications and brandishing a custom interface it could be well worth it.

Reveal similarly displays view hiearchies in an attractive, 3D view, along with full dynamic control over parameters and properties. However, it lacks the notifications debugging view of Spark Inspector entirely, and it’s not ‘real time’ - Spark mirrors your UI automatically, whereas with Reveal you will have to ‘snapshot’ it.

Part of this is down to how Reveal is implemented at a code level, but it’s also a very new tool, having just been released. Hopefully new features will be added to make it more competitive. As a result, Reveal is currently in free beta. Integration is similarly straightforward, and you may want to check it out. Since the company behind Reveal (Itty Bitty Apps) haven’t announced final pricing it’s hard to make a judgement call at this stage.

Having taken a look at AFNetworking in brief, let’s dig a little deeper and see how we can cache our responses. Caching often gets neglected during development, but it can make a big difference - especially if your users are connecting over slow, cellular connections. Although AFNetworking supports caching by default, it’s not always obvious what’s being cached where. Sometimes it can be beneficial to have more finite control over our cache.

AFNetworking uses iOS’s built-in caching, provided by NSURLCache. NSURLCache was, for a time, somewhat variable in quality. Since iOS 5 it’s improved, but if you need to support iOS 4 you may also want to look at the open-source SDURLCache subclass. To have finite control over the cache we need to first create our shared cache, and then tell our network requests what cache policy they should follow.

The first step is to create our cache. A good place to do this is in your application’s delegate:

A cache has both in-memory (RAM) and disk capacities. The diskPath is a subdirectory of your app’s default cache directory (which won’t be synced with iTunes or backed up to iCloud).

AFNetworking will now use the cache we’ve created by default - however, by default iOS picks a caching strategy appropriate to the protocol you’re using, which is not always the best option. For example, as standard HTTPS traffic is not cached, which could be a problem if you’re interfacing with a rate-limited service.

Chances are then that you’ll need to set your own cache policy. You provide a cache policy when you create a NSURLRequest:

Here I’m using NSURLRequestReturnCacheDataElseLoad as my caching policy: this specifies that the cached data should always be loaded where available, regardless of any expiration date. You might also want to use NSURLRequestReloadRevalidatingCacheData (which checks the cache is still valid before loading), or NSURLRequestReloadIgnoringLocalCacheData (which doesn’t use the cache at all). Other cache policies are detailed in Apple’s documentation.

If your app consumes lots of memory, you might want to consider clearing out your cache in response to a memory warning. After all, what’s more important - having your responses cached, or stopping your app from crashing? Just add the following line into your applicationDidReceiveMemoryWarning method:

To help avoid this entirely, I’d recommend setting your cache to something fairly small, something around 4MB of in-memory storage.

So you’re writing an iOS app. What’s the one thing your apps almost guaranteed to need to do? Networking. Chances are at some point you’re going to want to talk to a web service, download or file, or send some data off somewhere - and you probably also don’t have that much time to do it in, so here’s a quick start guide for you.

Unfortunately, there’s a tendancy for developers new to iOS to gravitate towards the [NSData dataWithContentsOfURL:] method. What could be simpler? Set a URL, get a NSData object back. In practice, there are a number of problems with this method that mean it’s rarely used:

• By default it’s synchronous
• …and you’re probably using it on the main thread
• Very limited error handling
• HTTP GET support only
• No caching support

So what’s the alternative? Out of the box, NSURLConnection is the place to go for all things networking. The bad news is NSURLConnection and its related classes can, at first glance, be a little confusing. But help is at hand, in the form of numerous open source libraries that set to make networking on iOS a joy, not a pain.

One such library is AFNetworking. It’s used by developers big (Parse and Heroku use it in their apps) and small (me!).

AFNetworking has lots and lots of advantages, both for advanced and budding iOS developers. Here’s a top level summary of some of the features I like most:

• A category for UIImageView that provides asynchronous remote image loading
• Automatic parsing of JSON, XML, and the like
• A client interface for interacting with APIs and web services
• Compatible with NSOperationQueue

If you’re just starting out on iOS a lot of that might not have made much sense - AFNetworking is a library that will grow with you as you learn more about the platform.

First of all you’ll want to integrate AFNetworking into your project. The best way to do this, in my opinion, is to use CocoaPods (if you’re new to CocoaPods then check out my previous blog post about it).

Next, we’ll download a JSON feed. I’m going to use The Guardian’s API to retrieve the most recently published stories on their site.

Notice that since I know the API returns JSON I’m using AFJSONRequestOperation, a subclass of AFHTTPRequestOperation. This means that I’ll get back a parsed NSDictionary containing my results, rather than a block of NSData.

Although the code looks a lot more complicated than using dataWithContentsOfURL, it’s a lot more flexible: I’ve got JSON parsing, error handling, and asynchronous networking support from six lines of code (give or take). AFNetworking brings lots and lots of advantages, and very few drawbacks. Plus, it’s very widely supported - it’s the second most watched Objective-C library on GitHub - and as a result is extremely stable and well documented.

I’ve been using CocoaPods, the unofficial Cocoa package manager, for a while now in most of my projects. I thought it was pretty well known, but recently I’ve come across a fair few Objective-C developers who aren’t aware of how much time can be saved and pain reduced by using it.

In this post I’m going to take a quick look at what CocoaPods is, and how to get started with it. First off:

Fundamentally, CocoaPods is a package manager for Objective-C. A package manager provides an automatic way to download, install, and update software packages - typically, when programming, libraries. Well known package managers include RubyGems (Ruby), npm (Node.js), APT (Debian), and Homebrew (OS X).

For a long time, managing libraries in Objective-C was pretty tricky. Either you manually copied them over (and then subsequently forgot to update them), or you used something along the lines of Git submodules (with quite a steep learning curve).

Even then there were still lots of problems - you’d have to make sure your project referenced the right frameworks, maybe add set a few flags…each library often had its own unique install instructions (early versions of the Facebook SDK were particularly bad at this).

Luckily, some developers got a bit fed up with this state of affairs. “Why”, they said, “can’t dependency management be as easy as it is in Ruby?”. And thus, CocoaPods was born. With it, you can manage all your third-party dependencies and libraries almost entirely automatically. I cannot stress enough how awesome CocoaPods is. If you’ve never used package management before you’ll be amazed - if you’re used to things like RubyGems and npm you’ll be relieved.

First of all you’ll need to install CocoaPods. Pop into the terminal, and run the following commands:

$ gem install cocoapods
$ pod setup

…you may need to use sudo for the first line. Once that’s over, you’re ready to start using CocoaPods in your own projects. In the root of your project, create a new file named Podfile. This file will list all the libraries you’re going to need, along with some other optional information.

Here’s an example that uses two common libraries, AFNetworking and the Facebook SDK:

platform :ios, '5.0'

pod 'AFNetworking', '~> 1.2.1'
pod 'Facebook-iOS-SDK', '~> 3.2.0'

The first line of our Podfile tells CocoaPods what platform we’re developing for (in this case, iOS), and optionally the deployment target (5.0).

The next two lines list the libraries we want to use. CocoaPods maintains a website listing all the libraries currently available. Optionally, you can also request a specific version number. Here, we’ve used a special symbol (~>), which means ‘all minor versions above the stated version number’.

Now that our Podfile is setup we’re ready to go. In the Terminal we navigate to the root of our project, and run pod install. Get ready for the cool bit: Cocoapods will now…

• Download the latest versions of the libraries in our Podfile
• Download any dependencies that those libraries rely on
• Install them all into a special ‘Pod’ project, making sure all required frameworks and compiler flags are set
• Create a new Workspace containing our project and the Pods project

From now on, you work on your app inside the Workspace. You’ll be able to access all the libraries in your Podfile as normal, without any of the hassle of having to manage the installation or dependencies yourself.

Moreover, at any point you can run pod update to get the latest versions downloaded and installed automatically.

The podfile I’ve used above is very simple - there’s lots more you can do, such as specifying multiple targets, and advanced versioning logic. There’s lots more information at the CocoaPods GitHub wiki.

If you’re feeling helpful, you can also help add to the available libraries in Cocoapods, either by creating ‘podspecs’, or by updating existing libraries (this is one downside of Cocoapods: sometimes library specs are uploaded into the Cocoapods repository by third parties, and never get updated). Again, lots of information about this is available in the CocoPods wiki.

There’s really no excuse for not giving CocoaPods a go - it’ll save you time, and make managing third-party libraries a pleasure rather than the chore it used to be.

Before I started this whole programming lark, I used to work in theatres designing, rigging, and programming lighting. Just as we’ve seen smartphones bring rapid developments to the mobile space, the same technology (touch interfaces and embedded technology) has brought a lot of change to lighting.

For example, here’s a couple of desks I used to program on a lot - an ETC Express and a Strand 300.

They have a couple of things in common: lots (and lots) of buttons and faders, and a user interface that is a little…functional (think ASCII and DOS).

But here’s the latest and greatest in lighting control - the ETC Eos Ti:

…what’s changed? Well, a lot fewer faders for one thing. And there’s the two giant touch-screens up top (think two iPads glued into a lighting console). Oh, and the secondary touch-screen used as a color palette amongst other things on the right hand side. The rise of tablets and touch interfaces has brought benefits far beyond the world of mobile.

For a very long time, I used a Samsung Galaxy S2 as my Android phone (I engineer iOS apps, but it’s good to know what’s going on the world outside Cupertino). Unhappy with the long, long waits for software updates from Samsung, I switched a few months ago to the Nexus 4.

Being produced by Google, the Nexus 4 is the flagship Android device - so naturally you’d expect it to be an advertisement for all things Android. Unless, that is, you want to watch ITV on it.

For the benefit of those not in the UK, ITV is one of the largest TV networks in the country. Last week, they made a change to their Android app: for the next few months, at the very least, it is exclusive to Samsung devices. Here’s what ITV had to say:

> The fragmentation of the Android ecosystem is well known. Therefore, as a commercial broadcaster, it makes sense for us to partner with the leading manufacturer of Android devices to further increase our technical knowledge of the operating system.

This makes little sense: the Nexus 4, for example, is the recommended device for the development of the Android OS itself. If I was developing an Android app and wanted to maximise compatibility I’d probably target the reference device as standard.

Although ITV frame this as a technical decision, we should probably be realistic - maybe Samsung provided financial or development support to maintain some level of exclusivity. Either way, I personally don’t see an benefit for either party.

Personally, I don’t see Samsung getting their money’s worth here. Are people going to buy Samsung handsets so they can download the ITV Player app? Presumably not, because the exclusivity period ends in a few months. People will buy Samsung handsets because Samsung spend far more money than anybody else advertising them. And, as other people have noted, it doesn’t do Samsung many favours with regards to their Google relationship.

The ITV Player app isn’t exactly doing very well on the store:

…if you are going to limit it to select handsets on the basis that you want a more stable experience then you’d better have made some improvements. Unfortunately, this doesn’t seem to be the case judging from the reviews. Additionally, many existing users who are running older versions of the player on non-Samsung devices are providing one-star reviews expressing their displeasure.

It comes down to this: exclusivity deals are not, in of themselves, a bad thing (although Trusted Reviews has a great article that offers a counterpoint to this). They can provide cash-limited companies with money to develop interesting and exciting apps. But turning a previously widely available app into an exclusive deal: that’s not so good. Users don’t like it, and I don’t see the benefit for brands…especially if your disgruntled, locked out users start giving you bad press.

Some of my most popular posts are those about mobile backend providers Parse and StackMob. It’s been a few months since I last looked at them, and since then much has changed - so I’ve decided to take a comprehensive look at both the large and small players in the mobile backend space.

BaaS stands for backend as a service, and is used to describe a company that provides a way for front-end developers to ‘plug in’ to cloud storage, user management, push messaging, and the like without having to write and support their own server architectures.

If you’ve read some of my other blog posts you’ll know I’m a fan of BaaS. It’s not for everyone - large apps with millions of users, in particular, will of course benefit from their own internal systems - but if you’re starting out and need a quick and efficient data storage system that works across multiple platforms you can’t go wrong with BaaS.

The BaaS industry has come to be quite closely associated with mobile, partly because many companies sprung up in response to a need by native application developers for secure, reliable data management systems. There’s nothing to stop you using a BaaS provider to power your desktop web apps, but I’ll be mainly focusing on mobile here since that’s my field of interest.

Wikipedia lists some fifteen different BaaS providers - some large, and some very tiny. There are two main players in the market, the Facebook bound Parse, and StackMob. In addition, a number of smaller players are all vying for your business.

I’ve chosen to look at five different BaaS platforms and compare their strengths and weaknesses. Each provider has a brief review, followed by a pricing comparison and some general recommendations for what to look out for. Hopefully you’ll find it useful - and I’m always happy to answer questions either through Tumblr or Twitter (@objclxt). You can either read on, or jump to the provider you’re interested in:

• Parse
• StackMob
• Kinvey
• FatFractal
• QuickBlox
• Helios

Although not the oldest in the game, Parse is probably by far the most well known BaaS provider, if only due to it’s acquisition by Facebook last week.

As standard, Parse offers support for data synchronisation, push notifications, social integration, and custom code via server-deployed JavaScript. Parse has official client libraries for iOS, OS X, Android, JS, Windows 8 (desktop and phone), and .net. There are also many third party libraries available for languages such as Ruby, PHP, Python, Go, and the like. Currently, Parse’s first-party libraries are all closed source, which is a shame (hopefully this will change under Facebook). Parse is also well known for its excellent documentation, which includes complete sample applications and walk-throughs.

Server-side code is supported through Parse’s Cloud Code feature, which is JavaScript based. In addition to your own custom code, you can also plug into third-party modules to directly integrate with services such as SendGrid, Stripe, Twilio, Mailgun, and the like. Parse also recently added support for static hosting, which allows static and JS based pages to be served up quickly and easily.

Parse charges on a per-API request model, plus storage. Anything below 1 million requests is free, which for many low-usage projects will be more than sufficient. Their standard ‘pro’ plan provides 15 million API requests, 15 million push notifications, and 10GB of storage for $199 per month. Enterprise plans are also available with dedicated SLAs and the like.

To put that in some perspective, 15 million API calls a month lets you support 50,000 active users at 300 calls per month.

I do! Also, a number of large brands and agencies, including IDEO, Cisco, Hipmunk, BBDO, and Deloitte (it should come as no surprise that agencies tend to be big users of BaaS - they often lack backend expertise at scale, and many of their apps are for short-lived campaigns).

• Acquired and backed by Facebook (…or a con, depending on your viewpoint)
• Wide range of well supported SDKs
• Excellent documentation

• Acquired and backed by Facebook (…or a pro, depending on your viewpoint)
• Client libraries are closed source
• Custom ‘cloud’ code somewhat limiting compared to other providers

Stackmob has been in the BaaS business for a while, and along with Parse are one of the bigger players in the space. They aggresively compete, to the point where StackMob posted a “migrate from Parse tutorial” the day after Parse’s acquisition.

Stackmob offer broadly the same feature-set as Parse, but with a few additions such as distinct production / development environments, API versioning, and a more comphrehensive custom code framework that supports server-side Java or Scala. Many of these advanced features are made available on a modular basis in the StackMob marketplace (but more on that below). Both the Android and iOS client libraries are open source, and available on GitHub.

StackMob recently changed their pricing model from a usage based to a more generous ‘freemium’ model. Basic API access is both free and unlimited, but additional functionality can be ‘unlocked’ through the StackMob marketplace (if you’ve used Heroku this marketplace model will be familiar to you).

The downside of this is that depending on what you need this can end up being very expensive. For example, let’s say we want to support custom code and 5 million push messages a month. Both of these features are included in Parse’s Pro package, but with StackMob you’ll need to purchase each module separately. This ends up costing $399 for the push and $199 for the custom code, or a total of nearly $600. That’s three times as expensive as Parse for broadly equivalent functionality.

As a result, using StackMob could require some careful planning to make sure you only use the modules you absolutely require. Don’t forget to think about your future requirements when pricing up or you might have a very expensive surprise!

According to StackMob’s rather limited case studies page, the platform is used by Atari, ShopKeeper, and Meexo, amongst others.

• Unlimted API calls as standard
• Open source client libraries
• Good documentation

• Free plan has unlimited API calls, but missing functionality such as HTML5 hosting
• Paid modules quickly add up

Based out of Boston (woo), Kinvey have been around for a couple of years with their BaaS offering. They were recently selected as a Facebook Technology Partner.

Kinvey offers the usual plethora of data storage, user management, push notifications, and social integrations. They also offer versioned APIs and usage analytics. Additionally, Kinvey’s enterprise plans support existing authentication systems such as LDAP or OAuth, along with data links into products such as Salesforce CRM.

Kinvey bases their pricing on the number of active users. An ‘active user’ is defined as one that has made an API request that month. I’m not the biggest fan of this model, because it can makes apps with large numbers of users but with small backend requirements rather expensive. Kinvey do offer API pricing as an alternative, but you’ll need to get in touch with them directly to discuss further.

A number of marketing agencies use Kinvey, presumably on behalf of their clients, as well as Johnson & Johnson.

• Enterprise-level features such as LDAP, Orcale, Salesforce, and OAuth support (for those on enterprise plans)
• Agencies can benefit from Kinvey’s referral program

• Default ‘active user’ pricing model not suitable for all apps
• No ‘custom code’ support a la Parse or StackMob, although backend business logic is supported

FatFractal also seem very responsive to customer requests and feedback - I actually got in touch to ask whether they supported bulk data export whilst writing this post, and they implemented it into their system overnight.

Currently, FatFractal provide up to 3 million requests and 5GB of storage free of charge whilst in public beta. Their gold plan provides 12 million API requests and 15GB of storage for $200 per month. You should, however, be aware that unlike other providers, FatFractal charge for outgoing bandwidth overages. The gold plan include 12GB of outgoing bandwidth, and it’s $0.15/GB after that. I doubt for most people this would be a problem, but if you’re building an app that’s going to require significant bandwidth (video sharing, perhaps) you’ll need to take this into account.

In FatFractal’s defence, they are still in beta and have a limited client list as a result. They have a number of testimonials from smaller developers and agencies, and list a couple of minor apps in production.

• Responsive customer service, and quick to reply to feedback
• Very developer-centric business, which may appeal to some

• A smaller player in the business
• At the time of writing, still in beta

QuickBlox’s unique selling point is its discrete ‘modules’, such as video and text chat, leaderboards, and the like. More experienced developers may find this restricting.

QuickBlox’s pricing is probably best described as ‘opaque’. Their free tier offers unlimited API calls, and a 10GB traffic/storage limit. If you exceed this limit you’re offered three options - switching to an enterprise account (which requires a sales call for a quote), paying the hosting costs your app is consuming plus a 10% management fee (which, again, requires a sales call to get a quote), or cross-promotion sponsorship (…yep, that needs a sales call too).

It is a shame that QuickBlox are not willing to put any pricing information above their free tier on their site.

A variety of small apps, mainly being developed by marketing agencies, including the Official Dane Cook App(?) and a fan app for Liverpool FC.

• Modular approach may be appealing to novice developers

• Must call their sales team to get any pricing information

Helios is Heroku’s answer to the rise of ‘all in one’ BaaS providers. It’s an open-source backend framework that you can deploy directly to Heroku, or your own hardware if you prefer. It’s written by the highly respected Mattt Thompson, and combines data synchronization, push notification, in-app purchase, analytics, and passbook management into a single attractive GUI. There’s no single client library - rather, a collection of existing libraries such as AFIncrementalStore that integrate into the backend system.

As an open-source framework, Helios is completely free. You’ll need to pay for hosting though - either on your own hardware, or through a provider such as Amazon Web Services or Heroku. Since Helios is backed by Heroku I’m going to use that as a benchmark for pricing - a basic setup with a production database and several dynos will be around $120 per month.

Many popular apps use Helios’s discrete client libraries - I’m not aware of any apps currently using Helios itself.

• It’s free!
• Totally open source, with hosting flexibility
• Created by one of the best mobile developers out there

• OK, not really BaaS as you’re going to have to manage it!
• Currently best suited to iOS apps only
• If you’re not comfortable with basic server admin this isn’t for you

I’ve tried to break down both the free tier limits and the price you might expect to pay for ‘typical’ use with each provider. I’ve defined ‘typical use’ as an app with 40,000 active users, 12 million API calls per month (or 300 per user), and 500,000 push notifications.

* StackMob’s free tier has unlimited calls, but additional functionality that is free with other providers (such as HTML5 hosting or custom code) may cost extra. I have included StackMob’s Push module ($399) in estimating typical cost, but other modules such as custom code will add on to this figure.

FatFractal seems to be quite developer focused and led, whereas QuickBlox seem to be going after marketing agencies and judging by their lack of clear pricing information aren’t particularly interested in the indie space. I think Kinvey have a pretty exciting product, and their focus on enterprise integrations mean those building internal B2B apps may want to consider them.

I was initially very excited with StackMob’s new pricing structure, but the modular model they’re going for means it becomes very expensive to match Parse’s $199 plan functionality. Once you’ve added collaboration, push messaging, custom code, and hosting into StackMob’s package it becomes a very expensive proposition.

Finally, of course, there’s Parse. If you harbour negative feelings torwards Facebook you might have already made up your mind - personally, I’ve been really impressed with the speed at which Parse have added to their product, and I enjoy working with their client libraries. Who knows exactly what Facebook will do with Parse long term, but post-acquisition they’re still adding new features such as HTML5 hosting.

Don’t forget, the usability of the client libraries is just as important as the features and pricing. You’ll be working with your chosen provider’s APIs and SDK a lot - you want the experience to be pleasurable. I recommend taking a look at sample code, and maybe trying out the various libraries yourself.

You’ve probably read that this week Facebook acquired Parse, the mobile BaaS service. I’ve been using Parse for quite a well in production, and if you’ve read any of my previous posts you’ll know I quite like the service (see here, here, and here).

So what now? Does Facebook acquiring Parse change anything? Well, if you go by the press releases, no - it doesn’t. But perhaps there’s more too it than that. What should you be doing if you’re either an existing customer (like me), or someone who’s been thinking of using the service? Here’s my own thoughts on the subject.

A lot of what you do next is going to depend on your own gut feeling. Some people have quite a visceral reaction to Facebook - I’m not one of them. What I will say is that the last time Facebook bought something I used (face.com) they ended up shutting down the APIs. But Parse is considerably bigger, and more importantly is used by some sizable customers. I personally don’t see Facebook cutting them off - and I suspect new customers will be welcomed for some time as well.

The bottom line is this: whenever you use any third-party provider to manage critical infrastructure in your apps you’d better have an escape plan. Companies get acquired, go bust, or retire products all the time. This isn’t an issue unique to Parse. If you’re not planning for the worst you’re sowing the seeds for a big headache in the future.

Parse already offer a mass-export feature that gives you all your data in JSON. You can use this, along with the Parse APIs, to migrate over to another provider fairly easily (although some scripting on your part may be required). One provider (Stackmob, who I’ve reviewed here before) even have a semi-automatic migration tool available.

Again, this is going depend on how you feel about Facebook. If you’re not a fan, you’ve probably already made your choice. Here’s my two cents: even if Parse keep supporting existing customers, it’s almost certain that at some point in the future the product is going to change in a fairly significant way. I don’t see Facebook gaining any value from running Parse as an entirely separate entity.

I really like Parse as a product - I’ve used it in several production apps. Would I use it now? I’m not sure. I don’t necessarily think any of the competitors out there (Stackmob, Appcelerator, Kinvey, Fat Fractal, to name a few) are any more secure. If anything, financially speaking Parse is now top of the pile.

I appreciate I haven’t really provided many direct answers. One thing this should really re-inforce, regardless of your BaaS provider, is that you need a back-up plan. To help with that I’ll be posting a new backend-as-a-service comparison in the coming weeks, updated to take into account all the recent changes in the marketplace.

OK, so it’s not a very exciting topic - but still, it can often be a pain to convert JSON into Objective-C objects. There’s a lot of boilerplate code, and you invariably end up with something like this:

…and that’s just to decode from JSON. If you need to subsequently archive your object back to JSON you’ll end up with even more brittle and lengthy code, thanks to encodeWithCoder and its counterparts. Finally, you’d better hope your JSON never changes, because in the example above if there’s no url field in the dictionary an exception is going to get thrown.

I had to deal with this problem recently - I was working with a quite complex JSON API, and I needed something to help me manage my models. Fortunately, Github have open-sourced a framework used in their own Mac application called Mantle. Mantle aims to simplify the process of working with JSON in Objective-C, particularly in places where something like Core Data might be overkill. It works without NSCoder, and uses @property declarations to provide default implementations.

Here’s an implementation of the Article example above, but rewritten to use Mantle:

A really simple JSONKeyPathsByPropertyKey method maps JSON to properties, and reversible transformers allow things like dates, URLs, or other custom formats to be both encoded and decoded easily. The value transformers also handle missing or nil fields, meaning you don’t have to worry about exceptions.

I’m really enjoying using Mantle, and it’s made my code cleaner to read and easier to maintain. The source for Mantle, along with pretty comprehensive documentation, is available on GitHub, and you can use it in your own projects via the ever reliable CocoaPods.

Debugging is twice as hard as writing the code in the first place
Brian Kernighan - The Elements of Programming Style

Debugging your own code may be a chore, but debugging somebody else’s can be downright painful. A particularly bad experience last week reminded me that debugging is as much a skill as writing code itself - and just like programming, there are lots of tools that can make it both easier and even enjoyable.

Here are three really useful tools that I use when debugging iOS applications.

Hidden away on Apple’s developer site is Technical Note 2239, or iOS Debugging Magic. It’s packed full of tips and tricks to help the frustrated iOS debugger get to grips with XCode. Unfortunately, it’s also slightly out of date, written for iOS 4.1, XCode 3, and GDB (rather than the newer LLDB debugger now standard for iOS development).

Still, it’s still broadly applicable, and it’s the only place on Apple’s site where recursiveDescription, a category extension on UIView that lets you print out a view’s complete hierarchy, is documented. This alone justifies its existence:

Command line debugging is extremely powerful, but as many web developers will tell you being able to visually debug can be just as useful. Although Apple provide some tools to do this (such as the Core Animation Instrument), a number of third party options are available to help with layout problems.

DCIntrospect is one such popular library - designed to be used with the iOS simulator, it enables a number of keyboard shortcuts to allow dynamic manipulation of views.

Installation is particularly straightforward, so DCIntrospect is a good option if you need to quickly debug more complex view hierarchy or display problems.

PonyDebugger is one of the more complex iOS debugging tools - it requires both a client on device and a server on your development machine - but it’s arguably worth it in the long run. Once installed, you can remotely debug network traffic, Core Data, and view hierarchies using Chrome’s Developer Tools. It’s maintained by the good people at Square.

The networking traffic tools in PonyDebugger supplement, rather than replace, a traditional proxy. Because networking traffic is forwarded rather than sniffed traffic sent over HTTPS/SSL is viewable without needing any special certificates. The Core Data browser is also a nice touch, and is directly integrated into the traditional Chrome dev tools ‘resources’ tab. One particularly nice feature of PonyDebugger is its ability to convert an app’s view hierarchy into a HTML-like format that can be immediately edited, just as you would a normal web site within Chrome’s developer tools.

All of these features do come at a cost, namely a somewhat complex installation - I’d recommend using CocoaPods to handle the client library. You should take care for both DCIntrospect and PonyDebugger to only enable them in your debug builds, as you definitely don’t want either library to end up in your production code.

If you’ve read my previous posts you’ll know I’m a big fan of Parse and other Backend-as-a-Service providers. However, they’re not for everybody - especially if you need control of your own servers, or aren’t comfortable with out-sourcing your application’s data to a third-party.

With that in mind, I’m really excited about Helios, from Heroku and Mattt Thompson. Helios provides data synchronisation, push notifications, passbook, in app purchase, and analytics support ‘out of the box’. It’s open source, and - importantly - instantly deployable to Heroku (naturally). This means developers who are not willing or able to manage a full backend server stack can quickly get a full mobile backend platform running on a managed provider or hardware of their own.

Full source code and documentation is available on GitHub, and it integrates well with many standard libraries such as AFIncrementalStore. It’s good to see Heroku moving into the mobile backend space, and I’m sure there will be a number of Helios backed app in the iTunes Store soon.

One of the new features in iOS 6 that hasn’t exactly been shouted out from the rooftops is state preservation, probably because on paper it’s far from exciting. However, having implemented it into an app I’ve realised there are some great benefits - not least of which is making your users happier.

State preservation is designed to solve the problem of app termination. The majority of iOS users don’t know the difference between application backgrounding and application termination. Anecdotally, many people who test the apps I work on are unaware that removing apps from the ‘recent apps’ list terminates them completely.

This can result in quite a confusing and frustrating experience: sometimes coming into an app will take you back to where you were last, and at others you’ll be back to square one. Some developers had attempted to solve this by keeping track of the current app state and attempting to restore it upon relaunch. Inevitably this led to a number of different approaches, some good and some bad.

The good news is that iOS 6 now offers state preservation out of the box, and enabling it is a simple two step process:

To keep track of a user’s journey through an app you need to provide restoration identifiers for your view controllers. You can identify as many or as few controllers as you wish, but only controllers with restoration identifiers present will automatically instantiated and navigated to by iOS upon launch.

If you’re working with XIBs you can add identifiers within Interface Builder - and with Storyboards it’s even easier (since Storyboards already track a user’s progress through an app). In code you can simply set the restorationIdentifier property.

Currently, state preservation is ‘opt in’. To opt in you need to implement three methods in your application delegate, described below:

- (BOOL)application:shouldRestoreApplicationState:
Sometimes you might not want iOS to automatically restore the user’s state: perhaps your app has had a major UI update, and the area of the app your user was last in no longer exists. You should return YES to enable restoration.

- (BOOL)application:shouldSaveApplicationState:
As above, except this method is called when you application is terminated. Again, return YES to allow iOS to save the most recent state information.

- (BOOL)application:willFinishLaunchingWithOptions:
To support state restoration a new launching method has been introduced that complements the more traditional didFinishLaunching. willFinish is called before the state is restored, and didFinish is called afterwards. You’ll probably therefore want to split your launching code across these two methods: code that is required for your app to run should go in willFinish. Final completion code should go in didFinishLaunching. What counts as ‘final completion code’? Things like checking whether a user is logged in, where you might want to display a modal login page rather than your app itself, for example.

If you’d like to support iOS 4 and 5 users (where state preservation is not supported) you’ll need to watch out for a few things. Firstly, be sure to test that restoration identifiers are supported using respondsToSelector (if you’re using IB you can skip this step):

if ([self respondsToSelector:@selector(restorationIdentifier)]) {
        self.restorationIdentifier = @"Home Controller";
}

However, a more serious issue is how to deal with the new willFinishLaunchingWithOptions method, which is only available on iOS 6, into which you’ve moved most of your launching logic. You could put your launch code into both willFinish and didFinishLaunching and conditionally test the current version of iOS, but this is unnecessary duplication.

Instead, you can use this great little trick which Apple recommend in their WWDC videos:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [self commonLaunchInitialization:launchOptions];

    // Code that must execute in didFinishLaunching whether state restoration is enabled or not
    return YES;
}

- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [self commonLaunchInitialization:launchOptions];
    return YES;
}

- (void)commonLaunchInitialization:(NSDictionary *)launchOptions {
    static dispatch_once_t pred;
    dispatch_once(&pred, ^{
    // Your launch code here
});

If you are not familiar with Grand Central Dispatch you’re probably wondering what this code does. The dispatch_once GCD call is a clever method that is typically used when doing singleton work: it will execute it’s code block once only, and no nothing for any subsequent calls. This allows us to guarantee our launch logic will only be executed once, even though we’re calling commonLaunchInitialization in both didLaunch and willLaunch.

For reasons that will become quickly apparent, there are a few ‘gotchas’ involved with testing state restoration. Confusingly, terminating an app from the app switching pane disables restoration. Why? To prevent a mis-behaving or broken app from keeping a user stuck inside a loop. Perhaps the app has some terrible networking code that keeps the user locked inside a loading screen - resuming to that state would not be beneficial. Similarly, as you might expect state will not be resumed if your app didn’t terminate cleanly (i.e, it crashed).

So how do you test app switching? Well, when attached to the debugger you will want to exit to the home screen (by pressing the home button) and then terminate the app from Xcode (by hitting the ‘Stop’ button).

Over at Mobile World Congress this week, Samsung was busy announcing it’s new Samsung Wallet. Unfortunately, it’s pretty clear that Samsung rushed this out the door: there’s vast amounts of functionality missing, the developer documentation is poor, and unlike Microsoft or Google’s efforts it just feels a little half hearted.

Apple Passbook lets you distribute your passes in three ways: through a native app, through a web site, or via e-mail. The advantage of this approach is that brands without a presence on the app store can still offer consumers passbook enabled tickets, cards, and vouchers.

However, Samsung Wallet only supports distributing passes through a native app. To get technical, this is because to get a pass into Samsung Wallet you need to use intents, which allow apps to call actions within other apps.

For better or for worse, Apple have chosen not to put NFC into their phones. Samsung, however, haven’t only put NFC into many of their Android devices, they’ve made it a unique selling point, spending millions of dollars on TV commercials waxing lyrical about S Beam sharing. So to not have Samsung Wallet support NFC is more than a glaring omission - it’s embarrassing.

Samsung’s stated reason for not supporting NFC doesn’t really ring true either - apparently, retailers don’t have NFC hardware. Except for all those contactless card readers in CVS, Walgreens, Boots, and the like.

1D barcodes are ‘old school’ barcodes, like this:

Apple Passbook doesn’t support them - Samsung Wallet does. Now, you might think that this was a point in favour of Samsung Wallet, but it’s not. I think it’s a big mistake. When Passbook was in developer beta, it too supported 1D barcodes. Apple removed support before releasing it to the public.

The reason for not supporting 1D barcodes involves how barcodes themselves are scanned. When barcodes were first released, scanners used lasers to detect the codes. The laser light bounces off the white bars of the code, and is absorbed by the black bars. By detecting the laser light bounced back you can read the barcode. This is fine when your barcodes are printed on card or paper - but when your barcode is being displayed on a piece of reflective glass you’ve got a big problem.

Although some retailers have upgraded their point-of-sale systems to more modern, optical scanners (that can also scan QR and other 2D barcodes), many are still using lasers. Trying to scan a 1D barcode on a phone with a laser will result in failure a lot of the time. Users will either blame the shop themselves (bad), or the handset manufacturer (even worse, from Apple or Samsung’s point of view).

Basically, expect a lot of angry tweets along the lines of “the Samsung Wallet app is terrible, nobody can scan barcodes off it” for retailers who choose the ‘easy’ path of 1D barcodes.

I don’t want this post to come off sounding as if I dislike Samsung - on the contrary, until upgrading to the Nexus 4 my primary Android device for a Galaxy S2, which I got along with very well. But I find many of Samsung’s ‘own brand’ applications to be generally sloppy, with little thought put into long-term sustainability.

As it stands, the developer documentation for Samsung Wallet is poor, and the way vouchers are requested/generated is confusing and ill thought out. I wonder whether Samsung will truly see mass-adoption in the same way brands have flocked to Passbook. It’s a shame, because I suspect given another month or so Samsung could have had a product that was far more professional and better received by the community at large.

The way computing is taught throughout schools in England is going to drastically change from next year - and, importantly, the proposed new curriculum is under public consultation. The consultation runs until April 16th, and anyone with an interest in computing education in the UK should consider reading through the proposals and contributing his or her thoughts.

The good news is the new Computing Curriculum is a quick, four page read. The bad news is that responding to it is something of a bureaucratic nightmare - but more on that later.

One of the biggest changes (outside of the overdue renaming of the subject from ‘ICT’ to ‘Computing’) is making programming of some sort mandatory for all students. The UK has, for the time being, got the jump on the USA. Let’s take a look at exactly what sort of coding is being suggested for the relevant age groups:

By age seven, children should be able to “understand what algorithms are”, “write and test simple programs”, and “use logical reasoning to predict the behaviour of simple programs”.

The curriculum doesn’t prescribe how exactly this should be taught, and with what platform or software. The general expectation is that environments such as Scratch will be used.

By the end of their primary education, children should be taught how to “use sequence, selection, and repetition” in their programming projects, and be familiar with variables. They are also expected to demonstrate a basic understanding of algorithms, and how to test and diagnose errors in their programs.

Again, there’s no prescribed toolset, and Scratch would be more than able to fulfil all the curriculum requirements.

In secondary school students should continue to program, in “two or more programming languages, one of which is textual” (emphasis mine). They should also be fully versed in boolean logic, data structures such as arrays, and “use procedures to write modular programs”. More interestingly, students will be explicitly required to “understand at least two key algorithms for each of sorting and searching”.

Having read the curriculum in full you’ll probably have some comments to make. Unfortunately, the Department for Education have had to take their e-consultations tool offline, “due to technical problems”. It has been replaced with a thirteen page Word document which you must then upload via a rather confusing web form. It could be worse. It could also be a lot better.

So with that in mind, here’s how to respond in three ‘easy’ steps:

1. Download this Word document

2. To respond specifically to the new Computing curriculum fill out Sections 3, 4, and 7. Section 14 can be used for any additional comments, and you may also want to fill in Section 15, which provides feedback on the rather convoluted consultation process itself.

3. Once you’ve finished filling in the Word doc you can [upload it here] (make sure you indicate you’re responding to “Reform of the National Curriculum in England”), or e-mail it to NationalCurriculum.CONSULTATION@education.gsi.gov.uk

It’s that simple! I highly encourage you to take half an hour out of your day to respond - you have until April 13th, and the more people who comment the better.

Snapchat has been getting a lot of press recently, so I decided to take a look at the app. In doing so, I came across a security vulnerability that allowed anyone to obtain a Snapchat user’s cellphone number and e-mail address without their consent. This is a serious security issue, as many Snapchat usernames are publicly available.

Snapchat lets you find out if any friends who might have you in their contacts are using the service. To do this it needs your phone-number: on Android, this is obtained automatically. On iOS, however, you need to verify your number by sending a SMS to Snapchat with a unique code (partly to prevent abuse, but mainly because unlike Android, iOS does not allow system access to the device’s phone number). The Snapchat app makes a web service call to discover whether this SMS verification has succeeded or not. The call looks like this:

POST https://feelinsonice.appspot.com/ph/settings
username=john.smith
timestamp=1357768038866
req_token=13f413fwrf4[…]

The req_token is a little strange (it’s an obfuscation of two separate hashes), but fundamentally it contains the user’s authorisation details. If you’re interested you can find out more about how the req_token is generated here.

In response to that call you receive the following back:

{
    "message": "+16175551212",
    "param": "[base64 encoded username]",
    "action": "[base64 e-mail (optional)]",
    "logged": true
}

This information is used to display a user’s account information inside the app. Notice that the phone number for the requested user is returned. Normally the supplied req_token would be checked and compared with the supplied username to ensure a user’s private information wasn’t being handed out freely.

Unfortunately a bug in Snapchat’s backend system meant this call wasn’t being authenticated - by changing the username parameter of the POST request it was possible to retrieve any user’s phone number. The req_token simply isn’t checked or even looked at: given a username the system blindly returns a phone number.

As a good number of Snapchat users are using the service anonymously this is a very serious vulnerability. Many people have even posted their Snapchat usernames in reviews, tweets, or tumblrs. Depending on what you are doing in Snapchat you may not want other users to identify you. However, by taking advantage of this vulnerability anyone could easily find out a Snapchat user’s phone number and e-mail.

I disclosed this vulnerability to Snapchat shortly after discovering it, on Tuesday January 9th 2013. Snapchat were very responsive, and the issue was patched in less than twenty-four hours. I have confirmed that it is now fixed, and you can no longer abuse the call to obtain users’ personal information.

Security issues are to be expected with any large app or web service with millions of users. However, this error was very basic and shouldn’t have happened. That said, Snapchat were very receptive to disclosure, and it was patched almost immediately. Snapchat has grown exceptionally quickly, which I suspect has exacerbated some of their recent security problems.

Snapchat’s API is on occasion quite strange, and as security blogger Adam Caudill has pointed out out relies quite a bit on security through obscurity. I agree with Adam that Snapchat should consider using some of their recent funding to externally audit their systems and reduce the risk of this sort of thing happening in the future.