полноценное приложение на html5

Мобильная веб-разработка: HTML5 приложение для Android

Вступление

К счастью, есть более чем один способ написать приложение для мобильного телефона. Можно сделать сайт, упаковать его специальным образом, и вуаля, вот вам и приложение! Именно такой подход предлагает нам проект phonegap.com именно об этом методе и пойдет речь в этой статье.

Уверен что ни стоит обсуждать экономическую целесообразность данного подхода. Она на лицо. Да, знаний нужно больше чем у среднестатистического веб разработчика, но все же, это сайт! Это понятно! Это тот же HTML, это тот же броузер, тот же Javascript. Найти разработчика ни так сложно, как скажем “нативного”. А уж если умножить на кроссплатформенность данного решения, так и вообще может показаться что это панацея. Конечно, мы то с вами знаем, что ни какой “пилюли” не существует, но в ряде случае, это действительно best practic

Итак, мое рабочее задание звучало так: Разработать клиентское приложение, под ОС Android. Приложение — игра. Квест. Суть игры заключается в следующем: группа людей, желающих интересно отдохнуть, делятся на команды. Каждой команде дается по смартфону. В смартфоне приложение. Открываем приложение. Приложение соединяется с сервером и оттуда приходят вопросы. Для каждой команды они свои. Вопросы могут выглядеть как обычные вопросы с вариантами ответов, ну скажем Сколько лет городу Санкт-Петербург?, так и вопросы локации. Найдите парадный вход в инженерный замок. Команда двигается, находит вход, нажимает Мы на месте и координаты уходят на сервер. От сервера ответ, верно или нет. Есть также вопросы фотографии. Например Сфотографируйте себя на фоне инженерного замка. В сумме, все ответы оцениваются и в итоге одна из команд выигрывает, набирая больше очков. Вкратце все.

Шаг 1 — протитипы

В общем задание нам понятно. Предположим что техническое задание уже составлено. Что еще? Нужны прототипы. Вот они:

Шаг 2 — макеты

Следующий шаг. Нужно их от рисовать. Беремся за работу, получается следующее.

Шаг 3 — выбираем фреймворк

Возьмем Sencha Touch. Фреймворк сделан на подобие ExtJS. Большое количество классов. Компонуем их, настраиваем — получаем приложение. Доступ к HTML элементам есть, но на уровне фреймворка управлять элементами крайне не разумно. Грубо говоря, поменять стандартное визуальное отображение элементов крайне затруднительно. Зато данные от сервера получать в формате JSON одно удовольствие.

И наоборот. Jquerymobile это доступ к элементам, по сути расширенный Jquery. Добавляются теги к элементам. После загрузки фреймворк по этим тегам дополняет элементы стилями и другими элементами. Вот только подружить фрейморк с JSON данными от сервера у меня не получилось. Jquerymobile ждет от сервера html код. Безусловно можно получать JSON и его на стороне клиента преобразовывать в html код, что собственно и делает Sencha. Но это ни есть хорошая практика. Это идет в разрез с идеологией фреймворка. Возникает огромное количество проблем, решить которые крайне сложно.

Стоп. А зачем нам фреймворк? Что первый, что второй, по сути, это, так сказать, готовая элементная база, готовые решения, цель которых помочь вам сделать приложение (сайт) визуально похожим на нативное приложение. А нужно нам это? Нет. А как же PhoneGap? А что он, ему все равно, что вы используете. Ни где ни каких ограничений нет. Ну тогда давайте просто сверстаем приложение, как обычный сайт и дело с концом!

Шаг 4 — верстаем

Сам процесс верстки ни чем ни отличается от стандартного. Есть безусловно нюансы, вот о них и поговорим. Первым таким нюансом являются метатеги.

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

И самый последний нюанс это position:fixed. И это действительно проблема, ибо универсальных решений тут нет. Все упирается в сами мобильные броузеры, они просто не поддерживают, или поддерживают но не полностью, такой функционал. Ни получается закрепить панели управления одним решением для всех случаев. К примеру, jquerymobile, до версии 1.1, в случае если броузер не поддерживает position: fixed, эмулировал скроллирование и динамически менял позицию закреплённых элементов, что в общем-то не придавала реалистичности и порой выглядело “ни айс”.

Вот по этой ссылке есть описание мобильных броузеров, которые поддерживают position: fixed
bradfrostweb.com/blog/mobile/fixed-position
а также есть ссылки на Javascript библиотеки, которые эмулируют работу position: fixed и процесса скроллирования. К сожалению работу ни одного из них удовлетворительной назвать нельзя.

В моем конкретном случае, мобильная платформа была указана как Android 2.3, а она поддерживает position: fixed, но при этом пользовательский zoom работать не будет, что по сути в приложении ни к чему. Указываем в заголовке viewport

И прописываем стили

Шаг 5 — эмуляторы

