Our iPad app uses a webkit UI for a lot of the user interaction, and we are now fielding complaints from users that in iOS 6, the UI is ignoring their touches. We've done side-by-side comparisons, and are now quite certain that whereas a touch-small-drag-release gesture in iOS 5 would trigger on onclick event, a touch-small-drag-release gesture in iOS 6 does not. Thus, in iOS 6, you need to be very careful to never move your finger while pressing a button on the UI. (Or, perhaps they just changed the definition of "small" in small-drag.)
We believe that disabling multi-touch gestures in the Settings > General page improves things somewhat, although we're not convinced this isn't a placebo effect.
As a test, I tried removing the scroll-preventing:
document.body.addEventListener('touchmove', function(e){ e.preventDefault(); });
from our code, but it made no difference (other than making it really obvious that the drag events are dragging).
My next idea is to go through and change everywhere that we rely on onclick to instead rely on ontouchstart, but, well, yuck. (Particularly, yuck, in cases where we also need the same code to work in desktop browsers.)
Are we alone here? I'm not finding any complaints about this in my searches. Any clever ideas?
You are not alone!
We hit a similar problem in our new game Blue Pilot, while we extend the support to iPhone 5. We are now handling both events.
Related
This is a quite strange behavior that 'persecutes' me since iOS 7.0 :) I hope someone of you can help me this time! As you probably know when you are using VoiceOver your gestures are totally different from the 'normal way'. When you need to bypass VoiceOver for a specific view you can set its accessibility traits as UIAccessibilityTraitAllowsDirectInteraction. When the view has this parameter set the user can interact with it as usual (like VoiceOver is not active in that particular view).
Quite often happens that this ability is randomly lost so VoiceOver acts in its normal way.
Did anyone of you encounter this problem in its experience? Did he solve it? Fortunately turning off and on VO seems to temporarily solve this issue (until next time it happens again)
Any idea? Thank you very much
I've seen this with other things as well. For example, notifications can be spotty, particular Screen Changed or Content Changed notifications. I believe this happens as a result of turning VoiceOver on and off. For example, if you were to turn VoiceOver on, leave it running, and open your application as a user would, you would never experience these issues.
However, if you use the VoiceOver shortcut. Or interrupt the application, re-install, and restart while using Xcode, you can disrupt the VoiceOver's connection to the application. It doesn't bond correctly. So, simple things like navigation work fine. But advanced features like notifications (and perhaps some of the more complicated traits) don't work.
Essentially, I would classify this as a bug, but a bug that only shows itself when you use VoiceOver in a way that only a developer would use it.
I have a tableview with a UISegmentedControl as a subview on each row (cell). Before iOS 7 I could scroll up and down freely without any finger contact being interpreted as a tap on a segment. Now, only on iOS7, I cannot scroll without unwanted firing of setSelectedSegmetIndex. If the user is not paying attention they unknowingly change settings when simply intending to scroll. Any way to prevent this? I am using Xcode 5 targeting iOS 6 builds, and bc of our customer base need to be able to do this, since some will not have upgraded. If I target iOS 7 things work as usual, it only seems to be when iOS 6 targeted builds are run on a device upgraded to iOS 7.
I tried to reproduce the issue with Deployment target 6.0 and 7.0 SDK. But I didn't face the issue.
If you want to manually manage the firing of setSelectedSegmentIndex,
you can set the property momentary to YES on your segmented control.
This is indeed a bug, and it seems clear that Apple is not going to do anything to address it. In iOS 7 UIButton and UISegmentedControl objects placed on UITableViewCell objects will interpret user touches intended as swipes as taps (selections) This was not the case with iOS 6. Here's the vague, non-commital reply I received back from the Apple engineer: "After some investigation there indeed appears to be several changes within iOS 7 in how controls within UITableViewCells interact with gesture recognizers. For iOS 7 the table view is making its best attempts to mediate or allow controls like sliders and segmented controls to have a higher propiority over gesture/touch events. So this behavioral change doesn't appear to be customizeable, at least not allowing to revert back to the older behavior in iOS 6." My intention is not to besmirch Apple's reputation here. The previous times I've worked with their engineers they made determined efforts to figure out if their code was the cause, and admitted it clearly if so, offering help for workarounds.
Hi I have been working on a blackberry app and developed about 90% of the app .But my client wants the app should work on blackberry touch also. So I just wanted to know what changes I will need to do to convert the same code to work on blackberry touch .Please help me I am new to Blackberry app development .
Just to confirm, we are talking about a Java application running on BB7 or earlier OS.
The short answer is, it depends.
If you have used standard RIM controls (buttons, ObjectChoiceField etc.) then these will work on the touch screen with no change. If you have used your own controls, for example an image button, then these might not work very well - for example the button might not be big enough to be hit easily with a fat finger.
The other problem is the virtual keyboard, it may appear at points when you do not want it to and not appear when you do. Not a problem on a lot of phones, but remember there are at least 2 non keyboard phones out there, so the Virtual keyboard is the only option for typing.
The best approach is work through each of your screens and try them in the Simulator. Zoom the Simulator so that it looks like the real device. And pretend you are using a finger, don't rely on the mouse because you can position the mouse very accurately.
I would raise new questions about specific Fields that you have problems with, rather than continue this with any issues you find.
I'm using sencha touch 2 in my ios app. but the tab panel is too slow, there's is one tab that contains a lot of content, but all the tabs are slow (there's a lag between when the tab is hilighting and the page transition and it takes ~1 second to switch).
I tried the deferredRender parmater but it didn't help.
How should i write my tabPanel to make it faster?
Note : the same page switches tabs faster on android, although in everything else android webview is slower
Thank you
This question is quite similar to yours:
PhoneGap 1.4 wrapping Sencha Touch 2.X - What about performance?
As I said in that topic, generally Android's transition between views is faster but other effects (especially scrolling) are much slower than iOS.
Right now the only solution I've known is to keep your DOM light-weighted. Don't try to create all views that might appear in your app and call them later through setActiveItem() because it enlarges your DOM so terribly. When you switch to a new tab, I recommend that you should destroy all other tabs' child components (and only keep some variables if you want to restore their states when switch back).
Is it enough to disable a toolbar button if the OS does not support the underlying functionality such as the new Twitter Support in iOS 5 or do I have to remove it entirely from its toolbar?
The question is slightly subjective in that this is more of a design/user experience issue than anything else. I believe Apple may approve such an app, but you'll have to ask yourself this:
If you were a user and you saw a button that was never enabled. Would you fully understand why?
I would remove the button entirely for unsupported features - else it's like dangling a steak in front of a lion behind bars. Having a perpetually disabled buttons may confuse your users or cause them to be angry that they can't get this feature without upgrading or changing their device (in the case of differences between iPhone and iPod touch for example).