I have the same website for mobile and desktop devices. One weird behavior I discovered is on mobile devices - Android and Chrome browser.
I didnt have the opportunity to discover exact trigger of the behavior but I think it has something to do with screen turning off.
I have this code before unload. On desktop it works fine.
$(document).on('beforeunload',function(){
$('.loading').show();
})
On phone it works also good but when I minimize Chrome or screen turns off and I wake up the phone. It triggers beforeunload event. Because of that I need to reload the page. I tried also small workaround that clicking on the .loading class will hide it, but with this behavior it doesnt work.
Any ideas ?
Related
I've got a sticky situation. I'm developing a kiosk-style tablet application on JellyBean, and we're stuck with JellyBean.
We don't install a standard launcher on our Android tablets, and instead supply our own Home Screen/Launcher app, so that our application starts on system startup.
We were using a WebView for our GUI app. The WebView that comes with JellyBean is buggy and deficient in many ways, so our app doesn't work correctly in the WebView.
However, Chrome runs our app perfectly, so we want to switch to using Chrome, which we would launch from our own Home Screen application on startup.
We need to start it in full-screen mode, just like Launchers do when they launch any app/URL via a link that was placed on the Desktop.
I can't for the life of me find out how launchers pull this off.
I've tried adding --app="xxx", and/or --start-fullscreen to the /data/local/chrome-command-line file, but all to no avail. The additions options show up on the "chrome://version" screen in Chrome, but they have no effect.
Does anyone have any clue how they manage to launch Chrome in full-screen mode?
These tablets are all rooted tablets, completely under our own control, so no solution is out of bounds.
Thanks for any help!
Hey guys I am trying to trouble shoot an issue that seems to be only happening on certain Android devices that are version 5 or older.
What happens is, when I touch an input field say email-address or password to login, the page refreshes which makes it impossible to ever enter any information.
This is not just limited to those fields, but any form fields in the application. We have a leave feedback page and that form field also refreshes the page.
I had assumed I was having the same issue as Disabling android's chrome pull-down-to-refresh feature
But none of those solutions seem to be working for me and I just can't figure out what exactly is happening.
The information on my Android device:
Samsung Galaxy Tab A
Version 5.0.2
Is happening on Firefox, and Chrome on the device.
I am a little new to debugging on Android and could not find the version of touch my device is using.
We are using Jquery mobile for the front-end and some bootstrap javascript/css for forms.
So what I found out, was that whenever the screen resizes we do a refresh event for the new screen size.
What was happening on Android is that we had a css property `
orientation: landscape
on landscape mode. Well what was happening is you would click the form field on Android the keyboard fires and resizes the screen. Which was triggering a refresh, which took the keyboard away and sized the screen back to the regular screen with no keyboard event.
How we fixed this was using:
min-aspect-ratio: 13/9
This however was not happening on iOS because as far as I can tell, iOS just triggers a scroll-bar event instead of a screen resize event when the keyboard opens.
Hi I am developing an app in which on long press I will be able to move the icon and on single tap I perform some activities.
The app works fine in mobile phones but does not work completely in tablets.
In tablet it does not detect onLongPess just the single tap.
I actually need to press very lightly on the icon for the tablet to detect onLongPess if I try it roughly as I would in my mobile phone it does not detect at all.
Why is it?. Do we need to handle differently for tablets?
Can anyone please help me? I am pretty sure my code is fine since it runs perfectly in all mobile phones.
I'm new to Android development and my first application is looking good.
Curious if anyone has ran into problems with admob:
I have a ListFragment that displays a list with ads at the top and bottom of the list. The display is fine and everything runs ok except -
when I click on the ads and after the browser loads up, clicking back does nothing except for "going" back on the browser and it doesn't go back to the app.
Strangely enough this is happening on my Samsung s3 device but not on my HTC device.
This is because Samsung uses their own custom browser (not stock), and its deciding what to do with the back button. I don't think there's anything you can do- their browser has the focus, it gets to decide what to do with all IO. Your app is in the background and doesn't have any say over IO response.
I am trying to work with trigger.io and Kendoui Mobile.
the point is, when launching the mobile app on emulator all works like expected - but when it runs on android mobile the Layout / View doesnt show up until you touch the screen or turn the mobile to landscape or viceversa.
with a tabstrip of kendoui one time showed up you can swtich between views with no problems.
but if you redirect to another view with different layout you have to touch again the screen to show the content (it just shows just the background of body until touch).
the telerik guys at the moment dont know from where it comes from as they tested it with phonegap and no problems.
Maybe the trigger.io guys can find out why it happens?
Best regards
marc
It looks like this is an issue with hardware acceleration on Android 4.0, probably an unfortunate interaction between whatever hardware accelerated transitions Kendo UI use and that particular version of Android.
Phonegap seem to have hardware acceleration disabled by default, which is why they would not be affected.
As a fix we are going to add an option to disable hardware acceleration on that particular Android version, which we'll have live by the end of the week.