Enable mobile functionality for Web applications without changing application code

Brief introduction

Although mobile browsers are becoming more powerful as Android, IOS and other mobile operating system versions continue to grow, physical limitations remain, such as smaller screens and using touch as a new input mode (rather than using a mouse). Although some smartphones may be able to display a website, the final display results are often difficult to use or even completely useless. Buttons and other controls need to be resized so that they can be easily manipulated through the fingers rather than the mouse pointer, and new actions such as sliding and multi-touch gestures can be used efficiently. In short, the need to pull together to make these sites not only mobile friendly, but support mobile.

Reduced screen free space and touch control are the main factors that facilitate the simplification and reorganization of the Web UI and the application of Web applications to mobile devices. Although you can generate a single UI that is rendered differently on the desktop and on a mobile browser, this method is often used to avoid any modifications to existing WEB applications. Instead, the goal should be to generate a set of static assets (tags, style sheets, and JavaScript code) that provide mobile access to WEB application functionality without modifying server-side code in any way. Existing sites are still intact.

From an operational standpoint, this avoids the high cost of deploying code changes to a production environment. It also eliminates the need for regression testing of existing functionality modified during the addition of mobile support. In addition, because the same requests and responses are used, if you expect to add mobile support to significantly increase your access traffic, you can simply perform performance testing on your application. With this technique, you can simply insert static files (. html,. css, and. js) so that the same domain that hosts existing WEB applications serves them and reuses existing services that the application has already provided.

By restricting yourself to creating only new static assets, you actually write only one client for an existing WEB application.

WEB application: A Brief History

Most non-trivial Web applications are built around the concept of model-view-Controller (MVC), where the controller is on the server. The server maintains session state and navigates the user request to the next page to be rendered by forwarding or redirecting. Each client request typically gets a markup for the entire page, even if only part of the page is changed in a different view. The Portlet framework was introduced to address this issue, which supports more flexible execution of page aggregation.

Then, Ajax began to spread rapidly, and Web 2.0 was born. Ajax supports the asynchronous request being made programmatically. The payload no longer needs to be a tag, but XML, and later JSON. This allows the controller to be transferred from the server to the client, and the page aggregation work can be unloaded to an increasingly powerful and more standardized client browser. At one extreme, the Web application's browser and tag renderer are no different, and all features and streams are managed by the server. At the other extreme of the scope, many of the control and flow logic of WEB applications are performed on client browsers (like JavaScript, Flash, or Silverlight), and the server provides RESTful services to meet data requirements. and execute any onerous calculations that the application may require.

When it comes to mobile Web applications, the latter pattern is often thought of as a way of designing mobile frameworks such as JQuery Mobile or Dojo mobile. But what happens when you need to have a more server-centric design for mobile-enabled applications without REST services?

Use a WEB application as a black box

Because our intention is to avoid any code changes to the application, you can view the application as a black box, focusing only on the output you get for any given input; the input here is the HTTP request, and the output refers to the HTTP response. Therefore, if you create a mobile client to simulate a particular HTTP request and be able to analyze and identify all of the possible responses to that request, you can provide a mobile "skin" to take advantage of the same request/response pattern of an existing application. Although this sounds simple in theory, it may not be that simple in practice.

Logon sequence

Let's look at an example of the authentication sequence for a typical WEB application. (The details of HTTP requests and responses can be collected using a single tool, such as Firefox Firebug or Developer tools in Chrome or Safari.) We first look at the authentication from the location where the credentials were submitted. Listing 1 shows the source code markup for the login form.

Listing 1

<form name= "LogonForm" action= "/abc/salesportal/j_security_check" method= "POST" > <input type= "hidden" name= "Page" value= "Signin.wss"/> <table cellspacing= "0" cellpadding= "0" class= "sign-in-table" > <tr> < TD class= "C1" ><label for= "user_id" >email id:</label></td> <td><input dir= "ltr" class= " Wpseditfield "size=" "value=" Name= "J_username" id= "user_id" type= "text"/> (e.g., joe@abc.com) </td 
  > </tr> <tr> <td class= "C1" ><label for= "passwd" >Password:</label></td> <td><input dir= "ltr" class= "Wpseditfield" "size=" id= "passwd" name= "J_password" type= "password"/></ td> </tr> <tr><td><input type= "hidden" name= "Login-form-type" value= "pwd"/></td> &L t;/tr> <tr> <td>&nbsp;</td> <td><p><a href= "Http://www.abc.com/passwo Rd ">forgot your password?
      </a></p></td> </tr> </table> <table cellspacing= "0" cellpadding= "0" Clas s= "Submit-table" > <tr> <td class= "buttons" align= "right" > <span class= "Button-blue" > <in Put type= "Submit" value= "Submit" name= "Submitbutton"/> </span> <span class= "Button-blue" > <inp 
  UT type= "button" value= "Cancel" name= "CancelButton" onclick= "Cancelsignin ()"/> </span> </td> </tr> </table> </form>