Очевидно, что верстать и смотреть в броузере, в окне монитора, затруднительно. Разрешение андроид приложение, скажем 320×480, а какие размеры экрана у вашего монитора? На помощь приходят эмуляторы. Самый простой эмулятор уже есть в вашем броузере! Если вы загрузите сверстанные страницы в Google Chrome и нажмете Ctrl+Shift+I, броузер покажет вам инструменты разработчика. В правом нижнем углу вы можете найти иконку с шестеренкой, нажимайте на нее. Далее выбираем вкладку Override и вот он, ваш эмулятор. Выбираем User Agent и ставим галочку Device Metric. На первом этапе этого будет достаточно.

А еще есть эмулятор от самого PhoneGap! emulate.phonegap.com
Называется Ripple. Ставится в виде дополнений к Google Chrome. Ура! Наши возможности резко увеличились. В случае, если в своем приложении вы используете библиотеку cordova для расширения функционала приложения, скажем для работы с камерой телефона или компасом, то Ripple даст вам возможность симулировать данные процессы.

Ну и раз пошла речь про эмуляторы, нельзя ни сказать и про эмулятор, который ставиться вместе с Eclipse, если следовать инструкции от Phonegap
docs.phonegap.com/en/2.2.0/guide_getting-started_android_index.md.html#Getting%20Started%20with%20Android
Этот эмулятор уже ведет себя совсем как настоящее устройство. Все ошибки, какие были найдены на этом эмуляторе, все аналогичным образом были найдены и на устройстве. Ну и конечно нужно сказать, что пользоваться этим эмулятором оперативно сложно. Долго грузится, трудно текст набирать и т.д. Подходит он для самой последней стадии. Когда ваше приложение уже работает прекрасно на всех других ранее перечисленных эмуляторах.

Шаг 6 — программируем

Хоть статья и для программистов, размешать весь код тут просто глупо. Опишу в общем. Программирование веб приложение, по сути, ни отличается от программирование небольшого сайта. Тут те же методы и подходы, но выполнены на Javascript. Тот же MVC, те же паттерны: синглетон, компановщик и т.д.

Вот фронт контроллер

* В javascript нет магических методов. Если скажем в PHP мы можем использовать __call, и вызывать App.SomeSome(‘ ’), то тут нужно будем писать App.Run(‘SomeSome’, ‘ ’)

Вот пример контроллера:

Вот небольшой пример модели

Вот пример представления

По сути, тут тоже самое, что и в случае, если бы сайт писался на PHP. За исключением фундаментального принципа, Javascript — асинхронный язык и без callback тут ни как (если не использовать специальные библиотеки конечно же)

Отдельно хочется остановится на нюансах, а именно работа с фотокамерой смартфона. Из коробки javascript не умеет этого делать. На помощь приходит библиотека Cordova, которую предлагает подключить PhoneGap. А вот ссылка, на описание работы с камерой телефона

При работе с расширенными функциями Javascript и в частности с камерой, я ждал от них больше всего проблем. И не напрасно. Первое, с чем пришлось столкнутся, это с тем, что после фото съемки, камера просто показывала черный экран и не возвращалась обратно в приложение. Как оказалось, это связано с тем, что по умолчанию фотография делалась максимального качества и файл получался большой. Процесс его переноса в приложение, в следствие не большой мощности самого телефона, занимает существенное время. Пришлось внести изменения в демонстрационный код

Но и это оказалось еще не все. Метод getPicture возращает base64 закодированную картинку, а вот данные между сервером и клиентом передаются в виде запросов JSONP.
Очевидно что передать такое количество данных через GET запрос невозможно. Серверная часть, кстати, не помню говорил я или нет, на PHP. Да, не самое лучшее решение, про WebSocket можно забыть. Проксирование тоже не сделать. Вероятно, решение данной проблемы была одна из самых сложных. А решение нашлось следующее. Время идет и стандартные классы расширяются, добавляются новые методы. Так вот класс XMLHttpRequest обзавелся новыми событиями. Кроме стандартного onreadystatechange появилось также событие onload. Если обработчик ответа от сервера “повешать” на него, и в заголовке Content-Type указать application/x-form-urlencoded, то броузер будет делать кроссдоменный запрос методом POST, что, собственно нам и нужно. Вот пример

И еще, очень важный момент. Кроссдоменный запрос, не важно как он реализован, является синхронным, даже не смотря на то, что выше приведенный код выглядит как асинхронный.

Столкнулся я также и с проблемой Same Origin Policy. Решение этой проблемы лежит на серверной стороне. В конфигурационных файлах прописывается разрешение на кросс доменный запрос и дело с концом.

Хочется также отметить, что в случае, если вам не нужны расширенные функции работы с телефоном: акселерометр, компас, камера, медиа и т.д. подключать библиотеку cordova не обязательно (а это примерно 300 килобайт). Геолокация, кстати, доступна и без нее.

Шаг 7 — отлаживаем

После загрузки эмулятора, в панели LogCat Eclipse будет огромное количество сообщений. Первым вопрос который возникает — какие наши? Для того, чтобы видеть только свои ошибки, и в частности, видеть сообщения которые приложение выводит в консоль console.log, нужно настроить фильтр. В панели LogCat, слева, есть отдельный блок, Saved Filters. Открыв ее, вы конечно увидите пустой список, ибо фильтров у нас пока нет. Нажимаем на плюсик и видим окно

