Every WebVR app on Android I tried become completely useless after 30 second due to screen timeout in the browser. Is there anyway to prevent it?
There is a (somewhat hacky) solution for this that is being used by the webvr-poyfill.
Android doesn't go to sleep when a video is being played back, so even creating an invisble video-element and playing it will disable the inactive-timeout.
On iOS, a page navigation is initiated and immediately stopped every 30 seconds to keep the screen awake.
Also note that this problem will probably go away when chrome for android ships the real WebVR implementation (probably sometime later this year, when the new daydream-compatible pixel/pixel XL-phones are released)
I think you might find that unless you're on desktop the browser itself is unable to keep the screen on. Instead this can only be sustained by a third party app, or more simply by the user directly through settings.
Simplest solution might be to ask user to adjust settings.
Related
I'm using opengl es 3.0 API with the android studio ndk to create apps.
But I've encountered a very huge problem. I've created a demo app, all it does it change the background color of the screen from white to black and vice versa, every frame. And so when I go to minimize this app, I still see it rendering the background, mostly at the edges of the screen, and not in full color but still very strongly apparent. And it doesn't go away when I close the app, when I restart the device, or when I run "kill apps" on it. Only a factory data reset fixes the issue, so it's not easy for me to debug this.
This is the relevant code that I'm using for when the app is minimized and receives the APP_CMD_TERMINATE event:
eglMakeCurrent(engine->display,EGL_NO_SURFACE,EGL_NO_SURFACE,EGL_NO_CONTEXT);
eglDestroySurface(engine->display,engine->surface);
engine->display = EGL_NO_DISPLAY;
engine->surface = EGL_NO_SURFACE;
I've error checked that eglDestroySurface() is successful.
And I've put debugging messages in to make sure that the main draw loop is NOT executing when the app is minimized. But the problem persists and I don't know what to do about it. Thanks for any help.
UPDATE: well, no one has responded, and I still don't know what to do. Could it be related to threads?
UPDATE: Still can't determine what it is, but for some reason it's messing with the System UI. Willing to upload my entire source code somewhere if someone would be willing to go through this with me, as I'd really like to be able to continue working on my game engine.
Is it the "Strict Mode" developer option on the device settings, perhaps?
That one flashes the screen if an app is blocking.
It would explain why a factory reset changes behaviour.
The answer is not a solution here. The above comment by the user columbo was correct.
I've demoed switching from black to white at high framerates on 3 different android devices, and also my Linux Desktop, all via the openGL api, and it has exhibited this issue on all the devices. So what he said must be correct: this is a problem with LCD monitor technology itself. Interestingly, doing completely random colors does not cause this problem.
I intergrated Unity Google Admob plugin for Android but my game takes about 3 seconds to display and close full screen ad. It's make my game ugly.
I think Unity take a time to call native APIs, i'm not sure. I use plugin from Google Team.
Are you have the same thing with me!
Interstitials taking a few seconds to close is a known issue (on Android). I've blamed the performance on Unity though; I tried opening up and closing an empty Activity, not ad related, and it took the same amount of time to close on Android.
I'm experiencing issues with the YouTube player failing to load when the power save mode is enabled in Safari 6.1 and 7 on OSX. The issue doesn't happen if the youtube user is using the experimental HTML5 player, but it's still in beta and most people are still using the Flash player. The "disable plugins to save power" option is on by default in most new versions of Safari and this causes the YouTube iFrame API to enter an endless loop as it tries to initialize the player.
Is there any attribute on the window or navigator objects that would possibly indicate that the power save mode is enabled so that I can warn users?
This issue is semi-intentional. The Power Saver mode in Safari deliberately stops flash content. You can read more about it in this article.
If the flash content is 'front and centre' (within a 3000 x 3000 pixel boundary starting at the top left corner of the document) it should still play. So it may help, if the youtube video is off to the side of the page, to try and centre it. Apple says content will not play if it is in the margins (see this page under the Safari Power Saver heading).
Well i do not think there is any readable JS property to know that,
if so Apple would have a flawed design, and the Safari Users would get nagged to disable that mode, in order to have the web site working "properly" ...
What you could do of course is to try to make a server call on your web site via flash, and then try to read the changed session variable via JavaScript, then you would know ...
I'm using Mobile Safari's cache manifest file to store a multi-page data entry application that is run on an iPod Touch (version 3.1.3) in offline mode. The application writes to the client-side database by way of the persistence.js ORM. This all works fine.
However, I run into the occasional, extremely hard to reproduce problem whereby Safari just seems to forget that the pages are cached. When this happens, the "Cannot Open Page" alert appears, which is the same one that comes up when you attempt to visit a non-cached website with the wi-fi turned off. The only way that I've found to fix this is to reconnect to a wireless signal and visit the site while online, which seems to set the cache straight. This is easy to do when you're in the office, but not so easy to do out in the field.
I'm not trying to reference anything outside of the cached resources, and I've verified that the application is cached by running through the entire site while disconnected, sometimes successfully for days on end. I feel like there's a bug in the OS that messes with the validity of the cache. I'm not necessarily looking for a solution to the problem (but that would be nice), but rather just some confirmation that others have encountered this problem.
Using a cache manifest and lot of troubleshooting, I am able to reliably cache an entire application; Do note that this is a single page app with only a few separate file resources.
As a further enhancement, I have been trying to modify the DOM based on
window.applicationCache status
to inform the user about updates, ie:
tap here to apply update
If that were possible, I could swap the cache
window.applicationCache.swapCache();
Which would allow me to swap in the updated cache and then restart the page to provide a streamlined update mechanism.
Potentially even more streamlined than apps from the apple store.
I suspect that the applicationCache API was hamstrung by Apple to hinder web apps for this very reason. Having said that, I believe the level of support for "html5" APIs on mobile devices is among the most robust in apple's safari.
Following are a few problems I have noticed so far, in no particular order. Please note that this is not a comprehensive list of bugs.
I never get an 'updateready' event; this alert line never runs:
window.applicationCache.addEventListener('updateready', function(e) {
alert('updateready event status=' + window.applicationCache.status );
}, false);
I can not manually check for updates. The following code gives me an exception
try{
window.applicationCache.update();
}catch (err){
alert('exception:\n' + err);
}
It seems that as soon as I start to interact with the cache state at all, the caching stops working. The bugs are fiendishly elusive; pinning down & isolating any one issue can take a lot of time, especially since all this code runs flawlessly on other browsers (chrome).
Now here's a good one:
I suspect that if you pin an app to your home screen, iCloud "backs up" resources and restores them after you run the app for the first time from the home screen. To avoid this issue, you may sometimes have to rename files. I have proven that apple makes discrete backups of obsolete components by
removing them entirely from my app server
deleting the pinned web apps from home screen
clearing all the caches
opening the app url in safari
verify that its the newest version
pin to home
verify that the pinned app the newest version
close it
run again - and its back to the old one, no longer on your server.
Finally, if you run the pinned app while the phone is in airplane mode, iCloud will not be able to restore the obsolete files. This proves that it's coming from over the air.
I have this issue when debugging mobile apps on the emulator. When I press F5, the build starts, then the deploy, then the app pops up in the emulator.
Because this takes a minute or 2, I am checking my SO score and maybe ask a question while I wait, and the emulator is in the background. When I finally switch back to the emulator, it shows the start page, not my app.
I figured out that by pressing the back button I can bring the debugged application to the foreground, but still, I don't know what is pushing it into the background to begin with. Has anybody noticed this, and found a way to prevent it?
The default behavior in WinMo is that if the device has no activity for a certain period of time (set in Settings->Today->Items->Today Timeout), the Today screen will come to the fore. Check to see if that's what's happening (though I think the smallest interval is still larger than a couple minutes).