Применение IBM Worklight для разработки межплатформенных гибридных видеоплееров HTML5

C возникновением потребности в расширении корпоративного доступа с компьютеров на мобильные устройства мобильные гибридные приложения начали использовать преимущества межплатформенных возможностей HTML5. К сожалению, поддержка HTML5 терпит неудачу, когда речь заходит о межплатформенных видеоплеерах, особенно в гибридных приложениях, работающих на операционной системе Android. Настоящая статья показывает, как можно обойти эти проблемы и обеспечить работу видеоплееров, воспользовавшись мобильными гибридными возможностями IBM® Worklight. Из журнала IBM WebSphere Developer Technical Journal.

Билл Парис, разработчик ПО, IBM

Билл Парис (Bill Paris) — программист-консультант по IBM Software Services в группе WebSphere. Специализируется на разработке мобильных приложений и промежуточного серверного ПО для телекоммуникационной промышленности.



Срини Памидала, старший сертифицированный ИТ-архитектор, IBM

Срини Памидала (Sreeni Pamidala) — старший сертифицированный ИТ-архитектор, в настоящее время работает ведущим архитектором ISSW Mobile Services группы AIM Software. В этой должности ему приходится много общаться с клиентами, работающими в разных отраслях промышленности, разрабатывая и поставляя мобильные решения на базе технологий IBM Mobile Foundation, которые интегрируются с корпоративной инфраструктурой и промежуточным ПО этих клиентов. До этого Срини в течение 15 лет работал с клиентами ComSector, где руководил несколькими успешными проектами по разработке и внедрению сложных сетевых решений операторского класса для провайдеров мобильных и проводных телефонных услуг, основанных на межбрендовых программных и аппаратных продуктах компании IBM и некоторых интеграционных продуктах сторонних изготовителей.



Рагхунандан K Харитас, консультирующий ИТ-специалист, IBM

Рагхунандан Харитас (Raghunandan Harithas) — ИТ-специалист, работающий в отделении IBM в Аннаполисе, штат Мэриленд, США. Он был техническим руководителем нескольких телекоммуникационных проектов, использующих продукты семейства WebSphere. В настоящее время он работает в области разработки мобильных приложений с использованием программы IBM Mobile Foundation, основанной на IBM Worklight.



24.06.2013

Введение

Мобильное гибридное приложение сочетает функциональность собственной операционной системы устройства с Web-технологиями. Как правило, гибридное приложение представляет контент во встроенном Web-браузере. Такой подход расширяет межплатформенные возможности, поскольку большую часть кода можно написать с применением технологий HTML5, одновременно обеспечивая доступ к собственным функциям устройства. Платформа для мобильных приложений IBM Worklight позволяет разрабатывать межплатформенные гибридные приложения, предлагая механизмы навигации между Web-представлением и собственным представлением, и предоставляет среду для разработки и исполнения, которая значительно приближает мобильные приложения к конечной цели — осуществлению принципа «написанное однажды выполняется везде».

Встроенный в приложение видеоплеер представляет собой одну из областей, где задача реализации межплатформенных возможностей является весьма непростой. Тег <video> в HTML5 предназначен для поддержки межплатформенных видеоплееров, однако отсутствие согласованной поддержки его возможностей не позволяет достичь конечной цели.

Настоящая статья посвящена разработке видеоплееров в межплатформенных гибридных приложениях HTML5 и поясняет, как платформа разработки IBM Worklight помогает обойти проблемы при отсутствии поддержки видеофункций HTML5 в какой-либо конкретной платформе.


Проблемы воспроизведения видео

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

Под видео понимается один видеопоток (или поток изображений) и один или несколько аудиопотоков, упакованные в один архив. Рассмотрим некоторые наиболее распространенные термины:

  • Видеоконтейнер содержит аудио- и видеофайлы, упакованные в единый архивный файл. Существует множество форматов видеоконтейнеров, наиболее популярными из которых являются MPEG4, Flash Video, Ogg, WebM и Audio Video Interleave. На формат контейнера указывает расширение файла, например: mp4, flv, ogv, webm, avi и другие;
  • Видеокодек— это программный алгоритм, с помощью которого выполняется кодирование и декодирование видеопотока (сжатие и распаковка). Для декодирования и воспроизведения видеопотока видеоплеер должен иметь информацию о кодеке, который использовался для его кодирования;
  • Аудиокодек подобен видеокодеку, но работает со звуковыми потоками.

Переход к HTML5