Вводим в Log Tag web console, как на картинке и теперь Log консоль будет показывать сообщения от вашего веб приложения.

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

Начинаем изучать ошибку. Очевидно что ошибка вызывается в момент получения данных с сервером. Ошибка говорит что приходит статус 0. Начинаем искать решение в Google, и вот что находим
simonmacdonald.blogspot.ru/2011/12/on-third-day-of-phonegapping-getting.html
stackoverflow.com/questions/11230685/phonegap-android-status-0-returned-from-webservice

Делаем вывод: вероятно нужно добавить статус 0, как верный статус, для продолжения обработки ответа сервера. Ищем, где же это сообщения JSCallback и находим его в файле cordova.js на строке 3740 (cordova-2.1.0.js)

Пробуем заменить if (xmlhttp.status === 200) на if (xmlhttp.status === 200 || xmlhttp.status === 0) и вуаля — ни какого эффекта!

Дальше не буду рассказывать как я потратил целый день, кружа вокруг этой ошибки. Скажу только, что был готов отчаяться, ибо ни что не могло мне помочь. Приложение все равно падало, пока я просто не решил закомментировать часть кода. И о чудо! Ошибка исчезла! Возвращая, по частям, свой код, я нашел его часть, которая приводила к ошибке.

Почему смена Хеша, приводила к такой ошибке, для меня осталось загадкой. Если у кого какие будут мысли на этот счет — велком.

Шаг 8 — запускаем

Чтобы запустить приложение уже не посредственно на телефоне, достаточно войти в решим настройки, выбрать раздел Разработка и там взвести галочку напротив пункта Отладка USB. Далее, нажимая RUN в eclipse, среда определит что у вас подключен телефон к USB, а я надеюсь вы уже это сделали, и начнет запускать приложение уже на аппарате.

Источник

Создание Web приложений с HTML 5

Это перевод статьи выложенной на сайте IBM. Автор — Michael Galpin, Software architect, eBay

Обобщение

Введение

Многие возможности и стандарты стали частью HTML 5. После того как вы определите какие функции доступны в сегодняшних браузерах,вы можете использовать эти возможности в вашем приложении. В этой статье вы узнаете как определить эти возможности и использовать современные Веб-технологии путем разработки приложения на примере. Большинство кода в этой статье только HTML, JavaScript, и CSS— это ядро технологии любого Веб-разработчика.

Начало

Для того чтобы следовать примерам самое важное что от вас потребуется — наличие нескольких браузеров для проверки. последнии версии Mozilla Firefox, Apple Safari, и Google Chrome настоятельно рекомендуются. При написании статьи использовались Mozilla Firefox 3.6, Apple Safari 4.04, и Google Chrome 5.0.322. Вы можете так же попробовать протестировать мобильные браузеры. Например, последние Android и iPhone SDKs исопльзовались для тестирования браузеров в их эмуляторах.

Вы можете скачать исходный код используемый в этой статье.

Примеры включают подключение очень маленького back-end компонента написаного на Java™. JDK 1.6.0_17 и использующего Apache Tomcat 6.0.14. Смотрите ссылки в конце статьи для того чтобы скачать эти приложения.

Определение возможностей

Есть старая шутка о том, что веб-разработчики уделяют 20% времени написанию кода и оставшиеся 80% тратят на то чтобы он работал на всех браузерах. Говорить что веб-разработчики привыкли к отличиям браузеров — несколько неверно. С новой волной инноваций в браузерах эта грустаня действительность опять имеет место быть. Возможности поддерживаемые последними и лучшими из браузеров — постоянно меняются.

Листинг 1. Скрипт определения

Огромное число возможностей и стандартов слилось в стандарте HTML 5. Эта статья фокусируется только на некоторых из них. Скрипт в Листинге 1 определяет четыре возможности:

Скрипт начинается с отображения user agent пользовательского браузера. Это (обычно) строка уникального для каждого из браузеров, хотя она может легко быть изменена. Просто повторю, что определение юзерагента будет хорошо для вашего приложения. Следующий шаг — начало определения возможностей. Сначало, проверяем Web workers через поиск функции Worker в глобальной области видимости (окно|window). Для этого используем одну идиому из JavaScript: double negation (двойное отрицание). Если функция Worker не существует, то window.Worker будет неопределенной, что будет значением «ложь» в JavaScript. Ввод одинарного отрицания перед ним превратит его в true, в вдойное отрицание превратит в false. После тестирования этого значения скрипт преобразует значение DOM структуры показанной в Листинге 2 для отображения результата теста.
Листинг 2. Определение DOM

Все популярные браузеры для настольных компьютеров поддерживают возможности в большей или меньшей степени:

Geolocation не поддерживает широко браузерами используемыми на настольных компьютерах, однако хорошо поддерживается в мобильных браузерах. Листинг 4 показывает список собранных данных для мобильных браузеров.
Листинг 4. Мобильные браузеры

Выше показаны данные для одного из последних симуляторов iPhone и двух вариантов для Android. Android 1.6 не поддерживает ничего из того что мы тестировали. По факту все это имеет место быть в нем, кроме воспроизведения видео, так как он использует Google Gears. Они эквивалентны API (через функцию), но не соблюдают Веб-стандарты которые мы используем для получения результата в Листинге 4. Сравните с Android 2.1, в нем все поддерживается правильно.

Обратите внимание, что iPhone поддерживает все кроме Web workers. Листинг 3 показывает, что настольная версия Safari поддерживает Web workers, так что есть резон не исключать вероятность появления в скором будущем такой возможности и на iPhone.

Теперь вы научились определять возможности пользовательского браузера, давайте изучим простое приложение которое использует несколько этих возможностей в комбинации—в зависимости от того что может пользовательский браузер. Вы создадите приложение используя Foursquare API для поиска нескольких популярных мест местоположения пользователя.

Создай приложение сегодня

В примере мы фокусируемся на использовании geolocation, но так же имейте в виду что Firefox 3.5+ так же поддерживает geolocation. Приложение начинает поиск звонков Foursquare вблизи текущего местоположения пользователя. Местоположение может быть любым, но обычно это рестораны, бары, магазины или что-то подобное. Будучи веб-приложением наш пример ограничен той же политикой ограничения свойственной всем браузерам. Оно не может вызывать Foursquare’s API напрямую. Вы будете использовать Java servlet как прокси для этих вызовов. В сервлете нет ничего специфичного для Java; вы можете легко переписать этот прокси на PHP, Python, Ruby, и даже на forth. Листинг 5 показывает прокси сервлет.
Листинг 5. Прокси сервлет для Foursquare

Важно отметить, что у вас проксифицирутеся два Foursquare API. Один для поиска, другой для получения детальной информации о месте нахождения. Чтобы их различать в API добавлен оперативный параметр. Вы так же можете указать JSON в качестве возвращаемого типа, для того чтобы позже легко разобрать данные используя JavaScript. Теперь, когда вы знаете какие вызовы совершает приложение и как оно получает данные, давайте посмотрим как оно будет их использовать для получения данных из Foursquare.

Использование geolocation

Это первый вызов в поиске. Листинг 5 показывает что вам требуется два параметра: geoLat и geoLong для широты и долготы. Листинг 6 ниже показывает как получить эти данные и совершить вызов сервлета.
Листинг 6. Вызов поиска с местоположением

Структурированное хранилище

Для сохранения данных о ТЦ в базу данных сначало созхдадим таблицу, в которой мы хотим сохранить данные. Для этого используется довольно стандартный синтаксис SQL для создания таблицы. (Все браузеры поддерживающие базы данных используют SQLite. Используйте документацию SQLite для изучения поддерживаемых, ограничиваемых и т.п. типах данных.) SQL выполняется асинхронно. Вызывается функция передачи данных и получаем данные. Функция callback получает переданный объект который мы можем использовать для выполнения SQL. Функция executeSQL принимает строку SQL, затем опциональные параметры, полюс правильность выполнения или функцию обработки ошибки. Если обработчика ошибок нет, то и ошибок нет. Для create table это хорошо. При первом запуске сценария таблица будет создана. В последующие запуски скрипт не сможет создать таблицу, так как таблица уже существует— но это правильно. вам это требуется просто для того, чтобы убедится что таблица создана, до того как будете делать вставку данных в нее.

После создания таблицы используем функцию forEach для вызова функции saveVenue с возвратом каждого торгового центра из Foursquare. Эта функция сначало делает запрос в БД чтобы убедится что такие данные уже не хранятся локально. Здесь вы видите исполнение обработчика. Результат полученный в запросе передается в обработчик. Если результатов нет, или ТЦ еще не был сохранен локально то вызывается функция insertVenue котора вставляет данные в БД.

После того как вы изучили использование БД если она поддерживается — следующий шаг — изучить работу Web worker если они поддерживаются.

Фоновые процессы с использованием Web workers

Вернемся к Листингу 6, и внесем в него изменения. Как показано ниже в Листинге 9, проверим браузер на поддержку Web worker. Если они поддерживаются — получим с их помощью больше информации о ТЦ.
Listing 9. Измененный поиск ТЦ

Код выше использует тоже определение возможностей что вы видели до этого. Если Web workers поддерживаются, то вы создаете нового worker. Для создания нового worker, вам требуется URL на другой скрипт, который worker будет выполнять, к примеру — details.js. Когда worker завершает работу, отправляет сообшение обратно в основной поток. Обработчик onmessage получает это сообщение; используйте простое его закрытие. Наконец, чтобы инициировать worker — вызовите postMessage с передачей некоторых данных для обработки. Вы передадите все данные полученные из Foursquare. Листинг 10 показывает соджержимое details.js, который является скриптом worker’ом.
Listing 10. Worker скрипт — details.js

