I've been coding against Facebook's Graph API the past few days, and it turns out - not unreasonably - that like Twitter, some of their error messages request you to retry (or to back off, wait and retry if you're a good web citizen and don't want to get your App hell banned).
This is easy peasy in synchronous code, you just loop and increment some counters and you're done, but in today's asynchronous world, things get a little trickier. Many async APIs require you to provide a completion handler and when you get a back off/retry error in your completion handler, you have to issue your request again, which means you have to pass - you guessed it - your completion handler. Which means you're recursing. Recursive blocks are allowed, though you might have a bit of a 'mare figuring out the syntax that allows them (or indeed, to do anything else with them).
Here's a pattern that i came up with this afternoon. I'm sure there's all sorts wrong with it, and it will likely blow up in the first bit of real world code I use it in, but it chunters along happily in its Foundation CLI tool, and it doesn't issue any compiler warnings. Food for thought at least.
And no, I'm not at all sure about that
sleep() either. Share and enjoy :-)
Update Thu 26 Jun 2014 (original code)
I worked on this a bit more this morning and got rid of some of the
__weak / __strong dance line noise. For context, I'm basically mocking out a small part of FB's graph API here, I'll post full code when I've integrated and tested it. It will still be pretty ugly, much uglier than this nice clean(ish) POC, I imagine.
Apologies to anyone who's left a comment and I've not replied or acknowledged. Somewhat annoyingly, the gmail account that I use to interact with Disqus has decided to file all communications from Disqus in the spam folder. I'm sure this was just a mistake, eh ?