Создание мобильных Web-приложений с применением HTML 5: Часть 3. Как заставить мобильные Web-приложения работать в автономном режиме с помощью HTML 5

Научите свои приложения работать как при наличии интернет-соединения, так и без него

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

Майкл Галпин, инженер по программному обеспечению, Vitria Technology

Майкл Галпин (Michael Galpin) имеет учёную степень по математике в Калифорнийском Технологическом институте. Он является Java-разработчиком с конца 90-х гг. и работает инженером по программному обеспечению в Vitria Technology, в Саннивейл, Калифорния.



29.06.2010 (Впервые опубликовано 10.02.2012)

8 июня 2010 г.: добавлены ссылки на часть 4 этого цикла в разделах "Об этом цикле статей", "Заключение" и "Ресурсы".

29 июня 2010 г.: добавлены ссылки на часть 5 этого цикла в разделах "Об этом цикле статей", "Заключение" и "Ресурсы".

Об этом цикле статей

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


Предварительные замечания

В этой статье мы разработаем Web-приложение с использованием новейших Web-технологий. Большая часть кода – это просто HTML, JavaScript и CSS – основные технологии любого Web-разработчика. Главное, что вам понадобится – это браузеры для тестирования. Большая часть кода из этой статьи будет работать с последними версиями настольных браузеров – за некоторыми заметными исключениями. Конечно, приложение нужно будет протестировать и на мобильных браузерах, так что понадобятся последние SDK iPhone и Android. В этой статье используются iPhone SDK 3.1.3 и Android SDK 2.1. См. ссылки в разделе Ресурсы.


Зачем делать приложение работающим в автономном режиме?

Часто используемые сокращения

  • Ajax: Asynchronous JavaScript + XML
  • API: Application Programming Interface – интерфейс программирования приложений
  • CSS: Cascading stylesheet – каскадная таблица стилей
  • HTML: Hypertext Markup Language – язык гипертекстовой разметки
  • HTTP: Hypertext Transfer Protocol – протокол передачи гипертекстовых файлов
  • JSON: JavaScript Object Notation – система обозначений (нотация) объектов JavaScrip
  • JSONP: JSON with padding – JSON с грунтованием
  • MIME: Multipurpose Internet Mail Extensions – многоцелевые почтовые расширения Интернета
  • PDF: Portable Document Format – портативный формат документов
  • SDK: Software Developer Kit – пакет ПО разработчика
  • UI: User Interface – пользовательский интерфейс
  • URL: Uniform Resource Locator – унифицированный указатель ресурсов
  • W3C: World Wide Web Consortium
  • WAP: Wireless Application Protocol – протокол мобильной интерактивной связи с Интернетом
  • XML: Extensible Markup Language – расширяемый язык разметки гипертекста

Автономно работающие Web-приложения привлекательны для пользователей и разработчиков по ряду причин. Многие разработчики мечтают о возможности написать одно Web-приложение, которое работало бы на всех популярных смартфонах, вместо того, чтобы создавать отдельные приложения для каждого из них. Но то, что удобно для разработчиков, не обязательно желанно для пользователей. В этом случае их мобильные Web-приложения должны будут обеспечивать многие (или большинство) из тех же функций, что и стандартные. Работа в офлайне определенно входит в число этих функций. Некоторые приложения в значительной степени зависят от данных и услуг, получаемых через Интернет – будь то мобильные Web-приложения или стандартные приложения. Понятно, что их функциональность будет ограничена, если у пользователя нет хорошего соединения с Интернетом. Однако это не повод для того, чтобы совсем не работать с приложением. С традиционными Web-приложениями дело обстоит именно так.

Офлайновые возможности сближают мобильные Web-приложения с обычными. Но у них есть и другие преимущества. Web-браузеры всегда кэшировали статические ресурсы. Они опираются на метаданные из заголовков ответа HTTP, отправленные Web-сервером, для извлечения HTML, JavaScript, CSS и графики, необходимых для отображения страницы. Если все необходимое для отображения страницы присутствует в кэше, то страница загружается очень быстро. Однако если что-то не нашлось, процесс может резко замедлиться. И это происходит чаще, чем хотелось бы. Возможно, у одного файла CSS был иной заголовок Cache-Control, чем у всех остальных, или браузер выкинул кэш, когда ему не хватило выделенного пространства.

Работая с автономными приложениями, можно не сомневаться, что в кэше есть все. Браузеры всегда будут загружать все из кэша, хотя тем, что не должно выдаваться из кэша, можно управлять. Стандартный прием – добавление параметра timestamp в запросы GET (или еще хуже, использование POST, когда достаточно GET) Ajax, чтобы браузеры не кэшировали ответ. С Web-приложениями, которые могут работать автономно, эта уловка не нужна.

