Android screen adaptation

1. How to adapt an application to a different phone, although this is not a technical problem, but for the developers who just do the screen, it is really not a simple thing.

First: You need toandroidmanifest.xml file <manifest>

<android:largescreens= "true"       android:normalscreens= "true"  android:anydensity= "true"       android:smallscreens= "true"> </supports-screens>

As the name implies, the above is a multi-resolution support for our screen (more accurately, the density of large, medium and small three). android:anydensity="True" , This sentence is very important to the entire screen, the value is true, our application when installed on a different density of mobile phones, the program will load the hdpi separately, The resources in the Mdpi,ldpi folder.

Conversely, if the value is set to False, even if we have the same resource under the Hdpi,mdpi,ldpi folder, then the application will not automatically go to the appropriate folder to find resources, this is in high-density, and low-density mobile phones, such as a 240x320 pixel cell phone, If you set android:anydensity="false",the Android system will convert the x 320 (low density) to 320x480 (medium density), so The app loads the resources in the mdpi file on the small-density phone.

2. Careful people will find that since android2.0 started drawable files are replaced by three folders drawable-hdpi,drawable-mdpi,drawable-ldpi three folders, Some programmers in order to let the application load some images by default, they will deliberately go in the application after android2.0 to recreate the drawable folder, in fact, it is not necessary to do this, through the first paragraph of the analysis we know, android:anydensity= "false" , the application will convert the size density to medium density to load the resources in the MDPI. Here again, when android:anydensity="false", the app will load the resources in the MDPI.

To summarize:

First: android:anydensity="true", the system will automatically find the corresponding folder according to the screen density

Second: android:anydensity="false",

(1) if the drawable-hdpi,drawable-mdpi,drawable-ldpi three folders have different density of the same picture resource, then the system will load the resources in the Drawable_mdpi folder.

(2) If there is a high density image in the drawable-hpdi, the other two folders do not have the corresponding picture resources, then the system will load the resources in the drawable-hdpi.

(3) If there is a picture resource in the drawable-hdpi,drawable-mdpi, there is no corresponding picture resource in the drawable-ldpi, then the system will load the resources in the Drawable-mdpi folder.

3. Note the different representations of the various folders.

DRAWABLE-HDPI the picture is applied to the horizontal screen, also for the vertical screen

DRAWABLE-LAND-HDPI, when the screen is horizontal and high density, load the resources in this folder

DRAWABLE-PORT-HDPI, when the screen is vertical and high density, the resources in this folder are loaded

4. Sometimes it is necessary to dynamically set a value in the code, such as a map, the map's pin and the map's address cue box relative offsets are different on different densities of mobile phones. In this way, the screen density can be calculated by:

Displaymetrics metric = new Displaymetrics ();

Getwindowmanager (). Getdefaultdisplay (). Getmetrics (Metric);

int densitydpi = metric.densitydpi; Screen density dpi (120/160/240)

You can then set the cost for these densities separately in your code.

But this method is best not to use, the best way is in the XML file different density of the phone to set separately.

The offset of the map here can be set in the Dimens.xml file in the values-hpdi,values-mdpi,values-ldpi three folder

It is worth mentioning that:

<dimen name="Bitmap_common_topoffset">40dp</dimen>

<dimen name="Bitmap_common_bottomoffset">-14dp</dimen>

The negative number here is completely functional, and the system thinks it's a negative value.

　　5. Major mobile phone manufacturers have more or less changes to the Android operating system, of course, these changes will have some impact on our application

Like what:

(1) System source code in the Connection music service Aidl file package name: Com.android.music

(2) LG may change the package of the Aidl file (e.g. fix to Com.android.music.player), and modify the contents of the file (add a method, or reduce a few methods, or modify the method name) then our application to be published on LG's mobile phone, then we have to change the Aidl file to be connected, Must be exactly the same as the LG manufacturer's modifications.

6. Internationalization issues.

Sometimes the appropriate language is set in XML, but why does the UI display still not work after we change the language?

Don't suspect that the system is out of the question, which is related to how we refer to strings in Values/string.xml in code.

The wrong way:

1. Declare global variables private static String tempstr;

2. Assign a value TempStr = context.getstring (r.string.test) to the variable in the OnCreate method;

3. Reference the variable in a method that updates the UI (non-OnCreate method). Textview.settext (TEMPSTR);

The reason is that OnCreate will not be executed again when the local language is modified. The variable tempstr will still use the default English loaded when the page was first started.

The right way:

Proceed directly to step three: Textview.settext (context.getstring (r.string.test));