Under the Bridge

Here’s a handy piece of the Cocoa runtime you might have overlooked the usefulness to your own code of:

doesNotRecognizeSelector:

Handles messages the receiver doesn’t recognize.

- (void)doesNotRecognizeSelector:(SEL)aSelector

The runtime system invokes this method whenever an object receives an aSelector message it can’t respond to or forward. This method, in turn, raises an NSInvalidArgumentException, and generates an error message.

Any doesNotRecognizeSelector: messages are generally sent only by the runtime system. However, they can be used in program code to prevent a method from being inherited. For example, an NSObject subclass might renounce the copy or init method by re-implementing it to include a doesNotRecognizeSelector: message as follows:

- (id)copy { [self doesNotRecognizeSelector:_cmd]; }

Came to our attention via this tweet suggesting that the exception-throwiing pattern there was a good one to adopt in your base classes for methods intended to be overridden. Well, true enough, although we generally tend to design our base classes so that there is sensible … or at least non-fatal … default behaviour; however, it struck us that one particularly hard to debug problem this pattern would save us from is people who create an object without using the designated initializer. Yeah, all those of you out there who work in teams larger than one are nodding in agreement there, aren’t you? Indeed, you can see from the “or init” mention in the discussion there Apple positively endorses that approach. We believe we’ll make an immediate resolution to adopt that practice from now on; if there’s a designated initializer, make it actually IMPOSSIBLE not to use it!

Sometimes idioms are just too apropos:

live in cloud-cuckoo land

to believe that things you want will happen, when really they are impossible

A common sentiment lately is to find iCloud CoreData syncing a particularly cuckoo land, as you may have heard:

Tom Harrington: iCloud: State of the Union

As some of you know, I’ve spent a lot of time over the past year working with iCloud in Mac and iOS apps. Specifically, working with Core Data’s built-in support for iCloud. I’m going to be doing a series of blog posts covering iCloud in various ways. Today I’m going to start off with an overview covering how iCloud is supposed to work with Core Data and a little about how it actually works in practice…

Daniel Pasco: The Return of NetNewsWire

As far as sync is concerned, we knew we would likely need an alternative to Google Reader as early as last year. At the time, the option that seemed to make the most sense was to embrace iCloud and Core Data as the new sync solution of choice. We spent a considerable amount of time on this effort, but iCloud and Core Data syncing had issues that we simply could not resolve…

Rich Siegel: The Gathering Storm: Our Travails with iCloud Sync

In general, when iCloud data doesn’t synchronize correctly (and this happens, in practice, often), neither the developer nor the user has any idea why.

Sometimes, iCloud simply fails to move data from one computer to another…

… While attempting to deploy iCloud sync on Mac OS X 10.7, we ran into a situation in which the baseline (a reference copy of the synchronization data) would become corrupted in various easily encountered situations…

…There’s no discernable consistency or rationale for when it says no and when it finally says yes … you can just keep trying, and eventually it might just work, or not.

Yikes! More discussion can be found at The Verge, and at Ars Technica, and here and there and everywhere, most wittily over at NSHipster; but let’s just settle for declaring it a given that people much better at this programming stuff than you are can’t make iCloud CoreData sync work, so neither will you.

However, it’s also getting close to a given these days that Your App Needs to Sync:

If your app deals with users’ data, building cloud sync into your app should not be a feature you bolt on to an app – it is the feature. It’s why you will beat competitors or lose hard to them. It’s what will make your app feel effortless, thoughtless, and magical. It’s what will gain a user’s trust, and once you have that, they will sing your app’s praises and never give it up. But to earn that trust, you have to account for sync at every step of the design and engineering of your app.

Developers have a number of choices as to how to build an app around sync. You can use iCloud, you can use a hosted service like Parse, or you can build a custom sync service for your app. Each solution has trade offs. So what should you optimize for?

