Essential knowledge of mobile terminal development

Mobile device users more and more, the daily activation of Android phone has more than 1.3 million units, so we face the mobile Terminal WebApp also began to follow. This paper mainly introduces the relevant knowledge and experience of webapp development and debugging, and gives several optional solutions.

I. Basic concepts (1) CSS pixels and device pixels

CSS Pixels: The abstract unit used by the browser, used primarily to draw content on a Web page.

Device pixels: Displays the smallest physical unit of the screen, with each DP containing its own color and brightness.

The equivalent CSS pixels on the phone screen, which is not fixed, depending on a lot of properties. After analysis and summary, we can draw such a formula: 1 CSS pixels = (devicepixelratio) ^2 device pixels (^2 is the meaning of the square, as to what is devicepixelratio, will be explained later).

(2) ppi/dpi

The PPI, sometimes called dpi, represents the number of pixels (pixel) per inch, the higher the value, which means that the display can display the image at a higher density. (Note: The pixels here refer to device pixels.) Figuring out what the PPI means, we can easily understand how the PPI is calculated, we need to figure out the diagonal equivalent of the cell phone screen, and then we can get the PPI by the diagonal (the length of the diagonal of the phone screen, which is what we normally call screen size). Accurate calculation of the publicity can be referred to. Interestingly, the PPI for the iphone 4, based on the formula, is 330, a little higher than the official Apple announcement of 326.

Similarly, with HTC G7 as an example, the resolution of 480*800, 3.7 inches, is calculated to be 252 ppi.

(3) Density determining ratio

We calculate the PPI in order to know what density range a mobile device belongs to, because different density intervals correspond to different default scaling ratios, which is an important concept.

By the know, the PPI in the 120-160 between the cell phone is classified as low-density mobile phones, 160-240 is classified as medium density, 240-320 is classified as high density, more than 320 is classified as ultra-high density (Apple gave it an upper name--retina).

These densities correspond to a specific scaling value, and the PPI is 326 for ultra-high-density phones, as we are most familiar with iphone4 or 4s. When we write a page with a width of 320px and put it on the iphone, you'll find that it's full-width. This is because the page is magnified by default by twice times, that is, 640px, and iphone4 or 4s width, it is 640px.

The high-density category is circled because it is an Android phone statistics, in the domestic Android phone market, high-density equipment accounted for the majority of the market share, this is very important, but also we do the Android Terminal WebApp to pay attention to the key points.

(4) Use of viewport

Viewport a total of 5 properties, respectively:

<meta name= "viewport" content= "height = [pixel_value |device-height], width = [Pixel_value |device-width], INITIAL-SC Ale = float_value, Minimum-scale = float_value, Maximum-scale = Float_value, user-scalable =[yes | no], TARGET-DENSITYD PI = [dpi_value | device-dpi| high-dpi | medium-dpi | low-dpi] "/>

Within these attributes, we focus on target-densitydpi, which can change the default scaling of the device. MEDIUM-DPI is the default value for target-densitydpi, and if we explicitly define TARGET-DENSITYDPI=DEVICE-DPI, then the device renders the page at a real dpi. For example, a 320*480 picture, placed in the iphone4, the default is full screen, but if defined target-densitydpi=device-dpi, then the picture only occupies One-fourth of the screen (One-second Square), Because the resolution of the iphone4 is 640*960.

Ii. Solutions (1) Simple rough

If we make the page in 320px wide design, and do not make any settings, the page will automatically zoom to the width equal to the phone screen (this is because MEDIUM-DPI is the default value of target-densitydpi, and the different densities correspond to different scaling ratios, All of this is done automatically by mobile devices). So this solution is simple, rough and effective. But there is a fatal drawback, for high-density and ultra-high-density mobile devices, pages (especially pictures) will be distorted, and the more dense, the more distorted.

(2) Ultimate Perfection

In this scenario, we use target-densitydpi=device-dpi, so that the mobile device will be rendered according to the actual number of pixels, in professional terms, is 1 CSS pixels = 1 device pixels. For example, for 640*960 's iphone, we can make 640*960 pages, and there will be no scroll bars on the iphone. Of course, for other devices, you also need to make different sizes of pages, so this approach is often used media queries to form a responsive page. This scenario can be perfectly presented at a specific resolution, but as more resolutions are compatible, the cost is higher because individual code needs to be written for each resolution. Here's a simple example:

<meta name= "viewport" content= "target-densitydpi =device-dpi, Width=device-width"/>

#header {background:url (medium-density-image.png);} @media screen and (-webkit-device-pixel-ratio:1.5) {/* CSS for high-density screens */#header {Background:url (High-den sity-image.png);}} @media screen and (-webkit-device-pixel-ratio:0.75) {/* CSS for low-density screens */#header {Background:url (low-dens ity-image.png);}}

(3) Reasonable compromise

The vast majority of Android devices are high density, part of the characteristics of medium density, we can use a compromise solution: we have 480px wide design manuscript to restore, but the page system is made of 320px wide (using background-size to reduce the image), and then, Let the page scale automatically by scaling. This way, low-density mobile phones have a scroll bar (which is basically no longer used), the density of mobile phones will waste a little bit of traffic, high-density mobile phone perfect, ultra-high-density mobile phone slightly distorted (ultra-high-density Android phone very few). The advantages of this scheme are obvious: only a set of design drafts, a set of code (this is just about Android phones).

Iii. Development and Commissioning (1) weinre Remote real-Time debugging

Web developers often use Firefox's Firebug or Chrome's developer tools for Web debugging, including debugging for javascript,dom elements and CSS styles. However, these tools are difficult to use when we expect to debug a mobile Web site or app.

Weinre is a debugging tool that helps us to remotely debug a Web page or app running in a mobile device browser on the desktop. Weinre is a shorthand for web INspector remote and is now an open source project for Apache hosted on GitHub.

The following will describe how to use it in daily work.

First of all, we want to download weinre jar Package--the project has not found the jar file, the Web can be found, it is recommended to build a separate Web server, the jar after the run is a local server, and the Web server almost ~ ~ ~

Then start it by running a DOS command ( Note that the JDK is already installed on your computer). To run the command as follows, you need to change the path to your actual file location:

Java-jar D:\tools\weinre-jar\weinre.jar–httpport 8081–boundhost-all-(Httpport is the specified service port, boundhost parameter description can use IP access, The all parameter represents support for all host).

To access localhost:8081, if you see the following page, the Weinre has started successfully:

Enter the debug client user interface address (Debug clients UI address). In this case: http://localhost:8081/client/#anonymous, where #anonymous is the default Debug ID (Debug ID). If this weinre debug server is only used by you alone, then you can use the default debug id:anonymous. Start the Weinre debugging client UI such as:

In the page that needs debugging, add the following script: <script type= "Text/javascript" src= "http://localhost:8081/target/target-script-min.js# Anonymous "></script>, pay attention to replacing localhost with a real IP address that the phone can access. When the phone accesses this page, the WEINRE client detects the target device and can then debug it.

Because the phone is not convenient, I am using two browser window to show the effect, in fact, the effect on the phone and the right is the same.

(2) AVD Simulator commissioning

Static pages do not meet our needs, many practical effects such as touch events, scrolling events, keyboard input events, etc., need to be tested in the real environment, then need to use the simulator. Just as we test IE6, the AVD simulator can be analogous to a virtual machine on a PC, and when we need to test a particular model, we can create a new AVD to perform a series of tests. However, the use of AVD is premised on the deployment of the Android development environment, which requires JDK + Android SDK + Eclipse + ADT, or a bit cumbersome.

(3) Mobile phone grab bag and match host

On the PC, we can easily match the host, but it is a problem how to match the host on the phone.

Here the main use of fiddler and remote agents, to achieve the mobile phone with host operation, the specific operation is as follows:

1. First of all, to ensure that the PC and mobile devices under the same LAN;
2. Turn on Fiddler on your PC and tick "Allow remote computers to connect" in Settings
   
3. The agent is set on the phone, the IP address of the proxy IP is the PC, the port is 8888 (this is the default port of fiddler). Usually the phone can be directly set up the agent, if not, you can download a call Proxydroid app to implement the proxy settings.
4. At this point you will find that using mobile Internet, walking is actually the Fiddler on the PC, all the request package will be listed in the Fiddler, with Willow use, you can achieve with host, or even reverse proxy operation.

Summarize

The above is our actual development in the accumulation of some experience and skills, hope to give you some help, if you have a good method or tools, please also share in the message ~ ~

Essential knowledge of mobile terminal development