Using Hammer.js's H5 page to develop some novel methods of Dom

A few days ago, a small partner said that I help him to write a mobile end of a carousel map, the individual is generally not to take reverse telecommuting, after all, usually work is a single double, time is not much.

Probably most programmers, the extra time is to look at the news, play games, or learn new knowledge, lack of exercise bar.

So, the personal feel to take reverse telecommuting that point of time, you can go to exercise, or learn new knowledge, of course, these are views, does not mean that you and I have the same view, OK, but since is a friend, is also a classmate, and not just a carousel map, I also wrote some mobile side, Carousel diagram is one of the most common ad display features on the mobile side.

However, when the small partners to the general requirements of high-speed me, completely with the Carousel Map No, no, only a dime relationship, because his demand is to help him write a small game.

The game content is roughly, the user registers, chooses, then enters to chooses the topic category, then gives the user the prompt, then enters the topic preview, the user previews 5 topics, the topic is an English word, has 3 Chinese characters lets the user swipe to choose the answer, then after reading the preview question then can enter the answer mode through the button. And users answer a question to do a statistical user's right and wrong, because the user answers, there will be statistical users to answer what is wrong or all right. That is, to announce the correct answer. and give the user points back to the initial page, continue to start the game.

Need to say, is not the feeling of dry carousel diagram has anything to do with, every time to the next page is the carousel to the next page 0 0! Hey, that doesn't count.

Next to the game to the structure of the DOM, build up and start to write JS.

Here is a dependency and jquery.js of the lightweight gesture library, you may ask why not zepto, I do not explain here, in short, the pit to listen to many. This hammer.js supports the following gesture features and makes a brief introduction:

Tap Finger no more than 250m

Press fingers longer than 500m

Pan Finger press down to slide to lift, including press slide to start, heel slide to cancel, top 3 with Ontouchstart ontoumove ontouchend like native;

Swipe fast slide, including swipeleft quick slide swiperight quick right swipe, etc.

Pinch 2 finger zoom and zoom gesture

Rotate 2 finger rotation

　　

Using it requires a new constructor, such as: var $obj = new Hammer (element);

Element is the DOM object you are going to pass in, but the disadvantage of hammer.js is that you cannot bind events to multiple DOM elements at once, meaning that each new DOM object can only be one, so element can only be a DOM element, not a group, for example: $ ( ' #obj ') [0]

You can then use its own encapsulated event binding function, On,off, and so on, more property methods can be new out of an object, Console.log ($obj), it can be all displayed.

Let's talk about the structure of the DOM:

　　

For example, the current slide is to DOM3 the displacement, transform:translate (x, y, z);

In general, we may bind the event to DOM3, but when you bind it, it is shifted like -1000px, and now your finger position is not calculated according to the current screen position, which is calculated according to the current position of the element, which may be a little cumbersome. You might say that it's OK to bind the event to the DOM1, get the value to shift the DOM3, and then how your finger will operate on the DOM1 is also the original position. Yes, I did the same thing, but it just did the trouble for myself, a lot of times the event is not triggered, or to operate 2 times to trigger, why?

This is probably the difference between the event mechanisms that are often mobile, and the elements do not bubble up to the parent in time. For this problem, because of the device limitations, with the Chrome simulator does not trigger the event, the next time to find another way to test debugging. But the above problem is not a problem in the built-in browser, there are problems on other browsers, including Chrome's app and Apple's own browser

So we usually try to bind the event to the inner DOM, reducing our chances of falling out of the hole.

and spit it out. Some well-known apps have poor support, such as the Firefox desktop browser is very good this as a web programmer is aware of, but to the app support is very little, even possible to get the screen size is wrong, so I basically test the browser only Apple each version of the own browser, QQ built-in browser, built-in browser, with the UC browser, more than a QQ browser.

But I believe many apps can slowly support more, just hope the pace can be faster.

Literary talent is not good, the article only exchanges with their own records. Thank you

　　

　　

Using Hammer.js's H5 page to develop some novel methods of Dom