Android Training Learning notes adapted to different devices

Android is an open source operating system, and anyone in the world can customize it to suit their own activities based on this system. Such a feature of Android makes the Android world fragmented very seriously, with all sorts of Android devices too much. This brings great difficulty to app development and ensures that the app's experience on different devices is consistent and that every developer has to think about it, but it's a headache. Google also does a lot of work on this, especially in the latest Android 6.0, where multi-device support and self-adaptation have been done very well. In order for your app to take advantage of the excellent adaptive features offered by Google, you have to follow some of Google's basic guidelines. Google has given his specifications in training:
Https://developer.android.com/training/basics/supporting-devices/index.html
This specification is divided into 3 parts:

1. Support for different languages
2. Devices that support different screens
3. Devices that support different system versions

Let's take a quick look at Google's basic specifications.

1. Support for different languages

Android as a global operating system, Android will run in any country in the world, then the language used by Android users is very diverse. To support the languages of different countries, Android provides a string resource mechanism, specifically: you should be in the source directory of your project res directory (that is, your app's resource directory), a number of new directories in this format:

values-<ISO 639-1 locale codes>

Then create a new file named Strings.xml under this directory, all tags in this file start with a string, specify a name, and finally specify a corresponding value:

<stringname="app_name">HelloWorld</string>

It is to be explained here that the ISO 639-1 locale codes mentioned above is an ISO global standard for national language codes between countries, and of course Android is complying with this. An introduction to the ISO 639-1 locale codes specification can be seen on Wikipedia:
Https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
A comprehensive introduction can be viewed on the ISO website spec:
Http://www.iso.org/iso/home/standards/language_codes.htm
If your app supports multiple languages, your string resource directory might look something like this:

MyProject/    res/       values/           strings.xml       values-es/           strings.xml       values-fr/           strings.xml

This example supports the default language support (this is used by default when no supported language resources are found, usually in English), Spanish support, and French support. The following are examples of default language support:

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

This is an example of a Spanish language support:

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

This is a French support example:

<?xml version= "1.0" encoding= "Utf-8"?     <resources ;  <string  name  =< Span class= "Hljs-value" > "title" ;  Mon application</ string ;  <string  name  = "Hello_world" ;  Bonjour Le Monde! </string ;  </resources ;   

Yes, it is that simple, as long as you define a string of the same name in different languages in the strings.xml of different directories, the Android system can decide what text to display based on the language of the current system!
There are two basic ways in which we use these string resources: in Java code and in files such as XML, let's look at how to use it in Java code First:
Examples from Google

string resource from your app‘s ResourcesString hello = getResources().getString(R.stringOrstringtostringnew TextView(this);textView.setText(R.string.hello_world);

To use in an XML file:

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

2. Support for different screens

Android-based devices are so many, from small-screen smart watches to everyday-use smartphones, in smart cars from car to big screen smart TVs. The size and resolution of the screen is an issue that must be considered in our development, and as with the internationalization of language, this Google has its own specifications.
First explain the current screen size and the classification of screen clarity:
Four screen sizes: small (small), normal (medium), large (large), XLarge (Extra Large)
Five screen sharpness (fineness): Low (LDPI), Medium (MDPI), high (hdpi) height, extra high (xhdpi) superelevation, Extra extra high (xxhdpi) Extreme
Here's an additional explanation, starting with Android 3.2 (API level 13), the above 4 screen sizes are no longer recommended, instead of a new technology to manage the screen size based on the available screen widths.
In general, several of the above screen size and definition definitions are as follows:

For more information on screen size and clarity, please refer to Google's instructions:
Https://developer.android.com/guide/practices/screens_support.html
In support of screen size, there are two basic problems: first, the interface layout, but the image display size. First of all, the interface layout problem, the layout of the interface and the size of the screen is relatively large, such as a comparison of the large screen size and a small screen size is certainly different for each screen display, a larger screen can display a little more content, layout can be more free, smaller screen display less content, The layout of the interface elements will be relatively compact. As with multi-lingual support, we can also use different directories, same filenames, and different layouts to make the Android system decide the layout according to the actual situation. We can create such a directory from the layout directory in the Res directory:

layoutsize pattern>

Here the screen size pattern can be this:

空land（表示横屏）large（表示大屏）large-land（表示大屏横屏）

That means your directory might look like this:

MyProject/    res/        layout/              # default (portrait)            main.xml        layout-land/         # landscape            main.xml        layout-large/        # large (portrait)            main.xml        layout-large-land/   # large landscape            main.xml

However, as mentioned above, this technology is not needed after Android 3.2, because Android can use new technology to define screen size:
Https://developer.android.com/guide/practices/screens_support.html#DeclaringTabletLayouts
In addition to the problem of the layout of the interface, there are pictures in the app display problems. Different resolution, clarity to display the same picture will certainly be problematic, the picture will usually have a deformation problem. Similarly, we can deal with this problem in the same way as different directories and the same file name. We can create such a directory in the Res directory:

drawable-<density>

Here are some of the density mentioned above, so if your app supports a different definition of display, then your image resource directory might look like this:

MyProject/    res/        drawable-xhdpi/            awesomeimage.png        drawable-hdpi/            awesomeimage.png        drawable-mdpi/            awesomeimage.png        drawable-ldpi/            awesomeimage.png

At any time you can use this image in @drawable/awesomeimage way, the system will automatically select the corresponding image display according to the current device's sharpness. In addition, the ratio between different sharpness is this:

1. xhdpi:2.0
2. hdpi:1.5
3. mdpi:1.0 (Baseline)
4. ldpi:0.75

In other words, xhdpi is the size of the mdpi image twice times, if the size of xhdpi is 200*200, your mdpi photo is 100*100. Also note that low-definition images are not required when you set up high-definition, if the device is low-definition, Then the system will automatically scale your photos according to this scale. However, it is best to specify such a picture, otherwise the scaling process may add additional memory and CPU consumption, and the effect of scaling is not necessarily what you want most. The more important picture resources may be the app's icon design, this is the app's façade, this part of the design can refer to Google's documentation:
Https://developer.android.com/design/style/iconography.html

3. Support for different system versions

Android is a fast-evolving operating system, you can see that Google's release update is very fast, and Android is also evolving at a very fast speed. One problem with the fast version evolution is the compatibility of new and old API versions. The old version of the API may have been deprecated, the new version of the API provides a good feature but a lot of device department support. Google's recommendation is to cover at least 90% of the device users at the beginning of the app's creation, which is to determine the app's target platform and the lowest platform.
In order for our app to run properly on different versions, we need to specify the appropriate version problem in Androidmanifest. We use the label to develop the corresponding version, the currently available version is:
Minsdkversion (Minimum version)
Targetsdkversion (target version)
Maxsdkversion (maximum version)
Where we generally develop minimum and target versions, the minimum version specifies the version that your app must run, and the target version specifies the most desirable version of your app to run. This section is specified in Androidmanifest in the following way:

<uses-sdk android:minSdkVersion="integer"          android:targetSdkVersion="integer"          android:maxSdkVersion="integer" />

Each value is an int-type unsigned number, which is the Android API level. For Android API level, refer to the table below (from Google)

All we have to fill in is the number in the API level in this table. For more information, refer to:
Https://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels
For a more flexible operation, we can also determine the current version of the system at run time, in the following way:

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);    }}

