Ajax will become the preferred development platform for Mobile Web2.0 era

Ajax|web|web2

First, the introduction

Recently, Opera has announced the application of Ajax technology to mobile device development through their browsers.

Given the popularity of opera browsers in the current browser market (especially in the mobile browser market), we can expect this announcement to have a significant impact on the entire browser market. From the experience of joining the mobile service development market for several years, I believe that Ajax today is likely to replace Java me and XHTML as the preferred platform for developing mobile applications.

Before I begin, I would like to make a note-I believe that mobile Web 2.0 is far more than the "mobile Ajax" layer of application. Mobile Web 2.0 should include all seven principles of Web 2.0 being applied to the mobile marketplace. In this article, I'd like to talk about Ajax, which is just one aspect of Web 2.0.

Two, what is Ajax?

Ajax is an optional enhancement technology for Web 2.0, not just a technology. Instead, it combines many of the existing technologies together, namely:

· XHTML and css-for standard-based descriptions

· Document Object Model-for dynamic display and interaction

· XML and xslt-for data interchange and manipulation

· xmlhttprequest-Asynchronous data retrieval

· Javascript-is used to "bundle" the previous technologies together.

Prior to the advent of Ajax, it was quite difficult to implement the rich and interactive design of "replicating" native applications. Ajax is significantly different in addressing these issues than some of the technologies it used before, because it is based on existing, generic standards that are already familiar to many developers.

In a traditional Web application, most user behavior triggers an HTTP request. The server then handles some processing and returns the results to the user. In the process of server processing, users can only wait! From a technical point of view, there is nothing wrong with this "start-stop-start" feature of Web applications, but it does not solve problems from the perspective of user interaction (since almost all user interactions cause a server to be processed, and when the server does this, the user can only wait!) ）。

Ajax solves this problem by using an AJAX engine. At the beginning of the session, the AJAX application loads the AJAX engine. The AJAX engine is developed in JavaScript (as a JavaScript library) and in a hidden frame. The user interacts with the Ajax engine instead of the original interaction with the Web server. If the user interacts and requires processing to the server, the AJAX engine itself handles the current interaction. When user interaction requires some data from the server, the Ajax engine will make an asynchronous call (via the xml/xmlhttprequest API) without interrupting the "mentality" of the user.