Основная проблема воспроизведения видео обусловлена эволюцией механизмов воспроизведения в компьютерах и мобильных устройствах. До появления спецификации HTML5 стандартный способ воспроизведения видео в браузерах отсутствовал, поэтому видео практически всегда пропускалось через надстройки сторонних изготовителей, такие как RealPlayer, Apple QuickTime и Adobe Flash. Функция воспроизведения видео в HTML5 отчасти направлена на устранение потребности в применение надстроек, даже несмотря на то, что популярность YouTube сделала Flash фактическим стандартом для воспроизведения видео на настольных компьютерах. После того как компания Apple отказалась от Flash в пользу HTML5 для воспроизведения видео в устройствах iOS, междоменное воспроизведение видео с помощью Flash стало невозможным, и разработчики начали создавать сайты, использующие для воспроизведения видео HTML5.

HTML5 добавил новый видеотег для непосредственного внедрения видео в Web-страницу для воспроизведения видео без применения надстроек. В листинге 1 показан пример видеотега для воспроизведения видео mp4 в окне браузера. Он определяет ширину и высоту — пространство, зарезервированное для видеоплеера, встроенного в окно браузера; указывает, что разрешено автоматическое воспроизведение, то есть видео начинает воспроизводиться без вмешательства пользователя; и разрешает отображение на экране органов управления воспроизведением (воспроизведение, пауза, громкость). Но главное — он указывает исходный видеоархив, который будет воспроизводиться.

Листинг 1. Видеотег HTML5 для встраивания видео в Web-страницу
<video width="320px" height="480px" autoplay="autoplay" controls="controls">
	<source src="dir/video.mp4" type="video/mp4"/>
</video>

Внедрение видеотега HTML5 активно поощряется. Сначала, сразу после появления чернового варианта спецификации HTML5, единственным браузером, поддерживающим видео HTML5, был Safari, однако сейчас эту функцию поддерживают все современные браузеры. Потоковое видео на Web-сайтах в настоящее время переживает быстрый переход от надстроек Flash к стандарту HTML5, несмотря на то, что спецификация HTML5 все еще существует лишь в черновом варианте и предположительно будет завершена лишь в 2014 году.

Когда воспроизведение видео HTML5 терпит неудачу

К сожалению, поддержка браузером видеотега HTML5 — это лишь часть проблемы, поскольку для воспроизведения видео нужно нечто большее, чем просто поддержка этого тега. Совместимость Web-страницы с разными браузерами в значительной мере зависит от поддержки форматов видеоконтейнеров, аудио- и видеокодеков, а также протоколов потоковой передачи. Например, поддержка браузерами таких кодеков, как H.264 и WebM, достаточно селективна, то есть некоторые браузеры могут поддерживать один из этих кодеков, но не поддерживать другой. HTML5 не определяет кодек, поскольку группы стандартизации не пришли к единому соглашению о применении конкретного кодека. Это значит, что Web-разработчики, размышляющие о применении видео HTML5, должны учитывать проблемы, связанные с совместимостью браузеров.

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


Пробы, страдания и найденное решение

Наш проект SmarterTVApp включал разработку межплатформенного мобильного гибридного приложения с функцией воспроизведения видео, поэтому вполне естественным выглядело применение HTML5. Мы сформировали среду разработки, использовав для этого Eclipse с надстройкой Worklight Studio 4.2, сервер с Worklight Server на Red Hat Linux® и видеосервер с видеофайлами MPEG4. Для тестирования использовалось несколько мобильных устройств с Android 4.0 Ice Cream Sandwich и Apple iOS 5, которые получали видео с видеосервера, передававшего данные с помощью протокола потоковой передачи HTTP Level Streaming (HLS).

Трехуровневая модель гибридного приложения

Созданные в Worklight приложения используют трехуровневую модель межплатформенного приложения, как показано на рисунке 1. Самый нижний уровень содержит функции собственной операционной системы, предлагаемые ее библиотеками API. Для нашего приложения SmarterTVApp эти функции включали точки вызова API операционной системы Android или iOS, которые были встроены в приложение.

Рисунок 1. Трехуровневая модель приложения
Figure 1. Three tiered application model

Средний уровень состоит из компонентов Worklight и Apache Cordova (поставляемых компанией Worklight), которые связывают код приложения HTML5 с функциональностью собственной операционной системы устройства. Apache Cordova (ранее известная как PhoneGap) представляет собой интегрированную среду с открытым исходным кодом для разработки мобильных приложений, которая позволяет разрабатывать гибридные приложения, предлагая доступ к возможностям собственной операционной системы через JavaScript™. Компоненты Worklight на этом уровне обеспечивают функциональность на стороне клиента, включая такие возможности, как скиннинг устройства, зашифрованное хранение, push-уведомления, система интеграции сервера и ряд других функций.

