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.
Related
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.
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'm designing my first Android IME and am a bit overwhelmed. My goals are accessibility-related, and as such I wonder if perhaps I'm trying things with the IME framework that just aren't possible. I've taken the default softkeyboard example and have it working along with some of my modifications, so I've definitely understood at least some of this, but there isn't a whole lot of documentation on some of the things I'm attempting. Here's what I mean:
Currently, Android phones with touchscreen-only keyboards are inaccessible. I currently have an accessible touchscreen keyboard using methods similar to those used in IOS/VoiceOver, so that part of the project is done and fairly straight-forward to accomplish in the IME framework.
Currently, Android's accessibility API doesn't provide accessible feedback for navigating text fields. That is, with an Android screen reader loaded, if you type the word "this", you'll hear individual characters spoken as you type them, but if you then try left-arrowing over the "s", that isn't spoken. So I want to trap movements and provide spoken feedback for the elements navigated past. Here's where I start encountering problems.
I currently have speech feedback for left and right arrowing, using getCurrentInputConnection.getTextBeforeCursor(1, 0) for arrowing left, and a similar call for arrowing right. This gets the character currently under the cursor after the movement is processed, and all is good.
My challenge, though, comes when arrowing up and down between lines. Ideally, I'd like to grab the current line of text and speak that, but I don't see any way to do that. The only thing I can think of is some combination of getTextBefore/AfterCursor(Integer.MAX_VALUE, 0) and combining those values, determining the current line by filtering for the previous and next \n. Is there another way--getting the entire text content of the field as a single block of text and using the cursor position to determine which piece of that text represents the current line? I'm seeing something about extracted text in the various input method classes, and it seems like there may be a way to monitor that, but I don't know if that is at all useful to me (I.e. would that return the entire field content?)
My next goal is providing standard text navigation capabilities. Android accessibility doesn't currently include touchscreen exploration, so it is impossible to otherwise scroll a large block of text. I don't necessarily expect folks to write novels on their phones, but I'd like to provide quick gestures or commands to move up/down paragraphs, and to the top/bottom of longer fields. Does the IMF provide methods for cursor movement, or is that outside of its authority?
Honestly, I didn't get the first part :(
For your second question, you will need to handle it by hand.
For instance, to add a key with a down drawable and make it work you will need to:
In the onKey method check for the code.
If it's 20, you should do a sendDownUpKeyEvents of that key event.
What I'd like to do is change the state (really, the background) of an EditText to reflect validity of its contents. E.g. if the user enters 999 where 999 is contextually invalid, the EditText should have a red border in place of the default orange border, likewise once the text is valid it should have a green border.
Methods I've explored:
Changing the style of the EditText programmatically via something like editor.setStyle(R.styles.SomeID). Seems to be impossible within android.
Adding custom states (state_valid, state_invalid) in R.attr, associating them with red/ green 9-patches, then calling drawable.setState() with one of these states. This worked in the sense that the state could be read back via getState(), but the border did not change colour.
Setting the background resource directly upon detection of (in)validity. This works ok, causing the correct visual effect, but seems a little hokey, and allows only one state (e.g. I have to manually check for whether the EditText is pressed, enabled etc).
Given limited UI real-estate I am hesitant to introduce a separate UI element to visually feedback the text's validity to the user, hence my desire to display it in the EditText itself.
So.. is this something that's even feasible? It seems like a fairly common use case, so has anyone achieved what I'm trying to do in a straightforward and elegant manner?
I would recommend changing the text color to indicate validity, rather than changing the color of the focus ring by any of the techniques you describe (of which only #3 seems practical).
Another possibility is to try setCompoundDrawablesWithIntrinsicBounds() to modify an icon on the left or right side of the EditText contents to indicate validity. I remember discussing this technique with somebody a few months back and forget if they got it working or not.
And, of course, another option is to not allow invalid input, via a custom input filter or listener or something.
Well, I'd just extend the EditText class and build the desired functionality on top ( using the third approach you are suggesting, because it works :-) ). Doing this, you have to walk the way only once, and are open to change your implementation once you know the best way ( I would have personally solved it also using the third approach, seems fine to me ).
i think a call to invalidateDrawable(yourDrawable) would work with approach number 2.
i didn't try .. but it make sense