Input action should happen like thisMobile Automation: I have a a scenario where i have to send keystrokes(inputs) from SoftKeyboard of an android device (like inputs from a real User). I tried with KeyEvent, SendKeys, androidkeycode, adb Shell input, Keys. Everything works fine, but i do not see any character pressed from a soft keyboard. Pls, help me to get solution for this.!!
The need: You need to simulate a press on the on-screen keyboard (using driver.tap())
The problem: Cannot get the Xpath or ID's of a on screen keyboard which puts us in a difficult situation.
Since i've struggled with this same problem in the past, i will advise you to create a function that calculate where each Key is located and press on it using the coordinates.
To be more clear:
Get the coordinates of lowest element you can find -> the keyboard itself is below it -> we can now know the height of the keyboard.
get the width of the screen
now, lets say you have a total of 4 rows(first row is q,w,e..) so we will divide the height by 4.
lets say you want a key from the first row which has 10 keys total, now dived the screen width by 10.
now you need to map each key to its location in a row. After that, call this function for each key you want to press.
I understand that it's ugly, and you will struggle with it a bit, but I don't know another solution to your problem.
Related
I'm having what seems to be an odd problem, and I'd greatly appreciate any suggestions which might help.
I'm trying to achieve due diligence by testing on a variety of screen form factors, but I'm having a problem when it comes to the default ( AKA Google ) keyboard on an emulated Nexus 4 using API level 19. AFAIK, according to the on-line specs the Nexus 4 was released with API 17, so it would seem to me that 19 ought to be able to handle any hardware in the Nexus 4.
I'm working with an app that displays a document and if the User wishes, allows notes about the document to be entered, at the same time the document is being viewed. By default most of the screen is taken by the view of the document. But when a Button is pressed to allow notes about the document to be entered, Views are re-arranged to allow for a soft keyboard to be displayed along with an EditText view to accept the notes and still allow for as much of the document to be viewed, as conveniently as possible, and scrolling is provided.
In the default "portrait" orientation I'm able to shoehorn in what I need with out too many problems; but oddly in "landscape" orientation, no matter how I try to constrain it, the on-screen keyboard itself occupies fully half the screen "height" and takes the other half with a separate input area it displays, several lines high; the "DONE" button is displayed separately about half way up the height of the input area near the right screen edge.
In order to keep the soft keyboard and any associated input area as small/simple as possible, I've supplied these attributes for the EditText:
android:inputType="text|textNoSuggestions|textShortMessage"
android:singleLine="true"
and this for the themes in my styles.xml file :
<item name="android:windowSoftInputMode">stateUnchanged</item>
I've even considered going as far as building a custom keyboard structure in XML, etc.. But my understanding is that Android won't allow a keyboard definition to be used "privately" for just one app; instead it requires a custom keyboard description to be approved by the User as the User's standard keyboard, or won't allow the custom keyboard to be used at all.
Have I've missed something? Am I not making the correct use of attributes for my purpose? Is there something else I need to do in order to get the desired effect? Does the actual Nexus 4 behave as I've described? Or is there a problem with the Emulation?
I'd be very grateful for any helpful thoughts.
Hopefully some images will help to illustrate the issue.
Default document viewing mode:
After the User presses the "MAKE NOTES" Button, note taking mode. This is before the User presses within the EditText view ( which is displaying the hint string "To enter notes, press here" ) :
When the "MAKE NOTES" button is pressed I rearrange things. It appears to me that the controls fit roughly in the upper left quadrant,
the document view is placed in the notably smaller scrollable area roughly in the upper right quadrant; I request that the keyboard be displayed, and it fits on the screen below those things. Since the keyboard does fit, I wouldn't have expected the "extract" view; especially since by the time I got these emulator screen snapshots, I had restricted the EditText view to one text line, so I would expect input to occur in place, within the
EditView, just as it does in "portrait" orientation...
Instead, when the User presses within the EditText view:
There is no way to change the height of the keyboard. The keyboard itself sets that, in the onComputeInsets of the InputMethodService class, combined with the height of the view returned in onCreateInputView.
You actually can create a keyboard just for your app, but your users will hate you. You aren't going to write Swype functionality, or good autocorrect, or anything else without spending the years on it the other companies have.
What you seem to be describing is a full-screen editing situation called extract view where the keyboard takes over the full screen in landscape mode. THat's the standard Android experience for phones because too little of the screen is left for apps to be usable. Is that what you're seeing, or is it something else? If it is extract mode, try adding android:imeOptions="flagNoExtractUi" to the textview.
I am creating a custom keyboard for android devices and i have managed to implement everything but being able to move up and down lines through the use of buttons not just dragging with your finger. I am implementing this for small screens of older devices.
I have managed to implement moving the cursor one character to the left and right and to the end and start of the text how ever i cannot figure out how to implement moving up and down multiple lines like you would when navigating a word document on a normal computer.
I am not sure how you programmed all that, and it sounds like some really nice work, so not sure if you had this idea or if it is even possible, but:
Couldn't you make the cursor move to the right x-Times when trying to go down a line, where x is the amount of characters in one line, or rather the length of the String in a line?
Depending on the way you programmed it, if there is a string for each line, you could see where the cursor is in the line you are going from (e.g at the 3rd character of the String) and then just put it there in the next line.
I have a user reporting an error with my app. I have several EditText fields in my layout. I only want the user to be able to enter signed decimal numbers. However, I don't have the layout declare them to be number|numberSigned|numberDecimal because I have a custom TextWatcher attached to these fields which handles the input and makes sure it is correct. I do this because I want the minus key to act as a toggle.
Let's say, the field has "300" in it. If the user taps minus, my custom TextWatcher intercepts it and turns it into "-300" instead of "300-". If they tap minus again, it'll remove the existing minus and change it to "300".
This works just fine for just about everybody, but it doesn't work on the Kindle Fire. The decimal point and the minus key on the virtual keyboard are disabled, so they don't even have the option of tapping those keys and letting the custom text watcher do its work.
If I do declare the fields to be number|numberSigned|numberDecimal, then the fields won't let the user tap the minus key unless the cursor is in the left most position (i.e. before the 3 in 300).
How can I tell the Kindle Fire to make sure the decimal point and minus keys need to be active, but at the same time not restrict the user's allowed input before it reaches my custom TextWatcher... you know, like the way EVERY other Android device has been working for me? :)
The answer from #zapl:
theEditText.setRawInputType(Configuration.KEYBOARD_12KEY)
worked! Go find some other good answer of his and upvote him so that he can get proper credit for this answer. ;)
My application has a simple 'About' box.
It has a few clickable TextViews (email addresses, phone nos, addresses) all contained within a relative layout within a ScrollView (To accommodate low res screens).
The device I am testing with (Motorola Charm O.S ver 2.1 update 1) has a regular QWERTY keyboard. The problem I am facing is with the use of the arrow keys.
I want the cursor to move predictably from one clickable field to the next and this is where I need help. On the fields that don't need focus I have set the android:cursorVisible="false".I tried using the android:nextFocus* properties but still don't get the desired behavior.
The cursor gets stuck in the first field and overall the behavior is a bit unpredictable. Any ideas on how to get this done. Right now trapping the keys using code seems to be the only option.
TextView.setMovementMethod(LinkMovementMethod.getInstance())
The documentation is a little terse but it's basically what you are looking for.
Does anyone of you friendly coders know how to change the text on the return key of the android keyboard. I am catching the return event of an EditText element to start an action. So I would like to show the user, that he can start the action with that key. Some applications do that. E.g. they replace the key with a search symbol.
I am also wondering why apps always have an additional button aside the text field. Clearly, this takes away screen space. But it may be necessary for some purpose I am not aware off. The one problem I could imagine is task switching. After switching back, the user would have to call the keyboard before he could start the action. The other is a hardware keyboard, but anyone will assume that the return key will start the action.
R.G.
There are some ways to change the behaviour of the return button on your software keyboard. If you want to have the search Icon on your keyboard you have to add android:imeOptions="actionSearch" to your EditText View. There are some other actions that you can set for an overview over the available options have a look at the documentation of the TextView.
I would guess the reason that there are buttons next to many textfields to trigger the action is because users are used to it and would be a little bit at loss if the button is missing especially users with a hardware keyboard or if the software keyboard disappeared. One additional problem is that the return key is also used to create line breaks this means that if you want to have a multi line text field you cant use the return key to start an action.
If you want, you can hide the additional button beside the text area by adding the attribute
android:imeOptions="flagNoAccessoryAction" to your TextView or add it in code using
myTextView.setImeOptions(EditorInfo.IME_MASK_ACTION & EditorInfo.IME_FLAG_NO_ACCESSORY_ACTION);.
This is generally advised against, however, because of the user not being able to see what action will be performed when, say, the return key is pressed, or not being able to perform an action at all.
More info in this blog post: http://android-developers.blogspot.dk/2009/04/updating-applications-for-on-screen.html.