Usando o IBM Worklight para Desenvolver Aplicativos Híbridos de Execução de Vídeo HTML5 para Diversas Plataformas

Com a correria para estender acesso corporativo além dos computadores para dispositivos móveis, aplicativos híbridos para dispositivos móveis estão sendo usados para aproveitar os recursos para diversas plataformas do HTML5. Infelizmente, o suporte para HTML5 deixa a desejar com relação à execução de vídeo em diversas plataformas, principalmente em aplicativos híbridos em execução no sistema operacional Android. Este artigo mostra como é possível contornar esses problemas e permitir a execução de vídeo alavancando os recursos híbridos para dispositivos móveis do IBM® Worklight. Este conteúdo é parte do IBM WebSphere Developer Technical Journal.

Bill Paris, Software Developer, IBM

Bill Paris é desenvolvedor de software que presta consultoria para o grupo IBM Software Services for WebSphere. Ele é especializado no desenvolvimento de aplicativos remotos e middleware de servidor.



Sreeni Pamidala , Senior Certified IT Architect , IBM

Sreeni Pamidala é Senior Certified, IT Architect e atualmente trabalha como Lead Architect para o grupo ISSW Mobile Services, AIM Software. Nessa função, ele passa a maior parte do tempo com clientes de todos os segmentos de mercado para desenvolver e apresentar soluções para dispositivos móveis usando as tecnologias IBM Mobile Foundation que sejam integradas à infraestrutura e ao middleware da empresa. Antes dessa função, Sreeni trabalhou com clientes do Setor de Comunicação por 15 anos, onde liderou diversos compromissos bem-sucedidos desenvolvendo e implementando soluções complexas de classificação de transmissão baseadas em rede na web para provedores de serviços de telefonia móvel e de legado usando a pilha de produtos de software e de hardware de diversas marcas da IBM e diversos produtos de integração de fornecedores terceirizados para soluções de melhores linhagens.



Raghunandan K Harithas, Consulting IT Specialist, IBM

Raghunandan Harithas é IT specialist no escritório da IBM Annapolis em Maryland, EUA. Ele trabalha como líder técnico em diversos projetos de telecomunicações usando produtos WebSphere empilhados. Atualmente, está trabalhando no campo de desenvolvimento de aplicativos remotos usando o software IBM Mobile Foundation baseado no IBM Worklight.



31/Jul/2013

Introdução

Um aplicativo híbrido para dispositivo móvel combina a funcionalidade do sistema operacional nativo com as tecnologias da web. Geralmente, um aplicativo híbrido apresenta conteúdo em um navegador da web integrado, uma abordagem que aprimora os recursos para diversas plataformas, porque a maior parte do código pode ser escrita usando tecnologias HTML5, enquanto permite, ao mesmo tempo, acesso a recursos nativos do dispositivo, quando necessário. O IBM Worklight é uma plataforma de aplicativo remoto que permite o desenvolvimento de aplicativos híbridos para diversas plataformas, oferecendo mecanismos para navegar entre a visualização da web e a visualização nativa, fornecendo um ambiente de desenvolvimento e de tempo de execução que deixa os aplicativos híbridos muito mais próximos do objetivo de "escrever uma vez e executar em qualquer lugar".

A execução de vídeo em um aplicativo é uma área em que um recurso para diversas plataformas pode ser difícil de se obter. A tag <video> de HTML5 tinha a intenção de permitir a execução de vídeo em diversas plataformas, mas o suporte inconsistente a seus recursos deixa a desejar com relação a esse objetivo.

Este artigo foca no desenvolvimento da execução de vídeo em aplicativos híbridos HTML5 para diversas plataformas e explica como a plataforma de desenvolvimento IBM Worklight pode ajudar a contornar problemas quando o suporte para recursos de vídeo de HTML5 deixa a desejar em qualquer plataforma específica.


Os desafios da execução de vídeo

Há tempos, a execução de vídeo em computadores e em dispositivos móveis impõe desafios aos desenvolvedores, pois o desenvolvimento com vídeo requer um entendimento de tecnologia e terminologia complexas. Antes de aprofundar-nos, vamos conhecer algumas terminologias.