The reality is that every app is different, and each sync system must cater to the data that is syncing. While it is certainly the most work, it’s my belief that you should optimize for control. You should have total and complete control over when and how your app syncs its data. You should be handling errors and conflicts, not abstracting them behind black-box middleware. Without this level of integration, you’re bound to a system that can fail unreliably, leaving users to figure out what went wrong. And when they try, it’ll be your app that feels broken.

Indeed. Read that whole article, it’s got the choices and tradeoffs discussed quite nicely.

For an enthusiastic exposition of the DIY extreme, check out Why Developers Shouldn’t Use iCloud Syncing, Even If It Worked:

You may think you’ll never want an Android or browser-based version of your app. But are you sure? Really, really sure?

You hope your app will be a hit. (If not, then quit writing it and choose something else.) If it’s a hit on iOS, it could be a hit on Android too — and you can bet that customers will ask for a web app version.

You don’t want to limit the success of your app just because you didn’t want to write your own server…

Well, there’s that. On the other hand, those of us who are not superhuman are challenged enough to write an app that works, never mind a server to go with it, and it limits the success of your app a good deal more to have it not released in a timely fashion, yes?

Splitting the difference, there’s the various backend as a service stuffies one could use; but just for the purposes of finishing off this post in a timely manner, let’s take it as given that your initial release is built around CoreData in the app, and you just want get sync working with that as quickly as you can with acceptable reliability. We’ve pretty much established here that iCloud’s out. What to do? What to do?

Well, here’s a few options that look worth a gander for that:

nothirst / TICoreDataSync is what Moneywell uses for Dropbox-based syncing:

TICoreDataSync is a collection of classes to enable synchronization via the Cloud (including Dropbox), or local wifi (coming soon), of Core Data-based applications (including document-based apps) between any number of clients running under Mac OS X or iOS. It’s designed to be easy to extend if you need to synchronize via an option that isn’t already supported…

AFNetworking / AFIncrementalStore eliminates sync problems by storing only in the cloud, which does make things simple if you can declare network access a requirement:

AFIncrementalStore is an NSIncrementalStore subclass that uses AFNetworking to automatically request resources as properties and relationships are needed.

Weighing in at just a few hundred LOC, in a single {.h,.m} file pair, AFIncrementalStore is something you can get your head around. Integrating it into your project couldn’t be easier–just swap out your NSPersistentStore for it. No monkey-patching, no extra properties on your models…

WasabiSync is a paid service that claims “Add seamless cloud synchronization to your Core Data based iOS app in less than an hour…”

Wasabi Sync monitors your existing Core Data persistent store and watches for when your application makes changes to it. When changes occur, Wasabi Sync serializes the changes and sends them securely over the cloud to the Wasabi Sync servers. Those changes are then propagated to the user’s other devices and written to their respective persistent stores.

Wasabi Sync requires almost no code changes to integrate with your app. The only things you have to do to start syncing are:

Add the Wasabi Sync SDK to your existing Core Data based project.

For any Core Data entities you want to sync, add a globally unique identifier to your models.

Specify that your syncable core data entities implement the WHISyncableObject protocol.

That’s pretty much it!

Simperium is another paid service whose flagship demo is Simplenote. Documented here:

Simperium iOS / OSX is a bit like iCloud: you can use it to easily move data among iPhone, iPad, and Mac versions of your app. But you can also:

• Move data to non-Apple versions of your app
• Retain control of your users and data
• Build backend services
• Earn money by selling more storage to your users
• Brand these capabilities as your own

How it Works

Simperium can work with Core Data or JSON data stored in NSDictionary objects. As your users interact with your app, Simperium efficiently aggregates changes and moves them through our hosted, scalable service.

Changes are moved to and from Simperium as soon as possible. In the case where all devices are online, changes are moved in realtime. In the case where one or more devices are offline, data moves as soon as those devices come online. Conflicts can be resolved automatically.

Although the Simperium service hosts your app’s data, you retain control. You can host your own services that can see and store all data that moves through the system…

Interestingly, Simperium was recently acquired by Automattic:

As mentioned in our post on the Simplenote blog, Simperium has been acquired by Automattic! We’re really excited about this and what it will mean for the platform.

