MOAIKeyboardIOS .. but no MOAIKeyboardAndroid. So: when?

[ibisum]

Any idea when we might see the MOAIKeyboardIOS functionality implemented for Android - is it on the list of things to do, or are we venturing into dangerous territories by using MOAIKeyboardIOS in the first place? Actually, the existing model for how the key input functions, works pretty well .. we're using the soft keyboard with the moaigui framework to enter data into fields quite easily .. so it would be great if this happens for Android, pretty soon, as well.

If its not on the agenda for you core MOAI guys, I'd sure like to know why .. and I guess I'd have to add it myself, anyway, in that case..

[sean]

@ibisum I haven't heard of this anywhere on our [near-term] road map and I don't know the history of MOAIKeyboardIOS. Feel free to file an issue in moai-dev on GitHub and I'll ask Patrick to respond to this post with some information for you.

[patrick]

@ibisum It's on the list but we are currently swamped with feature adds around 3D and iso. If you wanted to take a stab at an Android equivalent it would be *hugely* appreciated.

My longer term goal in the soft keyboard implementation is to let users show the system keyboard but pump all input to an on-screen MOAITextBox (instead of a native text box). It's more work on the SDK side (need to expose autocomplete, spell check, cut & paste, CTL, magnify...). But those are pretty discreet features we can glue in later.

[ibisum]

Well I will attempt a first pass at MOAIKeyboardAndroid, to complete the feature-set for our targets - we need soft-keyboard for data-entry, and it works pretty well on iOS right now for our needs - just needs to be done for Android too. I believe that if I get it working (will contribute a pull request), the next step would be for you guys to decide if you want to support this in the future and then decompose MOAIKeyboardIOS and MOAIKeyboardAndroid into, of course .. MOAIKeyboard. My personal view is that integration with the soft-keyboard is a need, not just a want.

[ibisum]

Okay, I've completed a first pass of this and have added MOAIAndroidKeyboard.cpp to the project. I'm getting keyboard events, and the host seems to be working - keycodes are received.

However, one thing that still needs to be done is the NSRange / TextWatcher handling. On the iOS side of things, MOAIKeyboardiOS uses a 'fake' text field to handle the inputs - with the advantage that the NSRange events (onKeychanged:, etc.) are called, meaning that the MOAI keyboard code can expect a properly edited text string on the input side of things - the NSRange returns pos-in-buffer, length-of-buffer, and last-char-changed fields, whereas MOAIAndroid just deals directly with the keycode.

But, Android has the TextWatcher interface, which is essentially the same thing as the NSRange object - it returns 100% compatible values, pos-in-buffer, length-of-buffer, and last-char-changed fields.

However, I'm struggling with adding a fake EditText view to the Android host to be able to wire this up properly, and I could use some help - has anyone done this before? Essentially, I think that I have to modify the Android host project so that it gets its layout from XML instead of dynamically building and attaching the EGL View - so that I can put an EditText view and the EGL View side by side, hide the text view, but still receive keyboard events from it when the user pops up the Android keyboard. Does that sound sane?

If so, maybe someone has some experience with doing this already?

[stephensullivan]

I've been playing around with an android keyboard as well and am having trouble getting soft key presses. Do you have this code on a git branch? From what I can tell the handler has to be set properly but can't figure out how to do this.

[ibisum]

I have completed this work, and have a fully integrated/implemented MOAIKeyboardAndroid class to add to the project. I'm having a little difficulty catching up with the patch/pull-request though, due to rapid changes in the MOAI 1.2 SDK (notably, changes in the locking scheme), so it will take me a few days - maybe this week - to get this ready to go.

If you can't wait and want to implement it yourself, I'd be happy to help - but it is my intention to get my contribution into the main MOAI source repo as soon as possible.

[stephensullivan]

Actually, All my android development is blocked on getting a working keyboard. I have not updated to 1.2 so your version should work for me. It would be a lifesaver to get it soon. Is there are way you can send it be email? I will give some feedback to get the bugs out with the 1.2 upgrade as well.

Thanks
Stephen

[ibisum]

