Part II: Spawning Threads Using Selectors With Multiple Parameters

05/18/2010 9 comments

In Part I, we introduced a method that emulates the Apple-supplied convenience method performSelectorInBackground:withObject:, but which adds support for selectors that take multiple objects as arguments. We saw the power of NSInvocation objects, but also saw how they were a bit cumbersome to use on a routine basis. Our solution gave us what we wanted by allowing us to pass in an array of objects to be used, along with a multi-parameter selector, to invoke an arbitrary method on a background thread (or on the main thread).

This solution is a great step forward when we need to invoke something like [myObj setCharacter:@"The Doctor" currentActor:@"Matt Smith"]. But what if we have a bunch of methods that don’t take objects? Wrapping them all in NSValues begins to really litter-up the code, and is frankly a bit tedious. And what if one want to invoke something like [myObj setCharacter:@"The Doctor" favoriteActors:@"Tom Baker", @"David Tennant", @"Matt Smith"]? There has to be a cleaner way, right? Behold! There is, and the answer lies in the somewhat obscure-ish va_arg macro. Now we can save the world from our unwieldy code. Allons-y!

Read more…

The Names of Fonts Available on iPhone OS

03/24/2010 2 comments

Interface Builder is great. It’s an Apple-y app the lets you build your own Apple-y apps. It’s all so much Apple-y goodness. Well, maybe even too much goodness. Say you want to change the font family for your UILabel. Maybe you like the Helvetica. Or maybe you like the Arial.  So off you go to the Attributes Inspector and dutifully click on the Font attribute.  POP!  The familiar ol’ standard OS X font selection dialog window springs up in front of you…with all your workstation’s installed and active fonts.  Here’s the catch: the vast majority of those fonts will not be available on your iPhone or iPod Touch application. What a downer. But we can at least sort this out easily enough. Read more…

Troubleshooting Bonjour Networking for the iPhone

01/17/2010 15 comments

Debugging good code running in a stable environment is hard enough.  Debugging code that responds to outside events, well, that’s even harder.  If you are an iPhone developer working with NSNetService or GKSession, then you already know this.  Despite a glut of excellent documentation on how to write code that uses these powerful classes, there is a dearth of documentation on how to troubleshoot and debug that code.  Here are my notes on lessons that I have learned along the way.  If you have a problem with your code and are stuck, hopefully they will point you in the right direction.

Still with me?  Then let’s dig in!

Read more…

Keeping User Defaults Synchronized with Settings.bundle

08/12/2009 3 comments

The first time you wade into the NSUserDefaults system in Cocoa, you feel sweet relief wash over you. Managing user preferences in any application can be a very tiresome chore. NSUserDefaults is like hiring a housekeeper, only it doesn’t cost you anything.

Excited with the possibilities, you dive in. You quickly have your Settings.bundle added to your project and your settings menus built. It all looks impressive, and only took a few hours. Woo hoo! You launch your app to watch this sorcery in action, when—bang! The app crashes. Not cool. A little debugging shows that the defaults you created on the root page work fine, but only if you open the your app’s Settings page before launching the program. And child menus have the same problem, except that users have to navigate to each child menu before the defaults work. You imagine the reaction you’ll get when you explain this to your users: I have to do whaaaat?

Read more…

Mysterious CALayer Object Proliferation Caused By Core Animation?!

07/15/2009 Leave a comment

I have been reviewing some UI code that I just completed. It’s my regular practice to check for leaks, etc., so that I can verify that my code is doing what I think it’s doing. I typically fire up Instruments running the Leaks monitor, and not only review any leaks that are found, but also review Object Allocation behavior.

I plugged a couple of leaks that sprang up, but I still could not figure out why object allocations were growing to infinity (albeit at a snail’s pace). I could launch my app and just let it sit idle and CALayer objects were just proliferating. I narrowed the problem down to a simple background [UIView animation] block. Surely Core Animation didn’t leak, right?

Turns out, the answer is: not really. Thanks to Apple Devforum poster Rincewind, we now know:

You are probably seeing a bug in ObjectAlloc. You can confirm this in one of two ways

1) Examine the memory address of these “leaked” objects – they will probably all be the same (or a small set of addresses).

2) Add the Memory Monitor instrument from the library and watch your application’s Real Memory – this is generally a far better indicator of how much memory your application is using in total anyway.

Sure enough, he was right! The objects pouring into the list on Instruments all clustered around the same few memory addresses. Watching the physical memory confirmed that, despite the ever-growing heap in Object Allocations, physical memory was holding steady.

Whew! But Grrr! Hopefully you can avoid the frustration (until it’s patched).

Happy Debugging!