This can happen if the user does not have an up to date version of
the DirectX SDK, as Microsoft intentionally broke it and requires
users to install the W8 SDK.
If we don't do this, then when the game starts we'll send out the
buffer size to clients being a super large value of junk, and they'll
hang forever trying to accumulate an input buffer a size that they'll
never ever reach in a million years.
This never manifested in release builds for some reason.
Made some class variables final, since they should convey that they cannot be changed after the first assignment.
Made the formatting consistent between files.
In some cases, it would fail to inflate correctly in the sense that it would only show the binding status and not the name of the actual control that was being binded.
Also, join a variable's declaration and assignment in the onMotionEvent() function.
If no explicit accessibility term (private, protected, public, etc) is given, then the permission level is set to something called 'package-private' which means it is set to the scope of the whole package. So technically any class could have access to this method and variable, which is likely not what we want.
This prevents inheritance of the classes (will throw a compiler error if you try and extend any of the classes).
This is mainly syntactical sugar and form. Nothing major.
This is what it now looks like: http://i.imgur.com/KOZgA1i.png
As usual, if any bugs arise from this rather large change. Please report it so I can fix it.
- Join variable declaration and assignments in function onTouchEvent()
- Change a for-loop into a foreach loop in dispatchGenericMotionEvent(). Makes the loop body a single statement.
[streamtype].flush() is called when [streamtype].close() is called.
No need to null the references either after calling close(), the garbage collection will take care of it.
Added an example translation (Japanese). So now the Android version can both display in English and Japanese, depending on what the Android device's system language is set to.
Also did a tiny clean-up of InputConfigItem.java so that the parameters are slightly more descriptive.
Now, to do a translation in [x] language, all you have to do is take the normal English strings.xml and translate the XML entries into said language, and simply make a folder in the /res/ sub-directory in the form of values-[region code]. IE) With the Japanese translation, it is in the folder /res/values-ja
No configuration other than that is needed. After doing the above, the language should load fine on any device when set to that specific system language.
By default, if a translation file does not exist for a given system language. The app will automatically fall back to using the English translation.
This *should* be bug-free since I did check everything multiple times. But if any issues occur, please report them so that I can fix them.
Jasper St. Pierre