Vídeo é uma combinação de um fluxo de vídeo (ou imagem) e um ou mais fluxos de áudio, tudo empacotado em um único archive. Em linguagem de vídeo comum:

  • Um contêiner de vídeo agrupa arquivos de áudio e de vídeo juntos em um único arquivo archive. Há muitos formatos de contêiner de vídeo e alguns populares são MPEG4, Flash Video, Ogg, WebM e AVI. O formato do contêiner é indicado pela extensão do arquivo, como mp4, flv, ogv, webm e avi, entre outras.
  • Um codec de vídeo identifica o algoritmo do software pelo qual um fluxo de vídeo é codificado e decodificado (compactado e descompactado). Um reprodutor de vídeo precisa identificar qual codec foi usado para decodificar e reproduzir o fluxo de vídeo.
  • Um codec de áudio é semelhante a um codec de vídeo, mas para fluxos de áudio.

O avanço para o HTML5

Um desafio primário da execução de vídeo vem da evolução dos mecanismos de execução de vídeo em computadores e dispositivos móveis. Antes da especificação HTML5, não havia nenhuma maneira padrão de executar vídeos em navegadores e, quase sempre, o vídeo era afunilado por meio de plug-ins de terceiros, como o RealPlayer, o Apple QuickTime e o Adobe Flash. O recurso de execução de vídeos do HTML5 surgiu, em parte, para lidar com a dependência de plug-ins, mesmo que a popularidade do YouTube para execução de vídeos tenha tornado o Flash o padrão de fato nos desktops. Com a rejeição do Flash pela Apple em favor do HTML5 para execução de vídeos em dispositivos iOS, a execução entre diversos domínios usando o Flash tornou-se impossível e os desenvolvedores começaram a focar na criação de websites que usam HTML5 para execução de vídeos.

O HTML5 incluiu uma nova tag de vídeo para integrar conteúdo de vídeo diretamente em uma página da web para reproduzir vídeo sem o uso de plug-ins. A Listagem 1 mostra um exemplo de uma tag de vídeo para reproduzir um vídeo mp4 em uma janela do navegador. Ela especifica a largura e a altura, a quantidade de espaço alocada para o reprodutor de vídeo integrado à janela do navegador, que a reprodução automática está ativada para que o vídeo seja iniciado sem ação do usuário e que controles de vídeo na tela (play, pause, volume) devem estar ativados. O mais importante é que ela especifica o archive da fonte de vídeo a ser reproduzido.

Listagem 1. Tag de vídeo HTML5 para integração de vídeo a uma página da web
<video width="320px" height="480px" autoplay="autoplay" controls="controls">
	<source src="dir/video.mp4" type="video/mp4"/>
</video>

A adoção da tag de vídeo HTML5 tem sido encorajadora. Inicialmente, o Safari era o único navegador a oferecer suporte a vídeos HTML5 quando as especificações HTML5 foram esboçadas, mas agora todos os navegadores modernos os suportam. O fluxo de vídeo na web está no meio de uma rápida transição de plug-ins Flash para o padrão HTML5, apesar de a especificação HTML5 ainda estar no formato de rascunho, com conclusão esperada para 2014.

Onde a execução de vídeo HTML5 deixa a desejar

Infelizmente, o suporte do navegador para a tag de vídeo HTML5 é somente parte da história, pois a execução de vídeo requer mais do que apenas suporte à tag. O suporte para formatos de contêineres de vídeo, codecs de vídeo e áudio e protocolos de fluxo tem uma função importante na interoperabilidade da página da web entre navegadores. Por exemplo, o suporte do navegador para codecs, como H.264 e WebM, tem sido seletivo, com alguns navegadores suportando um, mas não o outro. O HTML5 não especifica um codec, pois grupos de normas não concordaram em um único, o que significa que os desenvolvedores da web que contemplarem o uso de vídeo HTML5 devem considerar problemas de compatibilidade com navegador.

