Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
According to this
there are four size screens, small, normal, large and xlarge. So these qualifiers correspond on specific screens. For example, normal qualifier is a 3.7inches screen and small is a 2.7inches screen. So, what happens with the others sizes? How does my app cover other sizes, like 3.3inches or 3.2inches for example?
The screen sizes you mentioned are meant to be ranges. For instance, a 3.3 inch screen would probably fall into the ‘normal’ category , as it is bigger than the 2.7, but less than 3.7. now that said, there are some minor changes in terms of pixel density and that kind of thing, but the idea behind the screen sizes they chose is that there isn’t a whole lot of difference between a 3.2 inch screen and a 3.3 inch screen, so if you write your layout properly (using relative widths, etc.) then your app should look the same whether you are on a 3.2 or 3.3. The reason they add in all those sizes for the SDK is that you might want to have more information shown or have things laid out differently if your consumer is using a really small screen vs a really large one (like a tablet). For the most part, however, relative layouts are king – don’t use hard coded pixel values for sizing of view elements if you can avoid it, and keep your layout fluid – that way all screen sizes can be supported with minimal work and testing on your part.