I'm making an app and I'm nearing completion, now I'm trying to optimize it for different screen sizes and pixel densities. One of the devices (using an emulator) is really frustrating me. I can't seem to find a qualifier that edits the Notion Ink Adam (1024x800 or something, 10.1 inches). According to this: http://developer.android.com/guide/practices/screens_support.html , Notion Ink Adam at 10.1 inches should be considered "xlarge" in a qualifier. However, when I use this in my qualifier like "layout-xlarge" the Notion Ink Adam emulator doesn't follow it.
I also tried using "layout-xlarge-hdpi" because I have another folder that's "layout-hdpi" that the Notion Ink Adam follows, but I'm using THAT qualifier for other devices. Also I've tried "layout-hdpi-long" but it also edits my other "long" hdpi devices. Notion Ink Adam is a tablet, and I'm just trying to seperate: 1) tablets like the Notion Ink Adam, 2)MDPI screens, the smaller screens, and 3) Long hdpi screens like the Nexus One and Motorola Droid.
My main problem is trying to find a qualifier that seperates 1 and 3, the tablet always follows my qualifier for the long hdpi screens.
Support for xlarge devices was introduced only in Android 2.3 (Gingerbread) and later. If your Adam is still running Froyo, it will report itself as "large" and will not find xlarge resources.
I developed an app, "ScreenInfo", which will cause an Android device to report its screen size and density classification. You can find it in the Market, or grab the source.
To help you sort out the various categories:
small-screened phones (like the original G1): normal-mdpi
most high-end smartphones w/3.7-4.5 inch screens: normal-hdpi
small-screened tablets (7-inch): large-mdpi, or in the case of the Galaxy Tab 7, large-hdpi
large-screened tablets (10-inch): xlarge-mdpi
As far as I'm aware, you're already doing everything correctly - using -xlarge for tablets, -hdpi, -mdpi, and so on for the appropriate screen densities, and so on. If the Adam's emulator (or the actual device) don't pull from the -xlarge layout already, it's probably in your best interest to simply ignore it. It's not a particularly popular tablet now that the Android 3.x devices are out (probably wasn't even before that, but I don't know), and if they're ignoring standards, all the more reason to ignore them in favor of what works for the majority of devices.
In terms of common qualifiers, I'm not sure what you mean, but if you go by the information in the documentation you linked, that's what's "common."
Adam reports itself as a large device. So, xlarge resources wont work on Adam.
Related
I'm working on my first winjs app for windows 8.1. So I'm a newbie in this topic, so please forgive me if I ask something obvious.
My problem is the resolution of the target machine (DELL Latitude E7440 with touch screen) is 1920x1080, but when I run the app, it runs in 1370x771. Which is a bit confusing for me.
So my question is, how can I tell the app to run in the same resolution as the OS runs.
Strange thing I discovered: If I set the "Change the size of apps text, and other items on the screen (...)" settings from larger to default in the display settings then suddenly my app runs in the desired full hd resolution. But I don't wanna depend on this setting.
I know I could use ViewBox control, but all of the graphics and everything is designed for full hd resolution, so ViewBox would simply scale it down, this solution sounds a bit ridiculous considering I have a full hd laptop, and full hd design as well...
This app is only for this particular machine, so I don't have to deal with different resolutions.
Any tip/suggestion is highly appreciated.
Windows abstracts the physical device resolution specifically so you don't have to think about scaling issues. Just do your work against the resolution that's reported from the API. This is done because a high pixel density display can result in UI that's too small to be usable, e.g. touch targets that get too small for fingers. Most of the time, then, a 1920x1080 display that's on a smaller physical device (e.g. 13" or smaller screens) gets a 140% scaling factor applied, hence it reports something closer to 1366x768.
Generally speaking, then, if you write responsive CSS for layout then you really don't need to worry about scaling at all with the exception of providing raster graphics that can work at the 100%, 140%, and 180% scaling plateaus (and 240% on Windows Phone 8.1).
For more details refer to my free ebook from Microsoft Press, Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition, which you can also read (free) within the Microsoft Press Guided Tour app in the Store. Page 42 (Chapter 1) has a short overview on Views and Resolution Scaling; the Branding Your App section on page 113 talks about sizes of logo/splashscreen images for different resolutions, and then Chapter 8, "Layout and Views" (starting on page 421) goes into all the details, especially "Screen Resolution, Pixel Density, and Scaling" on page 437.
I've seen that some Google's or other open source projects have resource directories like /drawable-v14 or /drawable-hdpi-v11.
Now, I understand what this means: all devices with SDK larger or equal than v11/v14 should use these images.
But what is the purpose of this? Why and when should I use them? Why devices of HDPI resolution and SDK v11 should ever use images different than HDPI devices and SDK 10?
I just cannot see when I will ever use one image for SDK 10 and another for SDK 17, for example. Makes no sense to me.
As a side note, the usage of resources /values-v{11/14/17} is logical and has the practical benefit.
This can be use in order to style your icons to the current UI guidelines on the given Android version.
Android has had a lot of evolution on its GUI style from its beginning. In Cupcake, icons had to show a 3D effect with a shadow. With ICS, there is more flat icons. And it will keep on changing with android 5 and more... (Let's watch the Google i/o 2014 to know more about it! ... by the way: its today!)
So basically you can stick to the GUI guidelines even from different Android versions. It's probably not the only use case but it is one of them.
I have 2 android tablets - 1 samsung and 1 micromax tablet, samsung has 800 x 1280 pixels, 10.1 inches (~149 ppi pixel density) and micromax has 600 x 1024 pixels, 10.1 inches (~118 ppi pixel density).
I want their assets to be seprate but both are picking from mdpi, How can I do it?
Is it possible to use something like drawable-w600-mdpi and drawable-w800-mdpi?
No. Have a look at the Providing Resources page over at Android Developers. In Table 1 you can find all admissible qualifiers. Personally, I would suggest you let the OS handle the layout and choosing the right resource. However, with the new format of specifying resources 'wdp' respectively 'hdp', you might be able to get what you want as the tablets feature different sizes.
However, unless you have a very good reason to do so, I wouldn't do it. Often when you think you need to do something that is discouraged, there is a flaw in your design or the requirements can be met in an easier, more standard, way.
Update:
As by the comments, your problem is probably related to the devices not correctly communicating their DPI and, therefore, Android not choosing the correct resource. An Android Developer blog I recently read details the problem and shows a few examples on how to use the new numeric selectors tied to screen width and height to resolve some of those problems.
My first question on stackoverflow, so my apologies if I'm missing something.
I read in a reply in another J2ME transparency question from 2009 here at stackoverflow that "You should note that alpha is sometimes ignored on some implementations and sometimes quantized to ugly levels (Some motorola phones snap alpha values to the nearest 2-bit value)."
I am currently experimenting with transparency in J2ME, testing on rather new devices (at least in the J2ME world).
They all return 256 when I call Display.numAlphaLevels();
Yet, I only count max 8 actual levels (and mostly only 5 I can tell apart) when I set an image to slowly fade in.
And it seems it is, as the above quote states, the nearest 2-bit value:
1% visible at level 2-3
3% visible at level 4-7
6% visible at level 8-16
12% visible at level 16-31
25% visible at level 32-63
50% visible at level 64-127
100% visible at level 128-255
Tested on Sony Ericsson Aino, Vivaz, and a Nokia N8, with both an 8bit PNG and a 24bit PNG.
I consider those devices to be some of the latest models that can run J2ME.
The above quote makes it sound like it's not all J2ME enabled phones that behaves like this though. And that's why I ask my question:
Can anyone confirm that this is just how alphalevels are with J2ME enabled phones? If not, then how is it set up on other phones, and which phones are they?
Do you know of any J2ME enabled phone that actually have all the 256 levels? Or one that can give e.g. 75% visibility?
Thanks
Well, not quite sure what I did wrong, but apparently it was something in my test-code that gave me these wrong results, that just so happened to match a quote from another JavaME developer, which made the results seem probable.
Since I posted the question, the alphalevels suddenly appear as I'd like them to appear: Nice and smooth. Not sure what I've changed in the code, and too busy/lazy to test at the moment.
So this can be closed.
Now that the new Macbook Pro is coming out with a Retina Display, there are a lot of resources out there on how to make Mac apps and now even websites "Retina Display Friendly". Even Google is updating Chrome for Retina Display...
Why is this necessary at all? From what I understand, Retina Display is just a higher resolution screen. Right?
I thought when you develop gui's for desktop software and develop websites, you are developing something that is supposed to work and scale properly with virtually any resolution... When you resize an app's window, or display it on a higher or lower resolution display, it is supposed to scale and display properly.
So why are these people coming out with guides on how to make something look good on a Retina Display? Shouldn't it already look fine by default? Is there something about Retina Display that I'm not understanding?
And for the record, I'm not talking about iPhone 4 Retina Display. Most iOS dev's make their apps with fixed position elements since they know the screen's won't change size/shape. So I understand the importance of developing an app to look good on the iPhone 4/s vs 3g/s.
With the Retina display apps don't actually scale like they're being resized, all the controls are resized to be twice as big. If an app would be scaled normally, not by scaling all the controls, etc. you wouldn't see anything, because everything would be too small. It's the same difference between a Retina and a lower-resolution display as on the iPhone 3GS / iPhone 4.
An example:
These images are actually the same size, just the pixel densities differ.
And here's how it looks not properly scaled (using some app to disable proper scaling):
http://cloudmancer.com/images/trueretina.jpg
I thought when you develop gui's for desktop software and develop websites, you are developing something that is supposed to work and scale properly with virtually any resolution... When you resize an app's window, or display it on a higher or lower resolution display, it is supposed to scale and display properly (StackOverflow, for example, uses a 960px-wide container).
From a web developer standpoint, you are often asked to develop fixed-width websites (ranging from normally 940 to 1000 pixels wide), and they don't get to scale at all. There are a lot of websites like this and many apps just aren't designed to increase in size.
Also, apps that do grow in size usually expect that a bigger resolution also means a bigger screen, so they simply stretch the main application panels and are done with it.
Now, consider static elements, like a 150x50 button that says 'Click me'. This button is not intended to become bigger and is perfectly acceptable on a regular 1440x900 display. Now the retina screen comes in with its 2580x1800 resolution. The app sees the resolution change but it thinks "Hey, that user must have a huge screen" so it keeps the button the same size.
The problem that now occurs is that the button, because both resolutions apply to the same 13" screen, is now appearing to be a fraction of the size of the original button. Depending on your user vision, he might not be able to read the text on it, and might have a hard time clicking it, depending on the mouse settings.
To fix that problem, Apple and Microsoft used two different solutions:
Microsoft decided to tell the app the display had a 2580x1800 resolutions, but that the user wanted to have everything scaled to 200 dpi. This means that, if an app does not follow the guidelines, it will look smaller. Many apps simply ignore the DPI settings (though this might change with Windows 8);
Apple decided to report to apps that the resolution of the monitor was 1440x900, but that it could display higher-resolution elements if asked to; This means that apps existing before the new retina settings will appear to be the same size as before for the end-user (with added benefits like crisper text if they use the default Apple APIs), but that they can decide to provide high-DPI images that will look much better on the display.
Both solutions requires apps to be aware that the display is high-DPI ('retina'), but the way Apple handled it means the static websites and apps mentioned earlier will keep looking just fine, except they wont have super-crisp, high-resolution images to use. And, to opt-in to the retina features, they have to provide 200x200 images for a 100x100 canvas, for example, and Apple will take care of the rest.