Knowledge required for mobile webapp development and webapp Development

Knowledge required for mobile webapp development and webapp Development

There are more and more mobile devices, and more than 1.3 million android mobile phones are activated every day. Therefore, our webapps for mobile terminals are also starting to follow up. This article describes the knowledge and experience of webapp development and debugging, and provides several optional solutions.

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

CSS pixels: the abstract unit used by the browser to draw content on the webpage.

Device pixels: The minimum physical unit of the display screen. Each dp contains its own color and brightness.

The size of the CSS pixels on the mobile phone screen is not fixed, depending on many attributes. After analysis and summarization, we can come up with the following formula: 1 CSS pixels = (devicePixelRatio) ^ 2 device pixels (^ 2 indicates square, and what is devicePixelRatio, ).

(2) PPI/DPI

PPI, also known as DPI, indicates the number of pixels per inch. The higher the value, the higher the display density. (Note: pixels here refer to device pixels .) After figuring out what the PPI means, we can easily understand the calculation method of the PPI. First, we need to calculate the diagonal equivalent pixel of the mobile phone screen, then we can get the PPI with a diagonal line (we usually call the cell phone screen size the length of the cell phone screen diagonal line. For more information about accurate calculation and publicity, see. Interestingly, the iPhone 4's PPI calculated based on the formula is 330, a little higher than Apple's 326 officially announced.

Similarly, taking HTC G7 as an example, the resolution of 480*800, 3.7 inch, is 252 PPI.

(3) density determines the proportion

We calculate the PPI to know which density range a mobile phone device belongs to, because different density ranges correspond to different default scaling ratios, which is a very important concept.

It can be seen that the phone number between and is classified as a low-density phone number,-is classified as a medium-density phone number, and-is classified as a high-density phone number, more than 320 are classified as ultra-high density (Apple gave it a high name-retina ).

 

These density values correspond to a specific scaling value. For the iPhone 4 or 4s that we are most familiar with, their PPI is 326, which is an ultra-high-density mobile phone. When we write a page with a width of PX and put it in the iphone, you will find that it is actually full width. This is because the page is zoomed twice by default, that is, 640px, while the width of iPhone 4 or 4s is 640px.

 

The figure circled the high-density category because this is the statistics of android mobile phones. In the domestic android mobile phone market, high-density devices account for the vast majority of the market share, which is very important, it is also the key point for us to pay attention to when making Android webapps.

(4) use of viewport

Viewport has five attributes, respectively:

Html code

<Meta name = "viewport"

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] "/>

<meta name="viewport"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] " />

 

 

Among these attributes, we focus onTarget-densitydpiThis attribute can change the default scaling of the device. Medium-dpi is the default value of target-densitydpi. If we explicitly define target-densitydpi = device-dpi, the device will render the page according to the actual dpi. For example, if a 320*480 image is placed in iPhone 4, the screen is full by default, but if the target-densitydpi = device-dpi is defined, the image only accounts for 1/4 of the screen (1/2 square meters), because the iPhone 4 Resolution is 640*960.

Ii. solution (1) simple and crude

If we create a page based on the px wide design without any settings, the page is automatically scaled to the same width as the mobile phone screen by default (this is because medium-dpi is the default value of target-densitydpi, which is determined by the different scaling ratios corresponding to different density values, all of this is automatically done by mobile devices ). This solution is simple, crude, and effective. However, there is a fatal drawback: for high-density and ultra-high-density mobile phone devices, pages (especially images) will be distorted, and the more density, the more distortion.

(2) perfection

In this solution, we use target-densitydpi = device-dpi. As a result, the mobile phone device will be rendered based on the actual number of pixels. In professional words, that is, 1 CSS pixels = 1 device pixels. For example, for the iphone 640*960, we can make a 640*960 page, and there is no scroll bar on the iphone. Of course, for other devices, you also need to create pages of different sizes. Therefore, this solution is usually to use media queries to form responsive pages. This solution can be perfectly presented at a specific resolution, but the higher the Resolution, the higher the cost, because you need to write separate code for each resolution. The following is a simple example:

Html code

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

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

 

Html code

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

}

#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 the vast majority of Android devices are high-density, and some are medium-density, we can adopt a compromise solution: We will restore the px wide design draft, however, the page size is PX (the background-size is used to scale down the image), and the page is automatically scaled proportionally. In this way, a low-density mobile phone has a scroll bar (basically no one is using this phone). A medium-density mobile phone will waste a little bit of traffic, and a high-density mobile phone is perfectly displayed, ultra-high-density mobile phones are slightly distorted (very few Android phones ). The advantages of this solution are very clear: you only need a set of design documents and code (Here we only discuss the situation of Android phones ).

Iii. Development and debugging (1) weinre remote and real-time debugging

Web developers often use Firefox firebug or Chrome Developer Tools for Web debugging, including debugging for JavaScript, DOM elements, and CSS styles. However, these tools are hard to come in handy when we want to debug a mobile Web site or application.

Weinre is a debugging tool that helps us remotely debug Web pages or applications running in mobile device browsers on the desktop. Weinre is short for WEb INspector REmote and is now an open-source project of Apache hosted on github.

 

The following describes how to use it in daily work.

First, we need to download the weinre jar package. The project official cannot find the jar file and can be found online. We recommend that you set up an independent web server, after jar is run, it is a local server, which is similar to the web server ~~

Then, run the doscommand to start it (Please note that JDK has been installed on your computer). Run the following command to change the path to your actual file location:

C code

Java-jar d: toolsweinre-jarweinre.jar-httpPort 8081-boundHost-all-// (httpPort is to specify the service port, the boundHost parameter description can be accessed using IP, the all parameter represents support for all hosts ).

Java-jar d: toolsweinre-jarweinre.jar-httpPort 8081-boundHost-all-// (httpPort is to specify the service port, the boundHost parameter description can be accessed using IP, the all parameter represents support for all hosts ).

 

 

Access localhost: 8081. If the following page is displayed, weinre has been started successfully:

Enter the address of the debug client user interface (UI address of the debug client ). In this example, http: // localhost: 8081/client/# anonymous, where # anonymous is the default debug id ). If the weinre debugging server is only used by you, you can use the default debug id: anonymous. The weinre debugging client ui started is as follows:

Add the following script on the page to be debugged: <script type = "text/javascript" src = "http: // localhost: 8081/target/target-script-min.js # anonymous"> & lt; /script>. Replace localhost with the real IP address that the mobile phone can access. When the mobile phone accesses this page, the weinre client detects the target settings and then can debug it.

Because it is inconvenient to use a mobile phone, I will use two browser windows to display the results. In fact, the results on the mobile phone are the same as those on the right.

(2) AVD simulator debugging

Static pages cannot meet our needs. Many actual effects, such as touch events, rolling events, and keyboard input events, must be tested in a real environment. In this case, a simulator is required. Like we test ie6, the AVD simulator can be similar to a virtual machine on a PC. When we need to test a specific model, we can create an AVD and perform a series of tests. However, the premise of using AVD is that the android development environment has been deployed. This requires JDK + android SDK + Eclipse + ADT, which is a little complicated.

(3) Mobile Phone packet capture and host Configuration

In PC, we can easily configure the host, but how to configure the host on the mobile phone is a problem.

Here, we mainly use fiddler and remote proxy to implement host configuration for mobile phones. The specific operations are as follows:

Summary

The above are some of the experiences and skills we have accumulated in actual development. I hope to help you. If you have any good methods or tools, please share them with us ~~

In what situations should I develop a mobile Web App?

Mobile Web is the only platform for developers to publish mobile applications. It effectively connects various mobile interactions with desktop tasks. The mobile Web platform has the following advantages: easy to learn, low development cost, standardization, easy to use, and easy to publish. I sum up these advantages to the principle of "ubiquitous": often something that is simple to develop and has a broad market can be successful. "High Quality" is also one of the key factors for success, and mobile Web has not yet done well over the years. Mobile Web still has some difficulties in many aspects. Solving the diversity of devices is a major challenge to Improve the Quality of mobile Web. However, the difficulties faced by mobile Web are far less complex than those faced by Native Apps. In addition, these challenges will be effectively solved over the past few years. As we all know, I am a supporter of mobile Web; however, I am also the first person to acknowledge the importance of Native apps. Developing Native apps can make full use of the features of devices, which is often impossible for Web browsers. Therefore, Native apps are the best choice for a product. The following sections will discuss some main functions of Native apps. When should I develop a Native App1. the App charge? There is no place to stipulate that developers are not allowed to charge a usage fee for a mobile Web App. But for some reason, people often think that they cannot or shouldn't charge a Web App. Due to historical reasons, the payment service on mobile devices suffered two major obstacles: 2. payment methods are quite troublesome to enter a credit card number on mobile devices, and there is no security guarantee on many old-fashioned devices. A typical method is that if you need to pay for your application, you can reach an agreement with the carrier to allow the operator to charge for your service on its behalf. This also means that you need to cooperate with multiple carriers. This is usually the preferred method, because many mobile phone users may not have a credit card at all, such as teenagers. Another method is to save your credit card information on a secure website. You can log on to the website to purchase the application service. This process is not ideal, because it means users cannot buy services directly from their mobile devices. 3. A commission is required to be forcibly divided into mobile operators. Apps Are released through carriers or mobile devices. They provide a charging mechanism for applications. These operators and mobile devices will extract part of the revenue and then hand over the rest to application developers, which also means that developers must abide by their market rules. It is usually very difficult to adapt to the operator's market rules and requires a large amount of human resources. In comparison, the market rules for mobile devices are much simpler, but there are also many difficulties. Applications and Services that impede the interests of operators and mobile device developers will be blocked. In the past, websites that do not rely on operators and mobile device developers could not escape the fate of being shut down if their incomes were too conspicuous. However, such things have rarely happened recently. If you want to charge for your Native App, you must accept this reality-you must abide by the market rules of others and give up some benefits. If you want to develop a mobile game (mobile games are the largest in the mobile market), you need to develop a Native App. Games occupy a large amount of resources and require many device APIs or platform APIs. Although several games fully developed using Web technologies have a certain market share, it is still insignificant compared with the Native App market. Game users have high requirements on the visual and operational effects of applications. Although mobile Web provides some simulation experience, it is far from satisfying users' needs. When developing mobile games, you need to carefully consider which platforms your applications need to support. Fortunately, there are many tools that can help you push your game to multiple platforms, but it still takes a lot of manpower and material resources to complete the work. 4. Use the positioning function. The next function is the positioning function. You can use GPS or signal detection to determine your current location information. In the past, only the APIs of the Native App can be used to view the user's location information. However, most mainstream mobile browsers have embedded the W3C Geolocation API. Such as iPhone or Android... the remaining full text>

How can I learn mobile webapp development?

Find resources online or submit a software course.