Touch-web: Swipe

Этим постом мы продолжаем серию статей на тему разработки веб-интерфейсов для touch-устройств.

Смартфоны с сенсорными экранами достаточно сильно распространены и стали незаменимыми помощниками многим из нас. Потому нельзя не учитывать их особенности при разработке мобильных веб-интерфейсов.
Сенсорное управление существенно отличается от привычного управления мышкой.
Пользователь взаимодействует пальцами с самим экраном. И в зависимости от того, какие движения и сколькими пальцами производит пользователь, интерфейс реагирует по-разному: если быстро коснулся экрана и отпустил палец, то срабатывает клик; если коснулся и провел пальцем по экрану – скролл; если провел двумя пальцами – zoom; и великое множество других вариантов реакции.

Сегодня речь пойдет о swipe, в простонародье – листалке. Swipe позволяет перелистывать «страницы» привычным движением пальца. О том, как грамотно реализовать swipe, я расскажу на примере блока новостей на главной странице портала Mail.Ru.

Начнем с ключевых моментов, на которые надо обратить внимание при разработке листалки:

• Во-первых, нужно точно определить, чего хочет пользователь — перелистнуть страницу блока или проскроллить
• Во-вторых, нужно перемещать страницу при движении пальца вслед за ним
• В-третьих, если листать некуда, нужно дать пользователю это понять
• В-четвертых, реагировать на касание только первым пальцем
• И, наконец, перелистнуть страницу в нужную сторону, когда пользователь отпустил палец

Touch events

Специально для работы с touch-устройствами ввода в браузерах реализованы следующие события:

• touchstart – коснулись пальцем
• touchmove – подвинули палец
• touchend – отпустили палец
• и touchcancel – почти как touchend, но происходит в момент, когда мы палец не отпускали, но касаемся уже другого элемента. Например, поступил входящий звонок, и на экране уже не браузер.

Но некоторые браузеры на touch-устройствах — например, WP IE — не поддерживают эти события.

В целом ничего, казалось бы, не мешает имитировать аналогичное поведение через мышиные события — как, например, в десктопном drag’n’drop:

• touchstart – mousedown
• touchmove – mousemove
• touchend, touchcancel – mouseup

Но мышиные события в мобильных браузерах работают довольно странно ¬–
события происходят, только если был click (да и то сначала click, а лишь затем — mousedown, mousemove и mouseup).

Потому swipe реализован только на touch-событиях.

В touch-событие падает полезная информация о касаниях:

• touches – коллекция всех касаний, происходящих в данный момент
• changedTouches – касания, по которым есть изменения, т.е. непосредственно те, которые вызвали событие
• targetTouches – касания, ассоциированные с target события. Касания, произошедшие внутри элемента, на который навешан текущий слушатель

Каждому касанию присваивается уникальный идентификатор. В разных браузерах может иметь различные значения, в одних постоянно инкрементируется, в других сбрасывается, когда прикосновений больше нет.

Также объект касания содержит информацию о координатах относительно viewport, экрана и страницы.

Логика довольно простая:

Touchstart

/* 	Проверяем флаг started (не был ли уже начат swipe) и кол-во touches. Если swipe уже идет или toches не один, значит, пользователь орудует несколькими пальцами, и реагировать на это не надо. */ if (e.touches.length != 1 || started){ 	return; }  /* 	Ставим флаг detecting = true, означающий, что далее на touchmove надо определить, что имел в виду пользователь — хотел ли он перелистнуть страницу, просто прокрутить или тапнуть по ссылке */ detecting = true;  // Запоминаем текущее касание и его координаты touch = e.changedTouches[0]; x = touch.pageX; y = touch.pageY; 

Touchmove