Автономные приложения кажутся привлекательными, но может быть, они сложны в разработке? На самом деле, все очень просто. Нужно сделать три вещи:

  1. Создать файл офлайновой декларации.
  2. Сообщить о файле декларации браузеру.
  3. Задать MIME-тип на сервере.

Офлайновая декларация

Для приложения нужен один важный файл: декларация кэша. Этот файл сообщает браузеру, что именно записывать в кэш (и, возможно, что не записывать.) Он становится источником истины для вашего приложения. Пример простой декларации кэша приведен в листинге 1.

Листинг 1. Простая декларация кэша
CACHE MANIFEST
# Version 0.1
offline.html
/iui/iui.js
/iui/iui.css
/iui/loading.gif
/iui/backButton.png
/iui/blueButton.png
/iui/cancel.png
/iui/grayButton.png
/iui/listArrow.png
/iui/listArrowSel.png
/iui/listGroup.png
/iui/pinstripes.png
/iui/redButton.png
/iui/selection.png
/iui/thumb.png
/iui/toggle.png
/iui/toggleOn.png
/iui/toolbar.png
/iui/whiteButton.png
/images/gymnastics.jpg
/images/soccer.png
/images/gym.jpg
/images/soccer.jpg

Этот файл содержит список всех файлов, с которыми приложение должно правильно работать. Это включает в себя HTML-файлы, а также JavaScript, CSS и изображения. Он может включать и видео, PDF, XML-файлы и т.п. Обратите внимание, что все URL-адреса в этом примере относительны. Любые относительные URL-адреса должны относиться к файлу декларации кэша. В данном случае файл декларации кэша находится в корневом каталоге Web-приложения. Сравните структуру каталогов в листинге 2 с относительными адресами URL в листинге 1.

Листинг 2. Текстовая версия структуры каталогов Web-приложения
  Name
V images
    gymnastics.jpg
    soccer.png
V iui
    backButton.png
    blueButton.png
    cancel.png
    grayButton.png
    iui.css-logo-touch-icon.png
    iui.css
    iui.js
    iuix.css
    iuix.js
    listArrow.png
    listArrowSel.png
    listGroup.png
    loading.gif
    pinstripes.png
    redButton.png
    selection.png
    thumb.png
    toggle.png
    toggleOn.png
    toolbar.png
    toolButton.png
    whiteButton.png
  manifest.mf
  offline.html
> WEB-INF

Вы могли заметить, что это приложение использует среду iUI. Это популярный комплект JavaScript+CSS для придания мобильным Web-приложениям вида стандартных приложений iPhone. Как видно из листинга 1 и листинга 2, вместе с файлами JavaScript и CSS среда использует несколько изображений. Однако все эти файлы будут кэшироваться браузером, и их можно будет использовать в автономном режиме, если они указаны в декларации.

Другая важная особенность листинга 1 – это сведения о версии. Это не часть спецификации. На самом деле, это просто комментарий в файле. Тем не менее, нечто подобное позволяет сообщить браузеру, что существует новая версия вашего приложения. Предположим, что вы изменили какой-то код HTML, или JavaScript, или даже просто изображение. Если не изменить декларацию, браузер никогда не станет заботиться о загрузке новой версии модифицированного ресурса. Декларация кэша не имеет срока действия, поэтому все будет оставаться в кэше, пока пользователь не удалит его или пока не изменится файл декларации. Браузер будет проверять, появился ли новый файл декларации. Для указания на новый файл декларации достаточно просто что-нибудь изменить в существующем. Возвращаясь к нашему примеру с изменением кода HTML на странице, если вы изменили HTML и строку версии в файле декларации, браузер поймет, что ресурсы изменились, и загрузит их снова. Помещение номера версии в комментарий – простой способ управлять этим процессом.


Как сообщить браузеру о файле декларации

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

Листинг 3. Web-страница с поддержкой автономной работы
<!DOCTYPE html>
<html>
<html manifest="manifest.mf">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
    <meta name="viewport" content="width=device-width; initial-scale=1.0; 
        maximum-scale=1.0; user-scalable=0;"/>
    <meta name="apple-touch-fullscreen" content="YES" />
    <link rel="apple-touch-icon" href="/iui/iui-logo-touch-icon.png" />
    <style type="text/css" media="screen">@import "/iui/iui.css";</style>
    <script type="application/x-javascript" src="/iui/iui.js"></script>
    <title>Let's do it offline</title>
