Recently I was able to create a tablet software for my Cerebral Palsy girl to "talk" to me, since she can't speak.
Well, a friend of mine has Amyothrophic Lateral Sclerosis (ALS). He can move just one finger and he is willing to use my daughter's software to be able to "talk" again.
Since he can move just a finger, I created a version where each item "blinks" (in yellow) for some time (just one second) and if he presses a mouse button, the item focused (in yellow) is activated.
See below:
It works if you leave the mouse over the black portion of the screen. If mouse is over the buttons, it won't work, it will click the button where the mouse is over.
Also, if he uses a keyboard and he presses the ENTER key, it will activate the first button, then, if he clicks the left arrow and then presses the ENTER again, it will activate the second button and so on.
So, I wish I could create an generic event that if he would press the ENTER key, just the selected (in yellow) item would be activated.
Any ideas?
Well you could make two different modes. One where there are click listeners for each picture,and another where simply a click anywhere on the screen is recognized ( ex. find the largest layout id and set a listener). Then in the second mode, use
http://developer.android.com/reference/android/view/KeyEvent.html
to detect KeyEvents such as Enter, and handle them depending on the highlighted View.
Related
I have the keyboard open in my app, I want the user to be able to type, and then tap a colour selector widget I have made (which changes text colour). The problem is that it takes 2 taps, the first one closes the keyboard, the second one actually selects my colour picker. Is there a way to make this one tap? and also keep the keyboard open if possible, so they can change colour then go back to typing without focus issues.
I'm looking at the Support4Demos from the Android SDK and I'm not sure if this is working as intended. Specifically, I'm referring to accessibility focus when using the Widget > Explore by Touch Helper demo. If I tap on one of the blue regions to give it accessibility focus then tap on the on-screen home button focus will switch to the home button. But if I tap on the same blue region as before nothing happens (but if I tap on the other blue region focus transfers from the home button). I'm testing this on a Kindle with on-screen navigation buttons.
Am I correct in assuming that focus should transfer back to the blue region? If so, what is the proper way to handle this? Presumably there would be a way to know that the user tapped on something outside of the app and in response to this I could clear state in the ExploreByTouchHelper but I'm not sure how I would go about that.
Hi there is thery any way to invoke a method that enables or disables the Touch Screen of Android?
I want this, because I have several buttons on my activity. When the user clicks on a button, it takes a few seconds to start the following activity, and because of that, while waiting that time, I don't want the user to be able to press anything.
I used a boolean that is True at start, then It changes to false when I click on the first button. And to every click on a button I check if the boolean is true...
But the problem is that Visually the user can click the button, it gets that look of being pressed..
So is there any good method that disables the entire touch screen ? And another that enables the entire touch screen ?
Thanks alot in advance ;)
But the problem is that Visually the user can click the button, it gets that look of being pressed
Disable the buttons, using setEnabled(false). This will not only prevent the user from clicking on them, but they will visually appear disabled, to let the user know that the user cannot click on them. It is important for the user to get the proper visual feedback about the buttons being disabled (and later enabled).
is thery any way to invoke a method that enables or disables the Touch Screen of Android?
Not really.
I have a EditView. When some one clicks on the EditView, the only way the keywbaord will go away is if the back button id press.
I saw some apps have it so when the keyboard comes up, there is a button that says done in the lower right hand corner. When this is press the keyboard goes away.
My app does not do this, does anybody know how they did this?
Also is it possible to have the keyboard go away when the enter key is press, insrad of having it add another line of text?
You can either use TextView.setImeOptions() and pass it actionDone or use the android:imeOptions="actionDone" attribute in your layout.
To close when enter is pressed, use a custom OnEditorActionListener. However, it would probably be better to change the enter key to done as above so as to convey what action will occur.
See this SO question.
On Android 2.1, just as on most graphical computer OSes, pressing the mouse while in a button, then dragging away, then dragging back, then releasing (while within the button rectangle) would result in a button press. It would also highlight while the mouse pointer was within (or actually near) the button, going off as the pointer left the zone, then back on when the pointer returned.
This behavior allows the user to cancel, mid-press, by dragging away from the button until its highlight is off and releasing; it also allows the user to change her mind about cancelling, so long as the mouse is still down, and go back into the button to "rescue" the click.
In 2.2, it appears that Android no longer allows a return to the button. Dragging away cancels the highlight, but returning with the mouse still held down does not re-highlight the button, nor does an away-and-return click generate a click event.
So, my questions: Is this change real (has anyone else seen it)? and: Is it intentional? What is the rationale for this change, if it is intentional?
Since I tested in an Android 4.0.4, I can guess this was intentional.
My guess is that they made the change to prevent some problems with people who are not used to touchable screens. It can also be to improve usability for people with disabilities. However, I'm not Google nor know the real reason of the change. Those were just my guesses.