Определение браузера как мобильного
Определение мобильных браузеров на PHP
С быстрым развитием рынка мобильных устройств становится актуальной тема создания сайтов для них. Это могут быть самостоятельные страницы сайтов, или же просто облегченные версии страниц с минимумом графики, особыми стилями, версткой, чтобы сайт можно было комфортно просматривать на маленьком экранчике мобильного телефона или КПК. И лучше делать это автоматически, не заставляя пользователя искать на основном сайте какие-то дополнительные ссылки. Например, если вы откроете с мобильного телефона любую страницу моего сайта, то вас автоматически переадресует на облегченную версию этой же страницы для мобильных устройств. Определять браузер средствами PHP мы уже умеем, главная сложность - выделить сигнатуры браузеров мобильных устройств. К счастью, это уже сделано на сайте Detect Mobile Browsers. Весь сайт целиком посвящен только одному скрипту для определения мобильных браузеров, но сам скрипт обвешан ненужными наворотами и написан каким-то жутким стилем, так что в исходном виде практически бесполезен. А вот позаимствовать из него сигнатуры и некоторые другие методы определения вполне можно, что и было сделано. Код полностью вычищен и оптимизирован.
- //--------------------------------------------------------------------
- // Функция проверки принадлежит ли браузер к мобильным устройствам
- // Возвращает 0 - браузер стационарный или определить его не удалось
- // 1-4 - браузер запущен на мобильном устройстве
- //--------------------------------------------------------------------
- function is_mobile ()
- $user_agent = strtolower ( getenv ( 'HTTP_USER_AGENT' ));
- $accept = strtolower ( getenv ( 'HTTP_ACCEPT' ));
- if (( strpos ( $accept , 'text/vnd.wap.wml' )!== false ) ||
- ( strpos ( $accept , 'application/vnd.wap.xhtml+xml' )!== false ))
- return 1 ; // Мобильный браузер обнаружен по HTTP-заголовкам
- >
- if (isset( $_SERVER [ 'HTTP_X_WAP_PROFILE' ]) ||
- isset( $_SERVER [ 'HTTP_PROFILE' ]))
- return 2 ; // Мобильный браузер обнаружен по установкам сервера
- >
- if ( preg_match ( '/(mini 9.5|vx1000|lge |m800|e860|u940|ux840|compal|' .
- 'wireless| mobi|ahong|lg380|lgku|lgu900|lg210|lg47|lg920|lg840|' .
- 'lg370|sam-r|mg50|s55|g83|t66|vx400|mk99|d615|d763|el370|sl900|' .
- 'mp500|samu3|samu4|vx10|xda_|samu5|samu6|samu7|samu9|a615|b832|' .
- 'm881|s920|n210|s700|c-810|_h797|mob-x|sk16d|848b|mowser|s580|' .
- 'r800|471x|v120|rim8|c500foma:|160x|x160|480x|x640|t503|w839|' .
- 'i250|sprint|w398samr810|m5252|c7100|mt126|x225|s5330|s820|' .
- 'htil-g1|fly v71|s302|-x113|novarra|k610i|-three|8325rc|8352rc|' .
- 'sanyo|vx54|c888|nx250|n120|mtk |c5588|s710|t880|c5005|i;458x|' .
- 'p404i|s210|c5100|teleca|s940|c500|s590|foma|samsu|vx8|vx9|a1000|' .
- '_mms|myx|a700|gu1100|bc831|e300|ems100|me701|me702m-three|sd588|' .
- 's800|8325rc|ac831|mw200|brew |d88|htc\/|htc_touch|355x|m50|km100|' .
- 'd736|p-9521|telco|sl74|ktouch|m4u\/|me702|8325rc|kddi|phone|lg |' .
- 'sonyericsson|samsung|240x|x320vx10|nokia|sony cmd|motorola|' .
- 'up.browser|up.link|mmp|symbian|smartphone|midp|wap|vodafone|o2|' .
- 'pocket|kindle|mobile|psp|treo|android|iphone|ipod|webos|wp7|wp8|' .
- 'fennec|blackberry|htc_|opera m|windowsphone)/' , $user_agent ))
- return 3 ; // Мобильный браузер обнаружен по сигнатуре User Agent
- >
- if ( in_array ( substr ( $user_agent , 0 , 4 ),
- Array( "1207" , "3gso" , "4thp" , "501i" , "502i" , "503i" , "504i" , "505i" , "506i" ,
- "6310" , "6590" , "770s" , "802s" , "a wa" , "abac" , "acer" , "acoo" , "acs-" ,
- "aiko" , "airn" , "alav" , "alca" , "alco" , "amoi" , "anex" , "anny" , "anyw" ,
- "aptu" , "arch" , "argo" , "aste" , "asus" , "attw" , "au-m" , "audi" , "aur " ,
- "aus " , "avan" , "beck" , "bell" , "benq" , "bilb" , "bird" , "blac" , "blaz" ,
- "brew" , "brvw" , "bumb" , "bw-n" , "bw-u" , "c55/" , "capi" , "ccwa" , "cdm-" ,
- "cell" , "chtm" , "cldc" , "cmd-" , "cond" , "craw" , "dait" , "dall" , "dang" ,
- "dbte" , "dc-s" , "devi" , "dica" , "dmob" , "doco" , "dopo" , "ds-d" , "ds12" ,
- "el49" , "elai" , "eml2" , "emul" , "eric" , "erk0" , "esl8" , "ez40" , "ez60" ,
- "ez70" , "ezos" , "ezwa" , "ezze" , "fake" , "fetc" , "fly-" , "fly_" , "g-mo" ,
- "g1 u" , "g560" , "gene" , "gf-5" , "go.w" , "good" , "grad" , "grun" , "haie" ,
- "hcit" , "hd-m" , "hd-p" , "hd-t" , "hei-" , "hiba" , "hipt" , "hita" , "hp i" ,
- "hpip" , "hs-c" , "htc " , "htc-" , "htc_" , "htca" , "htcg" , "htcp" , "htcs" ,
- "htct" , "http" , "huaw" , "hutc" , "i-20" , "i-go" , "i-ma" , "i230" , "iac" ,
- "iac-" , "iac/" , "ibro" , "idea" , "ig01" , "ikom" , "im1k" , "inno" , "ipaq" ,
- "iris" , "jata" , "java" , "jbro" , "jemu" , "jigs" , "kddi" , "keji" , "kgt" ,
- "kgt/" , "klon" , "kpt " , "kwc-" , "kyoc" , "kyok" , "leno" , "lexi" , "lg g" ,
- "lg-a" , "lg-b" , "lg-c" , "lg-d" , "lg-f" , "lg-g" , "lg-k" , "lg-l" , "lg-m" ,
- "lg-o" , "lg-p" , "lg-s" , "lg-t" , "lg-u" , "lg-w" , "lg/k" , "lg/l" , "lg/u" ,
- "lg50" , "lg54" , "lge-" , "lge/" , "libw" , "lynx" , "m-cr" , "m1-w" , "m3ga" ,
- "m50/" , "mate" , "maui" , "maxo" , "mc01" , "mc21" , "mcca" , "medi" , "merc" ,
- "meri" , "midp" , "mio8" , "mioa" , "mits" , "mmef" , "mo01" , "mo02" , "mobi" ,
- "mode" , "modo" , "mot " , "mot-" , "moto" , "motv" , "mozz" , "mt50" , "mtp1" ,
- "mtv " , "mwbp" , "mywa" , "n100" , "n101" , "n102" , "n202" , "n203" , "n300" ,
- "n302" , "n500" , "n502" , "n505" , "n700" , "n701" , "n710" , "nec-" , "nem-" ,
- "neon" , "netf" , "newg" , "newt" , "nok6" , "noki" , "nzph" , "o2 x" , "o2-x" ,
- "o2im" , "opti" , "opwv" , "oran" , "owg1" , "p800" , "palm" , "pana" , "pand" ,
- "pant" , "pdxg" , "pg-1" , "pg-2" , "pg-3" , "pg-6" , "pg-8" , "pg-c" , "pg13" ,
- "phil" , "pire" , "play" , "pluc" , "pn-2" , "pock" , "port" , "pose" , "prox" ,
- "psio" , "pt-g" , "qa-a" , "qc-2" , "qc-3" , "qc-5" , "qc-7" , "qc07" , "qc12" ,
- "qc21" , "qc32" , "qc60" , "qci-" , "qtek" , "qwap" , "r380" , "r600" , "raks" ,
- "rim9" , "rove" , "rozo" , "s55/" , "sage" , "sama" , "samm" , "sams" , "sany" ,
- "sava" , "sc01" , "sch-" , "scoo" , "scp-" , "sdk/" , "se47" , "sec-" , "sec0" ,
- "sec1" , "semc" , "send" , "seri" , "sgh-" , "shar" , "sie-" , "siem" , "sk-0" ,
- "sl45" , "slid" , "smal" , "smar" , "smb3" , "smit" , "smt5" , "soft" , "sony" ,
- "sp01" , "sph-" , "spv " , "spv-" , "sy01" , "symb" , "t-mo" , "t218" , "t250" ,
- "t600" , "t610" , "t618" , "tagt" , "talk" , "tcl-" , "tdg-" , "teli" , "telm" ,
- "tim-" , "topl" , "tosh" , "treo" , "ts70" , "tsm-" , "tsm3" , "tsm5" , "tx-9" ,
- "up.b" , "upg1" , "upsi" , "utst" , "v400" , "v750" , "veri" , "virg" , "vite" ,
- "vk-v" , "vk40" , "vk50" , "vk52" , "vk53" , "vm40" , "voda" , "vulc" , "vx52" ,
- "vx53" , "vx60" , "vx61" , "vx70" , "vx80" , "vx81" , "vx83" , "vx85" , "vx98" ,
- "w3c " , "w3c-" , "wap-" , "wapa" , "wapi" , "wapj" , "wapm" , "wapp" , "wapr" ,
- "waps" , "wapt" , "wapu" , "wapv" , "wapy" , "webc" , "whit" , "wig " , "winc" ,
- "winw" , "wmlb" , "wonu" , "x700" , "xda-" , "xda2" , "xdag" , "yas-" , "your" ,
- "zeto" , "zte-" )))
- return 4 ; // Мобильный браузер обнаружен по сигнатуре User Agent
- >
- return false ; // Мобильный браузер не обнаружен
- >
Функция возвращает false, если браузер стационарный или по каким-то причинам его не удалось определить. Если браузер запущен на мобильном устройстве, то результат будет от 1 до 4, это код метода, которым он был определен. Сигнатуры на сайте время от времени пополняются, так что можете брать их оттуда самостоятельно и дополнять эту функцию.
От автора: простой и эффективный способ определения мобильных браузеров. Предложение Client Hints уже доступно в Google Chrome и представляет собой очень экономичный способ обнаружения (среди прочего) мобильных устройств.
Стоит ли мне его уже использовать?
Если эта функция широко не поддерживается, стоит ли ее использовать?
Используя эту функцию сегодня, мы потенциально можем улучшить производительность для большинства пользователей и сеансов.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Недостатки парсинга User-Agent
Один из известных методов определения того, считается ли браузер мобильным, настольным или любым другим форм-фактором — это извлечение информации из строки пользовательского агента, особенно для серверов, которые не могут выполнять определение функций. Так почему я считаю это неоптимальным?
Это очень нестабильно: Строки пользовательского агента нерегулярны и не соответствуют строгому формату, в результате все проверки выполняются вручную. Целые библиотеки и базы данных построены на этой ошибке.
Это затратно: Из-за низкой точности структуры строки пользовательского агент, сопоставления являются сложными, часто не ориентированными на какую-либо конкретную функцию пользовательского агента.
По этим и другим причинам группа сообщества W3C предложила стандартный способ объявления функций пользовательского агента, который включает, среди прочего, особую подсказку для определения мобильного браузера.
Примеры реализации
Реализация браузера с резервным вариантом
Мы уже писали о методах (Mobile First и Response Web Design), которые используем при разработке нашего сервиса. В этой статье я хочу поделиться с вами нашим опытом. То, что в теории кажется простым, на практике порой оборачивается кошмаром. Речь пойдет о том, как нам удается создавать универсальный веб-сервис, способный работать на большом количестве устройств.
Классы поддержки браузеров
На рынке тысячи устройств, несколько платформ и мобильных браузеров. Давайте посмотрим на глобальную статистику распространенности мобильных браузеров. На графике представлены данные StatCounter за прошедший год. Нас интересовали лидеры — Opera, Mobile Safari, Android и Nokia (у всех, кроме Оперы, браузер работает на движке WebKit).
Мы позаимствовали у Yahoo идею классовой поддержки браузеров, которая определяет следующие три класса:
- Браузеры класса «С» не получают JavaScript и CSS. Осуществляя поддержку этого класса, мы гарантируем получение контента любым пользователем. В этот класс мы отнесли Internet Explorer 7-ой версии и ниже.
- В класс «А» попадают самые распространенные браузеры, поддерживающие многие стандарты. В этих браузерах осуществляется обязательное тестирование. Мы отнесли в этот класс Internet Explorer 8 и 9 и последние стабильные версии Chrome, Safari, Firefox, Opera, Opera Mobile, а также Opera Mini 4 и 6.
- В класс «Х» попадают браузеры, отсутствующие в обоих классах. Это, как правило, старые версии браузеров из класса «A» и их последние нестабильные версии. Определяя браузер в этот класс, мы предполагаем, что в нем будут отсутствовать какие-либо серьезные ошибки. В этих браузерах мы не проводим тестирование.
Таким образом, осуществляя поддержку класса «C», мы гарантируем, что контент будет получен пользователем, и он будет способен с ним работать. Это означает, что без поддержки отображения картинок, JavaScript и CSS, пользователь будет способен ориентироваться в контенте. Это базис для класса «A» и всего приложения.
Адаптивный дизайн
Несколько слов о том, какие основные требования предъявлялись к веб-дизайну. Во-первых, это «пиксель-перфект» при просмотре мобильной версии сайта на десктопе (то есть необходимо было придерживаться попиксельного соответствия верстки и макета). Во-вторых, поддержка touch-устройств. И, в-третьих, минимальное поддерживаемое разрешение экрана равнялось 240 пикселям по ширине.
Почему же 240? Дело в том, что это ширина экрана телефона Nokia на платформе S60 третьего поколения, выпущенного в 2006 году, и (внимание!) с WebKit-браузером на борту, то есть с частичной поддержкой CSS3 и JavaScript 1.5. Очень сложно найти на рынке мобильный телефон с меньшим разрешением экрана, который бы использовался для интернет-серфинга.
Резиновая верстка, на которой строится адаптивный веб-дизайн, не подходит для «пиксель-перфект», помимо прочего нам было необходимо ограничить пространство ленты с контентом. Поэтому, указав минимально и максимально допустимые значения ширины, мы получили тянущийся до определенных крайних значений блок с контентом.
Для маленьких экранов мы уменьшаем значения отступов у основных блоков с помощью media queries. И вообще, когда начинаем разрабатывать какой-то блок, то определяем, как он будет отображаться на устройствах с низким разрешением экрана, какие элементы блока будут отключаться или заменятся и на что с помощью media queries.
Важно помнить, что, хоть телефон 7-летней давности с Opera Mini 4 и поддерживает media queries, но их не поддерживает Internet Explorer 8. Поэтому в своем проекте мы использует media queries для деградации, то есть в сторону уменьшения размера экрана устройств.
В ленте мы используем «плавающие» изображения, которые подстраивают свою ширину под ширину родительского элемента, сохраняя при этом оригинальные пропорции. Указав max-width равным 100%, вы запрещаете картинкам быть больше, чем оригинальный размер в случае, когда контейнер оказывается шире картинки.
На изображении ниже вы можете видеть, что картинка сжалась до размера ленты, а с помощью media queries были уменьшены отступы внутри ленты и скрытыми оказались фон, дополнительные слои с тенями и элементы шапки страницы.
Особенности работы мобильных браузеров
Современные мобильные браузеры отлично показывают страницы, не созданные для таких низких разрешений, какими обладают мобильные устройства. Как вы, должно быть, знаете, им это удается за счет использования логического, а не физического разрешения. Например, iPhone по умолчанию рендерит страницу в окне шириной 980 пикселей и показывает уменьшенный вариант, позволяя пользователю масштабировать отдельные участки страницы. При разработке мобильного сервиса такое поведение крайне нежелательно, поэтому необходимо браузеру указать размер логического окна равным физическому размеру экрана устройства (за это отвечает значение device-width в примере ниже).
Параметры minimum-scale и maximum-scale определяют допустимые значения масштабирования страницы. Если их задать равными единице, то вы запретите пользователю менять масштаб страницы. Для этих целей существует еще один параметр — user-scalable . Если у вас в дизайне имеются элементы со свойстовом position равным fixed, то обязательно укажите этот параметр равным 0, чтобы активировать поддержку position: fixed в Андроиде (установкой в одинаковое значение параметров minimum-scale и maximum-scale такого не добиться).
В мобильных браузерах (в особенности в touch-устройствах) может отсутствовать поддержка псевдо-классов :hover , :focus и :active . Поэтому, если в дизайне есть функционал, который необходимо показывать только по наведению мышки на родительский элемент, следует по умолчанию оставлять такие элементы видимыми. А после загрузки страницы, определив тип устройства, скрывать их с помощью каскадов в CSS. Например, следующим образом:
Хочется отметить, что определение возможностей браузера становится как никогда предпочтительней определения наименования и версии браузера. Ведь мы делаем сервис, способный работать на каком угодно устройстве.
JavaScript и AJAX — это круто. Но нужно понимать, что не всем, чем удобно пользоваться на большом экране, будет удобно пользоваться на экране шириной 240 пикселей. Многие динамические вещи мы отключаем для маленьких экранов, как например, возможность написать ответ в ленте без перехода на отдельную страницу (в телефоне это оказывается не таким приятным действием, потому как интерфейс «тормозит» и дергается).
Мы придерживаемся концепции Progressive Enhancement, которая заключается в использовании простой семантической верстки для представления всего контента и функционала, а последние нововведения в CSS и JavaScript должны быть лишь приятным улучшением пользовательского взаимодействия. Это позволяет гарантировать работу проекта на любом устройстве, поддерживающем HTML. Таким образом, нет ничего сложного в том, чтобы отключать какие-то тяжелые вещи для устройств с низким разрешением экрана (как правило, они обладают меньшим объемом оперативной памяти и низкой производительностью). Вот обычный пример обработчика события клика по кнопке, которая отправляет некоторую форму.
Я хочу заметить, что мы не отключаем весь JavaScript – только функции, которые удобней было бы совершать на отдельных страницах, специально созданных для таких случаев.
Практика
Теперь давайте попробуем создать вот такую интересную кнопку.
У кнопки градиентные границы и фон, есть иконка и текст, а может быть только иконка или текст. Эта кнопка играет роль собирательного образа, на примере которого я попытаюсь охватить как можно больше проблем.
Градиенты сделаем с помощью CSS, для этого поместим в кнопку еще один элемент button__inner . Сделаем возможным, чтобы обычные ссылки выглядели как наша кнопка. Здесь и далее будет приводиться код CSS, в котором опущены многие свойства, типа цветов и градиентов, и будет использоваться синтаксис Sass (SCSS). Sass это метаязык на основе CSS, в котором есть поддержка переменных, выражений, примесей и много другого.
По требованиям, у кнопки должны быть границы шириной $border-width пикселей, а высота должна равняться $height пикселей. Поэтому для класса button мы сделаем педдинг равным $border-width , а высоту равной требуемой высоте $height за вычетом педдингов. Для вертикального выравнивания элементов внутри button__inner, таких как иконки и текст, воспользуемся указанием line-height , равным всему свободному пространству.
На нашем проекте мы не используем элемент IMG для создания иконок. И вот почему. Сделаем сначала кнопку, в которой для отображения иконки будет использоваться элемент IMG . В качестве источника картинки укажем путь до файла с прозрачной картинкой, а через CSS свойства background-image и background-position укажем иконку в спрайте. Это, пожалуй, самый известный способ создания спрайтовых иконок.
От этого варианта нам пришлось отказаться по двум причинам:
- Альтернативный текст может вовсе не отображаться браузером (так делает WebKit).
- Нет возможности обеспечить функционирование такого элемента в браузерах с отключенным CSS.
IE6 | Chrome |
---|---|
- В десктоп режиме страницы отображаются практически так же, как и в большой Опере, за тем исключением, что браузер все-таки постарается уместить блоки с текстом по ширине экрана, чтобы исключить появление горизонтального скролла.
- Второй режим — мобильный, переключиться в который можно из настроек браузера. Находясь в нем, Opera форматирует страницу в такой вид, чтобы она уместилась в одну колонку, т.е. стала удобной для просмотра на устройстве с небольшим экраном без появления горизонтального скролла.
Еще несколько слов о media queries и мобильном режиме Opera Mini. Давайте теперь заставим кнопочку с иконкой и текстом скрывать текст на экране с разрешением меньшим или равным 320 пикселям по ширине:
Вроде бы все просто и в iPhone даже работает. Но не в Opera Mini в мобильном режиме:
Не забывайте, что в таком режиме Opera Mini определяет себя как handheld устройство. И в медиа запросах нужно либо явно указывать тип handheld, либо использовать волшебный идентификатор all.
Теперь несколько слов о мобильном Safari. Давайте сделаем кнопку из ссылки и делегируем обработчик событий click на ней элементу body .
Это пример кода с использованием jQuery, он работает, обработчик вызывается. Но стоит сделать кнопку на другом элементе, отличном от ссылки или элемента формы, например на DIV , как код перестает работать — обработчик не вызывается.
Дело в том, что событие click , выполненное не на ссылке или кнопке формы, не поднимется до body , и наш обработчик не будет вызван. Но если указать свойство cursor: pointer для класса button , то, о чудо, все начинает работать.
Заключение
Хочу отметить теперь, что современные мобильные браузеры практически не уступают своим большим братьям. Та же Opera Mini поддерживает media queries, частично CSS3 и JavaScript (хоть и с ограничениями). Однако у мобильных браузеров есть еще пара больших отличий:
- Поддержка position: fixed . Несмотря на то, что где-то поддержка и появилась (iOS 5, Android 3, Opera Mobile), реализация хромает, и пользоваться зачастую невозможно. Блоки с position: fixed могут застывать при скроллинге, исчезать и не появляться до следующего touch-события. Если браузер не поддерживает position: fixed , то элемент ведет себя так, как если бы ему было установлено свойство position: absolute .
- Поддержка свойства overflow: scroll . Пример отсутствия поддержки — Opera Mini, где скролл может быть один — на документ. Если браузер не поддерживает overflow: scroll , то элемент ведет себя так, как если бы ему было установлено свойство overflow: hidden . Поддержка этого свойства реализована в iOS 5, Android 3.2.
- Об ограничениях и особенностях работы Opera Mini (в том числе и JavaScript) вы можете прочитать на сайте Opera для разработчиков.
Я постарался рассказать о том, как мы создаем наш сервис, которым удобно пользоваться на ноутбуке, смартфоне и планшете, игровой консоли, телевизоре с выходом в интернет, и даже на холодильнике.
Однажды этот прекрасный день пришёл. День, когда я физически осознал, что мне нужно определять, каким устройством пользуется посетитель сайта, чтобы соответственно отрисовывать для него страницу.
Прошлая методика с помощью медиазапросов по ширине экрана в моих глазах себя изжила — в таком случае на страницу всё равно загружается все элементы, только часть из скрывается или модернизируется. С одной стороны — это правильный и надёжный подход. С другой стороны, когда у нас присутствуют тяжёлые медиафайлы (например, видеофон) или немного другое расположение элементов, то будет намного проще и лучше грузить только нужные элементы в зависимости от того, каким устройством пользуется посетитель сайта.
Проект постоянно поддерживается и обновляется, ибо весьма полезная вещь.
Подключается скрипт очень просто — с помощью requred_once мы указываем путь к файлу, а затем инициализируем объект:
Настройка скрипта завершена. Теперь через использование $detect мы можем определять устройства. Нам доступны следующие переменные для определения типа устройств:
- isMobile — переменная, которая определяет любое мобильное устройство — как смартфон, так и планшет;
- isTablet — переменная, которая предназначена для определения только планшетных компьютеров.
Также существуют две переменные для определения операционной системы мобильного устройства:
- isiOS — определяет устройства под управлением iOs (iPhone и iPad);
- isAndroidOS — устройства на Android;
- isWindowsMobileOS и isWindowsPhoneOS — тут можно не просто узнать, что эта мобильная система производства Microsoft, но даже указать его версии. WindowsMobile уже не столь актуальна, поскольку мелкомягкие перешли на единую платформу, но если вдруг к нам зайдут пользователи Pocket PC и Smartphone, то мы модем предложить для них уникальный сервис;
- isBlackBerryOS — можно определить также смартфоны этого производителя. Для России аппараты BlackBerry не слишком актуальны, но возможно всё (вдруг вы или ваш заказчик — фанат или пользователь этого девайса, и нужно сделать что-то особенное для других пользователей);
- isPalmOS и isSymbianOS — для устройств на таких операционных системах есть переменные для определения. Для меня это очень редкие устройства — настолько, что в жизни таких не видел (но это не точно), только на сайты заходят редкие пользователи этих устройств.
Кроме того, скрипт может определять производителя устройства. Укажу всего несколько переменных для определения вендора устройства, которые нам доступны:
- isiPhone и isiPad — можно чётко определить для каждого из устройств Apple, что показывать его пользователю;
- isSamsung — для устройств производства Samsung, один из самых популярных производителей;
- isLG — телефоны производства LG также весьма популярны и для них можно сделать что-то особое;
- isVertu — посетитель вашего сайта обладатель телефона Vertu, нужно больше золота (и умножаем все цены в магазине на 10).
В реальности этих переменных намного больше — на демо-странице скрипта можно увидеть список поддерживаемых переменных.
Для тех, кто хочет убойной точности и избирательности, можно указывать нужные устройства через значения UserAgent, но по мне такая избирательность уж слишком чрезмерная (хотя бывает всякое).
Разработчики не перестают совершенствовать свой продукт и вполне вероятно, что скоро нам будет доступна возможность определения версий браузеров и устройств (в первую очередь для продукции Apple) — функции уже есть в последнем релизе, но пока они находятся на бета-тестировании.
Этот пример немного бесполезный, но очень простой. Немного подумав, этот скрипт можно исползовать для более изящных решений, например, в зависимости от операционной системы подключать разные стили и изображения, чтобы дизайн сайта адаптировался под устройство. Либо, если на вашей странице есть реклама мобильного приложения, выводил предложения о переходе на AppStore или Google Play соответственно. Идей для применения может быть много.
Предлагаю вашему вниманию ещё один пример, который используется на моём сайте. Суть кода следующая — мы выводим разные варианты шапки сайта в зависимости от типа устройства. Код (с сокращениями) следующий:
И напоследок самое сладкое — эта библиотека была портирована на JavaScript, Varnish Cache и LUA.
На основе этого скрипта написаны плагины и модули для WordPress, Drupal, Joomla, Magento, PrestaShop (там он вообще поставляется в стандартном пакете с версии 1.5), Laravel, Yii Framework и множество других фреймворков и языков и платформ.
Недавно я разбирался с одним инфицированным сайтом. При заходе на него обычным браузером все было нормально, но при заходе с мобильных устройств, смартфонов и планшетников, пользователя автоматически перебрасывало на говносайт с троянами. Трояны у меня никаких эмоций не вызывают, а вот определение мобильных устройств было сделано очень интересно - через инфицированный файл .htaccess в корневом каталоге сайта. Я уже приводил пример определения мобильных браузеров на PHP, давайте посмотрим, как определение мобильных браузеров сделано в этом случае. В конец файла .htaccess был дописан следующий блок:
Как это все работает? На сервере обязательно должен быть включен модуль mod_rewrite, без него ничего не получится. Так что для надежности весь этот блок обернут в проверку наличия mod_rewrite у сервера Apache (в оригинальном коде этого не было). Дальше в модуле анализируется строка UserAgent браузера посетителя, в ней последовательно проверяется наличие подстроки, характерной для браузеров мобильных устройств. После этого проверяются специфические служебные заголовки, обычно отправляемые мобильными браузерами. Если хоть одно из этих условий выполнено, то следом выполняется дополнительная проверка на различные поисковые боты, а также некоторые другие сигнатуры, присущие стационарным браузерам или автоматическим модулям. Если и эта проверка пройдена удачно, то последней строчкой посетитель перенаправляется на мобильную версию сайта.
Нельзя однозначно сказать, что этот способ плох или хорош. У него есть как положительные стороны, так и явные недостатки. К плюсам можно отнести очень хороший процент правильного определения мобильных устройств, при этом вам не надо ничего менять в скриптах. А в случае появления новых мобильных устройств в список просто добавляются новые сигнатуры. Также этот метод будет прекрасно работать даже на статичных сайтах, вообще без какого-либо программирования. Минусы такого метода определения в том, что для мобильной версии придется создавать отдельный домен или субдомен. В принципе, это даже правильно, но так или иначе требует настроек на сервере. Еще к минусам можно отнести то, что ни вы, ни пользователь не сможете выбрать что открыть - полную или мобильную версию сайта. Например, у меня на этом сайте мобильные устройства определяются средствами PHP, но с мобильной версии сайта всегда можно переключиться на полную, и ей можно пользоваться даже с мобильного устройства. При работе через .htaccess пользователь без вариантов всегда будет переадресовываться на мобильную версию. Так что как всегда, выбор инструментария определяется поставленной задачей.
Читайте также:
- Как в 1с сформировать карточку учета страховых взносов
- Curl не является внутренней или внешней командой исполняемой программой или пакетным файлом
- Как запросить ттн из егаис в 1с розница
- Неподдерживаемый формат выберите другой файл рингтон xiaomi
- Условное форматирование в excel несколько условий одновременно