Lets meet in IRC and I can pass the work over to you that way - I'm torpor, #moai on irc.freenode.net .. and I'll be lurking all day.

[stephensullivan]

Awesome! I am stephenmsullivan. Saw you online earlier. Guessing there is a time zone difference

[adam]

Feel free to email me the current code if you are having trouble integrating it with 1.2.

[ibisum]

Adam: I have done the work of merging my work with the current MOAI 1.2 release, you can see it here:

https://github.com/seclorum/moai-dev/

This is working - but only if your Android package is named "at/allaboutapps/test/moaikeyboard" ..

So what I need to do (before I submit a pull request to merge with mainline moai-dev) is replace the code on line #38 here (as well as everywhere else the classpath is hardcoded):

https://github.com/seclorum/moai-dev/bl ... ndroid.cpp

.. with some sort of generic way of getting the package class path, so that instead of having a hard-coded:

Code: Select all

1.  


2.     jclass moai = env->FindClass ( "at/allaboutapps/test/moaikeyboard/MoaiActivity" );


3.  

.. I replace that "at/allaboutapps/test/moaikeyboard" bit with the "get current class path for the outer activity that is using this JNI call" code.

Trouble is, I am currently not sure how to do that. Anyone got any ideas? This is the last thing I need to do (plus a few comment cleanups, plus add a sample to the archive) before I do the pull request. I know a few of you are waiting for this, so if anyone has any ideas - please let me know and I'll give it a lot of attention to get this pull request made.

(In the meantime, if anyone desperately needs Android keyboard support - simply clone my repo, and change those hard-coded paths to whatever your package name is, and you should find that it works quite well..)

CAVEAT: Keyboard type switching is currently not implemented (i.e. changing to a numpad keyboard, or numeric, or ascii, etc.) This is something in the TODO.

EDIT: One more thing that needs to be done - make the same changes to make-host.bat that I made to make-host.sh in order to properly handle packagename replacement when creating a new Android host folder. I don't have a Windows machine, so I can't test this - so if someone else wants to do that work it would be very much appreciated, and please do a pull request so I can merge it before submitting it to mainline moai-dev ..

EDIT+1: I just wanted to describe this work to newcomers. The purpose of this code is to have a working MOAIKeyboardAndroid object within MOAI - equivalent to the existing MOAIKeyboardIOS object. The way the MOAIKeyboardIOS object works is that NSTextFieldDelegate is used to 'hook' into the keyboard input and provide the host client with a means of trapping keyboard events - so that live entry can occur in the MOAI host, each letter pressed results in a notification, etc.

On Android, I have implemented it in a similar way - albeit with the added complication of having JNI->Dalvik->LUA-VM paths to deal with. The Android host sources were modified to include an extension to LinearLayout, called LinearLayoutIMETrap, and the main layout now has a hidden EditText view - the main MOAI GL View still exists, and still takes over the whole screen, except that there is now another layout hidden off-screen which includes a real EditText. The advantage to this - in frameworks like moaigui, the keyboard/input/field updates inherit the behaviour of the native EditText view.

When MOAIKeyboardAndroid.showKeyboard() is called, the Android host pops up the soft keyboard, and input focus is set on the hidden EditText. All keypresses are trapped through the LinearLayoutIMETrap, so that we can catch BACK button presses (necessary!), and then dispatched through the NDK, into the Lua VM, for handling by whatever keypress handler has been assigned in the Lua side of things. PHEW!

It actually works very well, and is what we ended up using for Android keyboard support in some of our apps. The only thing is, I can't comfortably submit a pull request for inclusion in mainline moai-dev until I solve the classpath issue described above, so if anyone has any ideas .. please let me know. I'd be happy to move on from all this and to see this code included in moai-dev mainline, if its qualified ..

ALSO: I would like to add an example to the moaigui layouts that shows how to use this properly on both iOS and Android. One thing that is interesting is that the callbacks can be set up in moaigui (not sure about hanappe) so that when the keyboard is popped up, the screen offset can be adjusted so that the currently edited text field can always be visible .. this results in a very nice looking GUI-style app, but may not be clear to newcomers .. so I will add a sample as soon as I get the rest of the code submitted for inclusion in mainline moai-dev ..

