Mobile Bug-compatible

Summarize the current mobile development challenges.

1. The default style of iOS and Android input is removed. The mobile side always has a default fillet or something.

Input[type=button],input[type=text],input[type=password] {    -webkit-appearance:none;     outline:none;     Border-radius:none;        }

2, iOS back no refresh

false . Window.onpageshow=function(EV) {    alert ("is the page loaded from the browser cache?") "+ ev.persisted);}

3, ios-input the input box after the cursor will also appear flashing.

For example, you need to make a opacity 0 input box, and then trigger the input box value change to change some of the value effect, such as six boxes such as password input box, but in iOS can not hide the cursor. However, you can use the label trigger input implementation, and the input location disappears on the interface. <label><input type= "text" ></label>input{    position:absolute;     -99999px;    Top:0;    width:1px;    height:1px;}    

4, the browser back forward problems.

In general, this is not a problem, such as some takeaway software after the successful delivery of the order can also back to the payment page, but no longer submitted.

In the multi-page, this is a very helpless problem, because the browser control is not able to operate properly.

History, however, provides a way to push history or replace history with historical management.

Pushstate, Replacestate

These methods cannot trigger popstate snooping in the case of a refresh.

So push hash value is better, because in the absence of a refresh can trigger monitoring.

The current page is updated only if the pushstate push and replacestate replacement are not triggered by the refresh of the current page, only the forward fallback to this historical management.

So sometimes it will be found that iOS replacestate can trigger Popstate, while Android will not, because the iOS cache optimization cause, will not refresh the history of forward and backward,

And then Android will.

But now some browsers are starting to implement no flush forward and backward.

So the browser's control forward and backward operation is very ugly to implement.

Now the single page is better, because it is in some non-refreshing way to push into the history of management and achieve more elegant performance optimization, such as the change of hash value to know what page to display,

This enables historical management controllability on the front-end, so that you can have more permissions to achieve what you need and perform better.

function Hash () {            var hash = window.location.hash.substr (1);            Window.addeventlistener (function  () {                   console.log (history.state);            })             if (hash) {                history.back ();            }        }

In summary, the browser's forward and backward problem is a very difficult problem to solve.

If there are conditions, it is best to use the current popular single-page application development approach, so that more control and separation of front and back, and excellent MVVM framework has many, traditional MVC development front-end one person to realize too much trouble, the specification is also very messy.

such as SPRINGMVC, use the. Do method to implement the jump page, but here is a problem is the forward and backward jump page. The Do method will be removed from the cache in the history management record, then it will be requested again. Do and the page

The Ajax method does not indicate that the cache is directly re-request the situation, then there is a problem, such as to achieve a backward refresh of the page, can only use reload, and so on, then the page will flash a bit, because when the return

Cache page will appear directly, and re-page needs time request load, this is a page performance problem, and single page will not, because all the data are Ajax request back, the page's routing jump is implemented at the front end.

Mobile Bug-compatible