More of a programming nerd than is strictly healthy. See also {nevyn.nu, thirdcog.eu, twitter}

Projects

nevyn's blog

Writing your own jailbreak tweak

This article is my raw presentation script from CocoaHeads Stockholm 2014-02. It’s written as if I was talking to an audience, not as a blog article, so it might be a bit weird to read.

Hi! I’m nevyn from Lookback. Whenever Marthin sends panicked emails looking for presenters for next Cocoaheads, I look back through the things I’ve encountered recently looking for something interesting. In other words, I am far from an expert on the upcoming subject, but I find it absolutely fascinating. And the topic is: Jailbreak development. I’m going to try to sneak in a product announcement in here somewhere, so don’t zone out!

What does that even mean? Let’s break it down. Jailbreaking has two parts: There’s a jail, and there’s breaking it. The jail is all the security infrastructure of iOS: a virtual room in which your apps run, and very little bad can happen. This infrastructure includes sandboxing, code signing, NX, ASLR, and so on: a seriously impressive layer-cake of security. All of these pieces work together to make sure that only trusted code can be run on your device—only apps signed by Apple or by you as a developer for your own device—and even if that code is compromised, there is a very limited range of possible consequences; for example, even if you happen to have a buffer overrun vulnerability in your app, a hacker can’t use that bug to install malicious code (like a virus) on your phone.

I could go into details of how all this works, but to allow us to move on, instead I deeply recommend Charlie Miller et al’s iOS Hacker’s Handbook. It’s an excellent guide to both basic security, how to write secure iOS applications, the security infrastructure of both FreeBSD, Mac OS X, and iOS, and how all of those have previously been broken.

That gets us on to the “breaking” in “jailbreaking”. What does “breaking” mean in this context, anyway? Jailbreaking means finding operating system bugs that allow you to expose vulnerabilities by writing exploits to disable every single one of the defenses put in place.

For example, the iOS 7 jailbreak “evasi0n” works like this:

  1. The WWDC 2012 app has code signing that allows it to run anywhere forever. However, it’s still just a normal app within a sandbox, so it can’t make changes to the operating system.
  2. A bug in the way the app installer handles symbolic links allows us to run iOS’s file server instead (used to make backups, normally).
  3. A bug in the dynamic linker allows a flag to completely disable the sandbox. However, we’re still running as the user, not as root, so we can only modify the user’s apps and documents, not the operating system.
  4. A bug in the way the file server handles symbolic links gives us raw access to the harddrive.
  5. And at this point, we can write whatever we want to the disk. The sandbox is completely disabled, allowing us to run any software we want.

This should be scary. This means that on a jailbroken device, a mail attachment could contain a virus, and all the gatekeepers would be asleep: the virus could execute, and it could infect your phone and spread it to all your contacts. Just like on a normal computer.

and that’s sort of the point. You own your iPhone. It’s a computer, just like any other. You shouldn’t have to pay Apple *additional* money just to be able to install whatever software you want on it.

And I really mean *whatever* software. On a Mac you can also whatever you want, but there never really sprung up a big community of modders. There was CandyBar, Audio Hijack and a few others.

But on iOS, every jailbreak comes with Cydia, and a whole lot of infrastructure written by Saurik and other awesome hackers. Every piece of the system has a category of modifications on his store. Saurik likes calling “remixing software”, which I think is a great term.

How would one get started with jailbreak development, with remixing software?

Large parts of the jailbreak community is based on the idea that you shouldn’t need a Mac to do development, so they’re based on Makefiles and other traditional Unix development tools. Me, I prefer my GUIs. If you’re like me, you’ll appreciate iOS Open Dev, which is an Xcode plugin package with awesome templates to help you get started. One might think it’s just a bunch of unmaintained scripts (as is often the case with obscure dev communities), but I’ve found it to be very well put together.

After installation, iosopendev might not work right off the bat. If it doesn’t, you might to tell it to use the latest iOS SDK:

iod-setup sdk -d /Applications/Xcode.app/Contents/Developer -sdk iphoneos

Restarting Xcode and making a new project now gives a ton of new options. They’re all based on the idea that you want to put code into other people’s apps. Some interesting ones are:

Ok, so before we jump into live coding, I’d like a volunteer app. If you have an app on the AppStore and want to be horrified, yell the app name out loud!

While that’s downloading, let’s make a tweak. Primarily, a tweak is a uniform way of injecting code into apps using a library called Cydia Substrate. It will let you specify which apps you want to inject in, for example by checking for the existence of a class. This filter here will inject into any app that has the hypothetical class SpotifyViewController in it. You can also say “only inject into SpringBoard”, or “into any UIKit app”, or something else.

Once inside the target app, what can you do?

Well, a tweak is also method swizzling made into an art form. To make it really, really easy to swizzle stuff. two optional frameworks have emerged.

Logos is the oldest one, and it is a bit crazy. It’s a custom preprocessor on top of Objective-C with the extension “.x”. You tell it which class you want to swizzle, implement your replacement, and then you can optionally call the original implementation with %orig. It has support for many other things, but I think I’ll leave it at that.

The alternative is CaptainHook, which uses C++ template classes and macros to accomplish the same thing. It’s not less crazy. Here we are logging every call to [NSString writeToFile:], and then calling the original implementation.

So let’s write a very simple tweak. It’ll create a class called “ListClasses” when the app starts, using +load. We’ll wait for the app to finish launching properly before we do anything. At that point, we’ll add a button to the window after a second, to let the UI settle. It’s going to present a custom view controller on top of the app.

This’ll be a table view controller. We will list ALL classes available to the app, and get their names. Then we’ll just list those in a table view. Build and run, aaand… Let’s have a look inside the audience app.

So, these are real class names, and I could instantiate any one of them if I wanted, and call any method I wanted on them.

