Re: UIBarButtonItem exclusive touch
Re: UIBarButtonItem exclusive touch
- Subject: Re: UIBarButtonItem exclusive touch
- From: Conrad Shultz <email@hidden>
- Date: Tue, 30 Aug 2011 12:46:48 -0700
-----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 <email@hidden
> <mailto:email@hidden>> 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 (email@hidden)
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:
This email sent to email@hidden