4

I know and heard most UI related shouldn't be done in thread other than main.
I also know that you can update non-view related data member(that you added) of UIView derived class.

I wonder if the below operations are fine or not to do in background thread.

  1. allocing UIView
  2. init UIView with/without(CGRectZero or just init) frame info
  3. modifying frame/image(UIImageView's) property of UIView
  4. modifying image property of NSObject derived class. (treating UIImage as data)
  5. accessing subviews with subviews method
  6. etc.. Is there a well defined documentation on this issue?

Thank you

eugene
  • 39,839
  • 68
  • 255
  • 489

1 Answers1

3

You shouldn't be doing anything view related in a background thread. All of the items you listed should not be done in a background thread. If you're breaking your app up correctly for MVC, the view should only contain items that dictate how it is displayed. So anything relating to one should only be in the main thread.

All of your data manipulation should be residing in your model. It can be threaded as needed for performance. Just be careful that you send any messages to update the UI for the data manipulation on the main thread. This includes notifications. They gets sent on the same thread they were created on. So it's easy to forget to switch into mainThread when sending one.

McCygnus
  • 4,187
  • 6
  • 34
  • 30
  • thanks for answer, Isn't #4 fine? defining UIImage* as member of my custom class, and setting/getting the variable from other thread. – eugene Apr 22 '11 at 08:51
  • Yes, it is. Sorry, I misread UIImage as UIImageView. It's fine to do something like read in an image and do some processing on it in a background thread and then pass it to the main thread for display. Just make sure the image processing libraries your using are thread safe too. – McCygnus Apr 22 '11 at 20:55