If you think that something doesn't work in Aware IM post your message here
#49506 by idpSteve
Thu Nov 29, 2018 6:28 am
Hello.

There is a serious bug with Aware 8.1 and 8.2 and android phones. I have not tested with 8.0. This is an AwareIM issue - I've tested on AwareIM v7.1 and all works well. Something breaks when moving from 7.1 to 8.x

A bit of background..

Apps are built in phonegap. Phonegap.zip generated by AwareIM has a config.xml file. By default there is a preference in this config file that sets "fullscreen" to "true". The first issue is this. The keyboard on a phone screen covers a portion of the app. If your input fields are near the bottom of your phone screen they are covered and you cannot see what you are typing. This issue is resolved by setting "fullscreen" to "false". This causes the app to move above the keyboard, we've set "fullscreen" to "false" since our first app.

We've done this in mobile apps since starting mobile app development.

Recently (v8.x) this has bugged out badly on android phones. When typing into a text field (for some reason ONLY text fields cause this issue) the keyboard slides up from the bottom of the screen as expected, but the app is shifted up double the height of the keyboard. This is bad. To make this even worse when the keyboard is dismissed the extra space that was made above the keyboard doesn't go away. The app remains pushed half way off the screen.

I've attempted everything I can find, from changing android softinputmode to looking for other keyboard plugins. I can't find any solution to this.

I'm not sure if anyone else on the forum has mobile apps, if you do and are on V8.x you probably have this issue, even if you built your app when using v7.1.

See attached images. The app is completely unusable after tapping on a text field.
Attachments
after keyboard.jpeg
after keyboard.jpeg (27.08 KiB) Viewed 1947 times
with keyboard.jpeg
with keyboard.jpeg (43.68 KiB) Viewed 1947 times
before keyboard.jpeg
before keyboard.jpeg (44.83 KiB) Viewed 1947 times
#49510 by idpSteve
Thu Nov 29, 2018 1:53 pm
Found out that this is also an issue in Chrome.

Vlad suggested that I specify form height. This works at 200px (no scrolling to show keyboard required) but it won't work for my purpose.

Still investigating, and looking for help.
#49515 by aware_support
Fri Nov 30, 2018 12:35 am
This is a well-known bug in Chrome (in their scrollToView function) where it "jumps" the screen to bring an element into view. The workaround in this case is to make sure that all form controls are visible on a single screen, so that users don't have to scroll to access input controls. If forms are long split them in two or more.
#52108 by Jaymer
Sun Nov 17, 2019 10:21 pm
As of Nov 2019, v8.3, I DO NOT see this negative behavior on Android APK.
Using fullscreen=false, the screen scrolls up properly when editing a text field.
After closing the popup-keyboard, it may/may not scroll back down - several screens I have tried aren't that tall, or they have grids at the bottom.

One POPUP FORM that had a field on it had the keyboard display over the popup form, and not until I started typing did it scroll up to show my typing. But that was a popup, and the regular forms acted a bit different.

So, not having done exhaustive testing, it seems behavior has improved this this post.
#52114 by idpSteve
Mon Nov 18, 2019 4:44 am
Hi Jaymer.

I did find and pass on a solution to this to Vlad, and it was fixed.

From what I recall the resolution was removing class "k-splitter" from div "aw_main_splitter" for me. Not sure if the Aware team changed what was in class k-splitter, or if they just removed it too.
#52115 by Jaymer
Mon Nov 18, 2019 5:39 am
I would never have known about the "fullscreen=false" option if not for this thread.
I was doing a search on "phonegap" earlier to see how much was out on the forum about this topic... and not much Phonegap stuff since original posts about it in 2016/2017. Def. under 10 users here who have messed with it (according to posted questions).

(which is why it makes no friggin difference which section a post is put in - we have so little volume that a pro user is gonna read all threads regardless of where they are - AND the search is going to find them anywhere also)

I wonder how the hell you ever debugged that to find out about a specific CSS section? Since there's no INSPECT, and no way to reproduce that behavior on desktop??? what gives?

Who is online

Users browsing this forum: Google [Bot] and 5 guests