Is there some way to get the real screen-size or DPI of the device? I have certain elements in my application which are not usable if the display is too small and need to switch to a different presentation and/or omit the elements.
Short answer: No. There's (currently) no way to accurately design for the web using physical units.
Longer answer: you can only try to rely on the size of a "CSS Pixel" being roughly the same between devices, since device manufacturers have a vested interest in preserving the usability of sites when they have "high" pixel densities (~> 90 dpi).
A couple of notable exceptions:
the iPad mini is the same resolution as the original iPad, but (obviously) much smaller.
Opera on Android offers to pretend to be a desktop browser, including a fake device-width, etc...
Related
I built a Google Cardboard app (or at least a Google Cardboard-compatible app with room for improvement) that works well on phones with 5-6" screens (iOS and Android) and a Google Cardboard viewer designed to work with those 5-6" screens. However, if viewing the app in a larger "phablet" screen, vision doubles and the app becomes useless for those devices.
Since the app primarily runs in the phones' stock browsers Safari and Chrome, is there a way to scale down the app canvas/block element to stay within the 5-6" range on larger mobile devices? Here is a rough illustration of what I'm trying to accomplish:
So far my search brings me to answers like this one, explaining that this might not be totally possible? If that's the answer in this case, I'll work with it. I have seen other Google Cardboard VR apps that do scale down nicely on large screens, but perhaps JavaScript, HTML and CSS are not involved.
I'm using PhoneGap and Adobe PhoneGap Build to create this app, so I also have access to PhoneGap/Cordova plugins if that will help.
Maybe there's a an API that will allow lookup of device info via phone info available in the browser or a Google Cardboard API (at the moment not making use of a Cardboard SDK or two due to PhoneGap being in the middle).
I'll revisit this topic soon, but look forward to any thoughts you have on how to answer this question.
The trick is to get the screen DPI reliably.
On Android, you can use getRealMetrics
which returns the screen's DPI. Note that this is sometimes a bit off
On the web, you may want to check the webvr-polyfill's DPI database, which presents DPI values for some popular phones.
I am working on a mobile web project that needs to know the compass direction the user's device is pointing. It's incredibly simple right now, but here's what I have:
var updateDirection = function (evt) {
$("#direction").val(evt.alpha);
};
window.addEventListener("deviceorientation", updateDirection);
Based on what I've researched so far, the alpha channel of the event should be the compass position. However, I've observed (and read) that there are a wide variety of implementations based on OS and browser.
On my HTC smartphone, in Chrome or the default Android browser, I only get a reasonable reading (0 degrees = North, 90 = East, so on) when I hold the phone perfectly vertical in a "selfie" position. Any angle to the phone throws readings quite far off.
On my Surface Pro using Chrome, I can't get a reading greater than about 50.
On my Surface Pro using Edge, I get very reasonable readings, but only when I hold the device horizontal, as if it was laying on a table.
It seems likely that people have achieved getting the compass direction in a mobile browser regardless of device. Is there some library I can use to do this? Or is it necessary to simply code for many different specific scenarios, like this example, which also didn't work for all the devices listed:
Device Orientation Events
Is that really necessary for you to use javascript to find out orientation?
You could possibly achieve the same result with CSS media queries
Problem:
I have a small group of roughly 90 users which is extremely important, so when one or two of these business customers desire the UI changed in their web app, they usually get development resources dedicated. However, it's important for us to understand exactly how the application is being used by the group as a whole because this group tends to have strong personal views on how their UI should look and they all use the app differently. I'm having the most trouble with identification of their usage of hardware vs soft keyboard. Optimally I'm looking for an answer as simple as, "use the new Window.TabletMode == true!" I don't think that simple answer exists.
Research:
SO question Detect virtual keyboard vs. hardware keyboard is the only significantly similar question I see but it focuses half of its time on using a JavaScript keyboard to replace the soft keyboard, so the answers talk about how to make the keyboard specific to numbers, dates etc. Additionally, he's looking for cross-browser solutions where I need only IE11+ support. Finally, I can depend on the hardware keyboard being docked and a specific brand (Dell). Finally, I can depend upon Windows/IE11, so there could be other avenues of approach compared to this 3-year-old question. My use of a hybrid tablet also makes the approaches of capability checks useless since I already knwo all the capabilities (touch, etc) are already available on the device.
I could check the Registry for the UI setting, but I really need to stick to JavaScript or something similar.
Android has undocumented but known events which indicate showing and hiding of the keyboard. However, none of the users will be using Android.
IE should receive a WM_SETTINGCHANGE message when the change occurs, but I'm unable to determine if this is made available to a JavaScript API. I'm thinking it would be a message far more specific (if any), so I can't find anything with this search term and JavaScript.
Code:
From W3Schools,
The window.orientation property returns 0 for portrait and 90 or -90 for landscape view.
Combined with window.innerHeight, I could use something like...
var portrait;
$(window).on("orientationchange",function(event){
if (event.orientation == 0)
{
portrait = true;
}
else //if not, it's landscape
{
portrait = false;
}
});
Then I would use window.innerHeight in combination with the value of portrait to determine if the width to height ratio looks like I have a keyboard open. This approach really might work in fullscreen considering my fairly narrow constraints, but what if the browser isn't fullscreen? I'm sure there are plenty of other reasons to not write a hacky ratio calculation for this. Additionally, my greatest desire would, of course, be to do this with any browser and any screen size.
These things I can handle: I'd need to set variables on the loading of the document and work out a way to determine when the typing becomes relevant. I might need to check for some browser capabilities. Perhaps I'd increment counters for typing with and without a hardware keyboard. Once I hit a certain number (let's say 5 keystrokes), I'd send a POST request to my data tracking endpoint to let it know that session 12345 used the soft keyboard (or hard keyboard). Afterwards, I'd unsubscribe from the event handler. However I work this part is of less concern because I don't think I'll get stuck on anything, but I didn't want anyone to spend time on beautification or development of a huge example.
Environment:
Hardware should all be Dell tablet/laptop hybrids (specific model TBD) with IE11+. I hate to make something IE specific, but if it runs on IE11+, it's totally acceptable.
I should be able to pull in any sort of JavaScript libraries suggested, but keep in mind that JQuery 2.2 and Knockout 2.1 are already present, so little "weight" is added for a solution with JQuery usage.
I probably can't get approval to write an application that uses ActiveX or some other heavy handed customized approach that would require installation of a local application because my company has roughly 50,000 users, and a deployment like that for 90 users would be overly complex to maintain.
The screen sizes should all be 11 inches, but I'd be sad to resort to using specific size and resolution because an answer like that would be extremely limited in application for me or future readers.
Impact for Readers:
I'm seeing a move away from Ipads in the medical kiosk / EMR space because Ipads limit a lot of the UI choices in favor of a cohesive experience. Physicians especially will often get attention of high ranking IT leaders if they desire a very specific UI change. Microsoft has tended to allow a lot of non-standard intervention and (more recently) more standard types of intervention in how the browser works. I think a lot of this movement is going to Windows tablets for this reason and also for the reason that many medical groups are heavy on .NET development capability.
Bottom Line: You can't get exactly what you want. With IE11 you actually have a couple other challenges. You can't simply use the Fullscreen API with promise = element.requestFullscreen() because IE will request permission from the user first, and the API lets you check for capability but not state. Also, multiple fullscreen applications can share the desktop in Windows 8 and 8.1, which is a bit counterintuitive.
However, if you can count on the web app probably being fullscreen, your "hackish" JavaScript solution probably is the best answer. Get the initial dimensions when the document loads and compare during key presses. As a side note, keep in mind that the user might not be using the software keypad just because he or she isn't in the dock. The user still needs to explicitly open the software keyboard.
If you had said "Android only", it would be an easy solution, but you already demonstrated you knew that in your question. If you wanted to use a desktop app, there is some MSDN documentation on a hardware token here but again you specified that this wouldn't be simple enough.
Is there a way to tell/set, how many millimeters an element has, which works across various devices?
For example, I would like to create a white window which is 100 x 100 mm, with a black 10 x 10 mm square in the middle, which would have those dimensions on desktop, tablet, print, ...
I don't mind to use very latest browser but it has to use HTML/JS/CSS.
PS: Related: is there a way to tell, how many millimeters the screen has?
Edit
In other words, the problem is that using CSS units like pt, mm, cm, ... does not work as browser vendors decided to hardcode 96 DPI into the agents, according to here. Is there anything one can do to get real, physical, dimensions on web?
Not really.
In theory you can set lengths using mm units, but this requires that the browser accurately handles the DPI of the display … and browsers tend to assume a fixed value instead of getting the real one.
If that worked, you could then get the width in that unit by creating an off-screen element of known physical dimensions, reading the pixel dimensions using JavaScript and using that ratio to convert the pixel dimensions of any other element to mm.
In practice, if you need accurate measurements you are pretty much limited to drawing something on screen and asking the user to measure it with a ruler to get your ratio.
Alternatively, if you can identify the specific device in use (which the User Agent String may tell you for some devices) and you keep a database of the physical sizes of those devices (so this is limited to a subset of phones and tablets and won't work if they are connected to an external display) you could use that to determine the dimensions.
cm and mm can be used as CSS units , For more information please have a look at
http://www.w3.org/TR/css3-values/#lengths
16px == 0.17in == 12pt == 1pc == 4.2mm == 0.42cm
Im not sure how well they work in high screen density devices..
I have been working on making our CMS export valid content for mobile devices. One of the problems we encountered was that newer devices, like the iphone4 have a higher resolution display so we needed to find a way to render the same page correctly on older devices and newer that use a 300dpi display. So far we used javascript and window.devicePixelRatio in order to get the dpi resolution, but it turns out this is not working in opera(?) and opera mobile.
Any suggestetions or maybe a defferent approach? I researched a bit but was unable to find somethig.
Thanks
I think you might misunderstand what devicePixelRatio is really telling you — surprise, a pixel is not a pixel!
When you specify a pixel size in CSS, you're not necessarily specifying a size in physical pixels. Instead the CSS px unit is actually a "device-independent pixel" (DIP), which is relative to the device's DPI:
Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values.
The reference pixel is defined as 96dpi (Windows' default DPI setting), so on your computer, it is true that 1 DIP (CSS px) = 1 physical screen pixel. Additionally, even though older iOS devices have a physical DPI of 163, they still use 1 DIP = 1 pixel. However, on iPhone 4's doubled resolution of 326 DPI, 1 DIP = 2 screen pixels, which is what devicePixelRatio = 2 is telling you.
Thus, speaking strictly of the difference between the iPhone 3 and iPhone 4, a HTML element with the style { width:100px; height:100px; } should render at roughly the same size on older devices and on the higher-DPI iPhone 4 since it rescales the pixel values.
So there is no reason you sould have to use script to account for high-DPI devices; it should just work.
Opera Mobile doesn't have devicePixelRatio yet as it is pretty much a none-standard extension added by Apple. We are considering adding this however, and may be in the next release of Opera Mobile if we do. You don't need to use JS for this however. It should work in a Media Query too with device-pixel-ratio (with vendor prefixes).
HI all,
josh3736 gave a very nice and concise answer to the css vs device pixel issue. Just wanted to add that it does seem to be an issue with large, high definition images which may need to be served more specifically for individual dpi or ppi device spec's. Searching google, I found that others are (attempting to?) using the device-pixel-ratio as a base to resize images smaller for high ppi displays, while keeping the original high def. image available for these devices and providing low def. images for mobiles without high dpi displays. That way the image is of higher quality for these devices, yet looks sized the same relative to the rest of the page across the spectrum of user devices.
The ability to zoom seems to make this more useful I gather, since a user can zoom in on high def. images and get increased detail. Of coarse this does add another layer of complexity to deal with, but it may be important to address as we have more and more new high end devices entering the markets. Still looking into this, so post back if anyone has good examples.