По умолчанию поиск торговых центров возвращает 10 ТЦ. Вы можете себе представить сколько вызовов совершается чтобы получить детальные данные о каждом из них? Но Web workers делают задачу легкой и незаметной для пользователя, делая свою работу в фоновом режиме.

В этой статье освещено несколько новых возможностей HTML 5 поддерживаемых современными браузерами. Вы научились определять какие возможности поддерживаются браузерами и как прогрессивно наращивать мощь своего Веб-приложения, используя эти возможности. Большинство функционала уже широко поддерживается даже на мобильных браузерах. теперь вы можете начать исопльзовать такие в высшей степени примечательные вещи как geolocation и Web workers для создания новых, креативных Веб-приложений!

Источники

Обучение

Получение продуктов и технологий

Источник

Применение HTML5 для создания мобильных приложений

В статье обсуждается Internet Explorer 10 Consumer Preview. Любая изложенная здесь информация может быть изменена.

Продукты и технологии:

CSS3, Internet Explorer 9, Internet Explorer 10 Consumer Preview, JavaScript

В статье рассматриваются:

Исходный код можно скачать по ссылке code.msdn.microsoft.com/mag201205HTML5.

В прошлой статье я ознакомил вас с media-запросами CSS3 (msdn.microsoft.com/magazine/hh882445) — новым модулем, позволяющим адаптировать стили страницы на основе условных правил. Хотя media-запросы широко применяются на целом спектре устройств, о них часто упоминают в контексте создания мобильных сайтов и приложений. В частности, во введении в media-запросы в прошлой статье основное внимание уделялось созданию сайтов, рассчитанных на планшеты и мобильные устройства.

Учитывая трудности в создании мобильных сайтов и приложений, не удивительно, что разработчики ухватились за media-запросы. По сравнению с нежелательными альтернативами вроде анализа браузера (иногда называемого распознаванием устройства) и необходимостью создавать вариации мобильных приложений для каждой платформы индивидуально media-запросы кажутся настоящим подарком. Безусловно, это отличные модули, и причина, по которой я написал о них в прошлом номере, состоит в том, что вы должны использовать их уже сегодня.

Еще раз об адаптивном веб-дизайне

Однако не все так просто: media-запросы CSS — отличная штука, но это не более чем часть того, что вам понадобится на самом деле, чтобы создать по-настоящему удобное в использовании мобильное веб-приложение. В прошлом номере я упомянул термин «адаптивный веб-дизайн» (responsive Web design) — его ввел в употребление Этан Маркотт (Ethan Marcotte) в своей новаторской статье под тем же названием (bit.ly/9AMjxh). Маркотт основное внимание уделяет media-запросам и в то же время указывает на необходимость в двух других частях: «резиновых» (текучих) сетках (fluid grids) и гибких изображений (flexible images). Media-запросы — ядро, управляющее адаптивными сайтами, но они эффективны лишь в том случае, когда дизайн сайта тоже является адаптивным. В этой статье я познакомлю вас с некоторыми идеями, относящимися к двум другим стержням адаптивного веб-дизайна. Я начну с обзора ряда перспективных модулей CSS-разметки (CSS layout modules), а затем расскажу о том, как сделать элементы, отличные от текста, например изображения и встроенное видео, такими же адаптивными. Попутно я отмечу некоторые инфраструктуры и библиотеки, помогающие в этом деле. Я также упомяну кое-какие популярные инфраструктуры для создания мобильных веб-приложений, а в заключение кратко рассмотрю применение HTML5 для создания «родных» приложений. К тому моменту, когда вы прочитаете эту статью, вы должны получить четкое представление о том, как приступить к реализации адаптивного веб-дизайна в своих приложениях.

Резиновые сетки и разметки

Использование сетки для группирования строк (typographic design) — методика, которая в той или иной форме практикуется столетиями и была изобретена даже раньше, чем наборный шрифт (moveable type). Такая двухмерная структура состоит из пересекающихся вертикальных и горизонтальных осей, позволяющих дизайнеру выравнивать и упорядочивать элементы в разметке так, чтобы они приятно смотрелись (рис. 1). За последние несколько лет веб-дизайнеры начали применять многие из тех же принципов в своих цифровых работах, а ряд популярных инфраструктур вроде 960 Grid System (960.gs) и Semantic Grid System (semantic.gs) теперь делают разметку сеткой доступной всем.

Рис. 1. Типографская сетка

Однако прямое использование типографской сетки в Web имеет явный недостаток: печатные разметки фиксированы, а веб-разметки — нет. Более того, многие реализации сеток не особо поддерживают семантику, что требует добавления разметки для определения сетки и приводит к смешению визуализируемых элементов с контентом ваших HTML-страниц.

Чтобы сетки (или разметки) были по-настоящему резиновыми, они должны подстраиваться под изменения.