/* 	Первым делом проверяем: если не стоит ни started, ни detecting, не делаем ничего. Не наш случай */ if (!started && !detecting){ 	return; }  /* 	В зависимости от установленного состояния запускаем определение перелистывания или его отрисовку */ if (detecting){ 	detect(); }  if (started){ 	draw(); }  /* 	Определение */ function detect(){ 	/* 		Получаем сохраненное ранее касание из changedTouches. Если среди касаний нет нашего, значит, пользователь коснулся экрана еще одним пальцем. На это касание реагировать не надо 	*/ 	if (e.changedTouches.indexOf(touch) == -1){ 		return; 	}  	/* 		Самым простым способом определения того, хотел ли пользователь перелистнуть страницу, является сравнение смещений пальца по осям.  		Если смещение больше по оси х, чем по у, значит, пользователь листает. 	*/ 	if (abs(x - newX) >= abs(y - newY)){ 		/* 			Если не отменить поведение по умолчанию, то второго touchmove может и не быть (например, в Android). Поэтому необходимо определить swipe с первого раза и отменить поведение по умолчанию – скроллинг страницы 		*/ 		e.preventDefault();  		// Запоминаем, что началось перелистывание 		started = true; 	}  	// В любом случае заканчиваем определение, т.к. шанс определить у нас один 	detecting = false; }  // Отрисовка реакции на движение пальца function draw(){ 	/* 		Отменяем поведение по умолчанию, дабы в дальнейшем срабатывали обработчики touchmove и не срабатывал скролл 	*/ 	e.preventDefault();  	/* 		Получаем сохраненное ранее касание из changedTouches. Если среди касаний нет нашего, значит, пользователь коснулся экрана еще одним пальцем. На это касание реагировать не надо 	*/ 	if (e.changedTouches.indexOf(touch) == -1){ 		return; 	}  	/* 		Вычисляем смещение пальца относительно исходных координат касания. 		На эту величину надо сместить страницу, чтобы она «следовала» за пальцем 	*/ 	delta = x – newX;  	/* 		Если листать некуда, делим смещение на некоторую величину для создания визуального эффекта «сопротивления движению» страницы. 		Таким образом, даем пользователю понять, что дальше страниц нет 	*/ 	if (delta > 0 && !leftPage || delta < 0 && !rightPage){ 		delta = delta / 5; 	}  	// Отрисовываем смещение, о чем чуть позже 	moveTo(delta); } 

Touchend/Touchcancel

// Как и ранее, отсекаем ненужные касания if (e.changedTouches.indexOf(touch) == -1 || !started){ 	return; }  /* 	Отменяем поведение по умолчанию. Например, если пользователь отпустил палец на ссылке, то может произойти переход по ней, чего нам не надо. */ e.preventDefault();  /* 	Определяем, в какую сторону нужно произвести перелистывание */ swipeTo = delta < 0 ? 'left' : 'right';  // Отрисовываем перелистывание, о чем чуть позже  swipe(swipeTo); 

Алгоритм работы с событиями довольно простой. Его легко расширить новыми фишками. Например, если пользователь передвинул страницу на малое расстояние, возвращаться к исходному состоянию по touchend. А если пользователь очень быстро провел горизонтально пальцем, но на величину меньшую, чем пороговое значение для прокрутки, все равно осуществлять перелистывание.

Рендеринг

Для того чтобы сделать листалку, нужно расположить страницы в ряд.

Каждая из них должна быть шириной не больше и не меньше родителя.

Центральная всегда видна, левые смещены на 100% влево, а правые – на 100% вправо.

Многим хочется использовать таблицу, но она не подходит по нескольким причинам.
Чтобы получить ширину страницы 100% родителя, нужно каким-то образом задать ширину всей таблицы в <кол-во страниц>*100%, и самим страницам в 100%/<кол-во страниц>. Без дополнительных JS-манипуляций это невозможно и грозит погрешностями и неровностями, а так же дополнительными расчетами.

Сделать страницы float’ами тоже не вариант, т.к. это даст лишнюю нагрузку на и без того во многих случаях медленный браузер, даже если чистить поток.

Мы выбрали другой вариант:

.swipe { 	position: relative; 	overflow: hidden; 	height: 300px; } 

Обертке блока указали высоту, position:relative и overflow:hidden, тем самым значительно снизив нагрузку на браузер при рендеринге и расчетах – мы получаем обособленную ветку DOM-дерева внутри листалки, браузер не пересчитывает другие части дерева при изменениях внутри.

Страницы же были разбиты на 3 логичные группы:

1. страницы слева
2. центральная страница – всегда одна
3. и страницы справа

.swipe__page { 	overflow: hidden; 	position: absolute; 	left: 0; 	top: 0; 	width: 100%; 	height: 100%; } 

Чтобы ускорить рендеринг, нужно максимально обособить страницы друг от друга, потому для каждой страницы указаны position:absolute; и соответствующие координаты и размеры.

.swipe__page_animating { 	transition: transform 200ms linear; } 

Далее встает вопрос смещения страниц вправо и влево.
Анимируются страницы средствами CSS-transition.
Если анимировать left, получается очень медленно. Гораздо быстрее работает translate, а еще быстрее — translate3d из CSS-трансформаций.

.swipe__page_left { 	transform: translate(-100%, 0); 	transform: translate3d(-100%, 0, 0); }  .swipe__page_center { 	transform: translate(0, 0); 	transform: translate3d(0, 0, 0); }  .swipe__page_right { 	transform: translate(100%, 0); 	transform: translate3d(100%, 0, 0); } 

Поэтому всем страницам указан left:0 и оба варианта translate — на случай, если браузер не поддерживает 3d-трансформации, со значениями смещения по горизонтали 100%, 0 и 100% для левых, центральной и правых страниц соответственно.

Таким образом, у нас получилось следующее: видимая центральная страница, и за границей видимой части блока стопка страниц слева и стопка страниц справа.

Из всех страниц выбираются три:

1. центральная, видимая
2. следующая страница слева
3. следующая страница справа

transform: translate(delta, 0); 

Изначально класс swipe__page_animating (добавляет CSS-transition) не установлен. По событию touchmove для страницы устанавливается соответствующий translate, со значением смещения по горизонтали равным смещению пальца (либо смещению, деленному на «коэффициент сопротивления»). Т.е. страница просто двигается вместе с пальцем.

На самом деле все несколько сложнее. Одновременно двигаются три страницы: текущая видимая, и по странице слева и справа, что создает эффект непрерывной ленты. Соответственно, для правой и левой страниц смещение равно его ширине с соответствующим положению знаком (для правой – плюс, для левой – минус) плюс смещение пальца.

По событию touchend или touchcancel страницам устанавливается класс swipe__page_animating, включающий CSS-анимации, и величины смещений, соответствующие финальному положению – либо перелистываем, либо устанавливаем исходные значения.

По событию transitionend, т.е. по окончанию анимации:

• удаляется класс swipe__page_animating
• заново выбираются «следующие» страницы, переключаются классы _left, _center, _right в соответствии с новым положением. Например, если пользователь перелистнул влево, то центральная страница становится правой, левая – центральной, правая просто кладется в стопку правых, а из стопки левых выбирается новая «следующая»
• сбрасываются установленные скриптом смещения для того, чтобы при изменении ширины всей страницы — например, при смене ориентации устройства — страницы блока автоматически адаптировались браузером к новым условиям
• очищаются установленные флаги вроде started

Таким образом, блок находится в исходном состоянии и готов к взаимодействию с пользователем.

Как дать понять, что блок можно листать — это тема отдельного доклада проектировщика интерфейсов. Я лишь могу сказать, что должна быть какая-то визуальная подсказка или иной путь переключения.

Например, в случае блока новостей, на примере которого я рассказываю о swipe, мы сделали привычные всем табы. Пользователь может тапнуть по закладке и перелистнуть страницу. Плюс таб является и заголовком, дающим понять какую страницу видно в данный момент.

Такой метод хорош и для совместимости с браузерами, не поддерживающими touch-события. Например, в WP IE пользователь с таким же успехом может пользоваться блоком новостей, как и на других устройствах.

На этом на сегодня все. Вопросы и обсуждение приветствуются.

Егор Дыдыкин,
лидер команды разработки главной страницы Mail.Ru и кросс-портальных проектов