Верхний уровень состоит из компонентов приложения. В SmarterTVApp он содержит наше собственное приложение JavaScript, HTML и код CSS, а также компоненты, которые мы импортировали для поддержки нашего приложения, IBM Dojo Toolkit версии 1.7.2 и интегрированную среду IBM issw.mobile, используемую нашим приложением для презентации и перехода от одного представления к другому.

Среда разработки

При создании проекта Worklight в Eclipse надстройка Worklight Studio формирует исходную структуру директорий, заполненную папками для приложения и среды исполнения. Структура директорий для SmarterTVApp показана на рисунке 2. Папка common содержит файлы JavaScript, HTML и CSS, общие для сред развертывания всех устройств, а папки android, ipad и mobilewebapp содержат файлы оптимизации, специфичные для каждого конкретного устройства.

Кроме того, мы добавили в common папки, относящиеся к Dojo (dijit, dojo и dojox) для размещения файлов Dojo, используемых нашим приложением, и добавили папку issw для файлов, входящих в состав среды issw.mobile.

Рисунок 2. Папки проекта Worklight
Figure 2. Worklight project folders

Упрощенная структура испытательной среды приведена на рисунке 3. Устройства Android и iOS взаимодействуют с серверным приложением, работающим на сервере Worklight, которое затем инициирует потоковую передачу видео из видеосервера на устройства.

Рисунок 3. Испытательная среда для разработки
Figure 3. The development test environment

Начальная реализация с помощью видеотега HTML5

Для обеспечения межплатформенного воспроизведения видео наше первоначальное решение использовало видеотег HTML5, поэтому мы реализовали видеоэлемент с помощью двух элементов-источников, как показано в листинге 2. Когда браузеры сталкиваются с несколькими элементами-источниками, они используют первый распознанный формат. Мы полагали, что форматов MP4 и OGV достаточно для проверки межбраузерной совместимости.

Листинг 2. Видеотег HTML5, определяющий видео в нескольких форматах
<video width="320px" height="480px" autoplay="autoplay" controls="controls">
	<source src="dir/video.mp4" type="video/mp4/">
	<source src="dir/video.webm" type="video/webm/">
</video>

Наши надежды на быструю реализацию межплатформенного воспроизведения видео с помощью видеотега HTML5 быстро рухнули, когда мы приступили к тестированию первого прототипа. После некоторых доработок нам удалось добиться воспроизведения в наших приложениях, работающих на устройствах iOS, однако на Android мы были не столь удачливы. Таким образом, в нашей разработке начался этап проб и ошибок.

Поиск решения

Необходимо учитывать, что мобильный гибридный подход для Android в том виде, в котором он реализован в Cordova, использует для отображения Web-страниц класс Android WebView. Гибридные приложения на основе Cordova используют для отображения контента HTML5 WebView. В ходе тестирования мы обнаружили, что хотя наше HTML5-видео успешно воспроизводилось в браузере Android, с его воспроизведением начинались проблемы при отображении видеоконтента HTML5 через объект WebView гибридного приложения.

Естественно, мы обратились за информацией в Интернет, и результаты поиска подтвердили наши опасения: технические форумы пестрели жалобами страдающих разработчиков, столкнувшихся с подобными проблемами воспроизведения HTML5-видео через WebView в Android 4.0. Вооружившись прочитанными советами, мы пробовали использовать разные видеоформаты, изменяли параметры видеотега и пытались менять многие динамические (JavaScript) и статические (HTML) аспекты создания видеоэлемента и его атрибутов — все было безуспешно.

Пора было переходить к запасному плану: отказаться от воспроизведения видео с помощью видеотега HTML5, если приложение предназначалось для запуска в Android, и вместо этого использовать собственные функции Android для воспроизведения видео. Если приложение предназначалось для запуска в iOS, оно могло использовать воспроизведение видео HTML5, как и планировалось первоначально.

Одно из преимуществ разработки с помощью Worklight заключается в том, что Worklight предлагает простой механизм встраивания собственных страниц в гибридные приложения. Функции написания гибридного кода в Worklight позволяют приложению перемещаться между Web-страницами и собственными страницами и использовать на этих страницах общие данные. С использованием этой функции наше приложение приобрело способность переключаться на собственную страницу, которая использует Java API системы Android для воспроизведения видео, и затем, по окончании воспроизведения, переключаться обратно на код JavaScript, общий для iOS и Android.

Вооружившись этим знанием, мы приступили к реализации собственной страницы, которая для воспроизведения видео создает Android Activity с помощью VideoView, и в конечном счете добились успеха — воспроизведения видео при запуске приложения в Android.


Детальное описание решения

Решение включает собственный Java-код Android и код JavaScript. Для воспроизведения видео код JavaScript вызывает Java-код Android с помощью функций Worklight.

Собственный Java-код Android для воспроизведения видео

