On Mar 14, 2012, at 11:05 AM, Gary L. Wade wrote: > To solve your thinking on this matter, conceptualize the background thread as > a (M)odel object, the main thread a (V)iew object, and possibly an > NSMutableArray of NSStrings each having an individual log message being a > (C)ontroller object. By breaking your logic up accordingly, it should be more > obvious why things are the way they are. A simple way to update the UI is to > add a timer to your main thread that checks to see if the controller object > has been changed; if so, it can update the UI. To accommodate a full UI > thread and fit within a user's visual update time, a time interval of 1/120 > second should be fine. Naturally, you'll want to lock the controller object > while being updated by the model or being (quickly) read by the view.
For something that is frequently/constantly updating that is about perfect. Now for something that does not update frequently, a perfectly good option is to queue an event on to the main thread somehow. There are lots of ways to do this--the easiest for a one-off, and arguably dirtiest because of the coupling, is to use performSelectorOnMainThreadWithObjectWaitForCompletion: NO (yeah, I misspelled it, not looking at the reference right now), where the update can just be an object that is passed from bg to fg, and *not* shared otherwise. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