Automattic and WordPress are huge proponents of open source software so we’re happy to be able to go forward with our plans to open up the code, starting with the iOS and JavaScript client libraries. In the short term we’ll also be moving to faster hardware, so overall performance and stability of the hosted service should improve.

We’re going to keep expanding Simperium as a tool for building apps. Adding Simperium to apps that can work from a local datastore lets you automatically synchronize data across different instances and platforms. This way of building apps feels natural, a model where the developer can focus purely on the data itself, not networking or APIs. Synchronizing data is just part of the problem though. We’ll be adding better support for things like binary syncing and collaboration, along with a wider variety of client libraries…

One could be justifiably skeptical that interoperation with Core Data is likely to remain a priority at Simperium going forward. But maybe it will. And in any case, hey it’s open sourced so help out or fork it if you like.

Any experience with any of these solutions, Dear Readers? Or know of any CoreData-focused cloud syncing approaches we’ve missed here?

So as you all are panicking to get your UDID-replacing code submitted before May 1st Doomsday, might want to check out

The Developer’s Guide to Unique Identifiers

We had been warned that uniqueIdentifier was going away, and now Apple is giving us not just one but two alternatives to use. But which one should you use and when is it appropriate to choose one over the other? The documentation doesn’t answer these questions and it is left up to you to decide what is best for your applications’ purposes.

I am going to outline each of the iOS supported and deprecated unique identifier methods to explain what they do in hopes of arming you with the knowledge you need to make the right decisions…

Just in case there’s anything there that you might have overlooked so far.

Now, that article does omit the SecureUDID solution that we thought looked pretty nifty last April, so if you’re not going forward with IDFA/IDFV only, might want to give that one a look over as well.

Noticed mentions of this “ReactiveCocoa” thing popping up all around lately? Yeah, us too. Let’s take a bit of a look at what that is exactly, shall we?

ReactiveCocoa / ReactiveCocoa: “is an Objective-C framework for Functional Reactive Programming. It provides APIs for composing and transforming streams of values.”

Not feeling the excitement yet? Understandable. So what is this FRP thing exactly?

Functional Reactive Programming (FRP) is a programming paradigm for writing software that reacts to change.

FRP is built on the abstraction of values over time. Rather than capturing a value at a particular time, FRP provides signals that capture the past, present, and future value. These signals can be reasoned about, chained, composed, and reacted to.

By combining signals, software can be written declaratively, without the need for code that continually observes and updates values. A text field can be directly set to always show the current timestamp, for example, instead of using additional code that watches the clock and updates the text field every second.

Signals can also represent asynchronous operations, much like futures and promises. This greatly simplifies asynchronous software, including networking code…

If that’s a bit too abstract to get a handle on easily, NSHipster has a nice layman’s intro:

ReactiveCocoa is comprised of two major components: signals (RACSignal) and sequences (RACSequence).

Both signals and sequences are kinds of streams, sharing many of the same operators. ReactiveCocoa has done well to abstract a wide scope of functionality into a semantically dense, consistent design: signals are a push-driven stream, and sequences are a pull-driven stream…

So, it’s basically fancy-pants KVO, then? No, that’s underestimating it, check out this ReactiveCocoa: First Impressions post:

‘So what?’, I hear you say, ‘It’s a nice wrapper for KVO, big whoop’. Well, it gets better: in addition to a simply KVO API, ReactiveCocoa lets you express complex conditional behaviours.

GitHub’s example is as follows:

[[[[RACAbleSelf(self.username) distinctUntilChanged] take:3]
     where:^(NSString *newUsername) {
        return [newUsername isEqualToString:@"joshaber"];
     }]
     subscribeNext:^(id _) {
        NSLog(@"Hi me!");
     }];

Here’s their explanation of what’s going on:

We watch username for changes, filter out non-distinct changes, take only the first three non-distinct values, and then if the new value is “joshaber”, we print out a nice welcome.

Using KVO alone this simple isn’t possible: we would need to track and retain the value of username to compare it with the new value and keep a counter around to increment every time we receive a non-distinct value. This would certainly be more than six lines of code…

