In this article I would like to share my observations and experience in building applications for the Android platform. How to save time in the future.
Layouts
I think every novice programmer for the Android platform, immediately notices, in order to build a UI, you need to create an xml file in the / res / layout project directory, and then miraculously link it with Java code. At first, this seems to be a peculiar method, and immediately there is a feeling that something is missing, and the UI designer in the Android plug-in for IDE is far from a miracle. Well, enough talk, to the point!
If you do not go deep into the variety of devices on the market, which in my case turned out to be, there is a version of Android platform, we know the screen size of the target device. Suppose you have the same situation.
In general, you have to have two folders / res / layout and / res / layout-land. Here, -land acts as a qualifier, which means that any layout in this folder is only available for Landscape (horizontal) mode. If there is a layout that looks the same for both modes, vertical and horizontal, then it is placed in / res / layout. Android independently causes the Destructor of the Activity and creates a new Activity when the screen is rotated, unless a specific orientation is specified in AndroidManifest. Thus, you can place a layout with the same name in both / res / layout and / res / layout-land folders, and Android will take care of loading the current layout.
')
In the Activity code, as usual, is called
setContentView(R.layout.[ layout]);
What from me? And it is true that he described in short what can be found on the net anyway. The fact is that I had to write a very graphically modified application. Most of the elements have been greatly modified. The first thing that came to mind was wrong. I decided to write my own child component, from the same ListView, for example, and it started there: onDraw, dispatchDraw, etc. So it seemed to me a little, I also entered specific values ​​in pixels when drawing any element.
This is how not to do it. Even if there is no way out, try to the last not to create the component, but to wriggle out with layouts. It is much better to write a BaseAdapter for a ListView, for example, where to load another layout and control it. If there is no output, then all values ​​for UI in pixels should be transferred to the component properties (attrs), which will be transmitted when describing the component in xml. The values ​​themselves in xml, just do not point to a straight line, but use dimensions, links.
Let's look at what I mean by attrs and dimensions.
Attrs
Android provides an implicit way to extend your non-standard components with additional properties. You will need to create an attrs.xml file in / res / values. It is likely that you can call this file any differently, but I consider this name a standard.
The content of attrs.xml is readily accessible by human. Let's look at a simple example:
<?xml version="1.0" encoding="utf-8" ?> <resources> <declare-styleable name="MyExampleView"> <attr name="exampleAttrWidth" format="dimension" /> </declare-styleable> </resources>
Resources is constantly encountered, used to store any resources, and subsequently available in Java code through the static class R of an application package. For example, our declaration is available through R.styleable.MyExampleView. According to my observations and the fact that I had to use, there is such a format list (property type):
- dimension - can be a value of type 10px, 10dip or a reference to dimen / [value name]
- integer - may be a value of type 10, 5, 2. I also think that the link may work
- string - just a text value of the “Hello World” type or a link to the string / [value name]
- reference - reference to @drawable for example, which in turn can be @drawable, color or something else
Suppose we have our own class, derived from View: com.android.example.view.MyExampleView. We describe it simply:
package com.android.example.view;
Thus, we have created our own control that can be configured directly from xml, and this method is very flexible, because There is no binding to specific values ​​in the code, except for the default. To create an element, write in the layout:
<com.android.example.view.MyExampleView example:exampleWidth="@dimen/exampleWidth" />
Dimensions
In an ideal world, all values ​​should be put into /res/values/dimensions.xml in the format: [value] dp, then used in xml or code via a reference to
dimen / [name]. I advise, as I am doing at the moment, to make the size of the text, the main elements of the application, for example the offset of some panels, default padding / margin, etc. Do not make values ​​for any specific elements, for example in one dialog box from buttons at a distance of 10 pixels.
This approach will help to be sure that in the application all text looks standardized, for example, large headings are 30 pixels, medium ones are 24, and plain text is 16. If you don’t like it, change it only in one place.
In principle, this is not worth dwelling on, but there is one thing. Recently, Google updated the Android plugin for Eclipse, respectively, and now there is such a beast Lint. So, he winked at me all the time and convinced me that I should use dp, not px, and also painted for some other reason. I believed, did. And now let's remember Density. As far as I understand, this value shows how densely the pixels are located towards each other. Those. For example, you have a device in 800x600 resolution. But the fact is that one device has 800 * 600 pixels, in the other 2 * 800 * 2 * 600. I think you caught a difference? Those. The resolution is one, but the quality and density of pixels is completely different. And this is exactly where the Lint trick lies. After migrating to a device with a higher density, using dp, I had all the elements gone, and the text became completely different sizes (at a glance).
As it turned out, if I had used px from the very beginning everywhere and ignored Lint warnings, I would not spend extra time rewriting dp on px.
Colors
Colors in Android can also (should) be presented in xml in the following formats: argb, rgb. For example, white color:
- rgb = #fff. This is not # 0f0f0f or # f0f0f0 - this is a short form, we end up with an opaque white color #ffffffff
- argb = #ffff. Similar to the previous one, only including the alpha component
- rgb = #ffffff. Full rgb form
- argb = #ffffffff. Full form argb
In principle, it is very similar to the rules rules, usually located in /res/values/colors.xml, also in the resources tag. Bringing in colors is worth the colors that are used to standardize the full UI, and not any small details of one of the elements. So say golden serdina between paranoia and laziness.
I hope someone these notes will save time or help in something more deeply understood.
UPD:Thank you
sdfsdhgjkbmnmxc and
andreich for pointing out errors in the text.