А это ведет нас к понятию «резиновый» (fluid) в термине Маркотта «резиновая сетка» (fluid grid). Чтобы сетки (или разметки) были по-настоящему резиновыми, они должны подстраиваться под изменения. Как я говорил в прошлой статье, media-запросы помогают определять правила для изменения позиции элементов, но для эффективного применения этих правил такие элементы нужно сначала определить в резиновом или гибком контейнере. Ранее упомянутые мной инструменты (равно как и многие другие) действительно решают эту проблему либо «родными» средствами (Semantic Grid), либо через использование дополняющей библиотеки (Adapt.js для 960 Grid, см. adapt.960.gs), но, помимо этого, появляются новые CSS-модули, которые помогают в создании резиновых разметок.

Заметьте, что я несколько вольно обращаюсь с термином Маркотта «резиновые сетки», называя их также и резиновыми разметками (fluid layouts). Я делаю так потому, что некоторые из новых CSS-модулей, хоть и не основаны на сетке, все равно помогают создавать резиновые, адаптируемые контейнеры.

Давайте сначала рассмотрим CSS3 Flexible Box Layout Module (или Flexbox), который можно найти по ссылке bit.ly/yguOHU. Flexbox помогает создавать контейнеры разметки для элементов, которые будут автоматически позиционировать свои дочерние элементы в горизонтальном или вертикальном направлении, и предоставляет поддержку автоматического изменения интервалов (Goodbye «ul li < float: right; >«!). Этот модуль поддерживается (с префиксами поставщиков браузеров) в Internet Explorer 10 Platform Preview, Firefox, Chrome, Safari, iOS Safari и Android (детали см. по ссылке caniuse.com/flexbox).

Рис. 2. CSS для использования модуля Flexbox

Рис. 3. Изображения Photo Gallery с примененным Flexbox

Симпатично, конечно, но выглядит примерно так же, как и раньше. Чтобы увидеть гибкость Flexbox, измените размер окна своего браузера или откройте эту страницу на мобильном устройстве или в их эмуляторе. В этом примере не определены никакие media-запросы, и тем не менее разметка оказывается более гибкой. Скомбинируйте эти два модуля и вы сможете создать резиновые контейнеры, которые выравнивают, сдвигают элементы и меняют интервалы между ними в зависимости от изменения размеров окна. Например, можно создать правило media-запроса для экранов менее 480 пикселей, изменить ориентацию прямоугольника на вертикальную, и вуаля — у вас появилась начальная разметка для мобильных устройств.

CSS Grid Layout (или просто CSS Grid), которую можно найти по ссылке bit.ly/ylx7Gq, — более новая спецификация, переданная на рассмотрение в W3C CSS Working Group в апреле 2011 года и в настоящее время реализованная только в Internet Explorer 10 Consumer Preview. Идея в том, чтобы предоставить надежную «родную» поддержку сеток в браузерах. Разработчики и дизайнеры получат богатую типографскую сетку, которая избавит их от необходимости создавать табличные структуры или семантически нейтральную разметку.

CSS Grid позволяет разметить страницу заранее определенными строками и столбцами, а также определить правила, указывающие, как контент будет размещаться в этих элементах и вокруг них. Первый шаг — определение контейнера сетки (grid container) с указанием «grid» в качестве значения свойства display для выбранных элементов:

Здесь я выбираю элемент body, что приведет к охвату моей сеткой всего документа. Это не обязательно, и я мог бы легко смастерить сетку из меньшей секции страницы или даже определить несколько сеток на одной странице. После определения сетки нужно определить размеры ее строк и столбцов:

А здесь указываю сетку из четырех столбцов и четырех строк, для одних делая размер абсолютным (например, 50px, 75px), для других — относительным размеру окна (30%, 20%) и автоматически изменяемым в зависимости от ширины его контента (auto). Я также использую новую числовую единицу fr (fraction), которая определена в спецификации CSS Grid как «…доля доступного пространства». Значения fr вычисляются после присваивания фиксированных размеров пропорциональным делением оставшегося пространства между всеми строками и столбцами, определенными с этими значениями. В контексте моего примера это означает, что, поскольку под столбцы 1 и 2 суммарно зарезервировано 100 пикселей, столбец 3 получит две трети оставшегося пространства, а столбец 4 — одну треть.

Определив сетку, можно легко позиционировать дочерние элементы в сетке, присваивая им номера строк и столбцов, например:

Я помещаю свой главный (main) секционирующий элемент (sectioning element) во вторую строку и второй столбец сетки. Также разрешаю этому элементу охватить две строки и центрирую контент внутри этого контейнера. На сайте Microsoft Internet Explorer Test Drive Demo используется своя реализация CSS Grid Layout для создания точной реализации популярного сайта Grid System (thegridsystem.org), и вы можете сами убедиться в этом по ссылке bit.ly/gEkZkE.

Если вы когда-нибудь пробовали сделать нечто подобное с помощью обычной разметки и CSS2.1, то, несомненно, поймете ту гибкость, которую может обеспечить CSS Grid. Более того, CSS Grid в сочетании с media-запросами можно использовать для создания адаптивных структур, которые легко настраиваются изменением меньшего количества правил, когда пользователи подстраивают размер устройства и меняют его ориентацию.

