Android Bridge positioning issue

Venorcis · December 2013

Good afternoon,

I have a small problem when using the native Android bridge's TextFields. In one screen, I have such a textfield at the bottom of the screen with a (Gideros) send-button next to it. However, when one clicks on the field and thus opens up the keyboard, only the send-button moves up; the native textfield gets hidden beneath the keyboard. Why doesn't that move as well? Or if this is impossible, how can I handle the keyboard-open event myself?

Thanks in advance,
-Vincent

ar2rsawseen · December 2013

@Venorcis
cool I have not thought of possibility of this problem
Well the easy solution would be to create a scrollable view (either in Gideros or Android) and let user to scroll the textfield up

in the meantime I'll check if it can be handled automatically, or better how other apps are handling it

Venorcis · December 2013

@ar2rsawseen Yeah I would prefer handling this automatically, as the user probably won't understand where the textfield suddenly has gone to.
Again, the best solution would be to reposition the android elements in the same fashion as the native gideros elements, and a best alternative would be the option to handle a keyboard-open event or something like that.

Venorcis · December 2013

@ar2rsawseen Update: the input element DOES go to the right position after entering the first character. So somehow it does not get updated on keyboard-open.

I have another issue now though. When using an OptionsDialog, with e.g. 4 options (in of course a plain array), the device will show the first option's name 4 times. The event handling does return the correct name though (event.optionText, but this is Gideros native code). So something must go wrong in setting the items for display (build:setItems). This happens through 'String.newArray(options)', and I have no idea what that does, and it seems to fail.

Thanks in advance for the help,
-Vincent

ar2rsawseen · December 2013

Hello, about OptionsDialog having same options, yes it was the bug in creating object arrays, and I have fixed it and updated new libnative.so files in Gideros Labs

About the text input issue, unfortunately I could not find on displaying keyboard event on Android, closest I came was on text input focus changed, but it is far from what is needed, so currently I still don't have a solution for that.

And I just tried out when placing text input somewhere in the bottom of the screen, so even if I input the character it still does not jump up as you described.

That got me thinking why we get different results and I searched more and found that you can actually control the default behavior from AndroidManifest
http://developer.android.com/guide/topics/manifest/activity-element.html#wsoft
in your case setting
android:windowSoftInputMode="adjustPan" attribute on activity

if it is not provided, what system does depends on Android version and selected theme, thus us having different behaviors

Hope that helps

Venorcis · December 2013

@ar2rsawseen Yes, both solutions work perfectly, thanks a bunch!
-Vincent

Venorcis · January 2014

@ar2rsawseen After some more (better) testing, the android:windowSoftInputMode="adjustPan" does not help after all. The whole view switches upward, but the native Android element still stays beneath the keyboard. On our 'oldest baseline device', a HTC Legend (Android 8), as mentioned, the input element does move upwards after the first character is typed (causing my confusion). On other devices, this does not happen at all.
As mentioned, even without the adjustPan setting, the native Gideros elements do shift upwards (e.g. our submit button), so the problem really lies in the repositioning of the native element, which seems unrelated to that setting anyway.
I hope you can find a solution to this; thanks in advance!

ar2rsawseen · January 2014

Hmm, most probably this is due to using absolute positioning rather than relative that is usually used in Android layouts, just to match Gideros positioning.
But let me try more tests

Venorcis · January 2014

@ar2rsawseen Any progress on this issue?
-Vincent

ar2rsawseen · January 2014

Yes and no

Firstly I was wrong the right value to use for soft input was

android:windowSoftInputMode="adjustResize|stateHidden"

Only then it works in some situations, but not this one.

So firstly I do positioning using relative views, which should not be bad, but in this case the text input does not appear after first input. If I use gravity and margins instead (will have to rewrite ui lib to do that later), the text input appears correctly on top after first input. But initial it is also hidden under keyboard.

Basically it is a bug in Android, which incorrectly places the input when you are using activity in full screen (as Gideros does), thus first solution:

1) Remove fullscreen by removing

 android:theme="<a href="https://forum.gideros.rocks/profile/android" rel="nofollow">@android</a>:style/Theme.NoTitleBar.Fullscreen"

But of course if you are building a games (which most of us do), this is completely unusable solution. And this solution only works with Gravity positions, which I yet need to reimplement in UI lib.

So next solution
2) I found most of people seem to be using is to wrap all contents in ScrollView, which they say should also work in fullscreen mode. This is something I'm still working on and trying to use, but for now unsuccessfully, it did not work with all my attempts.

3) third solution I thought could be used is to input something on focus change, but setText function seems to be working differently from keyboard input, so the input only jumps to the top, when something on the keyboard was pressed.

4) thinking of some kind of api to control view offsets, but that won't help if there are no keyboard show/hide events, etc. So this won't work too.

Bottom line
I will keep experimenting with ScrollView and looking for other solutions.
But if that fails, I will rewrite lib to Gravity positioning, so at least input is shown after first input and developers would have an option to remove fullscreen to make it behave normally

So as you see, there is a progress, but no solution yet.

Venorcis · January 2014

@ar2rsawseen Thanks for the update! Annoying bug

Not using fullscreen is indeed not a viable option for us as well. However, if it works on first input on any device, at least part of the problem is solved, so that sounds good. I hope it works out with the ScrollView though

Venorcis · January 2014

