Mobile Couch

Creating great apps for Apple’s mobile devices.

This podcast is no longer in production.

56: Special Opportunity

Published 4 May 2015 Hosted by Ben Trengrove, Daniel “Jelly” Farrelly and Jake MacMullin

Jake has his watch in hand, so after going back over some unit testing follow-up, and with a single weekend’s experience, the couch looks at first impressions, the various delays that people are struggling with, and handling multiple asynchronous tasks with dispatch groups.

Jelly segues seamlessly into follow-up, and talks about how he spent some time since the previous episode creating unit tests for one of his open source projects. He struggled a little with getting started, but feels like the endeavour was worthwhile (it found bugs!). He’s still wary about full test-driven development though.

Pre-ordered watches have started arriving, including Jake’s, and so the couch discusses the pre-order experience, Apple’s offer of expedited orders to random developers, and the watch labs that were offered prior to the launch for on-device testing of Apps prior to day one release.

This leads to both Jake and Jelly giving their first impressions, including the delay that they experienced with waiting for Jake’s glance to load it’s data, and the fact that there’s a large gap between the experience of first-party and third-party apps.

Jelly uses this as an opportunity to cover what gives him the inspiration for his apps, and how being the first in the store doesn’t prevent someone from coming along with a better implementation and succeeding.

Moving along, Jake talks about an issue he had this week with implementing multiple API calls for displaying data in a today extension. After trying a few solutions (including NSOperationQueue), and then he discovered dispatch groups, so after he covers how he implemented them, the couch discuss why you would choose them over an operation queue.

This spawns a conversation about APIs and how Jake’s implementation is covering up a potential issue with the API he’s using. Is it better to use a potential complex API endpoint that doesn’t provide the data in the format you need, or stick a server between the app and the API to parse out just the bits you need?

Also, did you know Jake got an Apple Watch?

Show Notes