A mobile app developer’s dream is to walk into the office on day one of the first sprint of a new project and find the bounty of a fully functioning web API laid before him. He locks eyes with the developer next to him and sheds a single tear, not out of sadness or even joy, but with the grim satisfaction that both recognize as meaning “We’ve earned this.” Before them stands a pillar of perfection, an endpoint standard that will never change throughout the lifetime of the project, a bastion of coding best practices that meets their exact needs. Sadly, this is usually not the case: API teams get delayed, endpoints get altered to an unrecognizable state, and servers go down for annoying, albeit necessary, maintenance. Thankfully there are several ways to simulate incoming data in the meantime.
Here at Shockoe we handle incoming application data in three stages: mock fixture data, mock API data, and client API data.
Mock fixture data is a simple tool: static properties that allow you to quickly lay out screens with plausible values. Pages load instantly, because you’re not making any API calls, which is useful in the early stages of constantly going back and forth between the code and the app to change a border width or a shade of blue.
Once the screens are laid out, however, it’s useful to make actual API calls that rely on Wi-Fi and mimic the latency of calls to the client’s servers. This can reveal cases in which the app should utilize blocking UI to make sure the user can’t click on anything else while the API call is going out, or instances where there should be an activity indicator if the wait is going to be long.
Here at Shockoe we like to use Mockaroo, a fantastic resource for mock data that can be accessed through their API. The steps are simple: create a schema for your data and populate it with the types of properties you want returned (eg Person, with firstName, lastName, address, phone). Then make a call to Mockaroo’s API, specifying the schema and return type in the parameters. These parameters range from city names and email addresses to formulas and regular expressions. The most important aspect of this data is the randomness. Programmers filling in fixture data might have never dreamed that they would see their city property populated with Parangaricutirimicuaro, but when Mockaroo sends it, it exposes the fact that the field is too short or overlaps with other labels.
Another useful Mockaroo feature is missing data. You can specify what percentage of the time you want a certain field to return a blank value, so you can be sure that your app handles this from both a UI and functionality perspective: making sure the interface still looks good when certain properties are missing, as well as not crashing.
The end goal is to make the process of integration to a client’s API as smooth as possible. Indeed, a project manager’s pillar of perfection would mean this process is a simple URL swap. And while this is almost never the case, the Shockoe process leaves us more than adequately prepared to face that crumbling pillar and get through with integration unscathed, no matter what comes our way.
Sign up for the Shockoe newsletter and we’ll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.