</head>
<body>
    <div class="toolbar">
        <h1 id="pageTitle">Going offline</h1>
        <a id="backButton" class="button" href="#"></a>
    </div>
    <ul id="menu" title="Sports" selected="true">
        <li><a href="#gym"><img height="80" width="80" 
src="/images/gym.jpg" align="middle"/>
            <span style="display:inline-block;
 vertical-align:middle">Gymnastics</span></a></li>
        <li><a href="#soccer"><img src="/images/soccer.jpg" 
align="middle"/>
        <span style="display:inline-block; 
vertical-align:middle">Soccer</span></a></li>
    </ul>
    <div id="gym" title="Gymnastics" class="panel">
        <img src="/images/gymnastics.jpg" alt="Boys Gymnastics"/>
    </div> 
    <div id="soccer" title="Soccer" class="panel">
        <img src="/images/soccer.png" alt="Boys Soccer"/>
    </div>
</body>
</html>

Наиболее важным аспектом этого кода HTML является корневой элемент html. Обратите внимание, что он имеет атрибут manifest. Он-то и говорит браузеру, что данная Web-страница может функционировать в автономном режиме. Значением параметра manifest является адрес URL декларации кэша Web-страницы. Опять же, это может быть полный URL, хотя в данном случае это относительный URL (относительно данной Web-страницы). Другая важная вещь – DOCTYPE страницы. Это канонический doctype для Web-страниц HTML 5. Спецификация офлайнового Web-приложения не требует использования этого DOCTYPE, однако это рекомендуется делать. В противном случае некоторые браузеры могут не признать страницу как страницу HTML 5 и проигнорируют декларацию кэша. Остальная часть HTML – всего лишь простой пример использования iUI. На рисунке 1 показано, как эта страница будет выглядеть на имитаторе iPhone.

Рисунок 1. Автономное Web-приложение, работающее на имитаторе iPhone
Скриншот автономного Web-приложения Sports с опциями Gymnastics и Soccoer, работающего на имитаторе iPhone.

Тестирование автономного приложения может оказаться затруднительным. Простейший способ – установить приложение на Web-сервер, если есть такая возможность. Затем можно обратиться к странице, отключить интернет-соединение и попытаются обратиться к ней снова. Если ничего не получается, возможно, вы не включили какие-то файлы в декларацию кэша. Прежде чем попробовать это, нужно выполнить одну важную настройку Web-сервера.


Настройка Web-сервера

В листинге 3 показано, как указать местоположение декларации кэша с помощью атрибута manifest корневого элемента html Web-страницы. Однако спецификация декларации кэша диктует, чтобы при ее загрузке и обработке браузер выполнил дополнительную проверку. Он должен проверить MIME-тип декларации кэша, и этот тип должен быть text/cache-manifest. Обычно это означает, что при настройке Web-сервера нужно задать этот MIME-тип для статического файла или написать код создания файла и установки MIME-типа для динамического. Первый способ явно эффективнее, но если у вас нет контроля над конфигурацией сервера (например, сервер размещен в общей или хостируемой среде), придется прибегнуть ко второму. Если вы контролируете сервер и используете сервер приложений Java™, можно настроить это в рамках файла web.xml Web-приложения. Пример приведен в листинге 4.

Листинг 4. Настройка файла web.xml для установки MIME-типов
<?xml version="1.0" encoding="utf-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">
<!-- Servlets go here -->
    <mime-mapping>
        <extension>mf</extension>
        <mime-type>text/cache-manifest</mime-type>
    </mime-mapping>    
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
    </welcome-file-list>
</web-app>

Очевидно, ключевой раздел здесь – это элемент MIME-отображения. В данном случае мы указали, что любым файлам, имя которых заканчивается расширением .mf, нужно присвоить MIME-тип text/cache-manifest. Конечно, еще эффективнее было бы брать такие файлы с сервера, предназначенного для обслуживания статического контента, такого как Web-сервер Apache. В типичной установке Apache достаточно просто изменить файл mime.types в каталоге httpd/conf, как показано в листинге 5.

Листинг 5. Настройка MIME-типа в файле mime.types
# Этот файл управляет тем, какие типы  интернет-сообщений пересылаются клиенту в 
# файлах с данным расширением (расширениями). Важно, чтобы клиенту отправлялись 
# правильные сообщения, иначе он не будет знать, как обращаться с содержанием  
# файла. Дополнительные типы можно добавить здесь или в файлах конфигурации, 
# воспользовавшись директивой AddType. За дополнительной информацией о типах 
# интернет-сообщений обращайтесь к RFC 2045, 2046, 2047, 2048 и 2077. Реестр типов 
# интернет-сообщений находится по адресу: <http://www.iana.org/assignments/media-types/>.

