Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

whitehexagon

macrumors regular
Original poster
May 12, 2007
147
0
I have a long Java background and wondering if the iPhone has similar guidelines for working with multi-threaded GUI applications. for example only updating the GUI from the event thread?

What I'm planning is a Singleton data manager that is collecting data from various asynchronous data sources and a secondary thread that is updating the GUI based on the updated data. Does that sound like something that is manageable on the iPhone with cocoa-touch?

I know how to do this in Java and I'm wondering about the equivalants in objective-c. ie:

Thread safe collections. (Java ConcurrentHashMap)
ThreadPool with single thread. (Java Executors.newSingleThreadExecutor)
Singleton implementation - any doubled checked locking/memory guard issues?
Scheduled events (Java Executors.newSingleThreadScheduledExecutor)
 

xsmasher

macrumors regular
Jul 18, 2008
140
0
I have a long Java background and wondering if the iPhone has similar guidelines for working with multi-threaded GUI applications. for example only updating the GUI from the event thread?
Yes, UI methods should only be called from the main thread. It's easy to do so, though, with performSeleectorOnMainThread: , which queues up the method of your choice to run on the main thread.

What I'm planning is a Singleton data manager that is collecting data from various asynchronous data sources and a secondary thread that is updating the GUI based on the updated data. Does that sound like something that is manageable on the iPhone with cocoa-touch?
Sure, no problem.

I know how to do this in Java and I'm wondering about the equivalents in objective-c. ie:

Thread safe collections. (Java ConcurrentHashMap)
ThreadPool with single thread. (Java Executors.newSingleThreadExecutor)
Singleton implementation - any doubled checked locking/memory guard issues?
Scheduled events (Java Executors.newSingleThreadScheduledExecutor)

The built-in mutable collections are no thread-safe. You'll have to use locks.
The Cocoa equivalent of a hashMap is an NSDictionary, or NSMutableDictionary. This guide should help.
http://developer.apple.com/document...tml#//apple_ref/doc/uid/10000057i-CH12-125828

Apple gives a very straightforward recipe for creating a singleton - do not let the Objective c syntax scare you, it's all the same once you're used to it:
http://developer.apple.com/document....html#//apple_ref/doc/uid/TP40002974-CH4-SW32

I don't think I understand Executors enough to answer your other questions, maybe someone else does; but it's trivial to create a new thread and run a method on it:
Code:
[self performSelectorInBackground:@selector(someMethod:) withObject:arg];
 

whitehexagon

macrumors regular
Original poster
May 12, 2007
147
0
Thanks for the really useful info! I'll have a read though the provided links but I'm already feeling more comfortable with this design.

With regard to the Executors. Basically they are some nice factory methods that provide a thread pool with a single thread (with will be replaced should it fail), and with the second pool with the chance to schedule a job to run At a certain frequency, or with a fixed delay between each iteration.

Basically I don't want to be hogging the CPU, so just checking my data structure every 200ms or so, and then triggering the nessesary GUI updates as required.

btw for implementing thread saftey on NSDictionary, would it be best to encapsulate this with just some synchronized accessor/mutator methods? or is there a preffered approach (extending the class or something else I might not have found yet in objective-c?)

And finally I'm still reading about memory management, but this singleton pattern from Apple looks a bit hairy already? Are these gonna get cleaned up with my App shuts down?
 

xsmasher

macrumors regular
Jul 18, 2008
140
0
With regard to the Executors. Basically they are some nice factory methods that provide a thread pool with a single thread (with will be replaced should it fail), and with the second pool with the chance to schedule a job to run At a certain frequency, or with a fixed delay between each iteration.
Not sure about this, but check the list of methods built into NSObject (the root object for all classes in Cocoa).
http://developer.apple.com/DOCUMENT...ference.html#//apple_ref/doc/uid/20000050-SW3

btw for implementing thread safety on NSDictionary, would it be best to encapsulate this with just some synchronized accessor/mutator methods? or is there a preferred approach (extending the class or something else I might not have found yet in objective-c?)
There's an NSLock class you could use for this - either your code could lock the lock before touching the dictionary in any way and unlock after, or you could extend the class and put locks around all of the accessor/mutator methods.

And finally I'm still reading about memory management, but this singleton pattern from Apple looks a bit hairy already? Are these gonna get cleaned up with my App shuts down?

Everything allocated in your app will be cleaned up when you shut down. It's better practice to clean up yourself, of course - you could always write another class method that releases the singleton and sets the pointer back to nil.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.