Class names aren’t quite enough to know what to swizzle though: we want method names, and preferrably, even headers. Luckilly, or unfortunately if you want to keep secrets, Objective-C is very verbose in what kind of information is available at runtime, since it’s such a dynamic language. There’s a tool called class-dump that will take an app or a library, and output headers, much like this. However, all app-store apps are encrypted and aren’t easily class-dumped. First, they must be cracked using a tool using “Clutch”. This is also the same way that apps are pirated, so please don’t do that :(

Let’s do a classdump of the audience app. I will SSH into my phone, as if it was a regular UNIX computer o_O

This is a good time to mention that development on device is going to be very painful if you don’t enable SSH. SSH lets you get a command line shell right into your phone. However, you should change the password immediately after installation, since all iPhones have the same default password: alpine. You’ll also want to add a ssh key to your phone, so that iosopendev can install tweaks onto your phone directly from Xcode. If you add your phone’s IP address to your .bash_profile file, you can press command-shift-I to install tweaks.

You will probably also want the tool deviceconsole, which is like Xcode organizer’s console log, except as a terminal app which means it’s searchable, fast, and just generally awesome in every way that Xcode isn’t.

There’s so much more to talk about. How to publish your creation, how to debug, how to write activators, and much more. However, my time is up so talk to me afterwards if you want to know more.

I’d like to finish off with the tool I built that made me learn all this. You probably saw my previous presentation on Lookback, so now I’d like to show you Lookback Anywhere. Lookback Anywhere is very simple: I’ve taken the Lookback SDK, linked it into a tweak, and added two activator actions. That means Lookback is loaded into every app on your phone, and you can record them without having to install the SDK. The same concept could be applied to any developer tool: Reveal, PonyDebugger, Spark Inspector and others could be installed into any app very easily.

So I’d like to show you here how I can record in this audience app… And voila, it’s uploaded to lookback.io.

Lookback Anywhere is not ready for release, but you can install a beta on your phone by adding a custom source in Cydia.

Reblogged from The coding love

when I fix one bug

thecodinglove:

image

/* by slai47 */

Reblogged from MASTERVONE

mastervone:

Welcome, program! You have only two choices: Games, or immediate deresolution! Luckilly, you can bring one or two, or even three of your “friends” onto the Grid. Not so lucky: only one of you will survive. 

Gridlike is now available for iPad on the Apple App Store. It’s a two-to-four player lightbike game that we’ve been working on on and off since before Tron: Legacy was released.

We released a game! :D We were basically done with this game after a week-long game hacking lan party three years ago, but weren’t quite happy with the result, and there was this one annoying collision bug we never got around to fixing. Every game making lan party since, we’ve said that we’ll patch it up and release it, but things like CLOP (don’t click.), Candy Box (don’t click!!), Deathtroid (do click!) and just general procrastination got in the way. (We’re horrible procrastinators).

Last week, we had another game making LAN, (chronicled in my dev diary), and managed to both finish up Gridlike and start a new game, Tanks!

We’ve set the price to free for the first week, so go check it out! Let us know if anything’s weird, buggy or boring.

mastervone:

Welcome, program! You have only two choices: Games, or immediate deresolution! Luckilly, you can bring one or two, or even three of your “friends” onto the Grid. Not so lucky: only one of you will survive.

Gridlike is now available for iPad on the Apple App Store. It’s a two-to-four player lightbike game that we’ve been working on on and off since before Tron: Legacy was released.

We released a game! :D We were basically done with this game after a week-long game hacking lan party three years ago, but weren’t quite happy with the result, and there was this one annoying collision bug we never got around to fixing. Every game making lan party since, we’ve said that we’ll patch it up and release it, but things like CLOP (don’t click.), Candy Box (don’t click!!), Deathtroid (do click!) and just general procrastination got in the way. (We’re horrible procrastinators).

Last week, we had another game making LAN, (chronicled in my dev diary), and managed to both finish up Gridlike and start a new game, Tanks!

We’ve set the price to free for the first week, so go check it out! Let us know if anything’s weird, buggy or boring.

Continuously playing music in the background on iOS

tl;dr: Have an active background task and audio session running continously whenever the user is semantically playing music, so code can execute while empty buffers are being refilled.

For the longest time since multitasking was introduced in iOS 4, Spotify occasionally had problems with music playback stopping against the user’s wishes. See, iOS applications can only execute in the background when at least one of six conditions are true:

If you’re a streaming music service, music to be played in the background won’t always be immediately available. Say your music buffer runs out, your device is on EDGE, and it takes a few seconds to get the music data: silence. Or even if you’re not streaming music, perhaps you need to tear down and set up your audio subsystem in between tracks, e g because they’re different kinds of tracks. What should a well-behaved iOS app do in this situation?

When I realized what the problem is, my first approach was to detect situations when music would not be playing, try to pre-empt them, and start a background task just before music stops playing and then end it when music is back again. If this sounds fragile and stupid to you, you’re absolutely right. I’ve heard other developers come to the same solution, but don’t do it: you’ll miss edge cases, it’ll be buggy, and it’s so overly complex.

The epiphany came when I realized what the audio background mode actually means for background tasks: background tasks become no-ops, with infinite lease time, as long as audio is playing. Only when there is no audio playing does the timer start counting, from ten minutes. Start playing again and the lease is back at infinite time.

The solution is then obvious: whether your app is playing audio is uninteresting. The only interesting information is whether the user currently wants music to play. If she does, start an audio session and a background task, and don’t stop them until the user wants music to stop. In between, it’s up to other subsystems to make sure that audio is playing. With the continous background task, we allow these subsystems to continue to work, even if they can’t play music this very moment. As long as they don’t take playback pauses that are longer than ten minutes, we’re all good.

This is a very simple approach, and should work no matter how your underlying audio playback code works. Below, you can find some sample code implementing my approach.

(If you’re thinking you haven’t seen this problem in Spotify in a long while, you’re right: I wrote this code two years ago and have been thinking I should blog it since then. My apologies for not doing so earlier.)

Thinking alike: await/async in Python 3

Guido van Rossum’s 2013 PyCon keynote presents Python 3.4’s major new feature: coroutines as a language feature for working with asynchronous operations. I wonder where I’ve seen that before? :)

