The android keyboard can be a bit of a p.i.t.a. for developers who are trying to create a good user experience. Sometimes it won’t open when you would expect it to, and other times it will never dismiss without the user having to hit the back button (something which many android users wont realize). I’ve struggled often with the later situation.

Scouring the internet for advice turned up multiple solutions, and I’ve managed to figure some of my own as well. Here are the best solutions I have found.

Solution 1) Set the inputType to “text”

The easiest way to do this is in the xml layout declaration:

1
2
3
4
5
6

<EditText
	android:id="@+id/my_edit_text"
	android:layout_width="fill_parent"
	android:layout_height="wrap_content"
	android:hint="Tap here to type"
	android:inputType="text" />

This can also be done programmatically via. the method setInputType() (inherited from TextView). The programmatic equivalent of the xml above is setting the input type to TYPE_CLASS_TEXT and TYPE_TEXT_VARIATION_NORMAL (see below):

1
2

EditText editText = (EditText) findViewById(R.id.my_edit_text);
editText.setRawInputType(InputType.TYPE_CLASS_TEXT | InputType.TYPE_TEXT_VARIATION_NORMAL);

This method is slick and seems like the most appropriate and intended way for developers to ensure the keyboard closes when the user hits the action key. Unfortunately, sometimes a situation will arise where this won’t function as intended. When this occurs we’ll need to pull out some bigger guns.

Solution 2) Use the InputMethodManager.hideSoftInputFromWindow()

This method is mentioned frequently on the internet such as on this stackoverflow post here:

You can think of the InputMethodManager as a system service that mediates between your application and any input method you might be trying to use (in this case the keyboard).

1
2

InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
imm.hideSoftInputFromWindow(myEditText.getWindowToken(), 0);

A slight modification to this method worked for me in the past as well. Passing the InputMethodManager.HIDE_NOT_ALWAYS flag instead of 0 closed the keyboard for me when the above options had all failed.

1
2

InputMethodManager imm = (InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE);
imm.hideSoftInputFromWindow(myEditText.getWindowToken(), InputMethodManager.HIDE_NOT_ALWAYS);

If you’d like the code from this example I’ve shared a sample project demoing each of these solutions over on github: https://github.com/cephus/Android-soft-keyboard

Jalaga is short for Japanese Language Game. It’s a simple flash card game for studying Japanese kana, Hiragana and Katakana. Answer questions to gain points, gain enough points and you level up, as you level up the kana advance in difficulty as well.

I built Jalaga to be the kind of supplemental studying game/tool I would have liked to use when I first started studying Japanese. Way back in the early days of my lessons in MLJ 101 I quickly realized how necessary it was going to be to grind those flashcards in order to learn how to read the basic Japanese character set. However, grinding flashcards was such a chore, and much of my dedicated studying time would quickly devolve into “Age of Empires 2″ time (but at least I always played as the Japanese). I often wished for an enjoyable way to combine some gaming aspect into my studying.

Now 10 years later that original inspiration has lead to my first game for the Android platform. Of course, Jalaga on it’s own isn’t really a good game. It’s also not even a good replacement for your flash cards. I like to think of it as more of a supplemental distraction for a beginning Japanese student. It adds a basic game element to flash cards of gaining points or experience and subsequently levels. And hopefully some of you out there find it useful as you begin your trek into the Japanese language.

Anyways, please do download Jalaga if you are so inclined. You can either search for it on the market or scan the QR Code below with your phone to go directly to the market page. And if you do I’d also love to hear what you think. Please feel free to leave a comment here or on the market with your thoughts (and/or bug reports).

I also would be remiss if I did not give some huge props to Juan Sanchez. He gets all the credit for the incredible design and assets, without which I would’ve been too embarrassed to release this app.

Android has sensors to handle everything from acceleration to tricorder readings and all of them are managed via the SensorManager class. In order to detect changes to any sensor’s reading you need to register a SensorListener with the manager.

First, I recommend creating your SensorListener inside your activity.

1
2
3
4
5
6
7

private final SensorListener sl = new SensorListener() {
	public void onSensorChanged(int sensor, float[] values) {
	}
 
	public void onAccuracyChanged(int sensor, int accuracy) {
	}
};

Next you’ll want to find the Android SensorManager and register your SensorListener to listen for SENSOR_ORIENTATION events. It’s best to put this code in your onCreate function of your Activity.

1
2
3
4
5
6

// Locate the SensorManager using Activity.getSystemService
SensorManager sm;
sm = (SensorManager) getSystemService(SENSOR_SERVICE);
 
// Register your SensorListener
sm.registerListener(sl, SensorManager.SENSOR_ORIENTATION SensorManager.SENSOR_DELAY_NORMAL);

Now your listener will be catching orientation events from the SensorManager. As the orientation changes the onSensorChanged method of your listener will be repeatedly called. The first parameter of the method should match the SensorManager.SENSOR_ORIENTATION value, assuming you didn’t register it to listen to any other sensors. The second parameter will contain a float array of 3 values; Azimuth, Pitch, and Roll respectively.

Azimuth is used to detect your compass direction, where 0 = North, 90 = East, etc.. Pitch is used to track your devices side to side orientation, where vertical is around 0, tilted so the left side is on top is around 90, and tilted so the right side is on top is around -90. The documentation for pitch says the values range between -180 and 180, however when I tested this with my G1 device I found the values would not go beyond +/-90. As the device is tilted upside down the values would return back to 0 instead of +/- 180. This would make detecting whether the device is being held upside down or not rather difficult. I have not found a solution for this yet. The final value in the float array, roll, represents the degree to which the device is tilted back and forth.

I was only concerned with the side to side Orientation of the device, so I monitored only the pitch value like below and was able to easily track the device orientation.

1
2
3
4
5
6
7
8

float pitch = values[2];
if (pitch <= 45 && pitch >= -45) {
	// mostly vertical
} else if (pitch < -45) {
	// mostly right side up
} else if (pitch > 45) {
	// mostly left side up
}

The primary source of my previously mentioned frustration was from a class I first attempted to use called OrientationListener which extends the SensorListener class. From the name and the documentation you might think this would be the ideal class to use for listening to orientation changes, but it isn’t, at least as far as I can tell. When registered in the same manner above the class will call back on it’s onOrientationChanged funciton instead. The documentation says that values passed to this method represent the degrees of orientation of the device between 0 and 359 however in testing with my G1 I found the values to be completely useless and incorrect. Perhaps my G1 isn’t functioning properly (although the above method using the SensorListener works just fine) or more likely I’m just implementing the OrientationListener incorrectly. I don’t know because I haven’t taken a look at the source code behind it yet. Perhaps this class needs to be depricated though, regardless, I’d recommend steering clear of it until some more appropriate examples of using it surface.

While perusing through the Google Android documentation on the SensorManager class I noticed some interesting constants that had been tucked away inside the class.

Gravity constants eh? Well that's kinda neat I suppose

Right, well, I guess that’s interesting, and possibly useful for a couple of applications out there.  But then I noticed some other gravity constants hidden in there that didn’t belong to planets.  Namely, these two:

Yup.  Thanks google.  I suppose stuff like this should be expected from them, considering all the weird non-languages they support in google search as well.

Also, I’m still not quite sure what “the island” is a reference too. Perhaps lost?