Comments welcome!

[stephensullivan]

Thanks for this. I am sure someone from zipline will chime in, but for the hardcoded class path thing you should look at setting up the code in a way similar to MoaiFacebook.java and the like. That way the path can be something like com.ziplinegames.moai.moaikeyboard.

With the changes below, i've got things working reasonably well.

1.
You should look into updating the notifykeyevent signature to something that accepts a call like
Moai.NotifyKeyEvent(MoaiActivity.getKeyCode());
This way you can save yourself a round trip callback to java and avoid some serious threading issues I ran into. Threading is a big issue in general here. I still haven't figure out a good way to let you hold the delete button down without freezing my samsung phone

2. Show keyboard should take the input from the LUA call and use it to initialize the text field correctly.

3. in moai activity onKeyUp you have a call to onKeyDown which I believe should be
return super.onKeyUp ( keyCode, event );

[adam]

Yes, the MOAIFacebook class is a good one to look at for what you're trying to do.

Also, for the shell script, don't worry about it, since the batch file just calls the shell script in cygwin.

[ibisum]

I will work on just getting the classpath set dynamically from the project. There is a way to do this, I just haven't gotten it done yet. The reason not to set up a whole independent class just for MOAIKeyboard is because keyboard services should be implemented on the Main Activity anyway.

stephensullivan: did you find that there is a bug with threading in this implementation? Because there was an issue with threading in the implementation done on moai-dev-1.0, but this was resolved with careful locking - and since the handling of skuLock changed recently, its possible that something slipped through. I was pretty careful in the earlier implementation to avoid doing GUI updates outside the context of the main activity, and it works pretty well -but if you've run into a threading issue with this implementation (done quickly), then I'll double-check the context of things and make sure I didn't miss-step with locking.

I'll have a look, also, at you other points .. but I can't spend too much more time on this, so if you want to submit a pull request with your fixes, it'd be welcome. I rushed this out so you would have something to work with (your pleas for help were not un-noticed!) so if you want to refine it better, please be my guest .. we can get things cleaned up sufficiently well between us, perhaps, to get a pull request for submission to moai-dev/master this week. I believe this should make it into moai mainline, personally.

adam: I haven't even looked at the .bat file, so thats good news.

[adam]

There are still threading issues with the current model, I was going to be fixing them after we merge this request in. Its that the locks are blocking the Main thread, which is can cause the application to think it has stalled.

The reason we have separate classes for several of the things that are traditionally in the Activity is to keep it from becoming cluttered as well as to manage the namespace for jni calls. I haven't looked into keyboard services much, so it may be appropriate here, but just thought I'd let you know that.

[ibisum]

Got it Adam .. I don't have time to look at the class separation issue much for the next few days (got other code I should be writing) so how do you want to manage the merge? I think you mean that there is additional work required in the Android host vis-a-vis locking, no? So, just let me know what you want to do and at what point you'd consider my pull request appropriate ..

Of course if someone (stephensullivan?) can do the class name cleanup in preparation for merge to moai-dev/master, that'd be nice too. I just can't do it myself, soon.

[adam]

Well, you can look at it this way, if you submit it now, I will wait a few days before pulling it in, when I have time to clean up any issues. The more issues there are, the more runway I need.

I can take care of the threading issues, it might be best for me to anyways, since it requires re factoring some of the other Android classes. If you guy can get the class name cleanup, that would be nice. If its going to be a long time before you can get to it, feel free to submit it as is.

[ibisum]

I honestly can't work on it any more (boss is looking over my shoulder sort of thing), so if stephensullivan will do the class refactoring, it'd be really helpful. stephensullivan, what say you? Make the mod to my branch, then we submit the pull request from there?

[stephensullivan]

Ok. I got the class broken out. Still doing a little too much in the main activity but I that can be fixed. I am not that familiar with git so it would be nice to get some tips on the pull request since my company playnomi has its own fork.

Stephen