Oh My God They Killed parentViewController
Pre iOS 5, ‘parentViewController’ would return the view-stack’s parent view controller, or the controller which presented that controller when called on a modal view controller. This was the intended, documented functionality of the method, not some mistake.
iOS 5 changes this by splitting out the latter functionality to ‘presentingViewController’. Unfortunately, rather than creating 2 new methods with new functionality, they simply changed the old one and created the new one. So for anyone like me who missed this particular change (it’s not even in the API diffs as it’s not changed, or removed), [self parentViewController] starts returning nil, your code continus to run, but will probably hang if when you expect to have dismissed the view controller.
What terrible design. I think it would have been better to deprecated the old function & split it into two new ones. Or at least provide some warnings to the change. If Objective-C actually crashed on nil values like java, again this would be easy to spot & change – but hang bugs are particularly nasty to try and solve.
Anyway, here are my testing results of [self parentViewController] where self is a controller that was presented as modal:
XCode 4.1 & SDK 4.3: iOS 5: presentingViewController, iOS 4.x: presentingViewController
XCode 4.2 & SDK 5.0: iOS 5: nil, iOS 4.x: presentingViewController
As you can see, when iOS5 runs the older SDK it doesn’t break (because that would break everyone’s code), and iOS4 running with code from the new SDK doesn’t break either. Just SDK & iOS 5 together.
Fixing this if you only support iOS 5 is simple. Replace every instance of [self parentViewController] where you want the model view controllers parent to [self presentingViewController].
Most people need to support iOS 4. This is a bit of a pain because you can’t just call ‘presentingViewController’ without it crashing (due to this method not existing on iOS4). Here’s my #define to get the old behaviour back:
#define self_parentViewController (([self parentViewController] != nil || ![self respondsToSelector:@selector(presentingViewController)]) ? [self parentViewController] : [self presentingViewController])
In english, this means: if the parentViewController is not nil, or the presentingViewController method doesn’t exist yet (in the case of < iOS 5.0), return the result of presentingViewController. Else return the result of presentingViewController.
EDIT: if you need to call the old parentViewController on something other than self, try my revised #define.
NB. just like before – this *may* not return the presenting view controller, if self has it’s own parentViewController that isn’t the one which presented it. But this is equal to the old SDK behaviour, so I don’t think it will introduce bugs.
Everywhere in your code, replace [self parentViewController] with self_parentViewController (no square brackets).
#defines are normally pretty evil but in this case, until you drop 4.0 support I actually feel it’s cleaner. Now you could do [self parentViewController] || [self presentingViewController], and this will work in many cases, that is until parentViewController returns nil on iOS 4, when your app will crash due to the unrecognised ‘presentingViewController’ selector. Safter to use my #define for full backwards compatibility.
json-framework (now SBJSON) is EVIL
I just had an unforgivable bug due to the json-framework JSON library. It was a regression, as it previously worked well a year ago.
When I updated the library back in June, there was a massive flaw: all NSNumbers in NSDictionaries converted to JSON (a pretty common occurance) are limited to 6 significant digits.
so the long: 1234567890 becomes 1234560000
and a double: 123.4567890 becomes 123.456, 12.34567890 becomes 12.3456
Well that is totally shit, I lost the precision of a bunch of data because of this and I am not happy. Now I should have had my own tests to catch this, I accept that. But I guess I put some faith into widely-used data serialisation libraries, that they don’t lose any bloody data.
No idea if this bug is already fixed in SBJSON and I don’t really care.
I just converted my entire codebase to JSONKit. The precision is now preserved. The entire library is just two source files, and the code is actually readable. json-framework is so unnecessarily complicated I can’t even work out where my data is getting lost, so it’s no surprise the bug was introduced.