OK, so it’s like KVO, plus Cocoa Bindings, except not sucking. Well, that is pretty nifty. Definitely something to try out next time we have a complex pattern to implement!

Here’s some more discussion posts worth reading:

Input and Output

Better Code for a Better World : “… an introduction to using ReactiveCocoa to solve all of the problems currently facing mankind—a phrase I only use somewhat facetiously…”

Basic MVVM with ReactiveCocoa

And some coding samples:

ReactiveCocoa / ReactiveCocoaIO: “a framework for accessing and manipulating a file system through signals…”

ReactiveCocoa / ReactiveCocoaLayout: “a framework for describing Cocoa and Cocoa Touch layouts in a reactive way…”

uasi / AFNetworking-ReactiveCocoa “makes AFNetworking reactive.”

UIButton Edge Insets has both RAC and non-RAC implementations of button editing code.

Machx / Reactive-Cocoa-Playground: “a collection of useful and sometimes experimental ReactiveCocoa code.”

Here’s an excellent tutorial on how to compute device tilt using Core Motion and quaternions:

Computing the iOS device tilt

“Quatta-whatons”, you ask? Why:

The beauty of Quaternions

If you don’t know what a quaternion is yet, please don’t be afraid by this strange word that seems right out of Star Trek.

Quaternions were first described by Hamilton in 1843 and applied to mechanics in three-dimensional space.

It eases the way we deal with the orientation of a body in a 3D space, and is better suited than the Euler angles that Apple is computing for us because of three reasons :

• it’s easier to compose rotations or to extract values from it.
• it avoids the gimbal lock problem.
• and Apple provides a quaternion in the CMAttitude class instance.

And because we only want to compute the yaw we do not have to worry about the gimbal lock problem, since our goal is not to described the complete iPhone orientation in the 3D space but only the tilt…

Eyes glazing over yet? For a practical example of how to add some niftiness to your app with all this, check out

dulaccc / DPMeterView: “Gravity-aware gauge-style meter view with delightful animations.”

h/t: @romainbriche!

So we noticed this post Overlaying Application Version on Top of Your Icon to produce Springboard icons like this for your dev builds,

and promptly thought “Why, that is an immensely useful practice we must adopt immediately, what’s the trick?” Turns out the key is this command line:

convert -background '#0008' -fill white -gravity center -size ${width}x40 \
  caption:"${version} ${branch} ${commit}" \
  ${base_file} +swap -gravity south -composite "${CONFIGURATION_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/${target_file}"

Huh. We did not realize ImageMagick could do stuff like that!

For those of you who have been living under a rock the last 25 years, ImageMagick is a raster image manipulation library with a history dating back to 1987 that has been Apache-licensed open source since 1999. We haven’t really paid that much attention to it up until now, figuring there were better native alternatives available for the simple conversion and manipulation tasks we’d had the impression it was limited to, but perhaps that has been a bit of an oversight…

Here are just a few examples of what ImageMagick can do:

• Format conversion: convert an image from one format to another (e.g. PNG to JPEG).
• Transform: resize, rotate, crop, flip or trim an image.
• Transparency: render portions of an image invisible.
• Draw: add shapes or text to an image.
• Decorate: add a border or frame to an image.
• Special effects: blur, sharpen, threshold, or tint an image.
• Animation: create a GIF animation sequence from a group of images.
• Text & comments: insert descriptive or artistic text in an image.
• Image identification: describe the format and attributes of an image.
• Composite: overlap one image over another.
• Montage: juxtapose image thumbnails on an image canvas.
• Generalized pixel distortion: correct for, or induce image distortions including perspective.
• Morphology of shapes: extract features, describe shapes and recognize patterns in images.
• Motion picture support: read and write the common image formats used in digital film work.
• Image calculator: apply a mathematical expression to an image or image channels.
• Discrete Fourier transform: implements the forward and inverse DFT.
• Color management: accurate color management with color profiles or in lieu of– built-in gamma compression or expansion as demanded by the colorspace.
• High dynamic-range images: accurately represent the wide range of intensity levels found in real scenes ranging from the brightest direct sunlight to the deepest darkest shadows.
• Encipher or decipher an image: convert ordinary images into unintelligible gibberish and back again.
• Virtual pixel support: convenient access to pixels outside the image region.
• Large image support: read, process, or write mega-, giga-, or tera-pixel image sizes.
• Threads of execution support: ImageMagick is thread safe and most internal algorithms execute in parallel to take advantage of speed-ups offered by multicore processor chips.
• Distributed pixel cache: offload intermediate pixel storage to one or more remote servers.
• Heterogeneous distributed processing: certain algorithms are OpenCL-enabled to take advantage of speed-ups offered by executing in concert across heterogeneous platforms consisting of CPUs, GPUs, and other processors.
• ImageMagick on the iPhone: convert, edit, or compose images on your iOS comuting device such as the iPhone or iPad.

