Threading on iPhone and Java equivalents

Discussion in 'iOS Programming' started by whitehexagon, Jun 13, 2009.

  1. whitehexagon macrumors regular


    May 12, 2007
    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)
  2. xsmasher macrumors regular


    Jul 18, 2008
    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.

    Sure, no problem.

    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.

    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:

    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:
    [self performSelectorInBackground:@selector(someMethod:) withObject:arg];
  3. whitehexagon thread starter macrumors regular


    May 12, 2007
    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?
  4. xsmasher macrumors regular


    Jul 18, 2008
    Not sure about this, but check the list of methods built into NSObject (the root object for all classes in Cocoa).

    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.

    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.

Share This Page