Desafios adicionais ocorrem com a execução de vídeos em dispositivos móveis, devido à natureza diversa desses dispositivos com suas diferentes resoluções e processadores de tela. Por exemplo, há centenas de variantes do Android no mercado de dispositivos móveis, todas as quais precisam reproduzir áudio e vídeo.


Avaliações, tribulações e uma solução

Nosso projeto SmarterTVApp envolveu o desenvolvimento de um aplicativo híbrido para dispositivos móveis para diversas plataformas com capacidade de execução de vídeos e pareceu natural usar vídeo HTML5 para a execução de vídeos. Formamos um ambiente de desenvolvimento usando Eclipse aumentado com o plug-in do Eclipse Worklight Studio 4.2, hardware de servidor executando o Worklight Server no Red Hat Linux® e um servidor de armazenamento de vídeo preenchido com arquivos de vídeo MPEG4. Diversos dispositivos móveis executando o Android 4.0 Ice Cream Sandwich e o Apple iOS 5 foram usados para testes e receberam vídeo de um servidor de armazenamento de vídeo para fluxo de vídeo usando o protocolo HTTP Level Streaming (HLS).

Modelo de aplicativo híbrido em três camadas

Aplicativos desenvolvidos no Worklight usam um modelo de aplicativo em três camadas para diversas plataformas, ilustrado na Figura 1. A camada mais baixa consiste na funcionalidade do sistema operacional nativo fornecida pelas bibliotecas de API do sistema operacional nativo. Para nosso SmarterTVApp, isso consistiu em pontos de chamada de API do sistema operacional Android ou iOS integrados ao aplicativo.

Figura 1. Modelo do aplicativo com três camadas
Modelo do aplicativo com três camadas

A camada intermediária consiste nos componentes Worklight e Apache Cordova fornecidos pelo Worklight que fazem a ponte do código do aplicativo HTML5 com a funcionalidade do sistema operacional do dispositivo nativo. Apache Cordova (anteriormente conhecido como PhoneGap) é uma estrutura de desenvolvimento para dispositivo móvel de software livre que permite o desenvolvimento de aplicativos híbridos fornecendo acesso a recursos do sistema operacional nativo por meio de JavaScript™. Os componentes Worklight nessa camada fornecem funcionalidade do lado do cliente, como aparência do dispositivo, armazenamento criptografado, notificações push, estrutura de integração do servidor e muitos outros recursos.

A camada superior consiste em componentes de aplicativo. No SmarterTVApp, isso consistiu em nosso código JavaScript, HTML e CSS de aplicativo customizado, juntamente com componentes que importamos para suporte a nosso aplicativo, o IBM Dojo Toolkit release 1.7.2 e a estrutura de aplicativo IBM issw.mobile usada por nosso aplicativo para apresentação e transição de visualização para visualização.

Ambiente de desenvolvimento

Quando um projeto Worklight é criado no Eclipse, o plug-in Worklight Studio cria uma estrutura de diretório inicial preenchida com um conjunto de pastas para o aplicativo e o ambiente de tempo de execução. A estrutura de diretório para o SmarterTVApp está exibida na Figura 2. A pasta comum contém os arquivos JavaScript, HTML e CSS comuns a todos os ambientes de implementação de dispositivo, enquanto que as pastas android, ipad e mobilewebapp contêm os arquivos de otimização específicos do dispositivo.

Na pasta common, também incluímos pastas relacionadas ao Dojo (dijit, dojo e dojox) para hospedarem os arquivos do Dojo usados por nosso aplicativo e incluímos uma pasta issw para os arquivos que formam a estrutura de aplicativo issw.mobile.

Figura 2. Pastas do projeto do Worklight
Pastas do projeto do Worklight

Uma ilustração simplificada do ambiente de teste de desenvolvimento é mostrada na Figura 3. Os dispositivos Android e iOS interagem com um aplicativo de servidor em execução no Worklight Server que, então, inicia o fluxo de vídeo a partir de um Servidor de Armazenamento de Vídeo para os dispositivos.

Figura 3. O Ambiente de teste de desenvolvimento
O Ambiente de teste de desenvolvimento

Implementação inicial usando vídeo HTML5