Async/await is such an amazingly simple way to express asynchrony, and I’m very happy to see more languages adopt the thinking. Also, python is *finally finally finally* standardizing on a runloop API. That has been a crazy big gap in the standard libraries and frankly I don’t understand how people have been able to write Python apps without it…

Example python code with the new API below. “yield from” is identical to “await” in C#.

def getresp():
    s = socket()
    yield from loop.sock_connect(s, host, port)
    yield from loop.sock_sendall(s, b'xyzzy')
    data = yield from loop.sock_recv(s, 100)

My presentation of Methods of Concurrency at CocoaHeads Stockholm 2013-02. Don’t miss the rest of the talks from that evening!

Methods of concurrency — GCD, agents, tasks and invocations

My programmer world was turned up-side down when I first saw the new ‘await' keyword in C# about a year ago, and I’ve wanted to share all the thoughts that arose from that since, but never got around to it.

In the past few evenings, I’ve written some tools that I can’t not share with you, and thus we begin. You can skip the background chapters if you’ve already seen the video linked above. The code is available on Github.

tl;dr (abstract)

tl;dr: Building an application using a GCD queue for every class, simple NSInvocation-based dispatch between threads, and Tasks (stolen from .Net) to get results of asynchronous operations and chaining them together.

This article starts with five chapters on background: in what asynchrony is, how such code gets messy, my favorite solution of pretending there is no problem, how C# generalizes asynchronous operations as ‘tasks’ to gain enormous strength in generalizing asynchronous problems, and the new in C# 5 keywords ‘async’ and ‘await’.

Then comes five chapters on my own creations: I replicate C#’s Task in Objective-C as the basic building block for everything else, and delve into its implementation. Then I move all my classes onto their own GCD work queues and call them ‘agents’. I go through invocation grabbers again, because I use them to simplifly cross-thread communication with sp_agentAsync together with SPTask. Finally I delve into the implementation of sp_agentAsync.

In the summary, this code is disected, and hopefully by then, you will understand every part of it:

- (SPTask*)funkifyImageAndPublishResult:(NSURL*)link
{
	return [[[[[_backendService sp_agentAsync] requestURL:url] chain] then:^ id (NSData *response) {
		UIImage *image = [UIImage imageFromData:response];
		return [image funkyTransform];
	} on:dispatch_get_global_queue(0,0)] chain:^ SPTask*(UIImage *image) {
		return [_imageHostingService postImageAndReturnImageURL:image];
	} on:_imageHostingService.workQueue];
}

What is asynchrony, anyway?

Just to make things clear, let’s sort asynchrony into three categories:

Asynchronous code gets messy

If at all possible, many programmers choose to tackle asynchrony by opting out of it entirely. In some cases, this way of doing networking is acceptable:

while(true) {
	var imageLength = toInt(read(socket, 2));
	var image = read(socket, imageLength);
	var mirroredImage = mirrorImage(image)
	write(socket, length(mirroredImage))
	write(socket, mirroredImage)
}

If that code is part of UI, or needs to do any other thing than the above, the entire paradigm becomes unacceptable. A network read might take minutes, and image processing isn’t cheap, either.

Over the years, many patterns have emerged to deal with asynchrony. Some of them are, in rough order of evolution:

#2 is quite popular in Objective-C, as we have GCD (mikeash plug!) to help us out, and GCD is closure based. However, if you’re not careful, your code will end up looking like this:

- (void)handleOneRequest;
{
	// async I/O
	[socket readUInt32ToCompletion:^(uint32_t length) {
		[socket readToLength:length completion:^(NSData *data) {
			dispatch_async(dispatch_get_global_queue(0,0) {
				// async processing
				UIImage *image = [UIImage imageFromData:data];
				UIImage *mirrored = [image mirror];
				NSData *pngBytes = [image pngData];
				[socket writeUInt32:pngBytes.length completion:^ {
					[socket writeData:pngBytes completion:^{
						[self handleOneRequest];
					}];
				}];
			});
		}];
	}];
}

Yuck. And it gets way worse when you add error handling. The same level of asynchrony using either callbacks or delegates could get almost as messy. So, instead…

Let’s pretend that there is no problem

Gevent is a popular Python library among Spotify backend developers, and one that fascinates me. Gevent enforces cooperative multithreading on process-level threads (“green threads”), suspending execution when anyone does a blocking call. You can think of it as methods becoming coroutines, yielding whenever it would block. By patching system libraries, the following code, which looks synchronous, actually becomes asynchronous.

def print_head(url):
    print ('Starting %s' % url)
    data = urllib2.urlopen(url).read()
    print ('%s: %s bytes: %r' % (url, len(data), data[:50]))

jobs = [gevent.spawn(print_head, url) for url in urls]

The above code code will fetch all the headers at the URLs in ‘urls’ almost simultaneously. The implementation of ‘print_head’ pays no attention to asynchrony at all, and looks completely asynchronous. The problem has become invisible. That this is possible using just a library is a testament to the flexibility of Python.

C# 5 has new features to try to reach the same level of invisibility. They have been designed to be a little more explicit, and are added as the language features ‘async’ and ‘await’ rather than as a library. But before we can talk about them, we need to introduce the older concept of Tasks.

Tasks

First, we realize that we can probably generalize the concept of “do something and notify me when it’s done”. One such generalization is the future/promise (obligatory mikeash plug), but it seems that there are many situations in which they will block, which is unacceptable for UI code.