Ajax is "asynchronous", meaning that the Ajax engine communicates with the server and interacts with the user asynchronously. As a result, users get a "seamless" experience (i.e., users don't have to wait).

There is a "power" behind Ajax today-developers are already familiar with the background to this technical support, and all the technologies that make up Ajax are mature and stable. Ajax is the foundation of many new applications on the web, such as Google Suggest,google Maps, and part of the a9.com of Flickr and Amazon.

III. Mobile application development model and its drawbacks

From the above discussion and related reference articles, Ajax is able to address both of these issues explicitly, providing an excellent UI and a standardized form of data retrieval. In fact, these two problems can also be applied to mobile devices, and by extension, Ajax can also effectively solve these problems. However, I believe that its function is far from these! Specifically, it will address the following issues in the mobile environment:

1. Market share problem

2. Porting issues (specific to downloading applications, like the one built with Java me)

3. Application Barrier-Free publishing problem

In addition, it has a large number of community developers behind it-which is also an important aspect!

Let's consider existing mobile application development. There are two main categories of mobile applications: Browsing applications and download applications. Of course, there are other types (like messaging applications, SIM applications, and embedded applications), but most of the applications we see today should be within the scope of a download or browsing application.

Browsing applications: Conceptually, a browsing application is almost like a program browsing the web, but with mobility-specific restrictions (for example, small device size). Like the web, a service can be accessed through a micro-browser-it uses a URL to locate a service located on a wireless Web server. The client has almost no processing power.

A download application (a smart client application) is a type of application that downloads them first and then installs them on a client device, as opposed to a browsing application. These applications are then run on the local device. Unlike a browsing application, a download (or smart client) application does not need to be connected to the network while it is running. A download application is also called a "smart client" application because the client (i.e., mobile device) can do some processing and/or have some persistent storage capability (buffering). Currently, most java-based games are download applications, which are downloaded to the client and require some processing at the client and do not always have to be connected to the network. Enterprise mobile applications, such as sales industry automation, are also examples of regular smart client applications.

Java me is the most common way to develop a download application, and XHTML is the most common way to develop a browsing application. Next, let's go over the issues mentioned earlier and discuss how Ajax technology solves these problems.

Question one: Market share

Mobile applications are the primary consumer application. Like other industries that are developing during this period, the mobile data industry is also a rising industry, which only occupies a certain market share. Consumer applications require a large number of user groups in order to achieve commercial operational objectives, particularly in view of the need for network effects.

The operation of the above market may be based on a single patent standard, for example, from Qualcomm Brew (which clearly has its disadvantages) or through open standards with little industrial barriers that are not controlled by any business entity.

To illustrate how market share affects the viability of a new service, I often recommend the following approaches (where most of the data can be easily retrieved from the web). The idea is to use the "concentric circle" theory to try to estimate the target user base of your application.

Here's an example of the steps I used:

1. How many people are there in the countries that are preparing to issue your application?

2. What is the percentage of handheld devices per capita in the above population?

3. What kind of operator do you want to hire in such a population? (most countries have multiple types of mobile operators)

4. What are your target handheld devices in such a population? (Not all operators support all handheld devices)

5. What kind of publishing technology is used, java,sms, or WAP?

6. Does the application have any special technical needs, such as location-based services? How many people have handheld devices that support this technology?

7. What is the rule that your market segmentation analysis suggests? (The simplest division is male/female, prepaid/paid, etc.)

8. What are your marketing channels?

9. What market share do we expect to achieve and how many customers do we convert from our market budget? (i.e., conversion rate-typically about 2%)

This will provide you with the number of users you target, and the number of user groups multiplied by the number of potential downloads per month should calculate your monthly income. Also, this can directly relate to your cost base--including your development fee, transplant fee, and so on--to achieve a more objective understanding of the success/failure rate of investing in this new type of service.

The above approach reveals a market share problem, and it implies that few mobile services today can make a profit. As a result, we can create a proliferation service-' broadcast content applications ', such as ringtones and image software, but in the mass market there are very few corresponding tool applications.

Question two: transplant issues

This problem is specific to the downloaded application (more common in Java me). In the Java ME environment, "write a run Everywhere" is just a joke! Consider the case of a mobile game typically developed with Java ME (a portable application).

First of all, the good part is:

· It is reported that some operators, such as Sprint, currently occupy about 10% per cent of their annual income from mobile gaming and other data services;

· Industrial consultancy Ovum notes that there are now more than 450 million handheld devices in the global marketplace that support Java technology, as well as 38 million and 15 million handheld devices that support brew and Symbian;

· Mobile gaming publishers are selling 1.2 billion of dollars globally in 2004, and are expected to achieve a stronger sales momentum in 2005 as more and more consumers find that the mini game consoles actually exist on their phones.

But next, let's take a look at the negative factors:

· Game porting typically requires developers to adapt to different screen resolutions, processor speed, memory limits, and audio capabilities, all of which vary greatly depending on the device.

· For publishers, this would make them miss out on key market opportunities in a highly competitive industry.

· As an example, imagine that you are a medium-sized game publisher with a total of 30 games. To enable your game to be available in five languages worldwide and only on 50 devices, you need to create 7,500 different release versions. With each release you need to spend $2,500 computing, you need a transplant budget that's close to 19 million dollars.

This severely limits the size of the business and makes it possible to make very few mobile games profitable.

Issue three: Application "barrier free" release

The dilemma with each of the previous examples of mobile development using the Java ME technology shows that just creating a community (as Sun does, which is always working well in terms of technology) is far from enough. The technology and the applications built on it must remain homogeneous and interoperable to support network effects and access critical customer groups. The less "bottleneck" a platform has, the better it means for the industry as a whole.

[1] [2] Next page