Nosso design inicial usou vídeo HTML5 para obter execução de vídeo em diversas plataformas, portanto, implementamos o elemento de vídeo com dois elementos de origem, conforme mostrado na Listagem 2. Ao encontrar diversos elementos de origem, navegadores usarão o primeiro formato reconhecido e nossa expectativa era que os formatos MP4 e OGV forneceriam recursos suficientes entre os navegadores.

Listagem 2. Tag de vídeo HTML5 especificando um vídeo em diversos formatos
<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>

Nossas grandes esperanças de implementar rapidamente a execução de vídeo entre diversas plataforma por meio do uso de vídeo HTML5 caíram por terra assim que começamos a testar nosso primeiro protótipo. Com alguns ajustes, tivemos sucesso em reproduzir vídeo em nosso aplicativo em execução em dispositivos com iOS, mas não tivemos muita sorte na execução no Android. Assim, teve início a fase de tentativa e erro de nosso desenvolvimento.

Trabalhando em direção a uma solução

Uma consideração importante aqui é que a abordagem híbrida para dispositivo móvel para Android, conforme implementada por Cordova, é baseada na classe Android WebView para exibir páginas da web. Um aplicativo híbrido baseado em Cordova usa um WebView para exibir a parte de conteúdo HTML5 do aplicativo. Em nossos testes, descobrimos que apesar de nosso conteúdo de vídeo HTML5 ser reproduzido com sucesso no navegador Android, não era reproduzido quando o conteúdo de vídeo HTML5 era exibido pelo objeto WebView do aplicativo híbrido.

Naturalmente, procuramos informações na web e uma busca rápida confirmou nossos receios: os fóruns de tecnologia estavam repletos de posts de desenvolvedores angustiados enfrentando problemas semelhantes de execução de vídeo HTML5 no WebView no Android 4.0. Munidos com as sugestões que lemos, tentamos diversos formatos de vídeo, mudanças nos parâmetros de tag de vídeo e alterações de muitos aspectos dinâmicos (JavaScript) e estáticos (HTML) da criação de elementos de vídeo e seus atributos, tudo sem sucesso.

Então, havia chegado a hora do Plano B: abandonar a execução de vídeo em diversas plataformas usando a tag de vídeo HTML5 e, em vez disso, usar a funcionalidade de execução de vídeo nativa do Android quando o aplicativo fosse desenvolvido para executar no Android. Quando desenvolvido para execução no iOS, o aplicativo usaria a execução de vídeo HTML5, conforme planejado originalmente.

Um benefício de desenvolver com o Worklight é que ele fornece um mecanismo simples para incorporar páginas nativas a aplicativos híbridos. A funcionalidade de codificação híbrida do Worklight permite que um aplicativo navegue entre páginas da web e nativas e compartilhe dados entre essas páginas. Usando esse recurso, nosso aplicativo híbrido tinha a capacidade de alternar para uma página nativa que usava a API Java do Android configurada para executar vídeo e, em seguida, quando a execução do vídeo era concluída, alternar de volta ao código JavaScript comum ao iOS e ao Android.

Com esse conhecimento, começamos a implementar uma página nativa que criava uma Android Activity usando um objeto VideoView para executar vídeo e, por fim, fomos bem-sucedidos: execução de vídeo quando em execução no Android.


Solução em detalhes

A solução consiste tanto em código Java nativo do Android quanto em código JavaScript. O código JavaScript usa os recursos do Worklight para chamar o código Java do Android para executar o vídeo.

Código Java nativo do Android para reproduzir vídeo

Para implementar a funcionalidade de vídeo Java, criamos primeiramente uma nova classe StreamingVideoActivity.java sob o local da estrutura do projeto específico do Android, mostrado na Figura 4. A estrutura do projeto do Worklight (separando arquivos de otimização específicos do dispositivo em pastas separadas) simplificou a inclusão do código nativo do Android necessário para nossa solução.

Figura 4. Pasta de projeto do Worklight que contém código Java nativo do Android
Pasta de projeto do Worklight que contém código Java nativo do Android

