I have a problem with Samsung's "Easy Mode".
Our C# application is developed using Android.Webkit.WebViewClient where we call some Web pages (HTML / CSS / JS) as a user interface. All views respond to all types of different devices. Also, all views work as expected running in "normal mode".
As soon as you activate the "Easy Mode" of Samsung devices, the webview appears to change the fontfactor and other important layout rules. Due to complicated controls but limited screen space, we are now forced to ensure that our views are not affected by easy mode or alternatively are resized to their optimal state.
I've already tried some viewport settings on the pages and some properties on the webview instance but nothing seems to work.
Does anyone have any idea how to force deactivation or how to detect and react on easy mode using web technologies or the webview instance?
I am definitely grateful for any help or advice!
Thanks!
Related
I have a very strange problem with my web app seemingly triggering a colour adjustment from the android device - normally colours are fairly vibrant, in the same Chromium based browser for other pages, but once switched to my web app, the screen's colour temperature turns cool, and saturation seems to be toned down, resulting in a dull grey looking page.
Other pages within my web app doesn't seem to trigger this colour profile change.
I cannot think of what possibly might be causing this. Is this solely something done by the device, and not possibly controlled by me, or is there something that can be done for the front-end code? This is a web app, and not a native app, so I can't access android APIs.
Is it possibly the mobile view of the website? I've seen websites have a poorly optimized mobile view, causing similar issues.
Hey I'm a web developer and I'm looking for a way to emulate mobile devices which also displays their respective navigation bars, toolbars etc. In the 'Device toolbar' in Google Chrome (v58 on macOS) there's a specific mode available for the Nexus 5X (and 'supported devices', according to Google), which is exactly what I'm looking for (see screenshot below), however I can't seem to find a way to turn this on for other devices (such as iPhones, Galaxys etc).
Of course these bars would differ between the devices and the browser that it's running, so ideally I'm looking for a way to manually specify the height of the bars and how they interact with the viewport (e.g. iOS Safari includes the top bar in the viewport height calculation but leaves out the bottom bar, which kinda screws with how the bottom of the page is being displayed (as discussed here)).
Ultimately what I'm trying to achieve is a way to accurately simulate how a website would look on a specific device, by instead of looking at just screen sizes and pixel density actually taking in to account that there are other sections being displayed on the screen which of course takes up screen realestate themselves and affect the appearance and user experience.
All ideas are welcome =)
You can use Blisk browser, it's built on Chromium and supports toolbars and panels for IOS/Android devices, it has a good set of devices that you can emulate on.
This question has been asked many times on stackoverflow, but each time the correct answer was not working or not the correct one.
I am reopening this question, due to it's importance for mobile web device programmers.
I want to be able to stop rotation on a WEB SITE on a browser on one of the following OS: IOS and/or Android device or at least to modify the rotation to last landscape at least. So only landscape is permitted as a rotation.
I have tried many related questions with no solution:
Blocking device rotation on mobile web pages
Jquery mobile device rotation shrinks the screen
Any idea is welcome, thank you.
p.s.
#CommonsWare is right, you shouldn't just block the user from being able to rotate their device however they want. In fact, that's what makes mobile web apps so versatile. They encompass the principals of responsive design.
I know this isn't the answer you're really looking for but if you insist on doing so, take a look here: Block mobile web rotation with javascript.
I'm not sure but I'm guessing that still won't work simply because a web app isn't native to whatever device you're viewing it on and the app you're actually in is a browser eg Chrome, Safari, ect and those are almost certainly going to have different orientations enabled regardless of what your web app is doing.
We’re porting to Android some interactive iOS apps used to teach young children with learning disabilities. We have hit a major usability issue, because we can't figure out how to disable physical or on-screen navigation buttons (Home and Recent Apps).
Before anyone says “you don’t want to do that”, we fully understand why you would always want these buttons enabled for an able-bodied adult, but these children pose a unique set of accessibility issues. Specifically:
Their fine motor control may be poor - they may inadvertently touch a different area of the screen to the area they intend, or accidentally use more than one finger at once.
They may have weak muscle tone and poor physical strength – so e.g. the bottom of the palm of their hand may drop and touch the screen while trying to just use a finger.
They struggle to achieve and easily become disheartened or disruptive if they fail.
For instance, a typical 5 year old child with Down syndrome will accidentally drop out of the app they are using as a result of inadvertently touching the Home button: when this happens repeatedly, and the adult teacher or parent has to go back into the app for them repeatedly, the child loses interest and focus. Another typical scenario is a young child with Autism, who may freak out completely and need physically restraining if this happens while using their favourite app. Also, many disabled children will try to poke any other button they can find, in search of a response. In any of these situations, a potentially valuable educational session may have to be completely abandoned.
We're aware of SYSTEM_UI_FLAG_HIDE_NAVIGATION and SYSTEM_UI_FLAG_LOW_PROFILE, but these only reduce the visibility of the on-screen buttons until the child touches some other part of the screen, and then they re-appear in a way that’s more distracting than if they were visible all the time.
On iOS there is the “Guided Access” feature that solves this problem trivially. Can we emulate anything similar on Android?
On iOS there is the “Guided Access” feature that solves this problem trivially.
Guided access appears to be a device setting, not something that developers enable unilaterally themselves, thank heavens.
Can we emulate anything similar on Android?
There is no similar device setting in stock Android.
You can download the Android source code, modify it as you see fit, build the results into a ROM mod, and install that ROM mod on devices as you see fit.
Or, you can perhaps work with a device manufacturer creating tablets aimed at children to see if either they have already added this capability to their devices, or would be willing to work with you to add such a capability in a future iteration of their devices.
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.