Для реализации функций воспроизведения видео на языке Java мы создали в определенном месте структуры проекта Android новый класс StreamingVideoActivity.java, как показано на рисунке 4. Структура проекта Worklight (помещающая файлы оптимизации разных устройств в отдельные папки) упрощает добавление собственного кода Android, необходимого для нашего решения.

Рисунок 4. Папка проекта Worklight с собственным Java-кодом
Figure 4. Worklight project folder containing Android native Java code

Класс StreamingVideoActivity реализован как расширение класса Android Activity и воспроизводит видео с помощью классов VideoView и MediaController. В общих чертах эта реализация показана в листинге 3. Полное решение использует обратные вызовы для управления событиями прерывания и завершения видео, что позволяет возвращать управление Web-экрану Worklight.

Листинг 3. Реализация класса StreamingVideoActivity.java
public class StreamingVideoActivity extends Activity {
	
    /** Вызывается при первом создании операции. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
    	
	super.onCreate(savedInstanceState);
	Log.d("StreamingVideoActivity", "Entering onCreate");			

	// Извлекает URL из Intent
	String url = getIntent().getStringExtra("urlParam");
		
	Log.d("StreamingVideoActivity", "About to play URL: url");			
	VideoView videoView = new VideoView(this);
	videoView.setVideoPath(url);
		
	MediaController ctlr = new MediaController(this);
	ctlr.setMediaPlayer(videoView);
	videoView.setMediaController(ctlr);
       
	setContentView(videoView);
	videoView.requestFocus();
	Log.d("StreamingVideoActivity", "Leaving onCreate");			
    }
}

Вызов кода Android из Web-приложения

После завершения работы с Android нам оставалось лишь создать функцию JavaScript, использующую Worklight API WL.NativePage.show для переключения с Activity на основе Web на новую собственную Android Activity. Реализующий эту функцию файл JavaScript SmarterTVApp.js был помещен в относящееся к Android место структуры проекта, как показано на рисунке 5.

Рисунок 5. Папка проекта Worklight, содержащая файл JavaScript, предназначенный для Android
Figure 5. Worklight project folder containing Android specific JavaScript file

Приведенный в листинге 4 фрагмент кода SmarterTVApp.js демонстрирует реализацию функции openNativePage, которая вызывает функцию Worklight WL.NativePage.show для выполнения операции StreamingVideoActivity.

Листинг 4. Фрагмент кода SmarterTVApp.js
/**
 * Воспроизводит указанное видео на собственной странице Android
 * @param url - URL видео
 */
function openNativePage (url) {
	WL.Logger.debug("Switching to SmarterTVApp.StreamingVideoActivity to play " +url);

	// Создает объект для хранения URL. Имя поля, urlParam, должно совпадать
	// с именем, использованным в собственном Java-коде Android для извлечения URL
	var params = {urlParam : url};

	// Отображает собственную страницу Android
	WL.NativePage.show('com.SmarterTVApp.StreamingVideoActivity', 
		backFromNativePage, params);
}

/**
 * Вызывается как обратный вызов после возврата с собственной страницы Android
 * @param data
 */
function backFromNativePage(data) {
	WL.Logger.debug("Back from StreamingVideoActivity");
}

В довершение всего нужно было организовать условный вызов openNativePage при работе гибридного приложения на устройстве Android, и здесь нам снова помогла среда разработки Worklight Studio. Вместо того чтобы определять тип устройства и конструкцию if-then-else в JavaScript, структура проекта Worklight обрабатывает такую ситуацию автоматически. В нашем приложении воспроизведение видео выполняется в файле StreamingView.js. Создав две версии этого файла (одна из которых сохранена в папке common и инициирует воспроизведение видео HTML5, а вторая сохранена в папке android и вызывает функцию Worklight openNativePage для инициации собственного воспроизведения видео Android), как показано на рисунке 6, Worklight Studio автоматически вставляет версию файла, соответствующую среде исполнения.

Рисунок 6. Двойная реализация воспроизведения видеопотока
Figure 6. Dual implementations of video streaming

Кликните, чтобы увидеть увеличенное изображение

Рисунок 6. Двойная реализация воспроизведения видеопотока

Figure 6. Dual implementations of video streaming

Заключение

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


Благодарности

Мы хотим поблагодарить наших коллег: Антона Александрова, Раанана Авидора (Raanan Avidor), Карла Бишопа (Karl Bishop) и Тома Тачера (Tom Thacher) – за технический вклад и полезные советы, позволившие успешно завершить этот проект.

Ресурсы

Научиться

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

Комментарии

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=WebSphere, Мобильные приложения
ArticleID=935223
ArticleTitle=Применение IBM Worklight для разработки межплатформенных гибридных видеоплееров HTML5
publish-date=06242013