views:

142

answers:

2

I've got some somewhat hefty string size calculations happening in my app (each one takes close to 500ms, and happens when the user scrolls to a new "page" in my app (like the Weather app). The delay only happens once per page, as the calculation only needs to be run once (and can even be cached for subsequent launches with the same data).

Anyway, I still like to not block the UI for this type of work, as to me it screams using threads, but I know UIKit is not meant to be used from other threads. (I know NSString is not part of UIKit, but the string sizing methods are part of the UIKitAdditions...)

So how should I go about doing this? What's the best way to not block the UI and do so safely?

+1  A: 

I may be wrong, but I believe the prohibation of using UIKit in other threads is related to the general way that GUI's work (being single threaded) and normally is only applied to situations where the GUI itself is affected.

The sizeWithFont: method does not actually affect the GUI in anyway so I don't think there would be a problem with calling this in another thread.

Maybe an iPhone person with more experience in how this method works behind the scenes can confirm my thinking or set me straight.

Brandon Bodnár
It could also be that some calls do not handle multi-threaded calling well... that said, I would try it from an operation and see what happened, trying to trigger failures in any way possible through testing by repeatedly looping through the calculations while you exercise the UI.
Kendall Helmstetter Gelner
+1 on Kendall's comment. Since the UIKit methods were written with single threading in mind then they may not handle multithreading well.
Brandon Bodnár
+1  A: 

Consider using NSOperation/NSOperationQueue. There's a tutorial on Cocoa Is My Girlfriend, and Apple has a guide.

Shaggy Frog
This is the suggested route instead of threading in general, but does not address the question of where to do the work, on the main queue or some other queue. The main queue is sequential and so has the same blocking affect as running on the main thread, if I recall correctly.
Brandon Bodnár
I haven't used it personally, but at least according to the docs, it doesn't necessarily block: "The isConcurrent method of the NSOperation class tells you whether an operation runs synchronously or asynchronously with respect to the thread in which its start method was called. By default, this method returns NO, which means the operation runs synchronously in the calling thread."
Shaggy Frog
Sorry, I actually meant dispatch queues in my comment. The issue at question is wether it is safe to call sizeWithFont: on anything other than the main thread, using a operation queue or dispatch queue just gets around having to do the threading yourself, but not the issue of if it should be on the main ui thread or not.
Brandon Bodnár
I, of course, do agree with you about using Operation Queues instead of threading. My life has gotten so much easier since I started using them in both Mac and iPhone code.
Brandon Bodnár