UIAccessibilityTraitAllowsDirectInteraction and VoiceOver: issue or bug in iOS? - ios

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.

Related

iPhone web application : the virtual keyboard opens unexpectedly

I am having a very weird issue on an iPhone and I would like to have suggestions on the best way to troubleshoot. My web application works fine for a moment then suddenly all text fields and buttons will have no effect, but only to open the virtual keyboard.
For example, a "delete" button which used to display a "yes/Cancel" modal will only make the keyboard open, the modal won't show up... When I reload the page, everything is working as expected again.
I am testing with an iPhone 6 and Chrome.
Did someone already encountered an issue like that?
I have absolutely no idea how to track down this behaviour and all suggestions are welcomed, What do you suggest I should look in priority?
This issue was coming from a bug in a version of Chrome I was using at that moment (I have no idea which one, since my phone has regular automatic updates).
I strongly advise to have always at lease two different platforms when testing websites!

Can an iOS app interfere with the ipad keyboard?

I ve been getting some reviews on my app about a freeze on the right side of iPad keyboard. I did not even know that could be possible?
Does anyone experienced anything similar?
Any help on this keyboard freeze problem would be really appreciated cause I m little bit lost.
The "right side" of the keyboard is probably a red herring.
There are only two ways you could interfere with keyboard input:
Your input field is rejecting certain characters, but not giving user feedback that you're rejecting them.
You are doing some long-running work on the main thread (like downloading data, reading to/writing from disk, etc.) If this is the case, move it to a background thread.
No it's not readily possible from what I know, due to the strict permissions of the iPad and apple in general it would not be possible for an app to do this without you intentionally "hacking" the iPad. The only thing i could suggest is that the users are downloading malware to the iPad unwittingly through the site that you have made your app available ??

how to distinguish on iOS volume button clicked from setting it by a software

Is there any way to distinguish in the iOS app a situation that someone have changed volume by hardware buttons on iPhone/iPad from the situation that it has been done by some UI control in the app?
I have searched for that and so far I came up with many ways to be notified that the volume has been changed but there is no way to find out whether it was done by the UI control or hardware buttons. Notifications include info abut a reason of change but it is the same for both situations.
After a long search I came up with this:
There is no way to detect hardware button been pressed (so far iOS 7). You can only be informed with the result - volume changed. It means that the only solution will be to properly handle situation when the volume change is triggered by some UI component.
You might want to have a look at the private API. rpetrich did some research again.. :) click here
But you need to know that this is not really a good idea because apple probably will reject your app when accessing private apis.

Disable iOS "Perspective Compensation" programmatically?

Maybe I'm just searching for the wrong term, but I've been able to find very little information on this subject, and I think it could be a problem for my app.
A while back, there was an article on the accuracy of the touch screens on iOS devices, and it seemed quite poor compared to other phones. Here is a link a posting about it:
http://forums.macrumors.com/showthread.php?t=1660713
Anyway, many of the commenters referred to "perspective compensation" as a cause for the inaccuracy. Basically, they are saying that iOS intentionally registers touches above the actual point of contact to compensate for the typical viewing angle of the user or for the angle of their finger or something like that. I have found that there is some credibility to that claim myself by doing as one of the commenters suggested and trying to use my iPhone upside down. I did find that it was difficult to touch things in some cases, and I have also noticed this problem in one of the apps I'm developing.
So, in case you want to skip all that rambling above, here is why it's a problem for me:
I am developing an app that is intended to be used by two people at the same time. The iPhone or iPad is placed on a surface between two people who are sitting across from one another, and they are instructed to quickly and accurately touch items on their respective halves of the screen competitively. What the article's comments made me suspect might happen, and what I have also found in practice is that the person using the phone upside down will have trouble touching buttons and dots on their first try. I've also tested slowly with a stylus and found that the touchable area of a button does indeed extend below a button, or above the button for the person using the phone upside down, hence the discrepancy and problem/disadvantage for that person.
So finally, if you want to skip that also, here is my question: Can "perspective compensation"(if that's what it's called) be disabled programmatically, and can it be done for specific views of an app? Have any of you noticed this and dealt with it in an app of yours?
While I have found that "perspective compensation" does seem to be occurring, I have not found any official documentation of it, and therefore have no idea how or if it can be disabled. When I search for "perspective compensation," the only results I find are links to the same article and comments.
I can't help but expect that this may have been asked before or is solvable with a simple checkbox, but perhaps for lack of the correct term to use, I have been unable to find any leads.
Thanks in advance for any of your solutions or suggestions!
This can't be done with the current SDK. All we have access to is the touch location, which is at a single point. Other search terms you might try are "digitizer" or "raw touch data", but there is definitely no check box or simple option.
To implement this, you will have to compensate for the touch location yourself. You'll need to play around with a compensating offset value for the upside-down buttons. Hit testing on views is probably the best place to do this, then your buttons can just respond to events as normal.

When the device language changes, backgrounded apps quit themselves

I've observed that if I change the device language, and after coming back to home screen, all background processes quit themselves. If I click on a running app icon again, it starts from scratch -- i.e., from application:didFinishLaunchingWithOptions:.
Am I wrong somewhere? What can I do to work around this?
I think this is a nothing odd and a default behavior.
You may want to look into this post if you want to make changes right from inside your application, though I am not sure on how good this is, as I have not personally implemented it.
language change only after restart on iphone
Let me know if you need more help.
Hope this helps you.

Resources