In .Net, every asynchronous action is instead wrapped in a System.Threading.Tasks.Task. At its core, Task is almost a value class, just holding callbacks to be called when an operation is done, seemingly so trivial that it’s not even worth an abstraction. But once you have that abstraction, you can throw so many things at it. To enumerate a few in .Net:

  • Generic cancellation of operations
  • Shorthand for performing things in the background
  • Getting a callback when the operation completes
  • Waiting synchronously for the operation to complete
  • Chaining tasks together, with the later ones depending on the result of the earlier ones
  • Waiting for several tasks together (e g for an operation that depends on many separate non-interdependent things)
  • Delaying
  • C#: Async and await

    Back to fancy language features. In C#, the ‘async' keyword will transform a method into a special coroutine. The 'await' keyword is basically a coroutine ‘yield. Let’s take this (slightly fictitious) synchronous code:

    private byte[] GetURLContents(string url) {
    	var content = new MemoryStream();
    
    	HttpWebRequest request = WebRequest.Create(url);
    	WebResponse response = request.GetResponse(); // <-- network call, blocks!
    
    	Stream responseStream = response.GetResponseStream();
    	responseStream.copyTo(content); // <-- network call, blocks!
    
    	return content.ToArray();
    }

    … and turn it asynchronous:

    private async Task<byte[]> GetURLContents(string url) {
    	var content = new MemoryStream();
    	HttpWebRequest request = WebRequest.Create(url);
    
    	WebResponse response = await request.GetResponseAsync(); // <-- yields and returns from this method!
    	Stream responseStream = response.GetResponseStream();
    
    	await responseStream.copyToAsync(content); // <-- yields and returns from this method!
    	return content.ToArray();
    }

    Note the slight changes, highlighted in bold. Making a method ‘async' means that instead of returning the value, it returns a task representing the future delivery of that value. Since the caller now has a task, we have all eternity to perform the requested action, and will never block the caller.

    We can pretend that the method has been cut into three pieces: the part before the first await keyword, the part between the first and second await keyword, and the part after the second await keyword. We have a chain of three Tasks. Since I don’t really know C#, the language I will use below does not exist:

    private Task<byte[]> GetURLContentsAsync(string url)
    {
    	var content = new MemoryStream();
    	HttpWebRequest request = WebRequest.Create(url);
    	
    	Task<WebResponse> responseTask = request.GetResponseAsync();
    	Task task2 = responseTask.startAndCallback(^(WebResponse response) {
    		Stream responseStream = response.GetResponseStream();
    		
    		Task copyTask = responseStream.CopyToAsync(content);
    		Task<byte[]> bytesTask = copyTask.startAndCallback(^ {
    			return content.ToArray();
    		});
    		return bytesTask;
    	};
    	return task2;
    }

    This method contains three explicit tasks rather than implicit, and they are chained together, one starting when the previous one completes; and the method returns the first task in the chain, that sets it all off.

    Let’s face it, Objective-C is no C#: replicating the Task class in ObjC

    It seems that Apple felt they were done once GCD was out the door. Indeed, GCD is an amazing library, but it only helps us with where to execute our code, not with higher level questions like “how do I compose these operations” or even “how do I know when the work is done”?, nor does it try to. Microsoft has upped the game, and I hope Apple follows (and surpasses, of course).

    Until then, we make do with the tools we have. Before C# 5, .Net programmers had to make do without language support for asynchrony. The Task class achieves this with the “continueWith" method. This is a perfect recipe for something to replicate in our language of choice, and thus I built SPTask in the same vein. Let’s try out its header:

    typedef void(^SPTaskCallback)(id value);
    typedef void(^SPTaskErrback)(NSError *error);
    typedef id(^SPTaskThenCallback)(id value);
    typedef SPTask*(^SPTaskChainCallback)(id value);
    
    /** @class SPTask
        @abstract Any asynchronous operation that someone might want to know the result of.
     */
    @interface SPTask : NSObject
    
    /** @method addCallback:on:
        Add a callback to be called async when this task finishes, including the queue to
        call it on. If the task has already finished, the callback will be called immediately
        (but still asynchronously)
        @return self, in case you want to add more call/errbacks on the same task */
    - (instancetype)addCallback:(SPTaskCallback)callback on:(dispatch_queue_t)queue;
    
    /** @method addErrback:on:
        Like callback, but for when the task fails 
        @return self, in case you want to add more call/errbacks on the same task */
    - (instancetype)addErrback:(SPTaskErrback)errback on:(dispatch_queue_t)queue;
    
    /** @method then:on:
        Add a callback, and return a task that represents the return value of that
        callback. Useful for doing background work with the result of some other task.
        This task will fail if the parent task fails, chaining them together.
        @return A new task to be executed when 'self' completes, representing
                the work in 'worker'
     */
    - (instancetype)then:(SPTaskThenCallback)worker on:(dispatch_queue_t)queue;
    
    /** @method chain:on:
        Add a callback that will be used to provide further work to be done. The
        returned SPTask represents this work-to-be-provided.
        @return A new task to be executed when 'self' completes, representing
                the work provided by 'worker'
      */
    - (instancetype)chain:(SPTaskChainCallback)chainer on:(dispatch_queue_t)queue;
    
    ...
    @end
    
    /** @class SPTaskCompletionSource
        Task factory for a single task that the caller knows how to complete/fail.
      */
    @interface SPTaskCompletionSource : NSObject
    /** The task that this source can mark as completed. */
    - (SPTask*)task;
    
    /** Signal successful completion of the task to all callbacks */
    - (void)completeWithValue:(id)value;
    /** Signal failed completion of the task to all errbacks */
    - (void)failWithError:(NSError*)error;
    @end
    

    If the only method we had on SPTask was addCallback:, we would still be in the ‘yuck' situation from above. 'then:' and 'chain:' to the rescue! They lets us write code that looked just like the await code in C#, except it's indented one level:

    - (SPTask*)getURLContents(NSURL *URL) {
        NSURLRequest *request = [NSURLRequest requestWithURL:URL];
        
        return [[request sp_getResponse] chain:^ SPTask *(NSURLResponse *response) ^{
            return [response sp_readDataUntilEOF];
        }];
    }

    The signature of the hypothetical sp_getResponse would be -(SPTask/*<NSURLResponse>*/)sp_getResponse; (yes, I’m still pretending that Objective-C has generics). It’s a method that immediately returns an SPTask, that when completes will yield an NSURLResponse to its callbacks. We use this task to chain it together with a new operation. When we get the response (that represents just the headers, not the whole data response), we know that we will immediately want to start reading the entire HTTP payload into an NSData object. The signature of the hypothetical sp_readDataUntilEOF would be -(SPTask/*<NSData>*/)sp_readDataUntilEOF;. Returning the ‘readData…' Task from the 'chain:' block creates a new SPTask that represents the whole chain of getResponse > response done > request data > data has arrived. The caller of getURLContents can now add a callback to the SPTask she receives, and get the full data contents of the URL.

    When comparing this code to the C# example, each ‘return' is equivalent to a C# 'await’, because we have chopped the method up into smaller blocks, manually creating a coroutine (a method that can be resumed from where it last left off).

    Let’s look at an involved example.

    - (SPTask*)handleOneRequest
    {
        __block NSData *pngBytes;
        return [[[[socket readUInt32] chain:^(NSNumber *length) {
            return [socket readToLength:[length intValue]];
        }] chain:^(NSData *imageData) {
            UIImage *image = [UIImage imageFromData:data];
            UIImage *mirrored = [image mirror];
            pngBytes = [image pngData];
            return [socket writeUInt32:pngBytes.length];
        } on:dispatch_get_global_queue(0,0)] addCallback:^(id _) {
            [socket writeData:pngBytes];
        }];
    }

    This example has the exact same level of asynchrony as ‘yuck’, but because we can chain instead of nest, the method is much more readable. Let’s look at the calling side.

    [[[self handleOneRequest] addCallback:^(id _) {
        [self doMoreStuff];
    }] addErrback:^(NSError *err) {
        NSLog(@"Error handling the request! %@", err);
    }];

    Since exceptions aren’t used the way they are in C#, I had to steal ‘errbacks’ from the python framework Twisted. They work like the normal ‘callback’, except it’s called when an error happens. Chaining together tasks will also chain together errors, so in the case of handleOneRequest, errors will be propagated all the way up to the caller.

    Delving into SPTask

    SPTask is such a simple class that we might as well take a closer look at it.

    @interface SPTask ()
    {
        NSMutableArray *_callbacks;
        NSMutableArray *_errbacks;
        BOOL _isCompleted;
        id _completedValue;
        NSError *_completedError;
    }
    
    @end
    
    @implementation SPTask
    - (id)init
    {
        if(!(self = [super init]))
            return nil;
        _callbacks = [NSMutableArray new];
        _errbacks = [NSMutableArray new];
        return self;
    }

    We track all callbacks, errbacks, and whether this task has finished.

    - (instancetype)addCallback:(SPTaskCallback)callback on:(dispatch_queue_t)queue
    {
        @synchronized(_callbacks) {
            if(_isCompleted) {
                if(!_completedValue) {
                    dispatch_async(queue, ^{
                        callback(_completedValue);
                    });
                }
            } else {
                [_callbacks addObject:[[SPCallbackHolder alloc] initWithCallback:callback onQueue:queue]];
            }
        }
        return self;
    }
    
    - (instancetype)addErrback:(SPTaskErrback)errback on:(dispatch_queue_t)queue
    {
        @synchronized(_errbacks) {
            if(_isCompleted) {
                if(_completedError) {
                    dispatch_async(queue, ^{
                        errback(_completedError);
                    });
                }
            } else {
                [_errbacks addObject:[[SPCallbackHolder alloc] initWithCallback:errback onQueue:queue]];
            }
        }
        return self;
    }

    If the task has already finished, we call the callback immediately with the value we have stored. Otherwise, we store it away for later. We also return self, so that we can chain more calls onto it, such as an errback, of if the caller is returning it to another piece of code that also want to know about this task’s completion.

    - (instancetype)then:(SPTaskThenCallback)worker on:(dispatch_queue_t)queue
    {
        SPTaskCompletionSource *source = [SPTaskCompletionSource new];
        SPTask *then = [source task];

    then::' is the method you would call instead of “addCallback" when you want to add some background work to a chain of tasks. We start off by creating the new task, representing this background work. To show off how to use a completion source (the public API), I create the task through a source rather than directly, although the source just forwards to the private task API.

        [self addCallback:^(id value) {

    We can’t do that work until we have the result of the current task, so we wait for it with an addCallback.

            id result = worker(value);
            [source completeWithValue:result];
        } on:queue];

    Then we start doing the work. We just do it synchronously inline, since we have already been asynchronously dispatched to the requested queue. When we have the result, we complete our new ‘then’ task with that value. All the callbacks will now be called for it.

        [self addErrback:^(NSError *error) {
            [source failWithError:error];
        } on:queue];

    We also add an errback on self, so that our ‘then' task will fail if the original task fails.

        return then;
    }

    We’re done! Returning the task to the caller, who can now wait for the background task. Onto the next method.

    - (instancetype)chain:(SPTaskChainCallback)chainer on:(dispatch_queue_t)queue
    {
        SPTaskCompletionSource *chainSource = [SPTaskCompletionSource new];
        SPTask *chain = [chainSource task];

    chain::' is the method you would call instead of 'then::' when what you want to do is to ask someone else to do work with the data from the callback, rather than doing work yourself. The ChainCallback returns a task, which we will be waiting for using the ‘chain' task we create here.

        [self addCallback:^(id value) {
            SPTask *workToBeProvided = chainer(value);

    When ‘self' is done generating its value, we ask the callback for the task we should wait for.

            [workToBeProvided addCallback:^(id value) {
                [chainSource completeWithValue:value];

    We add a callback to this new task, and use the new ‘chain' task we created at the beginning of the method to signal its completion.

            } on:queue];
            [workToBeProvided addErrback:^(NSError *error) {
                [chainSource failWithError:error];
            } on:queue];

    If the work-to-be-provided fails, we fail the whole chain.

        } on:queue];
        [self addErrback:^(NSError *error) {
            [chainSource failWithError:error];
        } on:queue];
    If self fails, we fail the whole chain too.
        return chain;
    }

    We now have a task to return to the caller, that represents the completion of both ‘self’, and the task provided from the callback.

    - (instancetype)chain
    {
        return [self chain:^SPTask *(id value) {
            return value;
        } on:dispatch_get_global_queue(0, 0)];
    }

    chain' is just a convenience method for when the value this task yields is itself is a task. We will talk about it in depth later on.

    - (void)completeWithValue:(id)value
    {
        @synchronized(_callbacks) {
            _isCompleted = YES;
            _completedValue = value;
            for(SPCallbackHolder *holder in _callbacks) {
                dispatch_async(holder.callbackQueue, ^{
                    holder.callback(value);
                });
            }
            [_callbacks removeAllObjects];
            [_errbacks removeAllObjects];
        }
    }

    completeWithValue: is exposed by SPTaskCompletionSource, not Task itself, but this is the implementation that will be called. It simply dispatches the requested callback to the requested queue, with the value that we completed the task with. It also saves the value into _completedValue, in case someone adds a callback to the task after it has finished (see addCallback:: to see how this is done).

    - (void)failWithError:(NSError*)error
    {
        @synchronized(_errbacks) {
            _isCompleted = YES;
            _completedError = error;
            for(SPCallbackHolder *holder in _errbacks) {
                dispatch_async(holder.callbackQueue, ^{
                    holder.callback(error);
                });
            }
            [_callbacks removeAllObjects];
            [_errbacks removeAllObjects];
        }
    }
    @end

    The same goes for errbacks, except we save the error rather than the value.

    In the previous chapter, I ignored the ‘on:' argument on the Task methods, and didn't really focus on it in this chapter. Let's take a detour from task abstractions and talk about Grand Central Dispatch, before getting back to it.

    It’s queues all the way down: Agents and work queues.

    My day job is writing code for some streaming music company. My main annoyance with that product is that it stops and thinks too much (although not nearly as often as iTunes, phew!), doing too much work on the main thread. When working on my latest pet project, my counter reaction is thus to make sure no part of my system blocks any other part in a synchronous manner. Thus, SPAgent was born:

    /**
     Experimental multithreading primitive: An object conforming to SPAgent is not thread safe,
     but it runs in its own thread. To perform any of the methods on it, you must first dispatch to its
     workQueue.
     */
    @protocol SPAgent <NSObject>
    @property(nonatomic,readonly) dispatch_queue_t workQueue;
    @end

    Any object conforming to the SPAgent protocol is thus communicating that you MUST NOT call any method on it from any other queue than its workQueue, which is a private GCD dispatch queue that it owns and on which it does all its work. We are thereby externalizing synchronization to the caller, letting the caller use whatever method is most appropriate at that call point. It feels like such a bad idea to externalize what feels like an implementation detail like that, but so far I’m very pleased with the pattern. It’s very Erlang-y, a language where you do all major communication between “objects” as messages between processes, even as a part of the language syntax. The implementation of an agent is also very clean: you don’t have to do any locking anywhere, and you are guaranteed that only one method is being called at a time, so it’s very easy to reason about the internal state of your object.

    Let’s explore an example.

        MasterControlProgram *mcp = [MasterControlProgram new];
        dispatch_async([mcp workQueue], ^{
            int leetAnswer = [mcp multiplicatify:42 with:1337];
            dispatch_async([self workQueue], ^{
                NSString *prettyThingForUI = [self ingestAnswer:leetAnswer];
                dispatch_async(dispatch_get_main_queue(), ^{
                    [ui show:prettyThingForUI];
                })
            })
        });

    Well! This looks familiar. Dispatch queue spaghetti. What can we do about that? I decided to use invocation grabbers.

    NSInvocation refresher

    To refresh, NSInvocation is a Foundation class that encapsulates calling a method on an object. It can hold onto a target, a selector, a method signature (description of each argument and return value of a method), every argument of a call, and the return value. They are the building block that enables call forwarding and proxies to work. You can either create them manually, or have one created for you by implementing -forwardInvocation:, where one will be handed to you as an argument. In the latter case, you can use it immediately, but you can also store it and invoke it later.

    Creating invocations manually is a hassle. Therefore, it is common to create an “invocation grabber”, that is an object that will save the first unknown call being made on it, and then let the caller use the grabber in some manner. There are many open source grabbers, but this is the one I have:

    @interface SPInvocationGrabber : NSObject
    -(id)initWithObject:(id)obj stacktraceSaving:(BOOL)saveStack;
    @property (readonly, retain, nonatomic) id object;
    @property (readonly, retain, nonatomic) NSInvocation *invocation;
    ...
    -(void)invoke; // will release object and invocation
    @end

    You would use it like so:

        id someObject;
        SPInvocationGrabber *grabber = [[SPInvocationGrabber alloc] initWithObject:someObject stacktraceSaving:NO];
        [grabber doThatThingWith:anArgument];
        NSInvocation *invocation = [grabber invocation];

    You now have an invocation that you can call now, or later, with a reference to ‘someObject’, the method ‘doThatThingWith:’, and anArgument. You can optionally ask the invocation to retain all the arguments (it’s not done by default to save some overhead in case you use the invocation immediately).

    With some NSObject categories, you can have fun with higher-order messaging without closures:

    @interface NSObject (SPInvocationGrabbing)
    -(id)invokeAfter:(NSTimeInterval)delta;
    -(id)inBackground;
    -(id)onMain;
    @end
    
    // Example: blink
    [[self invokeAfter:0.2] setSelected:YES animated:YES]
    [[self invokeAfter:0.4] setSelected:NO animated:YES]
    
    // Example: Background computation with UI update later
    - ... {
        [[self inBackground] somethingExpensive];
    }
    - (void)somethingExpensive {
        ...
        [[button onMain] setTitle:computedTitle forState:0];
    }

    Simplifying agent communication with Invocations

    We can extend this concept to add a category on NSObject to dispatch to its workQueue, given that it’s an SPAgent:

    @interface NSObject (SPAgentDo)
    - (instancetype)sp_agentAsync;
    @end
    
    // Example
    - ... {
        [[_backendService sp_agentAsync] requestURL:someURL whenDone:^(id _){ ... } callbackQueue:_workQueue];
    }

    This simplifies communication to the agent, but not back: taking the return value of requestURL:whenDone:callbackQueue: wouldn’t make sense, as it’s not actually being called on that line, but being scheduled to be called later. If only we had a concept representing future values…!

    sp_agentAsync returns an invocation grabber, but what does the call on the invocation grabber return? An SPTask representing the real return value. Example:

    - foo {
        SPTask *dataTask = [[_backendService sp_agentAsync] requestURL:someURL];
        [dataTask addCallback:^ (NSData *data) {
            // Do something with the newly acquired data
        } on:_workQueue];
    }

    This also highlights why every SPTask method takes a queue in addition to the callback to be run: We certainly don’t want to run the callback on the work queue of _backendService, and since we’re communicating between agents, we don’t want to call the callback on the main queue. dispatch_get_current_queue() looks inviting, but the documentation states that it should only be used when you are the creator of the queue the call is executed from. Thus, we always need to be explicit about the destination queue.

    Delving into sp_agentAsync

    The implementation of sp_agentAsync is interesting enough to take a closer look at.

    @implementation NSObject (SPAgentDo)
    - (instancetype)sp_agentAsync
    {
        SPInvocationGrabber *grabber = [self grabWithoutStacktrace];
        __weak SPInvocationGrabber *weakGrabber = grabber;

    The general use case of invocation grabbers is to use them seldom, therefore I added a stack trace saving feature to them, to aid in finding the origin of bugs. Agents communicate often, so we want to keep the overhead down here.

        SPTaskCompletionSource *completionSource = [SPTaskCompletionSource new];
        SPTask *task = completionSource.task;
        __block void *unsafeTask = (__bridge void *)(task);

    When you return a Task from a method, the caller of that method shouldn’t be able to decide on the completion state of it: that’s a task for the creator of the task. To hide those method from the Task API, a CompletionSource is used for that purpose.

        grabber.afterForwardInvocation = ^{
            NSInvocation *invocation = [weakGrabber invocation];

    We have just now created the grabber, but not returned it from this method, so we don’t know what method it will grab yet. Thus, we need a time in the future when the invocation has been grabbed: that’s what this callback provides us with.

            // Let the caller get the result of the invocation as a task.
            // Block guarantees lifetime of 'task', so just bridge it here.
            BOOL hasObjectReturn = strcmp([invocation.methodSignature methodReturnType], @encode(id)) == 0;
            if(hasObjectReturn)
                [invocation setReturnValue:&unsafeTask];

    We only want to return a Task representing the return value if the method we’re wrapping returns a value of object type. If it does, we artificially set the SPTask as the return value of the invocation, which is what provides the caller with the task.

            dispatch_async([(id)self workQueue], ^{
    #pragma clang diagnostic push
    #pragma clang diagnostic ignored "-Warc-retain-cycles"
                // "invoke" will break the cycle, and the block must hold on to grabber
                // until this moment so that it survives (nothing else is holding the grabber)
                [grabber invoke];
    #pragma clang diagnostic pop

    Dispatch to the work queue of the target, and invoke the grabber’s invocation on that thread. In this weird case we actually want a retain cycle: the grabber should live until the dispatch to the new thread is done. This is similar to how NSTimer retains its target. Invoking the grabber will set its ‘afterForwardInvocation' to nil, thus breaking the cycle and cleaning everything up.

                if(hasObjectReturn) {
                    __unsafe_unretained id result = nil;
                    [invocation getReturnValue:&result];
                    [completionSource completeWithValue:result];
                }

    The invocation has now been populated with an actual return value. We can extract it, and complete our SPTask with that value. This value will now be propagated back to the original queue/thread, if a callback was set on the SPTask.

            });
        };
        return grabber;
    }
    @end

    And we’re done! The grabber is returned to the caller, ready to begin the whole dispatch chain.

    Summary

    We can now go back to the example in the tl;dr and step through it, hopefully with full understanding of what’s going on.

    @interface BackendService : NSObject <SPAgent>
    - (SPTask*/*<NSData>*/)requestURL:(NSURL*)url;
    @end
    
    - (SPTask*)funkifyImageAndPublishResult:(NSURL*)link
    {
    	return [[[[[_backendService sp_agentAsync] requestURL:url] chain] then:^ id (NSData *response) {

    We have a _backendService, which is an SPAgent. Therefore, we know we can’t just call requestURL directly on it: we need to be on its work queue first. We use sp_agentAsync to do that.

    Note that by doing so, the return value is actually SPTask<SPTask<NSData>>; that is, a task which yields a task which yields an NSData. To get to the NSData, we need to wait for the first task to complete. This is a common situation, and thus we can use the convenience method ‘chain’. Remember that ‘chain:on:' adds a callback that provides more work to wait for. 'chain' is a shorthand for '…] chain:^ (SPTask *task) { return task; } on:_workQueue]’. We’re saying, “the task yields a task. Just give me the latter when it’s ready”.

    		UIImage *image = [UIImage imageFromData:response];
    		return [image funkyTransform];
    	} on:dispatch_get_global_queue(0,0)] chain:^ SPTask*(UIImage *image) {

    The data has arrived. We’re on a global background queue, so we can do tons of expensive work here without affecting anyone. Once we’re done doing our work, chain it together with a new task that…

    		return [_imageHostingService postImageAndReturnImageURL:image];
    	} on:_imageHostingService.workQueue];

    sends our funky image to an image hosting service, which we also have an agent service for. -[postImage…] returns an SPTask, which we will wait for. We can return this final task to the caller of ‘funkifyImage…’, and it will represent the entire chain of actions. In addition, the task will yield the URL of the image when hosted at that service. Finally, we don’t have to handle any errors in this chain: the caller can add an errback to the last task in the chain, and it can thereby handle any error in any part of the chain.

    }

    Fin. I’ve packaged the two classes in a Github project called SPAsync. Feel free to fork, comment, or contact me personally!

    Thanks to Dan and Mattias for the feedback while I was writing this article!

    Reblogged from MASTERVONE

    mastervone:

