Recently, I have been enjoying the opportunity to practice implementing concurrency in my software engineering.
Following iOS’s own concurrency programming guidelines, I could develop some confidence in designing the workflow from the initial stage to achieve optimal performance.
By separating works into two types; for UI & not for UI; I have been able to keep queues of operations to be as simple as possible. Also, due to obvious convenience of using Block programming with iOS SDK, I could be able to actually see where asynchronous queues branched out, and merged back, right within the scopes of codes.
Being able to keep tracks of these operations was quite exciting for me, since I used to have great fear in adopting concurrency. But the real issue I have to fear should have been lack of real performance and difficulty in seeing the workflows among the objects.
Fortunately, learning more about the convenience of using NSOperationQueue and the basic criteria for deciding when to branch out and when to merge back, which is; “Are these operations for UI or not?”, I could see what’s actually going on much clearer than ever.
It has been a good case for me to realize it’s not enough to memorize the list of methods, but often it’s more important to know when and where to use them appropriately.
fXceed.com 