The

is judged by the constant of the build class, which contains a lot of information about the current system, including CPU type, device name, manufacturer, serial number, and so on, and more information reference build API Doc:
https:// Developer.android.com/reference/android/os/build.html
Here again, when the system parses the XML resource file, Android automatically filters out unrecognized or unsupported features. For example, you use the Actionbar element in an XML file, but this element is supported by Android 3.0 or more, and if it is a device less than 3.0, it will automatically ignore this element without any errors.
In addition to the above mentioned, Android also has some content about the system version in the interface effect. For each Android version, no version will have its own style and theme, which is the style and theme. For example, the 2.3 version of the style and 4.0 of the interface style is very different, 4.0 style more fashionable, 5.0 after the style and theme has changed a lot, because the introduction of "material design", so that the interface more natural and simple. Use these built-in styles and themes to make your app appear in a different version of the system in a style that is compatible with the system version. At present, Google has customized a lot of styles and themes, you can see the full content in the following links:
Style and topics:
https://developer.android.com/guide/topics/ui/themes.html
System built-in style:
https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/res/res/ Values/styles.xml
System built-in theme:
https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/ Core/res/res/values/themes.xml
We are more familiar with:
dialog box topic:

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

Transparent background:

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

Of course, we can also imitate the above system pre-defined way, custom style and theme, the definition of content is generally written in res/values/styles.xml, here is an example:

<style name  =< Span class= "hljs-string" > "Codefont"  > <item  name  =" android:layout_width " >fill_parent</item  > <item   Name  = "android:layout_height"  >wrap_content</ item  > <item  name  = "Android:textcolor"  > #00FF00 </item>  <item  name  = "Android:typeface"  >monospace</< Span class= "Hljs-property" >item  ></style>  

Of course we can also inherit from the system's predefined style theme, using the parent keyword, such as:

<stylename="Codefont"Parent="@android: Style/textappearance.medium"> <Item name="Android:layout_width">fill_parent</Item> <Item name="Android:layout_height">wrap_content</Item> <Item name="Android:textcolor">#00FF00 </item><Item name="Android:typeface">monospace</Item> </style>

We inherited the above Codefont style from the Textappearance.medium style of the system. For more information, refer to:
Https://developer.android.com/guide/topics/ui/themes.html#DefiningStyles
The way we use themes or styles is relatively simple, if you apply a theme style to an activity:

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

If you want to apply the entire application to all the activity, you can:

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

More detailed information on style and theme, you can look at this, explained or relatively in place (in English, hehe):
Http://docs.appcelerator.com/platform/latest/#!/guide/Android_Themes

Android Training Learning notes adapted to different devices