Examples of ImageMagick Usage shows how to use ImageMagick from the command-line to accomplish any of these tasks and much more. Also, seeFred’s ImageMagick Scripts: a plethora of command-line scripts that perform geometric transforms, blurs, sharpens, edging, noise removal, and color manipulations.

Indeed. There was actually an iDevBlogADay post about this not long ago, from the resource-creating perspective:

Tips for Mobile Devs – ImageMagick Command Line

But it didn’t mention that ImageMagick has been ported to iOS these days! Did you catch that last line of the feature list?

iOS Binary Release

~Claudio provides iOS builds of ImageMagick.

Download iOS Distribution

You can download the iOS distribution directly from ImageMagick’s repository.

Or you could go to marforic / imagemagick_lib_iphone on github too. Some pretty nifty stuff in that toolbox!

This is a stellar walkthrough of, well, as it says,

How to build a custom control in iOS

For example, what if you want to build a control to help the user select an Angle value between 0 and 360?

A solution would be to create a circular slider and let the user drag the knob to select the angle value. This is something you’ve probably already seen in many other interfaces but nothing similar is available in UIKit.

That’s why this is the perfect example we can use to set aside UIKit and build something special. But first, here’s a sneak peek of what we are going to create…

Some nifty little CoreGraphics and trigonometry tips to boot; worth reading even if you’re already familiar with control writing.

Another topic that goes nicely with writing a control is making it support UIAppearance skinning — so along with that, check out

UIAppearance for Custom Views

In the simplest case, add UI_APPEARANCE_SELECTOR to your properties to inform others that this property can be set via an UIAppearance proxy. There are however some gotchas that are not clearly mentioned in the documentation, and it’s always interesting how something like this works behind the scenes…

Good tips there it’d take you a fair bit of confusion to sort out on your own!

h/t: iOS Dev Weekly!

UPDATES:

robertwijas / UISS lets you use style sheets for your UIAppearance proxies.

Tutorial: How To Customize Native iOS UI Elements

We’ve mentioned before various libraries to serve as audio engines for your app, but here’s a new one which does look, indeed, amazing:

No, that’s really not an exaggeration at all:

• Effortless creation of live audio content with objects, blocks, or Audio Units and looping audio file players.
• Automatic mixing of multiple audio signals with per-channel volume and pan controls.
• Built-in support for audio filtering and effects, with support for Audio Units, blocks or object filters.
• Rich audio input support with sophisticated multi-channel support.
• Deep Audiobus inter-app audio system support.
• Sophisticated system output recording and monitoring for in-app session recording or analysis.
• Arbitrary audio format support: Interleaved, non-interleaved, mono, stereo, 16-bit, floating-point – whatever you need.
• Built-in audio file reading and writing, with support for all Core Audio-supported formats.
• Support for pinpoint-accurate timestamp based timing and alarm mechanisms.
• Very light, efficient C engine, designed from the ground up for speed.
• Fast, lock-free synchronisation between main and audio threads.
• High-quality documentation with sample code and a developer forum.

Woah. All that and a trivial attribution-appreciated license? The generosity of the good folks at A Tasty Pixel knows no bounds!