"Android App Development technology: User Interface" device adaptation

Guo Xiaoxing
Weibo: Guo Xiaoxing's Sina Weibo
Email:[email protected]
Blog: http://blog.csdn.net/allenwells
Github:https://github.com/allenwell

Because of the richness and diversity of Android platforms, Android devices around the world are available in a wide variety of sizes and sizes, and device adaptation is an important task in order to promote our applications to a wide variety of users.

A language adaptation

It is a good practice to store strings in the UI in an external file, which is extracted by code. Android can easily implement this feature through the resource catalog in the project.

To support multiple languages, create an additional values directory in res/named after the hyphen and ISO country code, such as values-es/is a directory of simple resource files for locales where the language code is "es". Android will load the appropriate resources at run time based on the device's locale settings

If you decide to support a language, you need to create a resource subdirectory and a string resource file, as shown in:

Add a string value from a different region language to the appropriate file, at run time, the Android system uses the appropriate string resource based on the current locale of the user device.

Example

Here are a few different languages that correspond to different string resource files:

English (default regional language,/values/strings.xml)

<?xml version="1.0" encoding="utf-8"?><resources>    <string name="title">My Application</string>    <string name="hello_world">Hello World!</string></resources>

Spanish (/values-es/strings.xml)

<?xml version="1.0" encoding="utf-8"?><resources>    <string name="title">Mi Aplicación</string>    <string name="hello_world">Hola Mundo!</string></resources>

French (/values-fr/strings.xml)

<?xml version="1.0" encoding="utf-8"?><resources>    <string name="title">Mon Application</string>    <string name="hello_world">Bonjour le monde !</string></resources>

Two-screen adaptation

Android classifies the device screen as two general properties: size and resolution. You should think that your app will be installed in a variety of screen size and resolution devices. In this way, your app should include some optional resources to optimize your app's appearance for different screen sizes and resolutions.

Generally speaking, there are 4 universal sizes:

• Small (small)
• General (Normal)
• Big (Large)
• Extra Large (XLarge)

and 4 different resolutions

• Low accuracy (LDPI)
• Medium accuracy (MDPI)
• High accuracy (HDPI)
• Ultra-high accuracy (XHDPI)

declaring layout and bitmap for different screens, placing these optional resources in a separate directory is similar to adapting to a different language. Also note that the orientation of the screen (landscape or portrait) is also a screen size change to consider, so many apps will modify the layout to optimize the user experience for different screen orientations.

2.1 Creating a different layout

To optimize the user experience for different screens, you need to create a unique XML file for each screen size that will be supported. Each layout needs to be saved in the appropriate resource directory, and the directory is named after the suffix. For example, for a large screen (large screens), a unique layout file should be saved in res/layout-large/. To match the appropriate screen size, Android will automatically measure your layout file. So instead of worrying about the size of the UI elements for different screen sizes, you should focus on the impact of the layout structure on the user experience, such as the size or location of the key view relative to the sibling view.

Android Studio is also very smart when it comes to handling the size and direction of this layout file, you simply create Layout-land, layout-large these directories, as shown here:

2.2 Creating unused Bitmap

We should provide bitmap resources for 4 Universal resolutions: Low, Medium, high, and ultra-high precision. In order to have good picture quality and effect in all screen resolutions.
To generate these images, you need to start with the original vector image resources and then generate images of various densities based on the following size scales.

• xhdpi:2.0
• hdpi:1.5
• mdpi:1.0 (Benchmark)
• ldpi:0.75

That is, if you generate a 200x200 image for a xhdpi device, the same you should generate 150x150 for hdpi, mdpi for 100x100, and a picture resource for ldpi to generate 75x75.

At any time, when you reference @drawable/awesomeimage, the system chooses the appropriate bitmap based on the resolution of the screen. In addition, low-density (ldpi) resources are not necessary, and when you provide HDPI images, the system will reduce the hdpi image proportionally by half, to fit the ldpi screen.

Three-system adaptation

The new Android version will provide you with a great APIs for your app, but your app should still support older versions of Android until more devices are upgraded to the new version.

Platform versions's Control panel is updated periodically to show the distribution of Android devices running each version by counting the number of devices accessing the Google Play store. In general, when updating your app to the latest Android version, it's a good idea to make sure your new app supports 90% of devices.

In order to provide the best features and functionality in several Android versions, we should use the Android support Library in the app to enable your app to use the APIs of the last few platforms on the legacy platform.

3.1 Specifying the minimum and target API levels

The Androidmanifest.xml file describes the details of your app and identifies which Android versions the app supports. Specifically, the element

• Minsdkversion: Level of the least compatible API
• Targetsdkversion: The highest applicable API level (the most
  High level is required through your test)

With the release of the new version of Android, some style and behavior may change, in order to enable your app to take advantage of these changes, and to adapt to different styles of user devices, we should set the value of Targetsdkversion to match the latest available Android version.

As shown below:

<?xml version="1.0" encoding="utf-8"?><manifest xmlns:android="http://schemas.android.com/apk/res/android"    package="com.allenwells.myapplication" >    <uses-sdk         android:minSdkVersion="4"         android:targetSdkVersion="15" /></manifest>

3.2 Checking the system version at run time

Android provides a unique code for each version in the build constant class, which can be used in your app to establish conditions that ensure that code that relies on high-level APIs is only executed when those APIs are available in the current system, as follows:

privatevoidsetUpActionBar() {    // Make sure we‘re running on Honeycomb or higher to use ActionBar APIs    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {        ActionBar actionBar = getActionBar();        actionBar.setDisplayHomeAsUpEnabled(true);    }}

Also, when parsing XML resources, Android ignores XML attributes that are not supported by the current device. So you can safely use the newer version of the XML attribute without worrying about the old version of Android that crashes when it encounters this code. For example, if you set targetsdkversion= "11", your app will include Actionbar by default on Android 3.0 or higher. Then add the menu items to the Action bar, which you need to set in your menu XML resource:

android:showAsAction="ifRoom"

It is safe to do so in a cross-version XML file, because older versions of Android simply ignore the Showasaction property, and you do not need to use a separate version of the file in res/menu-v11/.

3.3 Using platform styles and themes

Android provides a user experience theme that provides the app with the look and feel of the underlying operating system. These themes can be applied to your app in the manifest file. By using built-in styles and themes, the app will naturally automatically adapt to the latest look and feel as the new version of Android is released.

Make activity look like a dialog box

<activity android:theme="@android:style/Theme.Dialog">

Make activity have a transparent background

<activity android:theme="@android:style/Theme.Translucent">

Apply a custom theme that is defined in/res/values/styles.xml:

<activity android:theme="@style/CustomTheme">

Apply a theme to the entire app (all activities) Add Android:theme attribute to Element

<application android:theme="@style/CustomTheme">

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Android App Development technology: User Interface Device adaptation