Этот пост является частью Mobilizing веб-сайтов с адаптивным дизайном и учебником по HTML5 . Для всех сообщений, пожалуйста, см. Введение .
Нет отдельного «мобильного HTML».
Мобильные сайты — это обычные HTML-сайты. Отдельный протокол WAP уже несколько лет мертв. «Мобильный профиль XHTML» также мертв. Большинство телефонов делают нормальный HTML просто отлично.
Также в развивающихся странах, где использование мобильного Интернета более распространено по сравнению с настольным Интернетом, а база устройств ориентирована на функциональные телефоны с менее мощными веб-браузерами, широко используются браузеры для тонких клиентов, такие как Opera Mini, и они прекрасно поддерживают обычный HTML.
Основные соображения по поводу работы в Интернете на мобильных телефонах не являются техническими, с точки зрения протокола. Они включают
- Малый экран недвижимости
- Отсутствие физической клавиатуры
- Сенсорный экран вместо мыши в качестве указателя устройства
Смартфоны, такие как iPhone, Android и Blackberry, поддерживают новые функции HTML5 и CSS3, и в некоторых случаях мобильные браузеры имеют больше преимуществ, чем их настольные аналоги. Даже если вы не любите Apple как компанию как таковую, они много сделали для продвижения HTML5 в мобильном пространстве и перенесли опыт мобильного просмотра из старой, неуклюжей эпохи WAP в то, что вы действительно можете наслаждаться.
1. нет HTML5; есть только HTML
Окончательного стандарта HTML5 никогда не будет, и задавать вопрос, когда HTML5 будет готов, бессмысленно . Поставщики браузеров постоянно приспосабливают развивающиеся функции HTML к своим браузерам, и это зависит от обнаружения функций и изящных откатов, чтобы определить, можете ли вы сделать трюк с браузером или нет.
В мобильном пространстве функции HTML5 обеспечивают улучшения, улучшающие возможности серфинга
- Специализированные поля ввода для лучшего ввода текста на не аппаратных клавиатурах
- Использование стилей CSS3 вместо изображений для эффектов макета; это уменьшает полезную нагрузку передачи HTTP, заставляя страницы загружаться быстрее
- Поддержка сенсорных событий
- <video> и <audio> мультимедиа (в отличие от Flash)
- и т.п.
2. Стратегии построения мобильного сайта
Существует несколько вариантов «мобильной стратегии» вашего сайта.
- Адаптивный макет, как описано в этом руководстве
- Использование стандартной мобильной темы или надстройки для CMS с открытым исходным кодом ( Web и Mobile , WPTouch)
- Тематический HTML-прокси, такой как Diazo , является опцией, когда вы вообще не можете коснуться исходного кода внешнего интерфейса. Тематический прокси читает веб-HTML, анализирует его и преобразует результат в новый вывод мобильного HTML на основе правил (XSLT)
- Коммерческий скребок, который является темой прокси с причудливым пользовательским интерфейсом, например, Mobify.me
- Преобразования на стороне клиента с помощью Javascript, например Mobilize.js
- Иметь отдельно поддерживаемый мобильный сайт, используя специальную мобильную CMS с информацией, дублируемой вручную или использующей пользовательскую интеграцию. Подходит для крупных организаций, у которых большой маркетинговый бюджет и внутренние коммуникации.
Какую стратегию вам следует использовать, зависит от ваших навыков в области ИТ, организационной структуры и бизнес-целей. Вы должны балансировать между желаемым уровнем взаимодействия с пользователем, бюджетом и доступной компетенцией.
3. Инструменты для создания мобильного сайта
Поскольку мобильные сайты представляют собой обычный HTML, нет необходимости иметь конкретный «мобильный SDK» или «мобильную IDE».
Когда вы работаете над мобильным HTML, исключая этап тестирования устройства, нормально работает веб-браузер. Используйте инструменты разработчика Firefox + Firebug или Chrome / Safari +. Обычно вы не хотите разрабатывать в мобильных браузерах напрямую, так как в них отсутствуют инструменты проверки CSS, отладчик Javascript или какое-либо взаимодействие с источником HTML-страницы.
Примечание. Мобильные браузеры Opera предоставляют некоторые достойные возможности удаленной отладки HTML, CSS и Javascript через панель отладки Dragonfly.
4. Подмена браузера разработки как мобильного
При мобилизации веб-сайта с адаптивным дизайном единственная хитрость, которую вам обычно нужно использовать, — это сократить скорость реагирующей загрузки CSS, чтобы браузер разработки загружал мобильные таблицы стилей.
Вы можете сделать это на своем собственном уровне кода: вместо выборочной загрузки файла mobile.css принудительно загружайте его в браузер настольного компьютера путем жесткого кодирования mobile.css для загрузки для всех браузеров.
Вы можете включить условия на стороне сервера, которые позволяют выполнять подделку с помощью параметра URL:
http://site.com/?force-mobile=true
На уровне Javascript сенсорные события также могут нуждаться в подделке.
Примечание: не стоит заниматься мобильной разработкой, используя Internet Explorer в качестве браузера для разработки. Microsoft недавно улучшила свой послужной список в отношении открытых веб-стандартов, но им еще предстоит наверстать несколько лет, чтобы соответствовать темпам конкуренции.
5. Обнаружение агента пользователя
Пользовательский агент — это заголовок HTTP-запроса, который веб-браузер использует, чтобы сообщить веб-серверу версию программного обеспечения, которую использует веб-браузер.
Обнаружение пользовательского агента — это метод распознавания мобильных устройств на стороне сервера и предоставления им другой полезной нагрузки HTML. Я настоятельно не рекомендую использовать этот старый и устаревший метод мобилизации в современном мире, если вам действительно не нужно.
- Философия HTML заключается в том, чтобы клиентское устройство решало, как отображать информацию, а не веб-сервер, чтобы угадать, как. Сегодня мобильные устройства поддерживают достаточно Javascript, чтобы сделать это возможным.
- Обнаружение пользовательского агента хрупко, потому что сами строки пользовательского агента являются беспорядком, и на разных устройствах может быть один и тот же пользовательский агент или на разных устройствах разные пользовательские агенты: ложные срабатывания гарантируют
- Вам необходимо поддерживать базу данных устройств на стороне сервера, а качество доступных баз данных оставляет место для улучшения
- Разные полезные нагрузки HTML в зависимости от пользовательских агентов снижают производительность кэширования внешнего интерфейса, поскольку существуют тысячи типов устройств, и каждый из них создает свою собственную запись кэширования внешнего интерфейса.
- Кажется, что широко распространенный, полуоткрытый проект базы данных устройств Wurlf отталкивает своих пользователей
Если вам нужно иметь разные пути кода для мобильных устройств, используйте что-то вроде detemobile.js, которое выполняет обнаружение мобильных функций на стороне клиента, эффективно заменяя базу данных строк агента пользователя размером 5 МБ на 100 строк Javascript.
6. Нативные приложения
Нативное приложение в настоящее время является почти синонимом «встроенного WebKit» — если только вы не занимаетесь действительно высококлассными приложениями. Приложения выходят за рамки этого руководства.
Если вам нужно обернуть свой мобильный сайт для распространения в App Store, Android Market и т. Д., Вы можете использовать PhoneGap . Пользовательский опыт не так хорош, как создание дорогого 100% -ного собственного приложения с нуля, но ценник, как правило, легче проглотить.