Последняя спецификация разметки, которую я хотел представить в этой статье, — CSS Multi-Column Layout Module, которую вы найдете по ссылке bit.ly/yYEdts. CSS Multi-Column находится на стадии «Candidate Recommendation» (bit.ly/x5IbJv) и широко поддерживается всеми браузерами, в том числе планируется поддержка в Internet Explorer 10. Multi-Column позволяет размечать столбцы на странице без позиционирования вручную. Вам достаточно применить свойство column-width (с префиксами, если это необходимо) к контейнеру, например:

При таком правиле элементы статьи будут разделены на столбцы (колонки) по 240 пикселей — их будет создано столько, сколько позволит контейнер (в данном случае четыре столбца по 240 пикселей заполнят контейнер размером 960 пикселей). Я мог бы также воспользоваться свойством column-count для определения фиксированного количества столбцов, и тогда размеры столбцов были бы равномерно распределены по ширине моего контейнера.

Как и в случае с модулями Flexbox и Grid, комбинирование этого модуля с media-запросами дает возможность быстро определять простые, адаптивные правила для обеспечения удобства использования на мобильных устройствах.

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

В мире адаптивного веб-дизайна — особенно для мобильных решений — наибольшие затруднения вызывает медийная информация.

Советую также изучить появляющиеся инфраструктуры, которые используют эти спецификации. Применение одной из них может резко ускорить создание резиновых разметок для ваших сайтов. Две достойные внимания инфраструктуры — это Skeleton (getSkeleton.com) и Bootstrap (twitter.github.com/bootstrap), начальный набор от Twitter. Недавно я перестроил один из своих сайтов с помощью Skeleton (зайдите на html5tx.com).

Медийная информация в адаптивном веб-дизайне

В мире адаптивного веб-дизайна — особенно для мобильных решений — наибольшие затруднения вызывает медийная информация. Начнем с изображений. Один из простейших способов применения стилей к изображениям для повышения их адаптивности — добавить в таблицы стилей следующее:

Это правило будет всегда масштабировать ваши изображения (увеличивать или уменьшать) под размеры родительского контейнера. Таким образом, если элементы-контейнеры отвечают требованиям адаптивного веб-дизайна (возможно, по одной из ранее описанных методик), то и ваши изображения будут адаптивными.

Трудность этого способа в том, что изображения на сайте должны быть достаточно большими, чтобы их можно было масштабировать до любого размера без потерь качества. На сайте Photo Gallery, которым я пользовался, исходные изображения весьма велики, и поэтому их размеры можно изменять как угодно.

Однако использование огромных масштабируемых изображений создает крупные проблемы на мобильных устройствах: издержки передачи таких изображений слишком высоки. Даже если вы масштабируете крупное изображение под окно размером 320 × 240, на устройство все равно передается полное изображение. Это означает, что потенциально возможны ситуации, когда вы передаете картинку размером 2 Мб, когда для устройства требуется та же картинка, но размером всего 10 Кб. В мире мобильных устройств полоса пропускания все еще имеет значение, поэтому нужны другие подходы.

Однако в долгосрочной перспективе вы можете надеяться на лучшее. В статье «HTML5 Semantics» в журнале «Smashing Magazine» (bit.ly/rRZ5Bl) Брюс Лосон (Bruce Lawson), один из разработчиков Opera, агитирует за добавление элемента

. В сочетании с подставляемыми в строку media-запросами, новый элемент

мог бы наконец-то предоставить надежное решение для поддержки адаптивных изображений:

Хотя это решение завоевало популярность и вокруг него была сформирована W3C Community Group (bit.ly/AEjoNt), официальной рабочей группы W3C так и не было создано, насколько мне известно. Возможно, в свое время, в HTML6, мы увидим этот элемент.

Если вы обслуживаете видеопотоки со своих серверов или используете сервис, который предоставляет несколько версий для встраивания, то я настоятельно рекомендую применять этот синтаксис, чтобы передавать пользователям подходящие для их устройств видеопотоки.

В мире мобильных устройств полоса пропускания все еще имеет значение.

Хотя это решение поможет сэкономить полосу пропускания сетевых соединений ваших пользователей, вам все равно нужно подумать о масштабировании этих встраиваемых элементов — так же, как и в случае с изображениями. С помощью media-запросов эти элементы video легко адаптировать в зависимости от размеров экрана, но, если вы ищете более автоматизированное решение, рассмотрите FitVids.js (fitvidsjs.com), jQuery-плагин, который будет автоматически делать ваши элементы video резиновыми и адаптивными. Но учтите, что это решение (как jQuery-плагин) не будет работать для пользователей, в браузерах которых отключена поддержка JavaScript.

Создание мобильных веб-приложений с использованием HTML5-инфраструктур

Теперь. когда вы знаете о двух других стержнях адаптивного веб-дизайна (резиновых разметках и гибких изображениях), давайте немного поговорим о тех случаях, где вы создаете не просто дружественные к мобильным устройствам веб-сайты или приложения, а ориентируетесь исключительно на такие устройства.

