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;
}
Related
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.
I'm developing my project in Codename One. UI creating from code, not GUI Designer. Application consists of three forms, as navigation I use Hamburger sidebar. The emulator works fine, but the builded application works very slow. Application was tested on Android. The degree of brake application depends on the number of components in the form. The situation has changed a little after we changed android.asyncPaint to false, but the operating speed remains slow.
Above all, Hamburger sidebar animation works strange. At first shows previous form, and then only shows the selected form. But this problem is not as important as the terrible brake application.
In 9 our of 10 cases this is caused by developers using gradients which are notoriously slow. It can also be triggered by tiling very small images or too many layers of transparency.
We have a performance monitor tool in the simulator that exposes some of these issues. You should also watch this video which covers most performance issues: http://www.codenameone.com/how-do-i---improve-application-performance-or-track-down-performance-issues.html
Hello it's possible to block, landscape view just for Smartphones, but not for Tab's or bigger devices?
It all depends on the container holding your webview.
In android you can block orientationchanges, even changes under certain conditions, on your activity. The overridable method "onConfigurationChanged(Configuration newConfig)" is responsible for this.
On iOS you can do this on the ViewController. This post describes how to do it: iOS 6 - How to run custom code when orientation changes.
It is also possible to do this from the configuration files of the project. For iOS you can block certain views for certain device types. With Android this is only possible to block landscape mode entirely.
If you are feeling adventurous, there is also the option to CSS-transform your view, though this is more of a hack than a real solution: Prevent orientation change in iOS Safari
I have went all over the web to find a solution for this one ...
i want to create a fixed bottom menu for my web application,
As i learned the support is not cross platform and each device and browser presents a different obstacle,
I have placed an element with
position:fixed;
bottom:0;
left:0;
problem : it is very buggy on some browsers (pops to place after the scroll ends , stays on the center of the screen, etc ' ...)
is there a good solution for this issue , or should i give it a rest :-) ?
thanks
There is no cross-platform solution for this, mainly because many devices still do not support touch events, that's why iScroll fails on WindwsPhone for instance. I predict native position: fixed; won't be implemented for at least one year (even iOS did it recently, other mobile browsers are way behind; we can expect WP8 with IE10 will support it and some other browsers, but that is not enough). I suggest you keep your toolbar at bottom and keep you page height small enough so people do not have to scroll down a lot - your app will look same on all mobile platforms.
I'm retro-fitting a website for Mobile First Responsive Design (MFRD). My question is - how far do you go with the "Mobile First" part?.
For example - on the homepage I plan on having a list of upcoming events, say 4 or 5. On the mobile version I thought 2 would be enough to save screen real-estate. Should I load the other events in dynamically for the larger views, or should I just hide them since it will only be a few elements anyway?
Loading them dynamically for larger sizes means I have to attach an event to the window resize which typically gets fired every pixel. Even though I can offset that with Timeout, that's still a lot of client side checking is it not (even though it's not like users are constantly resizing their browsers).
I mean, even though you're designing for mobile first, you also have to consider the larger sizes right? Obviously larger JavaScript libraries and other assets that are needed for larger only you want to pull in later and not load for mobile - but how crazy do you want to get with the bandwidth saving?
What is the target market for the website? Are you making a completely responsive website that encapsulates smartphone to desktop? Or are you just concentrating on smartphone to tablet?
Mobile First really just means start your styling and content views at the smallest form factor and work up as the device dimensions get bigger. HTML, CSS (media queries) and jQuery all play a part to expand the UI and manipulate (show/hide) content elements as the browser gets bigger.
Take a look at Smashing Magazine, their responsive layout is one of the most extensive I have seen so far, it will give you an idea of how far you can take the MFRD or DARL (Device Agnostic Responsive Layout) methodologies.