In the new modern mobile technology smartphone is present everywhere. We know that these smartphones also support various types of programs like video capturing, movie playing, game playing, data and information writing as well as other types of information storage via different types of support systems. In these circumstances, it is very much necessary to have good screen size and excellent screen resolution. Otherwise it is too much difficult for users to operate their Jobs and manipulate their work.
For the first year or so since Android 1.0 was released, all production of the Android devices had the same screen resolution HVGA (High Video Graphics Array), 320 by 480 and also the size of the screen was around 3.5 inches, or 9 centimeters diagonally. The Size and the resolution has changed a lot from the starting of the fall of 2009, though, the devices have been arriving with commonly contrasting screen sizes and resolutions, from tiny QVGA 240 by 320 screens to the much larger WVGA 480 by 800 screens. Actually this screen size is dependent on the resolution, so our focus will always be on the screen size and the DPI.
It is sure that the mobile users will be expecting that our application to be well-designed on all of these screens as well as it should support good quality display, and possibly take advantage of the larger screen sizes to add superior value. Now it is observed that the Android 1.6 added new capabilities to help the enhanced support for different screen sizes and resolutions.
Actually the Android documentation has extensive coverage of the mechanics of handling multiple screen sizes. We are stimulated to read that information along with this Article, to get the best understanding and knowledge of how to cope with, and possibly take advantage of the multiple screen sizes.
After discussing the screen size options and principles, we will try to wrap up with an in-depth look at making a fairly simple application that can handle multiple screen sizes.
If our application is compiled for Android 1.5 or lower version, then Android will assume that our application was designed to look good on the standard screen size and resolution presentation. If our application is installed on the device with a larger screen format, then Android automatically will run our application in compatibility mode process, and do the scaling based on the actual screen size.
As per the illustration, assume that we have a 24-pixel square PNG (Portable Network Graphics) file, and the Android is installed and also runs our application on a device with the standard physical size of the screen but with a WVGA (Wide Video Graphics Array) resolution that is generally called high-density screen. The Android might scale our PNG file to be 36 pixels. For that circumstances it will take up the same visible space on the screen. On the other hand, Android can also handle this system automatically. But the disadvantage is that the bitmap-scaling algorithms tend to make the images a bit incoherent.
Additionally, the Android will block our application from running on the devices with a smaller screen size. From this time onward, the QVGA (Quarter Video Graphics Array) devices, like the HTC Tattoo, will not be able to get our application, though we know that it is available on the Android Market. When our application is compiled for Android 1.6 or higher version, then Android will assume that it can handle or control all screen sizes, and consequently it will not run our application in compatibility mode.
Screen Support Overview: In this section we will discuss the concepts and terms used to support different screens on android devices. The APIs are also important to understand before we go for any implementation. I will discuss the terms and concepts in tabular format to make it concise and understandable.
Screen size can be defined as the actual physical size of the device screen measured diagonally. To make the concept simple, Android makes a group for all the actual screen sizes into four general categories. These categories are 'small', 'normal', 'large' and 'extra large'. These sizes cover all the android devices starting from mobile phones to tablets and many more.
The concept of screen density is similar to any other density calculation. Screen density on android devices can be defined as the total number of pixels per unit of physical area/screen. This is defined as dpi (knows as dots per inch).For example, a low density screen can be defined as a screen which is having fewer number of pixels per unit of actual physical area/screen. The clarity of the screen display depends upon the screen density. If the screen density increases, the clarity increases.That are why, the high screen density has better quality display compared to the medium or low density screens. To make the grouping simple, Android has made four general categories covering all the densities. These groups are 'low', 'medium', 'high' and 'extra high'.
The orientation of an android device can be defined as the viewing position of the device with respect to the viewer. The orientation can be either portrait or landscape. This can be more clearly defined as the aspect ratio of the screen which is either wide or tall. The user can rotate the android device in different orientation for better viewing. The wide or tall view adjusts all other aspects automatically. The devices are designed in a way so that they can adjust the rotation by default. The orientation changes at run time as per the movement of the device.
Screen resolution can be defined as the total number of physical pixels actually present on an android device screen. But we must remember that the android applications do not have direct control on the screen resolution feature. On the other hand, applications are only concerned with screen size and density features. The android group has already defined the generalized size and density features, so the application developers should concentrate on it.
Density independent pixel(dp)
Density independent pixel can be defined as a virtual pixel unit used during the definition of user interface layout. This is used to define the dimensions of the layout or positions in a way which is not dependent on the density. To quantify density independent pixel, it can be defined as one physical pixel on a screen having 160 dpi. This is assumed as the baseline density for a 'medium' density screen. During runtime, the android system transparently handles the scaling issues of the dp units as per the requirement and also based on the actual density of the device screen. Let us check the conversion of dp units with screen pixels. The formula is px=dp*(dpi/160). It is always recommended to use dp units when designing application user interface. It ensures correct display of your user interface on different screens with different densities.
Table 1: Showing terms and their meaning
Supported Screen Ranges: From Android 1.6 (which is API level 4) onward, android provides support for multiple screen densities and sizes. This represents various screen configurations available in modern Android devices .Users can adjust applications user interface by using different features available in Android systems. This adjustment ensures proper rendering of your application based on various devices. It also ensures best of its class user experience on each android device screens. To make it simple for designing your applications user interface, android has divided the actual screen sizes in the following categories.
Four generalized set of sizes: These generalized set includes the following
Four generalized set of densities: These generalized set includes the following
- ldpi (low)
- mdpi (medium)
- hdpi (high)
- xhdpi (extra high)
These generalized sizes and densities are categorized based on some standard value. These standard values are known as the baseline configurations. The baseline values for these generalized sizes and densities are 'normal size' and 'medium density' (also known as mdpi).The baseline has been defined based on the screen configuration of the first device powered by android. It is important to remember that each category of generalized sizes and density covers a range of actual screen sizes and densities. For example, if two different devices report normal screen size, then also the actual screen size and aspect ratio might vary slightly when measured by hand. In a similar way if we consider screen density, then also two devices reporting screen density of mdpi can have actual pixel density slightly different. But these are always kept as abstract by the android system. Developers are always encouraged to use generalized sizes and densities during UI design and the rest is handled by the system. So the system is finally responsible for small adjustments required by the device.
Actual designs of screens are difficult as the size varies from one device to another. To design user interfaces for different screen sizes, there should be some minimum amount of space available. As a result, android system has defined a set of associated minimum resolutions for each set of generalized screen sizes. These minimum size ranges are in 'dp' units. So the developers should use the same unit while defining the layouts. It also helps to avoid changes in screen density. Following are the minimum size rages defined by the android system.
- Small screen: The small screen size should be at least 426dp x 320dp
- Normal screen: The normal screen size should be at least 470dp x 320dp
- Large screen: The large screen size should be at least 640dp x 480dp
- Extra large screen: The extra large screen size should be at least 960dp x 720dp
Please remember that the minimum screen sizes were not properly defined before android version 3.0.So there is a possibility that some of the old devices are not satisfying the size ranges defined above. There will be some conflict in size ranges defined between normal and large (as described above).This is also true for physical resolution of these screens. As a result, the minimum space available can be a bit less than the defined size. But it does not have much impact on the overall display. Please remember that the characteristics defined for generalized screen size and density are independent from each other. For example, a high density screen can be considered to have a normal screen size. Similarly, a medium density screen can have large screen size.
The alternate resources are very important for optimizing applications user interface. These resources help the developers to optimize both screen sizes and densities. To make it simple, developers can provide alternate layouts for covering some of the screen sizes which might have impact on the display. Similarly, developers can also provide alternate screen densities to cover some of the devices. But it is always recommended not to provide alternate screen and density for each and every combination of screen size and density. The modern system provides enough compatibility features to support rendering adjustments on different screen sizes and density. And the developers should implement proper techniques which can allow resizing the application UI smoothly.
Now we will discuss various aspects of handling different screen sizes on Android Device.
Actually the simplest approach to handle multiple screen sizes in the Android Device is to design our UIs (User Interfaces) in a way so that they can automatically scale for the screen size, without any size-specific code or the resources work. This indicates that everything that we use in our Users Interface can be charmingly scaled by the Android Device and everything will fit on the screen accurately, even on a QVGA screen.
Think About Rules, Rather Than Positions: It is important to know that the rules of the screen adjustment are not about the position. Because we have found that first and foremost thing is the position of the widgets not about the rules or protocol. It is also important to have particular widgets of certain fixed sizes at the specified fixed locations of the system.
As an alternative of thinking about the positions of the mobile device screen, think about the rules or the main protocol. At first we need to teach Android from the business rules about where widgets should be sized and placed, and then Android will interpret those rules based on the device’s screen which actually supports in terms of the resolution of the screen.
Actually the simplest rules are the fill_parent and wrap_content values for the android: layout_width and android: layout_height. That does not specify the explicit sizes, but rather adapt to the space available. The richest environment for easily specifying the rules are to use RelativeLayout model. While it is complicated on the surface side, but RelativeLayout does an excellent job of letting us control our layout while still adapting to other screen sizes.
For illustration, we can do the following:
- Actually place the explicitly anchor widgets to the bottom or right side of the screen, rather than expecting them to wind up automatically on other layout also.
- The control of the distances between the widgets that are connected to a label for a field should be to the left of the field without depending on the padding or margins of the system.
This is also very important for us that the greatest control for specifying rules is to create your own layout class. As per the illustration, suppose we are creating a series of applications that implement card games. We may want to have a layout class that actually knows about playing cards and also think about how they overlap with each other, which are face up versus the face down, as well as big to be to handle varying number of cards, and so on.
We could achieve the desired look with the way that we are generally called a RelativeLayout, we may be better served implementing a PlayingCardLayout or something that is more explicitly tailored for our application.
Consider Physical Dimensions: Android screen resolution considers the physical dimension of the system. So, Android offers a wide range of available units of measure for dimensions. Actually the most popular is the pixel (px- pixel is the smaller dot in the screen), because it is easy to bind our head around the concept or the theory. After all, each Android device will have a screen with a certain number of pixels in the each direction.
Nevertheless, the pixels start to become troublesome as screen density changes. We know that the number of pixels determines the quality of image or display. As the number of pixels in a given screen size increases, the pixels effectively contract or pact. A 32-pixel icon on a traditional Android device might be finger-friendly (as it is mostly work through touch screen supported device so it is very much important to develop the software both user friendly as well as very much finger-friendly). But on the other hand, on a high-density device that is WVGA in a mobile phone, there 32 pixels may be a bit small for use with a finger. If we have something essentially scalable like a Button where we can specify the size in pixels, we might contemplate by transferring to millimeters (mm) or inches (in) as the unit of measure is like 10 millimeters etc. In this specific way we can ensure that our widget is sized to be finger-friendly and user friendly regardless of the number of pixels used.
Avoid the Concept of Real Pixels: Pixel is very important but in some cases it should be avoided. In some circumstances, using millimeters for the dimensions will not make sense. Then we may wish to consider using other units of measure while still avoiding real pixels.
Simple Math: If we are to determine a specimen, on a 240-dpi device illustrated as a phone-sized WVGA device, then the ratio is 2:3, so 50 dip = 50px at 160 dpi = 75px at 240 dpi.
Now the advantage of going with Dots per Inch is that the actual size of the dimension stays in the same manner, so visibly there is no difference between 50dip at 160 dpi and 50dip at 240 dpi. Android also offers the dimensions measured in scaled pixels (sp).
Choose Scalable Drawables Actions: Now we are working with the Scalable and Draw- able actions, actually the Classic bitmaps—PNG (Portable Network Graphics), JPG (Joint Picture Group), and GIF (Graphics Interlay Format)—are not fundamentally scalable. If we are not running in the compatibility mode, The Android will not even try to scale them for us based on the screen resolution and the size. There are different ways to address this, like try to avoid static bitmaps, using nine-patch bitmaps and XML-defined to drawables as like a GradientDrawable as an alternative way of the format. A nine-patch bitmap is a PNG file specially encoded to have a rules indicating that the image can be stretched to take up more area. The XML is defined to use a quasi-SVG (Scalable Vector Graphics), shapes, their strokes and the fills, and also the other systems of the Screen.
Tailor-Made Processing: There will be times where we want for different looks or behaviors based on the screen size or the density of the image. Actually Android has facilities to switch out resources or code blocks based on the environment where our application can run. Achieving the screen size and the density-independence is eminently possible, at least for devices running Android 1.6 and newer.
The first step to proactively support screen sizes is to add the element to our AndroidManifest.xml file. This specifies which screen sizes we explicitly (indirectly) support and which we do not. Those which we do not maintain explicitly will be handled by the automatic compatibility mode described in the previously version.
Here is a manifest containing a element:
Listing 1: Sample showing manifest file
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.commonsware.android.sgc" android:versionCode="1" android:versionName="1.0"> <supports-screens android:largeScreens="true" android:normalScreens="true" android:smallScreens="true" android:anyDensity="true"/>
This is the manifest code which is used for determining the large screen, normal screen, small screen. If we set it to true then all the positions will be standard. Here in this code we have made all the option values to ‘true’.
Listing 2: Sample showing action and category
<application android:label="@string/app_name" android:icon="@drawable/cw"> <activity android:name=".sgc" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> </manifest>
This above manifest part is to generate the name of the package and it works with the Launch button that we have discussed bellow.
Each of the attributes of the program android: smallScreens, android: normalScreens, and android: largeScreens takes a Boolean (TRUE/FALSE) value indicating if our application explicitly (indirectly) supports those types of the screens (true) or requires compatibility mode assistance (false).
The android: anyDensity attribute specifies whether we are taking density into account in our calculations (true) or not (false). If we say false, then Android will behave as though all of our dimensions (as like 4px) were for a normal-density 160-dpi (Dot per Inch) screen. If our application is running on a screen with lower or higher density, Android will scale our dimensions according to the size. On the other hand, we can also indicate that android:anyDensity = "true", here we are telling Android not to do that, putting the responsibility on us to use density-independent units, such as Dot Per Inch, Millimeter, or Inch.
Density-Based Sets of the Image: Density is the major part of the screen size. If we wish to have different layouts, as well as dimensions, or like based on different screen densities, we can use the -ldpi, -mdpi, and -hdpi resource set labels. For illustration, res/values-hdpi/dimens.xml would contain dimensions used in high-density devices.
Size-Based Sets of the Image: if we wish to have different resource sets based on screen size, Android offers -small, -normal, and -large resource set labels.
After creating res/layout-large-land/would indicates layouts to use on large screens as per illustration we can say WVGA in the landscape orientation system.
Version-Based Sets of the Image: There may be times when the earlier versions of the Android get confused by newer resource set of the labels. Using the system we can include a version label to our resource set, of the form -vN, where N is an Application Programming Interface level. Here the res/drawable-large-v4/ indicates these drawables should be used on large screens at an Application Programming Interface level 4 (Android 1.6) and newer.
The Android has the ability to filter on version from early and so on, and also this technique will work going back to Android 1.5 (and perhaps earlier). So, if we find that Android 1.5 emulators or devices are gripping the wrong resource sets, consider adding -v4 to their resource set names to filter them out.
Adjusting the Density Process: Adjust density is another important part of the screen size, When we are working in the density system then we first think about the adjustment of the density, because without the adjustment of the density it is too much complicated job for working with standard size. The emulator will keep the pixel count accurate at the expense of density. We do have an option of keeping the density accurate at the expense of pixel count.
The easiest way to do this is to use the Android AVD (Android Virtual Device) Manager, introduced in Android 1.6. The Android 2.0 edition of this tool has a Launch Options dialog that pops up when we go to start an emulator instance via the Start button, as shown in Figure.
Figure1: Showing skin and density settings
Figure2: Showing screen size and dpi settings
Figure 3: Showing launch button to activate the new setting
When the user clicks on the Launch Button the Launch Options dialog will be appear and the following operations are performed.
By default, the Scale display to real size check box is set to unchecked, and the Android will open the emulator window in normal process. We can check that this check box, and then provide two bits of the scaling information format:
- The screen size of the device that we wish to emulate, in inches like 3.7 for the Motorola DROID.
- The dots-per-inch (DPI) resolution of our monitor screen.
- This will provide us an emulator window that more perfectly illustrates how our User Interface will look like on a physical device format, at least in terms of sizes.
- Conversely, since this emulator is using far fewer pixels than on an actual device, fonts may be difficult to read, images may be blocky, and so forth.
In modern mobility world smart phones are used widely. We generally use smart phones for multiple purposes according to our job requirement. For that reason, if our system is user friendly and also works with various screen formats, then it will be very easy to operate the system. In the above discussion, we have tried to deliver all types of possible ways and information about various screens Sizes. We have also covered the screen density, screen resolution as per the Technology of the Dot per Inch method.