Start from scratch-go deep into Android (practice-let's start writing code-Beginner's Guide-5. Support for different Android devices)

Chapter 1 support different Android devices

Android devices from around the world have many shapes and sizes on the External table. If you are compatible with different devices, you will obtain a large number of potential users for your app. To make your app as successful as possible on Android devices, you need to adapt to the configuration of various devices. Important changes to these devices are the language, screen size, and system version. For app adaptation on Android, we have talked about basic theories in the first article, and we have practiced the support of different languages in Chapter 3 "Guide" Hello, localization. In the future, I will continue to explore Android adaptation as appropriate. Remember that if you want to learn more about it, it will not be done in 1 or 2 articles. You need to practice and think, so I will step by step, without worrying about it. The content of this chapter is a simple and fast practice article, which allows you to practice the first article we have learned. Next, let's take a look at the Content preview in this chapter:

1. Support for different languages

2. Support for different screens

3. Support for different system versions

5.1 support different languages

It is a good practice to extract the UI string from your application and put it into an external file. We can easily do this in Android. When we use eclipse to create an android project, the tool will automatically generate the Res/values/strings. xml file. It is the main character of this section.

5.1.1Create local directory and string File

In the "Hello, localization" chapter, we are not only processing languages but also processing regions. Of course, in this section, we only Process Languages. The processing regions are related to "drawable, now let's follow the IOS639-1 standard to create a suffix folder for values, such as values-es, that represents a local language environment that uses the language code for ES (Spain, at runtime, Android loads the appropriate resources based on the local settings of your device. If your application supports several languages, you can create a folder. For example, if we need to support Spanish, French, and English (default), the following should be shown:

Myproject/

Res/

Values/

Strings. xml

Values-ES/

Strings. xml

Values-fr/

Strings. xml

This means that when the language in your device is set to French or Spanish, their language will be displayed accordingly. If your device uses Chinese, it is not supported here, the default English is used. The code in the three files is as follows:

English (default language environment),/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">Ma Application</string>    <string name="hello_world">Bonjour tout le Monde!</string></resources>

 

5.1.2Use string Resources

You can reference your string resources in your source code based on the name attribute of the <string> element you have defined. The language used in the source code is R. String. string_name. There are several methods to obtain strings in string. xml. As shown in code list 5-1.

// Use the following code in the activity to obtain the string resource string Hello = getresources (). getstring (R. string. hello_world); // Our textview needs to use this string resource to display text, so we can also directly use R. string. hello_world textview = new textview (this); textview. settext (R. string. hello_world );

 

Code List 5-1

If our textview is not the layout generated by code, but has been placed in the XML in the layout, we can use it like the code list 5-2.

<TextView    android:layout_width="wrap_content"    android:layout_height="wrap_content"    android:text="@string/hello_world" />   

 

Code List 5-2

5.2 supports different screens

Android devices use two parameters for screen differentiation: size and density. You should think that your app will be installed on screen devices of different sizes and density, so we should include some alternative resources to optimize the appearance of different screen programs. Next we will review the size and density of our screens.

Size: Mall, normal, large, xlarge

Density: low (ldpi), medium (mdpi), high (hdpi), extra high (xhdpi)

We have talked about the data Scope of these names before. This is not a popular topic. To use corresponding la S and bitmaps for different screens, you need to add resources in different directories, similar to strings in different languages. In addition, the screen direction (horizontal and vertical screen switching) is also a factor to consider when the screen size changes, therefore, many applications need to adjust the layout or use the new layout to optimize the user experience during horizontal and vertical screen switching.

5.2.1Create different la s

To optimize your user experience in different screen sizes, you can create a unique layout XML file for each screen size you want to support. Each layout is saved in the appropriate resource directory and named after "-<screen size>. For example, a layout specially designed for the large screen should be saved under Res/Layout-large. To properly adapt to the screen, Android automatically scales your layout. Therefore, we do not need to worry about the absolute size of layout elements in different screen sizes, but focus on the layout structure that affects user experience. For example, the following project contains a default layout and a selectable large screen layout.

Myproject/

Res/

Layout/

Main. xml

Layout-large/

Main. xml

The file names must be the same, but the file content can be different. The methods used in our code have not changed at all, just like in the following code list 5-3:

@Override protected void onCreate(Bundle savedInstanceState) {     super.onCreate(savedInstanceState);     setContentView(R.layout.main);}

 

Code List 5-3

The system loads the layout file from the appropriate layout directory based on the screen size of the running device. The following example shows how to support horizontal layout:

Myproject/

Res/

Layout/

Main. xml

Layout-land/

Main. xml

The default layout is used for Portrait screens. Therefore, the layout is supported. If you want to support multiple screens at the same time, you can refer to the following content:

Myproject/

Res/

Layout/# default portrait screen (portrait)

Main. xml

Layout-land/# landscape screen (landscape)

Main. xml

Layout-large/# large (portrait)

Main. xml

Layout-large-land/# large (landscape)

Main. xml

Note: android3.2 and later versions support more advanced screen sizes, allowing you to specify resources based on dip with the minimum width and minimum height. In the first article, we briefly introduced this new technology. We will explain it later. This chapter is a beginner's guide for simplicity and does not include this new technology.

5.2.2Create different bitmap

You should always provide resources for correct bitmap scaling. Remember! Is for each density: low, medium, high, extra-high. This can help you achieve good graphic quality and performance at all screen density. You can start to use a vector graph for each density as the original resource. Or you can use a vector graph directly. Do not use a bitmap where a vector graph can be used in Android. Let's take a look at the density conversion. I have already stressed this in the first article:

Xhdpi: 2.0

Hdpi: 1, 1.5

Mdpi: 1.0 (baseline)

Ldpi: 0.75

If the image is 150x150 Px in xhdpi, the other density is 100x100 (hdpi), x (mdpi), and 75x75 (ldpi ). Here, please take a moment to think about how to come. The following shows the directory structure:

Myproject/

Res/

Drawable-xhdpi/

Lam.png

Drawable-hdpi/

Lam.png

Drawable-mdpi/

Lam.png

Drawable-ldpi/

Lam.png

Usage: R. drawable. lam in the @ drawable/LAM code in XML. Although theoretically we need to support all density, we do not need to consider ldpi and xhdpi because hdpi and ldpi are integers. The relationship between xhdpi and mdpi is also an integer multiple, so we only support mdpi and hdpi.

5.3 support different system versions

Although the Android system is updated quickly and we may want to use the new version of the API, we should continue to support the old version of Android so that our applications can be used on more devices, this section will show you how to use the new API in a lower-version system. To provide the best functions and functions across multiple Android versions, we should use the android support library in our application (the next one describes its purpose ), it allows you to use APIs of earlier versions of the latest platform.

5.3.1Specify the lowest and target API levels

The androidmanifest. xml file describes the details about supported system versions. Specifically, the attributes mainsdkversion and targetsdkversion are marked with the lowest API level and highest API level in the uses-SDK node. For example, the following code list is 5-4:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" ... >    <uses-sdk android:minSdkVersion="4" android:targetSdkVersion="15" />    ...</manifest>

 

Code List 5-4

The targetsdkversion attribute may not be used by many people. Due to the release of the new Android version, some styles and behaviors may change. In order to allow your application to take advantage of these changes, make sure that your application suits the device style of each user. You should set the thetargetsdkversion value to match the latest Android version.

5.3.2Check the system version at runtime

Android provides a unique code for each system version, which is used as a constant in the build class. In the app, you can use these constants to determine whether the running system version meets your requirements, for example, in the code list 5-5, their purpose

Private void setupactionbar () {// ensure that the program runs in Honeycomb (Android 3.0) or a better system version to use actionbar APIs if (build. version. sdk_int> = build. version_codes.honeycomb) {actionbar = getactionbar (); actionbar. setdisplayhomeasupenabled (true );}}

 

Code List 5-5

When parsing XML resources, Android ignores properties not supported by the current device. Therefore, you can safely use the new XML version without worrying about the old version. For example, if you set targetsdkversion = "11", your app can use actionbar by default. To add a menu item to the action bar, you may need to set android in your menu resource XML: showasaction = "ifroom ". In a cross-version XML file, it is secure because older versions of Android simply ignore the showasaction attribute (that is, you do not need to create Res/menu-v11/separately for V11 menus /).

5.3.3Platform style and topic

Android provides the concept of theme, its appearance and feeling in the operating system. These themes can be applied to your app using the manifest file. By using these built-in styles and themes, your application uses a unified appearance style in different systems.

Make your activity look like a dialog box:

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

Make your activity have a transparent/translucent Background:

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

To apply a custom topic, you need to define the topic in/RES/values/styles. xml and then use:

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

To apply a topic to your entire application (all activities), add Android: Theme:

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

More detailed usage of styles and themes will be explained in the later frame learning.

FAQ: QQ Group 213821767