Android Bridge rendering issus

Venorcis

Good afternoon,

First of all, just to let you know, we successfully launched our business app (to accompany our website) in the Dutch Android app store yesterday, planning an iOs release in february. See https://play.google.com/store/apps/details?id=com.chainelsbv.chainels

However, we noticed that on some older models, an annoying issue again relating to the opening/closing of the keyboard and inputfields (edittexts). Please see the images in the attached ZIP for this; for two different screens, I made a picture (and not a screenshot, because on a screenshot everything looks fine again). This is what happens:
1) screen looks fine
2) input text in a field that is on the lower half of the screen, so the view pans up (as it should, resize is not an option here), but there is visible distortion (e.g. whitespace in this case).
3) close the keyboard, so the view pans back down. The distortion (white lanes/stripes) is still visible.
4) input text in a field on the upper half of the screen. Nothing happens, and the distortion goes away afterwards (even after keyboard close).
Again, on new devices, this does not seem to happen (no distortion occurs). I even tried to call the 'invalidate' function on all inputfields every second, but that didn't help in any way, unfortunately.

Another (perhaps related) issue seems to occur after the app has crashes; we had a piece of LUA code that contained a case error, and thus caused the app to shutdown. However, on some devices, apparently the whole Android bridge becomes buggy after this (see fields_after_crash image in attached ZIP). All inputfields become black and their placeholders unreadable. This can only be fixed by forcefully shutting down the app completely (e.g. remove it from background). Perhaps a crash on the LUA level should force that as well or something?

Finally, might it be correct that the event for a push notification is not fired when the app is opened from scratch, e.g. not running in the background yet (and then selecting a notification)? It does not seem to happen at all for us in this case. I also had some rare occurrences of the whole app staying black when opening a notification, but I cannot reproduce this.

Anyway, these were the main issues we have, all with the latest version of Gideros and all plug-ins. I hope you can look into them

Kind regards,
Vincent

ar2rsawseen

Woohoo, that would actually make it the first Android Native UI app in Gideros

1) I will check about the rendering issues, probably something due to combination of OpenGL. Unfortunately I can't seem to check the app, because it shows being incompatible with my LG P500 Android 2.3, any ideas why?

Also found some answer on stack overflow that it happens with adjustPan but should work ok with adjustResize value in manifest

What value did you end up using?

2) What do you by "we had a piece of LUA code that contained a case error"?

3) Will retest that

Venorcis

@ar2rsawseen
Nice!

1) I have no idea; the developer console reports that all 4431 devices are supported (0 incompatible). adjustResize won't cut it for us; that makes the whole screen look very ugly, unfortunately

2) It does not matter that much; e.g. I called a function 'dothis()' whilst it was supposed to be 'doThis()'. The thing that matters that on any LUA error/crash, the edittexts get distorted completely, like in the screenshot.

3) Thanks; curious what you find out for all of these issues!

-Vincent

Venorcis

@ar2rsawseen Hey, any progress on these issues yet?

ar2rsawseen

Sorry, spent the weekend mostly away from PC, will start checking now

Venorcis

@ar2rsawseen Np, just wondering if there were any updates yet Good luck

Venorcis

@ar2rsawseen Any luck yet?

ar2rsawseen

I could not find much info on the rendering issue. Maybe it is the combination of the GL surface and native UI, but for example nothing like that happens on my LG P500 Android 2.3
Unfortunately I can't test it with your app, because for some reason it says it is incompatible on Google Play. (maybe you could send me the .apk to ar2rsawseen@gmail.com)

About the lua error, then yes it is in our priorities to make Lua errors crash the app, not simply close it.

And about Notifications, I'm actually making some rearrengments there to add wasOpened bool to even to indicate app was opened from notification, so I will have to retest al behaviors again after that.

Venorcis

@ar2rsawseen On the lua errors and notifications; sounds really good
On the rendering problems: you might not be able to download our app because it is Dutch-only? You would need a log-in anyway, and why would the issue be specific to our app? Just put an Android inputfield towards the button of the screen...
We did notice differences between devices, however most we tried do have the issue, unfortunately: HTC Legend (Android 2.2), HTC Desire S (Android 4.0), LG Optimus 4xHD (Android 4.4) all show the error.

Venorcis

@ar2rsawseen Hey, can you give any progress indication on this? And do you have any idea about when the Gideros core (Object.wait bug) and/or Notification plug-in will be updated (detect external and such)? Thanks

ar2rsawseen

Hello @Venorcis
Currently fixing the AdsInterface is the first on my list (which I hope to accomplish this week) and fixing Notification plugin is the next one.

About the core update, unfortunately, there will be a delay.
http://www.giderosmobile.com/forum/discussion/4459/gideros-news/p1

Venorcis

@ar2rsawseen Thanks for that update. Two questions:
- Didn't you already fix that ANR I reported, and if so, can that be released already?
- Could you still check out this OpenGL issue, perhaps if I compile a very simple example-app that has this problem for you? I've already listed the devices that have that problem to make it easier.
And fixing the Notification plug-in would be great as well, see my reaction I've just posted there please
-Vincent

ar2rsawseen

Since I seem to stuck a bit with AdsInterface I will try to put a pause on it and spend tomorrow's day on Notification plugin and experiment again with the rendering issues. If you would have any examples, that would be great
About ANR, I said we discussed internally how we can try fixing it, but we still need to experiment if that works or not

Venorcis

@ar2rsawseen Sounds good! I've made a project in which I've reproduced our circumstances with the least amount of code possible; the bug persists in it! For completeness sake, I've also attached our version of the GiderosPlayer (and it's source in the ZIP), though any GiderosPlayer build supporting the Android Bridge should work with this example.

Venorcis

@ar2rsawseen Hey, any luck on reproducing this issue with my examples?

ar2rsawseen

Yes the effect is quite interesting and it did not appear in my tests before adding a BG image to OpenGL layer.

But you can actually fix it by calling:

local layout = bridge.getLayout() layout:requestLayout()

to redraw all invaldiated layouts

I just don't know how to better incorporate it with keyboard appearing events, but most probably you can also call it periodically while user inputting text or something like that

Venorcis

@ar2rsawseen Ok, that piece of code works; I run it every 1/2 second now, and it's much better. No idea how to solve the root of this problem?

ar2rsawseen

It seems that the content has been redrawn before the resizing ended, thus it is not updated properly, not sure if Android bug or not.

But I may have a more efficient solution for this problem.

Inside GBridge.java add static variable:

private static boolean wasRequested = false;

And then inside onCreate method, where layout is retrieved add this piece of code:

layout.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() { <a href="https://forum.giderosmobile.com/profile/Override" rel="nofollow">@Override</a> public void onGlobalLayout() { if(!wasRequested) { wasRequested = true; layout.postDelayed(new Runnable(){ <a href="https://forum.giderosmobile.com/profile/Override" rel="nofollow">@Override</a> public void run() { layout.requestLayout(); } }, 500); } else { wasRequested = false; } } });

Basically what it does is, that every time the View is redrawn, it requests to redraw it again (after 500ms passed). Should be more efficient than calling with static amount of time period, because it only will be called when there are changes to the layout

Venorcis

@ar2rsawseen Thanks, just tested that and it works great!