@ar2rsawseen In case you did not see it, and if it is of any use:
http://stackoverflow.com/questions/12422566/android-adjust-scrollview-when-keyboard-is-up
It seems you need all (!) three of those flags in combination with a scrollview to make it work?

ar2rsawseen · January 2014

Yes but,
According to Android documentation using multiple 'state*' or 'adjust*' values has undefined results. You should use 'one state', 'one adjust' or 'one state and one adjust' values.

still worth to try

Venorcis · January 2014

@ar2rsawseen I see using only resize (instead of pan, with stateHidden) also works, but they might both work? I don't know what you've already tried

Venorcis · January 2014

@ar2rsawseen As this is related to the Android Bridge anyway: what would be the best way to allow the user to select an (avatar)image?

ar2rsawseen · January 2014

I was thinking about it more as separate plugin before, but might be easier to achieve using bridge
hmm need to think about it

ar2rsawseen · January 2014

Still no proper solution to the Android fullscreen problem, so will redesign UI library to display native widgets with gravity

And about avatar selection, the media plugin to select images from gallery or camera is coming up quite nicely

Venorcis · January 2014

@ar2rsawseen Sounds good! We need both desperately to be able to finish our app! Please keep me up to date

ar2rsawseen · January 2014

Then you can check this post

http://www.giderosmobile.com/forum/discussion/comment/32833#Comment_32833

Venorcis · January 2014

@ar2rsawseen Looks good; I will try that out today

Any ETA on the positioning issue though? :P

ar2rsawseen · January 2014

I've read about one more thing to try on the weekend, so I will try it today, and after it if it won't work as expected, will start converting to the other structure, and with retesting, it should take 2-3 days (as there are other responsibilities I need to attend too

)

Venorcis · January 2014

@ar2rsawseen Ok, thanks for the info, good luck

Venorcis · January 2014

@ar2rsawseen On a related (Android Bridge) issue; I wanted to open a DatePicker when clicking on a TextInput. This is not available in your code, so I tried adding the following code in the TextInput constructor (following the code above and online sources for the pure-Java solution):
"local touchProxy = native.createProxy("android.view.View.OnTouchListener", {onTouch = function(view,edit)
local event = Event.new("onTouch")
event.text = event:toString()
self:dispatchEvent(event)
end})
self._core:setOnTouchListener(touchProxy)"
However, this causes the app to fully crash on the first createProxy call. Do you have any hints for me? :P

ar2rsawseen · January 2014

@Venorcis, hmm, try changing this
android.view.View.OnTouchListener
to this
android.view.View$OnTouchListener

This is how they relate internally

ar2rsawseen · January 2014

@Venorcis I have rewrited the bridge and ui lib and now testing
and unfortunately, the field only jumps up after first letter, when you don't set width to it (same behavior in old version)

But on the bright side, I added one functionality that bridge was missing, and now all widgets will take up for one view lesser, making it faster to load, and there probably be easier installation, as there won't be any layout changes in activity
just let me test that tomorrow a little more

Venorcis · January 2014

@ar2rsawseen Hey, what's the latest news on the rewritten bridge? It would be nice if we could get our hands on that soon! If it at least consistently jumps up after the first letter across all devices, it's better than it was (and of course improved speed is great as well).

ar2rsawseen · January 2014

Oops, sorry, I already uploaded it to the Labs, just forgot to post to forum.
And it behaves the way you described, but only when you don't set the dimensions of the text box.
Sorry, but it seems it is nothing I can do there, android fullscreen bug

Venorcis · January 2014

@ar2rsawseen Thx! Coming back on the on-touch issued, I've now tried the following:
"local touchProxy = native.createProxy("android.view.View$OnTouchListener", {onTouch = function(v,event)
self:dispatchEvent(event)
return false
end})
self._core:setOnTouchListener(touchProxy)"
This almost works; on the touch event itself, the following exception is generated:
"01-26 15:26:07.032: E/AndroidRuntime(2209): java.lang.NullPointerException: null result when primitive expected $Proxy1.onTouch(Native Method)"
So it does not seem to properly pass the 'return false' there; any suggestions?

ar2rsawseen · January 2014

It might be possible that eventProxy works only one way

You could try instead:

local eventProxy = native.createProxy("android.view.View$OnClickListener", {onClick = function()
    self:dispatchEvent(Event.new("onClick"))
end})
self._core:setOnClickListener(eventProxy)

Venorcis · January 2014

@ar2rsawseen Thanks, that works. On the positioning of a textinput at the bottom of the screen: it was very inconsistent on different devices. On some devices, the field positioned itself nicely at all times, on others only after typing, and again on other it staid hidden all the time. For now, I solved it using
"replyinput:addEventListener("onClick",function()
local inputDialog = TextInputDialog.new("Reactie","Geef uw reactie:","","OK")
inputDialog:addEventListener(Event.COMPLETE,function(event)
self.replyinput:setText(event.text)
end)
inputDialog:show()
end)"
Which works in combination with calling setFocusable(false) on the textinput's core element. It's a pity the Android behavior is so weird and inconsistent on this.

A final question: is it possible to hide the user's keyboard programmatically in Gideros?

Venorcis · January 2014

@ar2rsawseen Oh, and next to hiding the keyboard, is there any event that allows us to respond to an Android back-button click?

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Android Bridge positioning issue

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Android Bridge positioning issue

Comments