During the Music Hack Day Stockholm 2013 hackathon, me and mandy forked Deathtroid into Super Mutroid (full source code), added EchoNest and Spotify support, and made a Metroid music game.

You can download it here (requires Mac OS 10.8): Download from cl.ly

From the Hack project page:

Music/rhythm platform game with a Super Metroid theme

Description
Plays a song through Libspotify and downloads song data from EchoNest. Generates obstacles based on the beats in the song.

How to play
W - Jump
S - Duck
When you start the game, enter a player name to the left and your Spotify login details to the right. You can also enter a Spotify track url in the text field under the Login button.

Then just press “Create Game” and wait for the song to load! (The character will automatically start running when the song has been loaded. If nothing happens after several seconds, the song you entered probably isn’t available on EchoNest.)

You die if the character runs into the spikes. If that happens, press any key to restart. If you want to enter another track url, you have to quit the game and restart it.

Known bugs
Sometimes crashes when you press Create Game
Flickering character
You can jump through the spikes that you are supposed to duck under

    mastervone:

    During the Music Hack Day Stockholm 2013 hackathon, me and mandy forked Deathtroid into Super Mutroid (full source code), added EchoNest and Spotify support, and made a Metroid music game.

    You can download it here (requires Mac OS 10.8): Download from cl.ly

    From the Hack project page:

    Music/rhythm platform game with a Super Metroid theme

    Description

    Plays a song through Libspotify and downloads song data from EchoNest. Generates obstacles based on the beats in the song.

    How to play

    • W - Jump
    • S - Duck

    When you start the game, enter a player name to the left and your Spotify login details to the right. You can also enter a Spotify track url in the text field under the Login button.

    Then just press “Create Game” and wait for the song to load! (The character will automatically start running when the song has been loaded. If nothing happens after several seconds, the song you entered probably isn’t available on EchoNest.)

    You die if the character runs into the spikes. If that happens, press any key to restart. If you want to enter another track url, you have to quit the game and restart it.

    Known bugs

    • Sometimes crashes when you press Create Game
    • Flickering character
    • You can jump through the spikes that you are supposed to duck under

    My Inner Hulk

    The idea of writing iOS apps using HTML makes me mad. It infuriates me. This is a strange thing, and generally a sign that I should cool down, breathe deeply, and just ignore the subject until it’s been simmering in my brain long enough for me to think clearly about it. But it’s been years, now! How much breathing can a man take?

    It’s so slow! And ugly! And inelegant! I either need a few absolute-positioned elements, or a layout that I’ll need to write code for anyway. Why would I involve a super-complex layout engine for that? Why do I want a document-based model conceived in the nineties for my playback UI? Why do I want an engine where a single missing “return NO” will make my button completely wipe out all existing state in my app and effectively restart it? One where loading is so slow that it’s designed to always be progressive, flickering like an Atari while slowly putting UI controls on my screen?

    Argument: HTML will be fast enough soon.
    Counter-argument: And by then native will be even faster.
    Inner, loud voice: Oh yeah? I bet this will be the year of Linux on the desktop too.
    Digression: Whatever computer speed we reach, we will find ways to use that power to make better UIs. The idea that an inefficient platform can “catch up” because there is some kind of level where you don’t need more processing power to make a great UI is a fallacy. Remember when floating-point animations with multiple transparent layers was expensive? If you are using the above argument, you’re the guy who argued that they’re a waste of cycles and don’t make a UI better.

    Argument: HTML will have all the features native apps have soon.
    Counter-argument: And by then native will have more features, some of which will be untranslatable or very hard to translate to a web environment.
    Inner, loud voice: Draaag and droooppppp arrrrgggghhh

    Argument: The reason every native-app-with-web-UI sucks is because everyone else sucks. We can do it correctly.
    Counter-argument: Really? Facebook just don’t have good web developers? I don’t buy that.
    Inner, loud voice: No, YOU suck! Nngggghhhh

    Argument: A-B testing, dude! Fast deployments!
    Counter-argument: You’ve made a product change and agreed on all the design, figured out what to test and how to gather good data, implemented it, and got it through QA in less than a week? Maybe you need a web view. Actual, existing people: you can A-B test in any environment, whether a web browser is involved doesn’t matter, and you probably have time to wait a week.

    Please flame me and prove me wrong. I’ve seen so many shit HTML apps, but maybe everybody really just is doing it wrong. And you’re right, I’m not a web developer, my javascript is shit, I haven’t even built a web page in a year, and I make a living writing ObjC. Of course I’m biased. Still, no ad-hominems please.

    And you! You there staring at me angrily, just barely not shouting at me: yes of course some sort of insta-deployment web-ish platform is going to be amazing and take over the world, some time in the next decade. But it won’t be HTML5. Possibly it will be its grand-grand child platform, which will bear little resemblance to the original.

    I had completely forgotten about nil targeted actions. BigZaphod reminds me of the canonical way of dismissing the keyboard:

    [[UIApplication sharedApplication] sendAction:@selector(resignFirstResponder) to:nil from:nil forEvent:nil];

    The responder chain is so under-used in iOS. I’ll definitely try to think of ways to solve problems using it in the future.

    For those of you who haven’t coded for the Mac, nil-targeted actions are what makes menus (among many things) work. When you select “Copy” from the menu, this is sent to the first responder. If that happens to be a text field, that text field gets the chance to put things into the clipboard. If it had been a check box, the check box would have no idea how to copy. However, that check box might be in a window, which belongs to a NSDocumentController, and the document might have the concept of copying the document as a whole. The app would step through the responder chain for you, from the check box all the way to the document controller, and perform the copy. Magic!