Change of orientation performance issue - codenameone - codenameone

when orientation changes in android, native android call the destroy method and total new layout is to be made as far as I know. But I think codenameone doesn't do that which is a great thing. But when I checked the cn1 app in devices while changing from portrait to landscape a blank screen is seen for a while and then the orientation changes.
My Problem is that when I have many more components displayed in a form,
the blank screen appears for a longer duration and sometime it hangs. Does it
happen as I don't use Orientation listener methods etc or is there anything I
can do to solve this issue?

I just tried this on my device and it worked fine for the latest build on my Android 6 device. There was the rotation animation from Android where the screen rotated into its new place.
I'm guessing the rendering of your screen is so slow that Android takes too long to draw it and ends up drawing a black screen instead so it can proceed with the animation.
I can't benchmark an application remotely but I suggest going over the performance of your app and making sure it is truly optimized.

Related

Wrong photos orientation in Codename One

I need a clarification. Today I bought a new Android 10 Samsung device to test apps... and all captured images are shown rotated wrongly inside the Labels. The code is very minimal: takes a photo and then shows it in a Label. It works fine on my iPhone and my old Android device, but in this new Android device the image orientation is not detected correctly by Codename One.
Is it a bug of Codename One or is it something that needs coding in the app?
In the latter case, can you give us a code to take photos in the correct orientation? Thank you.
I think there might already be an issue on that, if not there should be. The gist of it is this... Some modern phones always take the photos in the same orientation and just mark the photo as rotated to X degrees in its tags.
This works usually since most apps know to show the photo rotated. Currently we have a workaround for that in the gallery API but that's a bad workaround. A good workaround would be to check that flag every time we load an image and rotate it dynamically. It would be inefficient but it would solve that problem once and for all.

Styling Spinner3D select row view borders

I have an app that renders CN1 LightWeight picker properly on low-res devices, namely some low-end Android devices but getting weird behavior on iPhone 7 plus upward, even on the simulated version.
I have tried styling the Spinner3DRow in GUI Builder but this doesn't fix the issue.
When the Spinner is pressed to spin, the text and the middle borders disappear and re-appear after releasing (sometimes). See the image below for reference:
December and lines are missing.
The app is also newly published in store and could be downloaded on the iPhone 7 plus upward for reference here.
How do I style these lines and the text to always remain visible regardless of the device resolution and keep the behavior consistent?
Edit:
On testing again, the issue is occurring even on low-res devices.

Inability to correctly scale canvas on iOS for an AirConsole controller created in Construct 2

I have been playing around with creating AirConsole controllers using Construct 2. Construct 2 comes with several scaling modes to ensure that the canvas scales as desired. I have tested every possible combination, and found that the simulator (running in Safari, Edge, Chrome, and Firefox) works correctly, the Nexus 5 works correctly, but the iPhone 7 Plus and iPad (running the iPhone AirConsole app) both do not obey the scaling I have set in Construct 2.
At 1280x720, this means a portion of the controller is always offscreen. I have used both the "AirConsole" and "AirConsoleController" plugins on the screen side, and both have the same issue. When I remove both plugins from my Construct 2 project and load the page using airconsole.com/#[SERVER_URL]/pong, the scaling problem goes away, but I lose the ability to call AirConsole API methods (set orientation to landscape, handshake, messaging, etc.).
I fully understand that this probably not high on the priority list, as the AirConsole team has done a great job putting together the controller generator, but would it be possible to take a look into this problem on iOS devices? Is there something happening on the AirConsole side that would overwrite the Construct 2 screen scaling rules for iOS controllers?
One of our team's goals is to create a controller minigame that a user would play on their device while the main game was in progress on screen.html. It would much simpler to do this in Construct 2, rather than coding it by hand.
Edit:
I reran a quick test of the Pong example using the Phaser.io tank screen as a controller, instead of the pong buttons. In this test, I would expect to see the tank screen loading onto the controller. This is what I see on the simulator and on my Nexus 5. On my iPhone, half of the tank screen is off of the edge of the phone.
Since a similar behavior occurs in both the Construct 2 and Phaser.io projects, I have a hunch that the problem might occur whenever a canvas element is placed on iOS screens for AirConsole controllers.
There seems to be a bug on iOS with iframes.
Applying this CSS to the controller.html fixed it for some developers:
html, body {
height: 100%;
overflow: hidden;
}

Fire event on Opera Mobile browser for orientation change

How can I fire an event when orientation is changed on a mobile device.
onresize works fine on iPod Touch but not on mobile device using Opera mobile as browser.
Any help on how to fire event on Opera mobile.
Thanks,
Abhishek Jain
I've racked the web trying to find a good solution to this, I was in the same boat. There dosn't seem to be any really fantastic solutions out there, but what I use is this. Like I said not the best option, but mobile and mini Opera don't seem to fire anything catchable when the screen is resized. Since I'm looking at mobile devices I set the viewport to which ever (width/height) is smallest. When the user turns their device it will at least be kind of intuative.
Edit: I actually did this and coupled it together with a update width&height routine on my div's, based on screen.width/height, and it turned out pretty good.

How do you detect tablet PC screen rotation in a full screen Silverlight application?

I am working on a Silverlight 4 out of browser (OOB) application on a Windows 7 tablet PC. The majority of the time, the program is in full screen mode. However, if the user rotates the tablet, the application rotates and stays full screen, but is scaled for the previous screen orientation. Taking the application out of full screen and putting it back into full screen rescales everything correctly. Is there any way I can detect when the screen rotates? So far I've tried the app's Resize, LayoutChanged and FullScreenChanged events and have a handler for the main page's SizeChanged event. None of these get fired when the application is rotated in full screen mode.
Per Josh Einstein's suggestion, I tried polling the ActualWidth/Height of the application on a timer. It looks like after the rotation, the ActualWidth/Height values returned from the Silverlight plug-in are the pre-rotated values. Only taking it out of full screen and putting it back in full screen will change the resolution of the plug-in. The HtmlPage.Eval hack didn't work since I am OOB.
The WP7 version of Silverlight has the OnOrientationChanged event, which doesn't seem to be available in the desktop version. Anyone have any ideas?
Great question but as far as I can tell, it doesn't seem to be possible. I tried changing the screen resolution in a virtual machine (orientation change is really just a screen resolution change that results in width being larger than height or vice versa) and could not trigger any layout events.
The issue seems to be that the Silverlight plugin itself is not resized. With an elevated out-of-browser application you could presumably use COM interop with WMI to get the actual screen resolution, but it's kind of hacky. If it's an in-browser application, you could use the HTML DOM. In both cases, you'll probably have to poll for the current screen resolution instead of being notified via an event.
Mister Goodcat has written a blog post about how to get at this information in both scenarios.
I would file it as a Silverlight bug too.

Resources