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.
In part 1 I wrote up a method of finding out what version of your iOS app a user originally installed that works great, provided you can get a network connection and the App Store servers are up.
But if you can’t rely on that being the case, and you don’t want to wait for it to be true before you take whatever action you’re basing on the original version number, you can get the receipt data locally and process it.
So, for whatever reason – lets say that you want to experiment with a free download and IAP monetization model in an existing paid app but you don’t want to double charge existing users, or maybe you need to do some clever user defaults or data model updates – you decide that you need to know what version of your app was originally purchased.
So far as I’ve been able to discover so far, there are basically two ways to go about this. Well, one way, but there are two ways of getting the data. Well, N ways actually, but let’s not get all forked up at this point. This is (one possible implementation of) the easy way.
Assuming you have a receipt (and you may well not, in your dev version at least, in which case you need a bit of SKReceiptRefresh magic) then you can find it in your app’s bundle, and (assuming you have some network connectivity, and can talk to it) you can fling it at the App Store servers and they’ll parse it for you and fling back some JSON.
It looks a little like this.
Before I show you the one weird trick, a caveat or two. There isn’t a framework method anywhere to do this, and while this code doesn’t involve touching any private APIs it does have a number of other issues. From an app store review perspective, it could easily be argued that if Apple wanted you to be able to detect this stuff, they’d have put an API in for you. While I do intend to try it out, I suggest that if you do use this code in a production app you ready yourself for rejection and have a backup plan. From a technical point of view, it seems likely that you will need that backup plan as this possibly rather less than robust. I’ll get to that in a minute, you want to see the code now right ?
I like C blocks and I cannot lie. Which is just as well, really, since so much of the iOS SDK is built that way. They don’t come without their own idiosyncratic set of problems though, one of which is that so much of the iOS SDK isn’t built that way. Maybe it’s just my bog standard codemonkey OCD spiking, but I sometimes find that when I’m deep into some bit of block based coding and going all data flowy and functional, dropping back to the objecty world of message passing and delegate protocols at an inappropriate point in my flow can lead to a lot of mental gear grinding and lo, gnashing of the teeth.
You want to return a block from an OCMock stub method, something like this :
[[[the_mock stub] andReturn:the_block] method];
That should work, right ? According to the blocks docs :
Blocks are Objective-C objects, which means they can be added to collections like NSArray or NSDictionary.
But it doesn’t work, and OCMock throws you an exception along the lines of
Expected invocation with object return type. Did you mean to use andReturnValue: instead?
I’m coding an ObjC application that I want to do a number of things in parallel using a GCD dispatch queue, but I want to limit the maximum number of tasks that can be running on the dispatch queue at any one time. Mainly because the tasks are going to be hitting up someone else’s web server pretty damn hard and I want to be able to throttle it to some reasonable number so as not to be rude.
If you have an Apple laptop of some kind, or you use a magic mouse or trackpad on the desktop, you can use gestures to zoom in and out of web pages in Safari.
If, on the other hand, you have some kind of non standard setup – I use a hefty MS Sidewinder multi button mouse and a Saitek Cyborg illuminated keyboard jacked into a Mac Mini, for example – your zoom option is : you can press [command] and [+].
But I missed my zoom wheel, so I stuck with Chrome until the flakiness of the wheel zoom add on I was using made me stabby and I finally sat down and figured out how to hack mouse wheel zoom into a Safari extension.
Because I like to show some summaries of recent posts on the front pages of the site, I have been using Wordpress’ ‘excerpt’ functionality quite heavily. However, even with various hacks, this leads to the unsatisfactory situation where some of the excerpts are truncated and/or the excerpt used on the blog home page is shorter than it really needs to be. Here’s the second simple plugin that I refactored out of my sprawling, hairy
I noticed that my (and quite a lot of other people’s) embedded gists were experiencing some drift between the line numbers and the code. This seems to be due to a mismatch between the line height and font settings on the line numbers and on the code, probably due to some elements inheriting body styles and others not, and code line fonts being set in %. (I think, I’m no CSS wizard, as you can probably tell). You can fix it by setting the requisite styles in your CSS something like this :