StreamingVideoActivity é implementado como uma extensão de uma Android Activity e executa vídeos usando as classes VideoView e MediaController. Uma estrutura de tópicos desta implementação está exibida na Listagem 3. Uma solução completa implementaria retornos de chamada para lidar com eventos de terminação e conclusão de vídeo para retornar o controle à visualização de tela baseada na web do Worklight.

Listagem 3. Implementação de StreamingVideoActivity.java
public class StreamingVideoActivity extends Activity {
	
/** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
    	
	super.onCreate(savedInstanceState);
	Log.d("StreamingVideoActivity", "Entering onCreate");			

	// Extract the URL from the 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");			
    }
}

Chamando o código do Android a partir do aplicativo da web

Com o trabalho do Android concluído, tudo que restava a fazer era criar uma função JavaScript que usasse a função da API WL.NativePage.show do Worklight para alternar da Activity baseada na web para a nova Android Activity nativa. O arquivo JavaScript SmarterTVApp.js que implementa essa funcionalidade foi colocado no local da estrutura específica do projeto do Android mostrado na Figura 5.

Figura 5. Pasta de projeto do Worklight que contém arquivo JavaScript específico do Android
Pasta de projeto do Worklight que contém arquivo JavaScript específico do Android

O extrato de código do SmarterTVApp.js na Listagem 4 mostra a implementação da função openNativePage que chama a função WL.NativePage.show do Worklight para executar a Activity StreamingVideoActivity.

Listagem 4. Extrato de código SmarterTVApp.js
/**
 * Plays the specified video in an Android native page
 * @param url  The video URL
 */
function openNativePage (url) {
	WL.Logger.debug("Switching to SmarterTVApp.StreamingVideoActivity to play " +url);

	// Create an object to hold the URL.  The field name, urlParam, must match
	// the name used in the native Android Java code for extracting the URL
	var params = {urlParam : url};

	// Show the Android native page
	WL.NativePage.show('com.SmarterTVApp.StreamingVideoActivity', 
		backFromNativePage, params);
}

/**
 * Invoked as a call-back on return from the Android native page
 * @param data
 */
function backFromNativePage(data) {
	WL.Logger.debug("Back from StreamingVideoActivity");
}

Por fim, precisávamos chamar o openNativePage de forma condicional quando o híbrido estivesse em execução em um dispositivo Android e foi aí que o ambiente de desenvolvimento do Worklight Studio foi útil novamente. Em vez de detectar o tipo de dispositivo e incluir a lógica Javascript if-then-else, a estrutura do projeto Worklight trata disso automaticamente. Em nosso aplicativo, a execução de vídeo é realizada no arquivo StreamingView.js. Ao criar duas versões do arquivo, conforme mostrado na Figura 6, uma armazenada na pasta common, que inicia a execução de vídeo HTML5, e outra armazenada na pasta android, que chama a função openNativePage do Worklight para iniciar a execução de vídeo nativa do Android, o Worklight Studio manipulou automaticamente a inclusão da versão do arquivo apropriada para o ambiente de tempo de execução.

Figura 6. Implementações duplas de fluxo de vídeo
Implementações duplas de fluxo de vídeo

Clique para ver a imagem maior

Figura 6. Implementações duplas de fluxo de vídeo

Implementações duplas de fluxo de vídeo

Conclusão

Com este projeto, aprendemos que a execução de vídeo em diversas plataformas pode ser difícil de se obter e que a solução pode requerer o uso de funcionalidade do dispositivo nativo. O Worklight simplifica o desenvolvimento por meio do uso de seus recursos para combinar a funcionalidade nativa e a baseada na web.


Agradecimentos

Os autores querem agradecer seus colegas Anton Aleksandrov, Raanan Avidor, Karl Bishop e Tom Thacher por suas contribuições técnicas e orientação que levaram ao sucesso deste projeto.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere, Desenvolvimento móvel
ArticleID=831979
ArticleTitle=Usando o IBM Worklight para Desenvolver Aplicativos Híbridos de Execução de Vídeo HTML5 para Diversas Plataformas
publish-date=07312013