Development and debugging of necessary knowledge WebApp for mobile terminal development

With more and more users of mobile devices, Android phones have more than 1.3 million activations per day, so our webapp for mobile terminals are starting to follow. This paper mainly introduces the knowledge and experience of webapp development and debugging, and gives several alternative solutions.

I. Basic CONCEPTS

(1) CSS pixels and device pixels

CSS Pixels: An abstract unit used by browsers to draw content on a Web page.

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

The size of the CSS pixels on the phone screen is not fixed, depending on many attributes. After analysis and summary, we can draw such a formula: 1 CSS pixels = (devicepixelratio) ^2 device pixels (^2 is the meaning of square, as for the devicepixelratio is what things, later will explain).

(2) ppi/dpi

The PPI, sometimes called the DPI, represents the number of pixels (pixel) per inch, the higher the value, which represents the display's ability to show the image at a higher density. (Note: The pixel here refers to the device pixels.) Figuring out what PPI means, we can easily understand how the PPI works, we need to figure out the diagonal equivalent of the cell phone screen, and then we'll get the PPI by going diagonally (the length of the phone screen that we normally call the screen size). Accurate calculation of publicity you can refer to the following figure. Interestingly, the 4 PPI for the IPhone, calculated on the formula, is 330 higher than the official 326 of Apple's announcement.

Similarly, in HTC G7, for example, the resolution of 480*800, 3.7 inches, is calculated as the 252 PPI.

(3) Density decision ratio

We calculate the PPI to know which density range a mobile device belongs to, because it is a very important concept to have different density intervals corresponding to different default scaling ratios.

It is known from the above picture that the mobile phone PPI between 120-160 is classified as a low-density handset, 160-240 is classified as medium density, 240-320 is classified as high-density, and more than 320 is classified as hyper-high-density (Apple gave it a high name of--retina).

These densities correspond to a specific scaling value, and for the most familiar iphone4 or 4s, their PPI is 326, which is a hyper-dense cell phone. When we write a page with a width of 320px and put it on the iphone, you will find that it is full of width. This is because the page is magnified by default twice times, that is 640px, and iphone4 or 4s wide, it is 640px.

The high density is circled because this is the Android phone statistics, in the domestic Android phone market, high-density equipment accounted for the vast majority of the market share, this is a very important point, we do Android end WebApp to pay attention to the key points.

(4) The use of viewport

Viewport has a total of 5 attributes, respectively, as follows:

Content= "

Height = [Pixel_value |device-height],

width = [Pixel_value |device-width],

Initial-scale = float_value, Minimum-scale = float_value, Maximum-scale = Float_value,

User-scalable =[yes | No],

target-densitydpi = [Dpi_value | device-dpi| high-dpi | medium-dpi | LOW-DPI] "/>

In these properties, we focus on target-densitydpi, which can change the device's default scaling. MEDIUM-DPI is the default value for target-densitydpi, and if we explicitly define TARGET-DENSITYDPI=DEVICE-DPI, then the device will render the page according to the true DPI. For example, a picture of 320*480, placed in the iphone4, by default is full screen, but if the definition of target-densitydpi=device-dpi, then the picture is only one-fourth of the screen (One-second Square), Because the resolution of the iphone4 is 640*960.

Ii. Solutions

(1) Simple and rough

If we make the page in 320px wide design and do not make any settings, the page will automatically zoom to the same width as the phone screen by default (this is because the MEDIUM-DPI is the default value of the target-densitydpi, and the different density corresponding to the different scaling ratio of the decision, All of this is done automatically by mobile devices. So the solution is simple, brutal, and effective. But there is a fatal drawback, for high-density and ultra-high density of mobile devices, the page (especially the picture) will be distorted, and the more density, the more distortion.

(2) Ultimate Perfection

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

#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-density-image.png);}

}

@media screen and (-webkit-device-pixel-ratio:0.75) {

/* CSS for low-density screens * *

#header {background:url (low-density-image.png);}

}

(3) Reasonable compromise

For Android devices, which are mostly high-density and partly medium-density, we can take a compromise: we restore the 480px-wide design, but the page is 320px wide (using background-size to shrink the picture), and then Let the page automatically scale proportionally. In this way, the low-density mobile phone has a scroll bar (the phone is basically no one is using), the medium density of the mobile phone will waste a little bit of traffic, high-density mobile phone perfect appearance, ultra-high density of mobile phone slightly distorted (ultra-high density of Android phone is very small). The benefits of this approach are clear: just a set of design drafts, a set of code (this is just a discussion of Android phones).

Iii. Development and commissioning

(1) weinre Remote real-Time debugging

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

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

Here's how to use it in everyday work.

First, we want to download the Weinre jar Package--the project officials can not find the jar file, online to find, it is recommended to build a separate Web server, the jar is running 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:toolsweinre-jarweinre.jar–httpport 8081–boundhost-all-//(Httpport is the specified service port, boundhost parameter description can be accessed using IP, The all parameter represents support for all host).

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

Enter the debug client user interface address, which is the debug clients UI address. In this example: http://localhost:8081/client/#anonymous, where #anonymous is the default Debug ID (Debug ID.). If this weinre debug server is only for you to use, you can use the default debug id:anonymous. The Weinre debugging client UI that is started is the following figure:

Add the following script to the page where you want to debug: Pay attention to changing the localhost to the real IP address that the phone has access to. When the phone accesses the page, the WEINRE client detects the target device, and then it can be debugged.

Because the phone is not convenient screenshot, I use two browser window to show the effect, in fact, the effect on the phone is the same as the right.

(2) AVD simulator debugging

Static page does not meet our needs, many practical effects such as touch events, scrolling events, keyboard input events, all need to be tested in the real environment, then need to use the simulator. 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 and perform a series of tests. However, the premise of using AVD is that the Android development environment has been deployed, which requires JDK + Android SDK + Eclipse + ADT, or a little cumbersome.

(3) Mobile phone grab bag and match host

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

Here mainly uses the Fiddler and the remote proxy, realizes the handset to match the host the operation, the concrete operation is as follows:

1. First, to ensure that the PC and mobile devices under the same LAN;

2.PC on the fiddler, and in the settings check "Allow remote computers to connect"

3. Set up proxy on mobile phone, IP address of IP for PC, port is 8888 (this is the default port of fiddler). Usually on the phone can set the agent directly, if not, you can download a call Proxydroid app to implement the proxy settings.

4. At this point you will find that the Internet with mobile phones, is actually on the PC fiddler, all the request package will be listed in the Fiddler, with Willow use, you can implement the host, or even the reverse proxy operation.

Summarize

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

Article Source: Http://isux.tencent.com/blog