I have an iOS function activated by a button that runs for a few seconds. I disable a couple of other buttons on the view and when the function that is running ends, if you have touched one of the disabled buttons, that function activates when the button is re-enabled.
It appears that the button touch is buffered, even if it is disabled, and when the button is re-enabled the action event happens.
It does not cause any functional problem other than the impatient user can cause an unwanted function to occur.
Is there a solution?
There are a number of possible solutions. A simple approach is to create a boolean property in the view, e.g. processRunning, and do something like this where you start the process:
if not processRunning then
processRunning = true
//run your process
processRunning = false
That sounds like a SERIOUS bug… disabled controls should NEVER produce events, buffered or not
I tried that technique and it seems that the timing of the “buffered button touch” makes it not work.
When the process ends and turns “off” the boolean the “buffered touch” has not yet registered so when the touch is activated, because it is “buffered”, the boolean has already been turned off.
I suppose I could turn off the boolean with a short single shot timer and have the other buttons simply exit if the boolean was still turned on.
Yes it does seem a bit like a bug. If I touch two buttons during the long running process they BOTH are buffered and first one happens then the second.
Clearly the buttons are disabled visually by being “dim”.
If your process is executing in the UI thread the button taps (whether they should register or not, a separate point) are handled after your process completes. In that case another approach would be to run your process in a thread. That has the added advantage of not holding up the UI and avoiding Watchdog stepping in and terminating your app should your process run too long.
The process calculates the distance from your current location to the Lat/Long of a list of locations from data in a SQLite table then redisplays the list. I probably need the UI to be held up because the list that is on the screen in an iosTable will change in a few seconds. I suppose I could also disable the iosTable in addition to the buttons.
If the Watchdog creates a problem then I suppose a thread is the answer.
The sort on my iPhone 6 takes about 2 seconds but I am not sure how fast on a 4 or 5.
It’s definitely a good idea to test on older hardware - the results can be surprising :). I do the main database tasks in threads to avoid UI interruption and, in the case where an iOSTable is displaying data, I don’t bother disabling the table as it seems fine in my app to just update the data in a live table. I use the iOSTableDataSource interface to supply table data which seems to work seamlessly. You really want to try to keep your app responsive at all times - users don’t like to wait!
I finally got all of this working in a thread. Thanks for the help to all who responded … and I learned a few more things about iOS development.