# MIME-тип                   Расширения
text/cache-manifest          mf
# многие другие оображения...

В обоих примерах для расширения имени файла декларации используется mf, так как это файл manifest.mf. Это расширение выбирается совершенно произвольно. Можно выбрать .manifest или .foo, лишь бы расширение имени файла декларации совпадало с расширением, используемым при отображении в файле конфигурации. Заметим, что другие серверы приложений и Web-серверы могут иметь другие механизмы настройки. Теперь, когда все важные составляющие создания офлайновых мобильных Web-приложений с использованием HTML 5 известны, рассмотрим более сложный пример, чтобы изучить другие возможности офлайновых мобильных Web-приложений.


Расширенный пример

В предыдущем примере весь контент был статическим. Было приятно получить возможность видеть все в автономном режиме. Но приложению часто бывает необходимо читать динамические данные со своего сервера и из Web-сервисов. Чтобы сделать пример более реалистичным, извлечем какие-нибудь данные из Twitter. Если вы прочли предыдущие части этой серии статей, то вам известно, как это сделать (см. раздел Ресурсы). Для начала рассмотрим модифицированный код HTML из листинга 6.

Листинг 6. Модифицированный код HTML
<body onload="init()">
    <div class="toolbar">
        <h1 id="pageTitle">Going offline</h1>
        <a id="backButton" class="button" href="#"></a>
    </div>
    <ul id="menu" title="Sports" selected="true">
        <li><a href="#gym">
            <img height="80" width="80" src="/images/gym.jpg" align="middle"/>
            <span style="display:inline-block; vertical-align:middle">Gymnastics</span>
        </a></li>
        <li><a href="#soccer"><img src="/images/soccer.jpg" align="middle"/>
            <span style="display:inline-block; vertical-align:middle">Soccer</span>
        </a></li>
        <li id="online" style="display: none"><img src="/images/online.jpg"/></li>
    </ul>
    <ul id="gym" title="Gymnastics"></ul> 
    <ul id="soccer" title="Soccer"></ul>
</body>

Основное отличие заключается в том, что элементы gym и soccer теперь представлены в виде списков, и они пусты. Мы будем заполнять их твитами из Twitter по гимнастике и футболу соответственно. Обратите также внимание на элемент списка с идентификатором online – он содержит изображение, которое будет использоваться, чтобы указать пользователю, находится ли приложение в онлайне или в офлайне. Однако по умолчанию этот элемент скрыт, то есть по умолчанию выбран режим офлайн. Элемент body указывает функцию init, которая вызывается после загрузки тела. Эта функция показана в листинге 7.

Листинг 7. Код JavaScript инициализации страницы
function init(){
    if (navigator.onLine){
        searchTwitter("gymnastics", "showGymTweets");
        searchTwitter("soccer", "showSoccerTweets");
        $("online").style.display = "inline";
    } 
    gymTweets = localStorage.getItem("gymnastics");
    if (gymTweets){
        gymTweets = JSON.parse(gymTweets);
        showGymTweets();
    }
    soccerTweets = localStorage.getItem("soccer");
    if (soccerTweets){
        soccerTweets = JSON.parse(soccerTweets);
        showSoccerTweets();
    }
    document.body.addEventListener("online", function() {
            $("online").style.display= "inline";
            applicationCache.update();
            applicationCache.addEventListener("updateready", function() {
                applicationCache.swapCache();
            }, false);
        }, false);
    document.body.addEventListener("offline", function() {
        $("online").style.display = "none";
    }, false);        
}

Первое, что делает этот код, — это проверка текущего режима: онлайн или офлайн. Если вы в онлайне, отображается значок онлайна. Еще важнее то, что если вы в онлайне, то данные загружаются из Twitter посредством вызова функции searchTwitter. Опять же, это прием (описанный в предыдущих статьях этого цикла – см. раздел Ресурсы), который позволяет осуществлять поиск в Twitter прямо из браузера с помощью JSONP. Далее, попытаемся загрузить существующие твиты из localStorage. localStorage – это еще одна возможность, позволяющая HTML 5 достаточно хорошо работать в автономном режиме. Подробнее об этом говорится в части 2 настоящего цикла статей (см. раздел Ресурсы). Обратите внимание, что как для новых поисков (производимых, если программа обнаруживает, что устройство находится в онлайне), так и для загрузки локально сохраненных твитов вызываются функции showGymTweets и showSoccerTweets. Это аналогичные функции, и в листинге 8 иллюстрируется showGymTweets.

