posted this on March 21, 2013, 01:36
The input method framework on the Android platform is quite open. There are many third-party implementations, and some of them are quite popular among Android users, like SwiftKey. Due to the variety of implementations and such complicated circumstances, we try our best to support most of them and make them compatible with Splashtop.
There are additional situations that make it even harder to achieve this goal:
On international keyboards, like the CJK language, one word may be composed by tapping more than one alphabetic letter.
Some input methods need prediction to work correctly, such as Swype.
Overall, in order to overcome the above situations, we would like to implement our app more generically like a native app on the Android device; that is, how it works in the local app, and how it will work when you try to input to the remote computer. So, we implemented a simulated input box — that's the one you see beside the remote cursor. That input box accepts the output from the input method. Thus, it can overcome the above limitations.
However, the solution is not perfect. This is especially true if what you are trying to input on the remote side is a password, not like a native app. Our client app has no context of that, so it will call out the text input keyboard too. Of course, we are working on solving this. We will roll in a new feature in the future to enable the client app to know what kind of input field is on the remote side. So if it's a password input box, the client side will also use a password input keyboard. We hope this will solve some related problems.
Also, concerning text input, for those who would like to directly input to the remote side without any client side prediction/first letter capitalization, etc. — usually, there are settings inside the input method itself for the user to fine-tune. Below, we have listed several example illustrations which indicate how to configure such settings, in some of these popular input methods.