В мире разработки традиционные настольные (или клиентские) и веб-парадигмы открыли путь третьему типу приложений, часто называемых «родными» (native applications), так как они размещаются на определенном устройстве (смартфоне на основе Windows Phone или на iPad, например), создаются с использованием инфраструктур, специфичных для данных устройств (iOS и Android) и устанавливаются через App Store или Marketplace.

Как бы ни были функциональны и надежны эти инфраструктуры, иногда веб-разработчики хотят добиться аналогичного «духа и буквы» в своих мобильных веб-приложениях. Такие приложения по-прежнему работают на серверах и могут доставляться вне рамок App Store или Marketplace.

Хотя вы определенно можете создавать приложения этих типов вручную, гораздо удобнее использовать для этого инфраструктуры. Одна из популярных инфраструктур для мобильных веб-приложений — jQuery Mobile (jquerymobile.com), которая обеспечивает UI-систему на основе HTML5, ориентированную практически на каждую мобильную платформу. На рис. 4 показан пример мобильного приложения для OpenTable.com, построенного с применением jQuery UI.

Рис. 4. Пример экрана, созданного с помощью jQuery Mobile

Другой популярный вариант для создания мобильных приложений с «родным» для мобильных устройств внешним видом — Kendo UI Mobile (kendoui.com), инфраструктура на основе HTML5, JavaScript и CSS от Telerik Inc. Kendo UI позволяет создавать мобильные приложения, которые выглядят точно так же, как родные программы для устройств на базе iOS и Android, и используют единую кодовую базу. На рис. 5 и 6 показана эта функциональность, которую вы можете проверить сами по ссылке bit.ly/wBgFBj.

Рис. 5. Мобильное демонстрационное приложение Kendo UI, просматриваемое на устройстве с iOS

Рис. 6. Пример мобильного приложения Kendo UI, просматриваемого на устройстве с Android

Создание родных приложений с помощью HTML5

Придание веб-приложениям родного для мобильных устройств внешнего вида — отличный способ не только применения на практике ваших знаний как веб-разработчика, но и создания приложений, удовлетворяющих ожиданиям пользователей мобильных устройств. Тем не менее, эти приложения пока не могут заходить дальше использования встроенных датчиков и родных API на этих устройствах. Если некоторые функции вроде геопозиционирования предоставляются мобильным браузерам, то многие другие (например, акселерометр или видео) — нет. Чтобы получить доступ к таким функциям, по-прежнему приходится разрабатывать программы, родные для каждой платформы.

Но есть и хорошие новости: популярность веб-программирования подтолкнула технологии HTML5, JavaScript и CSS к тому, что они «становятся родными». Популярные инфраструктуры наподобие PhoneGap (phonegap.com) и Titanium Appcelerator (appcelerator.com) позволяют использовать HTML5 и JavaScript для создания родных приложений под iOS, Android и Windows Phone с доступом к аппаратным API. Более того, инфраструктуры разработки мобильных приложений вроде jQuery Mobile и Kendo UI Mobile работают так же хорошо в этих средах, как и в браузере. На рис. 7 показано родное для iOS приложение, построенное с использованием PhoneGap и Kendo UI. Подробнее на эту тему см. публикацию в блоге по ссылке bit.ly/zpIAPY.

Рис. 7. Приложение iOS, построенное с помощью HTML, JavaScript и CSS

Microsoft вывела разработку родных веб-программ на новый уровень, официально добавив в Windows 8 поддержку создания приложений с применением HTML5, JavaScript и CSS, причем без дополнительных абстракций или инфраструктур. Вы можете посмотреть предварительную версию Windows 8 для потребителей, а также новые средства разработки для различных платформ по ссылке dev.windows.com.

Когда дело доходит до мобильной Web, у вас появляется выбор! Если вы являетесь веб-разработчиком, желающим создавать родные приложения с функциональностью дополненной реальности (augmented reality), подумайте о применении Windows 8 или одной из инфраструктур, такой как PhoneGap или Titanium Appcelerator. Если вас интересует лишь родной внешний вид программ, выполняемых в браузере, присмотритесь к jQuery UI и Kendo UI Mobile. Наконец, если ваша цель — создание единого веб-сайта или приложения, которое отвечает на запросы с разнообразных мобильных устройств, попробуйте использовать адаптивные стратегии, обсуждавшиеся в этой и прошлой статьях. Несомненно, что сейчас мобильные устройства — самый лакомый кусочек рынка для всевозможных разработок. Лучший вариант для вас (независимо от выбранных стратегий или платформ) — сделать разработку мобильных приложений высшим приоритетом.

Брэндон Сэтром (Brandon Satrom) — менеджер продуктов Kendo UI (kendoui.com) — набора инструментария для разработки HTML5- и мобильных приложений от Telerik Inc. Ведет блог UserInexperience.com и пишет заметки в Twitter.com/BrandonSatrom. В соавторстве с Крисом Селлзом (Chris Sells) пишет книгу «Building Metro Style Apps for Windows 8 in JavaScript».

Выражаю благодарность за рецензирование статьи экспертам Джону Боксу (John Box), Берку Холланду (Burke Holland) и Кларку Селлу (Clark Sell).

Источник