Virtual Keyboard Control for Android

There is now a control accessible via common/extras/android that gives you access to a clone of the system virtual keyboard.

This will automatically display when you touch inside one of the TextField/Password elements.
It will hide when the keyboard element loses focus or the enter key is touched.

This also gives me a chance to brag about the TextField (text range selection via touch/drag/release included) works without a hitch on Android. (Ya… I’m proud of this).

Oh… gimme about 24 hours to update the repo before asking where the hell the Android updates are.

Next on the list: Virtual Joystick

that’s pretty cool!
How does it perform?

@nehon said: that's pretty cool! How does it perform?

Actually… the whole library performs awesome. I’m going through a bit of shell shock, as I was expecting this update to be a nightmare.

Minus a glitch I had in handling moving elements that were set to effect another element (i.e. parent, absolute parent, some other arbitrary element) and an issue with locating audio assets (not sure why… but it doesn’t seem to be able to find them) everything has just worked… and really well.

I’m anxious to get to building the virtual joystick. I always thought those controls were slick.

For audio the problem is that to render audio on android we use mediaplayer and sound pool. Those API need the audio files to be in the asset folder of the android project (not in the asset.jar comming from the jme project).

I think @iwgeric changed the build so that all asset are automatically copied to that folder when creating the apk. But i’m not sure.(also audio data cannot be loaded from the assetmanager, so basically audio are loaded twice, which is a shame)

What I’m sure of is that he implemented an audio renderer based on opensl, that doesn’t have this issue and can use JME audio asset as the desktop audio renderer does. It’s still experimental, but it’s available through the class parameters that you have in the MainActivity.

@nehon said: For audio the problem is that to render audio on android we use mediaplayer and sound pool. Those API need the audio files to be in the asset folder of the android project (not in the asset.jar comming from the jme project).

I think @iwgeric changed the build so that all asset are automatically copied to that folder when creating the apk. But i’m not sure.(also audio data cannot be loaded from the assetmanager, so basically audio are loaded twice, which is a shame)

What I’m sure of is that he implemented an audio renderer based on opensl, that doesn’t have this issue and can use JME audio asset as the desktop audio renderer does. It’s still experimental, but it’s available through the class parameters that you have in the MainActivity.

I was reading about this. The minimum target is being bumped to ?? to accommodate this yes? This will be a good change, as default GUI sound files are in the library package itself, which I’m not sure would be seen/copied since they are externally referenced. =( Either way, I’m completely thrilled with no audio at all for now. Though, for any projects using this library, they can just alter the style def for audio and store the audio locally to the project to take advantage of the workaround.

minimum target becomes Android 2.3 but 2.2 is now 2,4% of the market according to this.
http://developer.android.com/about/dashboards/index.html

which left us with a 97,6% of supported devices…which good enough IMO

1 Like

A first feature request on the new Keyboard control. Could you add an option to switch the keyboard layout?
That is not necessary for the usability, but it would be nice.

@Erebos3D said: A first feature request on the new Keyboard control. Could you add an option to switch the keyboard layout? That is not necessary for the usability, but it would be nice.

This should be fairly easy to do… via style def?

Hmmm… giving this a bit more consideration. Are you talking about key layout (not considering characters) or character mapping? Character Mapping (for default, shift characters and symbols) needs to be read out of some kind of config file… or something along these lines (more than likely I’ll leverage the style system for this)… anyways. Let me know if you meant physical placement and we can kick around some ideas for how to accommodate this.

The constructor code for the keyboard with become much less… erm… verbose once this is the case. =)

Well, I meant the character mapping, the visual layout would be too easy :wink:
A config file sounds good!

@t0neg0d said: The constructor code for the keyboard with become much less... erm.... verbose once this is the case. =)

+1
It looks horrible :mrgreen:

@Erebos3D said: Well, I meant the character mapping, the visual layout would be too easy :wink: A config file sounds good!

+1
It looks horrible :mrgreen:

Lol… /agreed

Really nice. This is something nifty is still missing last I looked (it has a work around that pops up an android form that then pops up the keyboard, very ugly).

@nehon said: For audio the problem is that to render audio on android we use mediaplayer and sound pool. Those API need the audio files to be in the asset folder of the android project (not in the asset.jar comming from the jme project).

I think @iwgeric changed the build so that all asset are automatically copied to that folder when creating the apk. But i’m not sure.(also audio data cannot be loaded from the assetmanager, so basically audio are loaded twice, which is a shame)

What I’m sure of is that he implemented an audio renderer based on opensl, that doesn’t have this issue and can use JME audio asset as the desktop audio renderer does. It’s still experimental, but it’s available through the class parameters that you have in the MainActivity.

As @nehon said, the build script automatically extracts assets.jar in the mobile/assets directory and then removes assets.jar. This was only so that the audio files can be seen and loaded by the current default audio renderer.

For 3.1, the new audio renderer uses the existing audio input stream created by core and uses it directly, so what’s done today won’t be necessary. It will use the audio files located in assets.jar as desktop does.

1 Like