Листинг 8. Отображение гимнастических твитов
function showGymTweets(response){
    var gymList = $("gym");
    gymList.innerHTML = "";
    if (gymTweets){
        if (response){
            gymTweets = response.results.reverse().concat(gymTweets);
        }
    } else {
        gymTweets = response.results.reverse();
    }
    showTweets(gymTweets, gymList);
    localStorage.setItem("gymnastics", JSON.stringify(gymTweets));
}

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

Возвращаясь к листингу 7, последнее, что нужно сделать, это зарегистрировать обработчики событий. Регистрация на онлайновые и офлайновые события позволит определять, когда браузер изменяет статус с онлайна на офлайн и наоборот. Как минимум, вы сможете изменять значок онлайна, включая или выключая его. В том случае, если приложение переходит из офлайна в онлайн, вы обращаетесь к объекту applicationCache. Этот объект отображает все ресурсы, сохраняемые в кэше, согласно декларации кэша. В данном случае вызываем его метод update. Этот метод позволяет браузеру проверить, есть ли обновление для applicationCache. Как упоминалось выше, браузер сначала проверяет обновления файла декларации кэша. Добавим еще один приемник событий, чтобы проверить наличие обновления кэша. Если оно есть, вызываем метод swapCache объекта applicationCache. Это приведет к перезагрузке всех файлов, указанных в файле декларации кэша.

Что касается файла декларации кэша, то для этого расширенного примера понадобится еще один, последний штрих. Файл декларации нужно изменить, как указано в листинге 9.

Листинг 9. Измененная декларация кэша
CACHE MANIFEST
# Version 0.2
CACHE:
offline.html
json2.js
/iui/iui.js
/iui/iui.css
/iui/loading.gif
/iui/backButton.png
/iui/blueButton.png
/iui/cancel.png
/iui/grayButton.png
/iui/listArrow.png
/iui/listArrowSel.png
/iui/listGroup.png
/iui/pinstripes.png
/iui/redButton.png
/iui/selection.png
/iui/thumb.png
/iui/toggle.png
/iui/toggleOn.png
/iui/toolbar.png
/iui/whiteButton.png
/images/gym.jpg
/images/soccer.jpg
/images/online.jpg

NETWORK:
http://search.twitter.com/

В этом примере мы добавили в декларацию раздел CACHE. Декларация может иметь различные разделы, но если раздел только один, то считается, что это CACHE, и название можно опустить. Здесь же есть еще раздел NETWORK. Он сообщает браузеру, что все, что исходит из указанного домена (в данном случае домена search.twitter.com), должно извлекаться из сети и никогда не кэшироваться. Так как вы локально кэшируете результаты поиска в Twitter, вы, конечно, не хотите, чтобы браузер тоже выполнял какое-либо косвенное кэширование запросов. Теперь, когда это сделано, приложение всегда будет загружать живые твиты из Twitter, а также сохранять эти твиты и делать их доступными для пользователя, даже если устройство потеряет соединение с интернетом.


Заключение

Со времен Mosaic Web-приложения прошли долгий путь. Мобильные Web-приложения эволюционировали еще больше. Дни WAP-телефонов, которые говорят только на языке Wireless Markup Language (WML), сочтены. Теперь от мобильного браузера требуются такие вещи, которых не требуют даже от их старших настольных собратьев. Одна из таких вещей – автономная работа. Стандарты, собранные в HTML 5, тоже прошли длинный путь, чтобы упростить разработчикам наделение своих мобильных Web-приложений возможностью работать в офлайне. В следующей статье этого цикла мы рассмотрим, как значительно улучшить производительность мобильных Web-приложений, применяя другой стандарт HTML 5, Web Workers.


Загрузка

ОписаниеИмяРазмер
Исходный код для статьиoffline.zip437 КБ

Ресурсы

Научиться

Получить продукты и технологии

  • Проект Modernizr: мощная утилита для поиска функций HTML 5, в том числе таких, как localStorage, Web Workers, applicationCache и другие.
  • Web-сайт разработчиков Android: загрузите Android SDK, познакомьтесь с материалами по API и следите за последними новостями о платформе Android.
  • SDK iPhone: загрузите последнюю версию SDK iPhone для разработки приложений, работающих на iPAD, iPhone и iPod Touch.
  • Проект Open Source Android: получите открытый исходный код мобильной платформы Android.
  • SDK Google App Engine: загрузите инструменты Java и Python для создания масштабируемых Web-приложений с использованием Google.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=XML, Open source
ArticleID=792772
ArticleTitle=Создание мобильных Web-приложений с применением HTML 5: Часть 3. Как заставить мобильные Web-приложения работать в автономном режиме с помощью HTML 5
publish-date=06292010