I own an Asus Transformer (first model) with the US keyboard dock.
However, I'm French, and thus have to interact in French pretty regularly, which does include writing accented letters.
As far as I know, the current workaround for doing that is to basically popup the software keyboard, not very convenient.
One implementation of being able to write accented (and other special letters such as ß) with a traditional QWERTY layout is the one used in Mac OS X. For those who don't know, this is accomplished by pressing alt + a-key-which-usually-makes-a-lot-of-sense (I'm not kidding, they really make sense), that will give you the accent, then the letter which you want to be accented (so alt + e, then e will give you é).
That's the behavior I'd like to implement. However, I don't really find where I'd have to do that.
I looked at the documentation about keyboard devices ( http://source.android.com/tech/input/keyboard-devices.html ) but I don't think that's the right place to do any changes as I don't want to change any keymap or keycodes.
On the other hand, I took a glance at https://github.com/android/platform_frameworks_base/tree/master/core/java/android/inputmethodservice (keyboard.java and keyboardview.java in particular) but I have the impression this is more related to software keyboard.
Does anybody have more clues about this ?
Thanks
I had similar problems with entering Russian characters on TF101. I'm more used to phonetic layout than to standard one.
I was able to modify Android example application SoftKeyboard to accomplish that. You can find code at https://protronika.dyndns.org/websvn/listing.php?repname=FLEXKBD&path=%2F&sc=0 .
Sorry, code is very raw with many things hardcoded. I started that project very recently. So it is in "just works" state.
Related
Similar to this iOS-question ( VoiceOver announces dimmed instead of disabled for buttons ) I have the same problem, but for Android devices with Talkback.
Why is Talkback announcing some elements like buttons or checkboxes as "dimmed" instead of "disabled"?
Should I somehow change this, or leave it as Talkback reads it? If I should change it to "disabled / dimmed" so that it's consistent over the whole app, how?
[EDIT]:
Example:
It seems that not only buttons use "dimmed", but check / tick boxes as well.
Also only the english language seems to use "dimmed", in german it's still read as "deaktiviert" (disabled).
Don't change it. TalkBack is responding to properties in ways that users would be accustomed to. Sometimes the default behavior is the most accessible because it is expected, even when it isn't quite ideal.
If you would like an answer to the "why" I would need more information on the particular examples that your talking about. Are there apps that exhibit this behavior? TalkBack updated not too long ago, but I generally hear the "disabled" announcement over the "dimmed" announcement from TalkBack from the "obvious" times that such an announcement would apply. I certainly wouldn't expect there to be a general distinction between the two.
Also, I'm looking through the current version of TalkBack (again TalkBack has been updated recently, so the open source version may not be up to date and available) and can't find the localized string "dimmed" anywhere. There are references to "screen dimmed" but this is certainly different from what you're talking about. Which suggests to me that the "dimmed" announcement is coming from changes in the code that I would recommend be UNDONE, so as to allow the "disabled" announcement that TalkBack users would be accustomed to. This sounds to me like something someone coming from an iOS background wanted to duplicate. The behavior in iOS is to announce disabled things as "dimmed". Duplicating this on Android would absolutely be innapropriate. Let TalkBack do its thing!
Providing code examples would be helpful for me to be more sure about all of these things, your question is quite ambiguous. What types of controls? A Button for example may behave different from a Tab in a TabWidget, and this may be intentional. The way your question is worded, any more specific answers than I have given would be speculative.
EDIT:
The different parts of this announcement:
Every Sunday (0): The text of the control
Tick Box: The calculated role of the control. In stock Android this will announce as "CheckBox" (I'm testing on 7.0, with the current GitHub TalkBack). Samsung would be best off to leave this as "Check Box" from stock Android OS, I don't know why they felt the need to change "Check Box" to "Tick Box" just to be different. Doing things just to be different is annoying, there is no objective difference between "Check Box" and "Tick Box" (licensing???).
Not Selected: The current calculated state of the control. In Stock Android this would read out as "Not Checked". Unless the app is overriding this, Samsung would seem to be mucking with this as well. They should stop doing so, but again, out of your control and best left alone. Samsung users will be used to this. Though ultimately I find "Not Selected" to be a little ambiguous in terms of a CheckBox control. "Not Ticked" I think would be better.
Dimmed: Again, another thing that, unless your code is overriding (which I don't think it can in this case for this bit of calculated state). This is the calculated enable/disabled state of the control. In stock Android this would read out as "disabled". Again, leave this alone. Samsung would ALSO be best to leave this alone.
It would definitely appear that Samsung is doing strange things to the Accessibility read outs of calculated components. I'm not sure what version of Android this Samsung flavor is built off of, but I don't believe those read outs have changed. I know CheckBox and Disabled have been the same since 4.2 - 7.0 (probably Android O as well.). These minor changes fracture the Android Accessibility Ecosystem. For these particular elements, Samsung would definitely be best off just to leave them alone. HOWEVER, given that Samsung has made these changes, you are best off NOT fixing this fragmentation. Let Samsung users and Nexus users and Motorola users experience things in the way they are used to and get accustomed to their devices. Allow default behaviors unless overriding them is absolutely necessary. Hearing "disabled" when your expecting "dimmed" is confusing, not to mention a maintenance nightmare should Samsung decide NOT to override this any more or vice versa. When the OS is "calculating" state and doing so reasonably... let it happen!
I'm trying to make an a soft keyboard which an EditText presents have a layout of a phone keyboard but also with a "." and "#" signs.
What I tried was this on the edit text:
android:inputType="textEmailAddress|phone"
android:digits="0123456789.#"
I'm seeing the keyboard like I want as a phone layout in general and with the "." symbol but without the "#" symbol.. how can I add it to the keyboard?
I'm trying to make an a soft keyboard which an EditText presents have a layout of a phone keyboard but also with a "." and "#" signs.
There is nothing in the specifications that supports this.
android:inputType="textEmailAddress|phone"
Quoting the documentation for android:inputType: "Generally you can select a single value, though some can be combined together as indicated." The docs do not suggest that textEmailAddress can be combined with phone.
android:digits="0123456789.#"
This stipulates what characters are allowed. I am not aware that an InputMethod even finds out about this attribute; one certainly does not have to somehow magically adjust its keyboard layout to accommodate it.
how can I add it to the keyboard?
You don't, except perhaps by writing your own InputMethod, then forcing people at gunpoint to use it.
Please understand that there are over 8,000 Android device models. Dozens, if not hundreds, of input methods will be shipped on these devices, and others can be installed by users separately. These are written by independent developers. There is no requirement for any of them to even have keys, as evidenced by Graffiti Pro. And they certainly do not have to handle some arbitrary set of keys that an app developer wants.
android:inputType gives you a chance to supply a hint to the input method for how it should optimize the layout for the user. android:inputType specifically limits things to a few classes to keep things sane for the developers of the input methods. Furthermore, android:inputType is a hint, not a demand; as Graffiti Pro illustrates, not all input methods will necessarily change based upon android:inputType, at least for all possible types.
I'm developing a keyboard (IME) for Android. I want it to be useful for people from every country. So, I need to know which symbols should be placed on keyboard based on current locale.
My first idea is to copy computer keyboard layouts. Where can I get the contents of preferred computer keyboard layout for each locale?
Also, I've noticed that phone keyboards usually contains some special symbols which aren't present on computer keyboard. Which symbols are important for phones and why? For example, all keyboards I've met provide a way to type '¿' symbol. But this symbol doesn't make any sense in my locale (russian) and isn't used in english. Is there a reason for placing this symbol on every keyboard?
I have a login screen on my app which accepts a CPF as login (CPF is an unique number identification that every Brazilian citizen have, e.g: 10546819546), but it can also accept passport numbers as the login, and these may have letters on it.
My problem is that I want the keyboard, when it pops up, to show to number/symbols "view" before the default alphabet one. Changing the inputMethod to phone or number does not solve my problem, because as I said, the login may contain letters.
I've seen some explanations to questions somewhat similar to mine but all of them either didn't solve my problem or it was too overcomplicated.
This is merely a small adjust to slightly improve user experience and entertain me developing the app, so if the solution is something like "override the default keyboard, make a custom component" etc, I'll just leave it alone.
TL;DR: I want to show the number/symbol soft keyboard before the letters one.
Unfortunately when it comes to the soft keyboard you are somewhat at the mercy of whoever made the one the user has their device set to. Lots of devices come pre-loaded and defaulted to the swype keyboard. But many others have soft keyboards that were made by the manufacturer of that device. It it up to whoever created it to decide how the keyboard reacts to the android:inputType that you pass to it. It is possible that some of the ones out there right now actual have the behavior you are looking for when you set them to number or phone. I just checked it out on my sidekick and found that it was the same as yours both number and phone provided no way to input letters.
I just took a look on different devices and their soft keyboards. They are all looking a bit different. I attach two screenshots. One is from my HTC Desire (Android 2.2), another one from Emulator (Android 2.3).
As you can see on the device the enter key is on device just a symbol, on emulator it is "send".
Can I change it somehow?
I had this problem a year ago, my problem was that the numeric keypad is very different from each provider (not only on style but on the buttons that are shown)
In my personal experience is a pain to try to change that, you would need to create your own SoftKeyboard class with your own images.
If it's not an important issue I recommend to just pass over it, or find a keyboard type that satisfies your needs.
However, I don't know if in the newest versions of Android you get an easier way to customize keyboards.
Good luck on there :)