-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/29/11 11:51 PM, Leon Qiao wrote: > Hi, > > Thanks for your response ! I missed something.In the thread method > "saveTheData", I do call the popToRootViewController on the main > thread by using "performSelectorOnMainThread:".
OK; that's an important detail to note. While this is then technically acceptable, it still seems like a strange design. What it sounds like it will do is perform a save in the background then, when finished, pop the nav controller. Is this what you really want? Presumably you are multithreading the save operation since it could potentially take a while and you don't want to block user interaction (*good*). But then you are going to abruptly pop the nav controller, potentially in the middle of whatever else the user might have been doing (*bad*). (I'm also a little unclear as to why an "add" button has a "save" action; I'm assuming you meant "add" as an analogy to the contacts app as stated, with your actual button being a "save" button in the same location.) So here's my question: do you actually want the save action to prevent the user from continuing display/edit? If so, throw up some sort of modal view with, say, a UIProgressView, so the user knows a save is happening but keep the save on a background thread (if for no other reason than to prevent the watchdog from killing your app). If not, keep the save on the background thread but lose the navigation controller action, letting it quietly complete (but display a message if the save fails). > It seems that both of the two functions(saveAction: and > tableView's delegate method) are invoked. And the navigation > controller first pop all view controllers to the root. And then > push the detail view controller, and sometimes it push to the > detail view and then pop to the root. So is there any tips about > the synchronization? And now to your original question, which probably still applies regardless of how you handle the above issue... please see my comments below. > On Aug 29, 2011, at 19:34, Leon Qiao <leon.qiao....@gmail.com > <mailto:leon.qiao....@gmail.com>> wrote: > >> When using UIButton, we can set the exclusive touch property to >> avoid tapping the two buttons at the same time. But what should I >> do for > the table >> view and the bar button item. Well, the exclusiveTouch property is defined for UIView, so UITableView (and its components) can be set to have exclusive touches. I had forgotten that UIBarButtonItem does not inherit from UIView, so that is an interesting little puzzle. I notice that in the contacts app the behavior seems deterministic, so there is something going on to handle synchronization. My first wild guess as to how you might do this without exclusive touches is to have the "lower priority" action (i.e. whichever you would not want performed if there were a conflict) use a delayed perform (you probably only need delay 0 to kick it into the next run loop iteration) and have the "higher priority" action start by canceling any previous delayed performs. There may be a more elegant solution, but this is the usual approach for situations such as distinguishing between single- and double-taps (at least in the days before gesture recognizers, which presumably are using this mechanism under the hood). Since you are familiar with performSelectorOnMainThread: I'm going to guess you have also encountered delayed performs before, but if not you will want to take a look at NSObject's – performSelector:withObject:afterDelay: and + cancelPreviousPerformRequestsWithTarget:selector:object: - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOXT4naOlrz5+0JdURAqOnAJ9pzz/Pce9C3yGIKoMHVh8bHbmibACcCYeD wpNq+ubIp7Xcct0eUZyYeu0= =cjgQ -----END PGP SIGNATURE----- _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
