Under the Bridge

Runtime Compatibility

Here’s a good article on how to write code that deals appropriately with current runtime iOS versions:

Tips & Tricks for conditional iOS3, iOS3.2 and iOS4 code

Make sure you read the comments too; in particular, we like this trick for dealing with deprecated methods

Make a @protocol, eg DeprecatedMethods, that defines the deprecated methods, then cast, eg [x setText:@"foo"] to [(id<deprecatedmethods>)x setText:@"foo"]. No more compiler warnings, and the deprecated methods are still obvious in the source.

as we’re firmly in the “all possible warnings on, and warnings are errors” development style camp, but sometimes you just really have to use a deprecated method. That’s a very stylish method indeed of resolving that conundrum.

There is a particular kind of runtime compatibility that may cause you particular grief next time you’re updating though; MPMoviePlayerViewController is the new way to play movies in any target view, but it seems that the behaviour of the old MPMoviePlayerController has been changed when linking against the 4.0 SDK, so soon as you recompile your project hilarity ensues. Here’s an article over at Dr. Touch about the issues:

The 3.2 Hurdle of MPMoviePlayerController

as of today you’ll note it says

… I had to revert to compiling against SDK 3.2 and disable the 4.0 code for the time being. Will open an inquiry with Apple later…

So if you’ve got some MPMoviePlayerController code that needs updating, watch out for issues!

UPDATE:

Here’s another post on dealing with the movie playing thing:

Getting MPMoviePlayerController to Cooperate with iOS4, 3.2 (iPad) and Earlier Versions of iPhone SDK

UPDATE 2:

And another …

Play Video with MPMoviePlayerController in iOS 3.0 and 3.2/4.0

1