Пару слов о Wap и PDA сайтах – 2
В прошлый раз мы обсудили WAP-сайты и, надеюсь, пришли к общему выводу, почему не стоит поддерживать эту технологию. Однако, вопрос остаётся открытым, т.к. нашим сайтам всё ещё необходима мобильная версия. Сегодня мы обсудим PDA-версии сайтов.
Изначально, PDA – это personal digital assistant, обычное портативное устройство с различными полезными свойствами. К PDA по умолчанию будем относить все устройства подпадающие под характеристику мобильных – КПК, коммуникаторы, смартфоны и т.п. Нас в PDA интересует только возможность доступа к интернет, наличие браузера и малый размер дисплея. При этом, считаем, что мобильный браузер работает с давно знакомым нам всем HTML/JS. Нужно сделать отдельную ремарку – PHP и другие серверные языки никак не зависят от девайса клиента. Именно потому, что эти языки серверные. Единственная проблема, которая может возникнуть на стороне серверных языков – это куки, и как следствие, сохранение сессии в куках. Как правило, все мобильные браузеры вполне адекватно работают с куками (по крайней мере, в линейке телефонов Nokia), а значит, волноваться не стоит. Но протестировать всё равно будет нужно. Об этом чуть ниже.
Таким образом, нас, в основном, будет интересовать клиентский вывод. Вот ссылки на несколько хороших статей о вёрстке для PDA и некоторых JavaScript проблемах, с которыми столкнулись авторы:
http://www.websovet.com/pda-versiya-sajta
http://habrahabr.ru/blogs/webdev/19381/
Касательно этих статей, от себя добавлю, что при верстке следует обратить внимание на такой момент – есть множество мелких функциональных элементов, которые остаются мелкими в PDA-версии сайта и это очень неудобно использовать в дороге. Дело в том, что тестировщик, как правило, не испытывает никаких трудностей при тестировании сидя в мягком и удобном кресле. Но если вы едете, например, в трясущемся автобусе по плохой дороге, то в мелкие элементы попасть стилусом очень проблематично. К таким элементам можно отнести пагинацию страниц, рядом расположенные микроскопические ссылки-иконки и т.п. Возмите за правило такие элементы отображать на приличном расстоянии друг от друга и достаточно крупными по размеру. Для PDA действует то же правило, что и для обычных сайтов – вертикальные скроллеры – это нормально, горизонтальные – резко не приветствуются. Хотя экран некоторых моделей может быть реверсивно развёрнут на 90 градусов (т.е. маленькая вертикаль, большая горизонталь) стоит всё же ориентироваться на нормальное положение устройства. Если вы делаете резиновую вёрстку, то при развороте экрана, текст вполне нормально заполнит всю область отображения. Чем меньше картинок, тем лучше, – вплоть до их отсутствия.
Так же, большой англоязычный ресурс с информацией по WAP/WML. Хоть я и разнес WAP в прошлой статье в пух и прах, но иметь ссылочку на ресурс с информацией по теме никогда не помешает.
http://www.developershome.com/
В общем-то, на этом можно было бы поставить точку. Кое-какую полезную информацию озвучили авторы статей, доступных по ссылкам. На тестировщика можно спихнуть тестирование юзабилити вашей верстки, а себе оставить только HTML-валидацию. Но мы будем упорны и упрямы, добиваясь совершенства. Давайте посмотрим на PDA-верстку с, в общем-то, обычной для веб-программиста стороны. Итак, вопрос на засыпку – а какие хэдеры получает сервер, когда юзер работает с мобильного девайса? Можно ли как-то их использовать? В одной из статей, ссылку на которую я привёл, автор писал о некоторых дополнительных хедерах, которые передают мобильные браузеры серверу. Я уверен, что вы хотите узнать, что это за новые хедеры и можно ли их использовать 🙂 Я знаю ответ, но пока вам его не скажу.
Что касается стандартного набора заголовков, то все заголовки подробно описаны в документе RFC-2068 (http://tools.ietf.org/html/rfc2068), который описывает HTTP протокол. Вот русская версия в Википедии
В RFC-2068 в т.ч. говорится, что кроме обязательных заголовков, которые должны распознаваться всеми без исключения серверами, работающими с HTTP, как запрос, так и ответ, может содержать нерегламентированные дополнительные заголовки. Вполне понятно, почему это делается – любой пользователь, программист или браузер может быть уверен в том, что обязательный минимум всегда соблюдается и, в случае нестандартных дополнительных заголовков, просто их игнорировать. Сами заголовки – это ни что иное как пара ключ = значение, которые передаются в HTTP запросе или ответе для указания серверу или клиенту, что нужно делать с данными, как их воспринимать и т.д.
Итак, у меня в наличии есть следующие тулзы:
- локалхост
- удалённый сервер
- мобильный девайс (nokia 5800) с встроенным браузером от nokia
- opera mobile, установленная на ту же нокию
- фаерфокс с плагином для просмотра хедеров
- эмулятор android
В принципе, этот список можно было бы дополнить другими эмуляторами или браузерами, но для моей цели этого вполне хватило.
Для начала, напишем маленький тривиальный скрипт на PHP.
//посмотрите статью про API, чтобы найти этот файл.
include('vd.php');
$request_headers = array();
foreach ($_SERVER as $k=>$v)
{
if(strstr($k, 'HTTP'))
{
//выбираем из переменной $_SERVER только HTTP-заголовки
$request_headers[$k] = $v;
}
}
//$str = implode("\n\r", $request_headers);
$str = '';
foreach ($request_headers as $k=>$v)
{
$str .= $k." => ".$v."\n\r";
}
$str .= "\n\r\n\r\n\r***********************\n\r\n\r\n\r";
//ведём лог обращений.
$fp = fopen('headers.txt', 'a+');
fwrite($fp, $str, strlen($str));
fclose($fp);
//теперь, после запроса, в файле сохраняются все хедеры,
//которые сервер получил от клиента.
//их мы и будем анализировать
// просмотр хедеров последнего запроса клиента на дисплее.
echo vd($request_headers);
Первое обращение к скрипту с локалхоста (фаерфокс) дало такие результаты:
HTTP_HOST => localhost HTTP_USER_AGENT => Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 HTTP_ACCEPT => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_LANGUAGE => ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3 HTTP_ACCEPT_ENCODING => gzip,deflate HTTP_ACCEPT_CHARSET => windows-1251,utf-8;q=0.7,*;q=0.7 HTTP_KEEP_ALIVE => 115 HTTP_CONNECTION => keep-alive HTTP_COOKIE => phpbb3_aaipn_k=27a6f9c4685cc68d; style_cookie=null; phpbb3_aaipn_u=2; phpbb3_aaipn_sid=f9869639649998139e5f312e984905f9; bblastvisit=1294275420; bblastactivity=0 HTTP_CACHE_CONTROL => max-age=0
Нет, я соврал. Это было второе обращение. В первом запросе почему-то отсутствовал HTTP_CACHE_CONTROL. Честно говоря, сейчас разбираться с этим нужды нет, т.к. оффтопик.
Ту же самую картину я увидел в предварительно запущенном плагине LiveHTTPHeaders 0.16 –
GET /ebookie/docs/index.php HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Cookie: phpbb3_aaipn_k=27a6f9c4685cc68d; style_cookie=null; phpbb3_aaipn_u=2; phpbb3_aaipn_sid=f9869639649998139e5f312e984905f9; bblastvisit=1294275420; bblastactivity=0 Cache-Control: max-age=0
Что ж, посмотрим на те же хедеры, при попытке запросить удалённый хост.
HTTP_ACCEPT => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 HTTP_ACCEPT_CHARSET => windows-1251,utf-8;q=0.7,*;q=0.7 HTTP_ACCEPT_ENCODING => gzip,deflate HTTP_ACCEPT_LANGUAGE => ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3 HTTP_CACHE_CONTROL => max-age=0 HTTP_CONNECTION => close HTTP_COOKIE => ------------- HTTP_HOST => ultimacreative.com HTTP_USER_AGENT => Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 HTTP_X_FORWARDED_FOR => 255.255.255.255 HTTP_X_REAL_IP => 255.255.255.255
Господа программисты, прошу прощения, но в целях собственной безопасности значения HTTP_COOKIE, HTTP_X_FORWARDED_FOR и HTTP_X_REAL_IP заменены на заведомо ложные. Что поменялось? Поменялся HTTP_CONNECTION. На самом деле, это тоже оффтоп, но объяснение тут очень простое – удалённый сервер передал в PHP заголовки уже после того, как закрыл HTTP соединение, в то время как локальный сервер передавал заголовки в PHP по ходу дела. Странно, почему поведение отличается? Надо будет как-нибудь покопать это на досуге, а пока просто отложим этот факт в глубине памяти и будем надеяться, что мы никогда из-за этого поведения не получим баг на продакшн-сервере заказчика после инсталляции очередного проекта.
Теперь обратимся к удалённому серверу с мобильного девайса и встроенного браузера. Результаты такие –
HTTP_ACCEPT => text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, application/java-archive, application/java, application/x-java-archive, text/vnd.sun.j2me.app-descriptor, application/vnd.oma.drm.message, application/vnd.oma.drm.content, application/vnd.oma.dd+xml, application/vnd.oma.drm.rights+xml, application/vnd.oma.drm.rights+wbxml, application/x-nokia-widget, text/x-opml, application/vnd.nokia.headwrapper, */*;q=0.5 HTTP_ACCEPT_CHARSET => iso-8859-1, utf-8;q=0.7, *;q=0.7 HTTP_ACCEPT_ENCODING => gzip, deflate, x-gzip, identity; q=0.9 HTTP_ACCEPT_LANGUAGE => ru;q=1.0, bg;q=0.5, en;q=0.5, de;q=0.5, hu;q=0.5, ro;q=0.5, uk;q=0.5 HTTP_CACHE_CONTROL => No-Cache HTTP_CONNECTION => close HTTP_HOST => www.ultimacreative.com HTTP_PRAGMA => No-Cache HTTP_USER_AGENT => Mozilla/5.0 (SymbianOS/9.4; U; Series60/5.0 Nokia5800d-1/21.0.025; Profile/MIDP-2.1 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like Gecko) Safari/413 HTTP_VIA => 1.1 Comverse 5.5.1 HTTP_X_FORWARDED_FOR => 255.255.255.255 HTTP_X_NOKIA_MUSICSHOP_BEARER => GPRS/3G HTTP_X_NOKIA_MUSICSHOP_VERSION => 11.0842.9 HTTP_X_REAL_IP => 255.255.255.255 HTTP_X_WAP_PROFILE => "http://------------------.xml "
Отчётливо видны изменения юзер-агента. Обратите на это внимание. Это важно. Что касается остальных хедеров… Смех сквозь слёзы 🙂 Например, вот этот вот заголовок – HTTP_X_NOKIA_MUSICSHOP_VERSION. Интересно, эти горячие финские парни из нокии действительно считают, что ради того, чтобы узнать, зачем они приплели в мобильный браузер версию какого-то музыкального магазина, пусть даже и от нокии, кто-то полезет в дебри мануала по симбиан? Нет, я понимаю зачем это было сделано. Раз у меня нокия, значит музыку я должен только покупать и непременно в фирменном магазине 😀 И тут, оппа! Мой браузер скажет магазину, какая у него версия 😀 А заодно, и всему остальному интернету 😀 Ладно, поехали дальше 🙂
Следующий запрос от Opera Mobile, установленной на nokia 5800 –
HTTP_ACCEPT => text/html, application/xml;q=0.9, application/xhtml+xml, application/x-obml2d, multipart/mixed, application/vnd.wap.multipart.mixed, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 HTTP_ACCEPT_CHARSET => iso-8859-1, utf-8, utf-16, *;q=0.1 HTTP_ACCEPT_ENCODING => deflate, gzip, x-gzip, identity, *;q=0 HTTP_ACCEPT_LANGUAGE => ru-RU, ru;q=0.9, en;q=0.8 HTTP_CACHE_CONTROL => No-Cache HTTP_CONNECTION => close HTTP_HOST => www.ultimacreative.com HTTP_TE => deflate, gzip, chunked, identity, trailers HTTP_USER_AGENT => Opera/9.80 (S60; SymbOS; Opera Mobi/353; U; ru) Presto/2.4.15 Version/10.00 HTTP_VIA => 1.1 Comverse 5.5.1 HTTP_X_FORWARDED_FOR => 255.255.255.255 HTTP_X_REAL_IP => 255.255.255.255
В общем, тут картина более вменяемая. Юзер-агент опять претерпел изменения. Хотя, к сожалению, опера не договорилась со встроенным браузером, как именовать операционную систему. В то время, как встроенный браузер гордо именует ось полным названием, опера пренебрежительно сокращает до S60; SymbOS;
И на закуску посмотрим хедеры из Android эмулятора –
HTTP_ACCEPT => application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_CHARSET => utf-8, iso-8859-1, utf-16, *;q=0.7 HTTP_ACCEPT_ENCODING => gzip HTTP_ACCEPT_LANGUAGE => en-US HTTP_CONNECTION => close HTTP_HOST => ultimacreative.com HTTP_USER_AGENT => Mozilla/5.0 (Linux; U; Android 1.5; en-us; sdk Build/CUPCAKE) AppleWebKit/528.5+ (KHTML, like Gecko) Version/3.1.2 Mobile Safari/525.20.1 HTTP_X_FORWARDED_FOR => 255.255.255.255 HTTP_X_REAL_IP => 255.255.255.255
Просто, со вкусом и без избыточности.
А теперь, самое интересное – подводим итоги.
Анализируя все эти хедеры, мы можем однозначно утверждать следующее –
- Все протестированные браузеры поддерживают хедер Accept со значением text/html. Так что не стесняемся указывать правильный DOCTYPE.
- Все протестированные браузеры поддерживают кодировку utf-8
- Для однозначной идентификации протестированных браузеров достаточно только HTTP_USER_AGENT. Все остальные “фирменные” хедеры можно абсолютно просто игнорировать и вообще не стоит о них упоминать. Исключение составляет только ситуация, когда вы верстаете сайт для КОНКРЕТНОГО мобильного устройства, вплоть до точной модели и точной версии программного обеспечения. Но эта ситуация скорее фантастическая, нежели реальная.
- Ни один мобильный браузер не отправляет серверу самой главной информации – разрешения собственного экрана 🙁 Это, конечно, за рамками стандарта HTTP, но раз версию музыкального магазина можно, то разрешение сам бог велел.
Конечно, учитывая многообразие платформ и браузеров, этот обзор должен допускать вероятность невыполнения каких-то пунктов. Но, интуиция, подкреплённая опытом и стандартами w3c, подсказывает, что тестирование других браузеров и устройств покажет те же результаты.
Осталось сказать несколько слов о тестировании на эмуляторах. Дело в том, что софт, написанный для мобильника, обязан тестироваться на девайсе. Это негласное правило. Так уж сложилось, что на эмуляторах тесты проходят абсолютно все программы, а на конкретном железе эти программы начинают глючить, ломаться и жрать батарею. Но в вопросах веб-разработки мы этим можем вполне нормально принебречь, т.к. наш софт пишется для сервера, а для мобильника только лишь верстается. Для тестирования мобильной верстки вполне подходит эмулятор с браузером и с возможностью задавать нужные размеры экрана. При этом, тестирование обязано проводится на эмуляторах самых популярных мобильных платформ. Среди них – Android, Symbian, iPhone OS, Windows Mobile, Blackberry. И, заканчивая на мажорной ноте, – эмуляторы можно бесплатно скачать с сайтов производителей девайсов.
Да. Чуть не забыл. Кроме смартфонов и коммуникаторов в интернет можно ходить с обычных мобильных телефонов, которые также имеют встроенный браузер и микроскопический экранчик. Перефразируя Шекспира, – поддерживать или нет? Вот в чём вопрос!
Буду рад ответить на ваши вопросы в комментариях. Всем удачи.
В тему: