Proporcione uma Experiência de Web Móvel Excepcional Usando o WebSphere Portal e o IBM Worklight V5.0, Parte 1: Integrando um aplicativo remoto híbrido com páginas do WebSphere Portal

O IBM WebSphere Portal e as soluções Exceptional Web Experience da IBM lideram o mercado de experiência na web há mais de uma década. O IBM Worklight é uma plataforma de aplicativos corporativos nova e completa para entregar aplicativos nativos, híbridos e da web. Este artigo explica como, em conjunto, o WebSphere Portal e o Worklight capacitam os usuários corporativos a fornecer suporte de site em diversos canais para suas comunidades na web. O artigo inclui um exercício usando o IBM Worklight Developer Edition 5.0 para desenvolver um aplicativo Android híbrido para visualizar páginas do WebSphere Portal.

Este artigo se aplica ao IBM Worklight V5.x. Há outra versão disponível deste aplicativo que se aplica ao IBM Worklight V6.0.

Jaye Fitzgerald, Technical Lead for Mobile Portal Accelerator, IBM

Author photoJaye Fitzgerald é o líder técnico do Mobile Portal Accelerator no Laboratório de Desenvolvimento da IBM em Littleton. Contribui com produtos remotos para o portal e presta serviços de consultoria como membro da equipe de serviços do laboratório do WebSphere Portal. Jaye apresentou ofertas remotas do WebSphere Portal no Lotusphere e nas conferências IBM Exceptional Web Experience.



Jonathan Lidaka, WebSphere Portal Front-end Engineer, IBM

author photo: Jonathan LidakaJon Lidaka é engenheiro de frontend e trabalha no Laboratório de Desenvolvimento Research Triangle da IBM. Durante o tempo em que participou do desenvolvimento do Portal, contribuiu principalmente para o desenvolvimento de temas, focando na acessibilidade e globalização, e com vários componentes, como os portlets de administração e o integrador de aplicativos da web. Atualmente, é líder da missão de desenvolvimento remoto para o Portal. Jon foi palestrante em diversas conferências da IBM, tratando do design de interfaces com o usuário e otimização de temas do Portal para dispositivos móveis.



01/Nov/2013

Introdução

O canal remoto se tornou um canal crítico e estratégico para vendas, marketing e vários outros aspectos para muitos segmentos de mercado – até mesmo para a maioria deles. Já que as empresas gerenciam suas marcas por meio de websites, a entrega de conteúdo e aplicativos para dispositivos remotos se tornou um desafio comum.

Antes de examinar a intersecção entre o IBM WebSphere Portal e o IBM Worklight, é importante entender a diferença entre um website e um aplicativo:

  • o website agrega conteúdo da web e vários aplicativos da web em uma única experiência de usuário e opera em diversos canais, como navegador de desktop, quiosque, smartphones e tablets. O website de uma linha aérea é um exemplo simples. Provavelmente eles também têm um website remoto, que suporta telefones e tablets. O WebSphere Portal é a plataforma certa para construir um website.
  • Um aplicativos da web é customizado e frequentemente é voltado para tarefas específicas. Por exemplo: o aplicativo da linha aérea, procedente de uma loja de aplicativos, que permite reservar voos ou assentos é um exemplo de aplicativo da web. Geralmente contém um subconjunto de recursos do website, voltado para o que é possível fazer no dispositivo de modo prático. O IBM WebSphere Application Server é a opção correta para entregar aplicativos da web independentes. O IBM Worklight permite criar aplicativos nativos e híbridos, e é possível usar como backend o WebSphere Application Server (se você estiver criando aplicativos híbridos) ou o WebSphere Portal (se estiver criando websites híbridos).

Em seguida, as opções se restringem a desenvolver um aplicativo nativo, um aplicativo híbrido ou um aplicativo da web. No entanto, há duas perguntas que devem ser respondidas e influem na decisão sobre a tecnologia do canal remoto:

  1. quais dispositivos será necessário suportar?
  2. O que o aplicativo irá fazer?

As considerações subjacentes que ajudam a responder essas perguntas englobam coisas como: quais são os casos de uso? O aplicativo irá precisar de recursos de dispositivos específicos, como GPS ou câmera? O aplicativo exige visão da tela com alta fidelidade ou o navegador remoto é suficiente? As respostas dessas perguntas são essenciais para essa decisão, assim como os prós e contras de nativos, híbridos e web pura:

  • aplicativos nativos para aplicativos remotos corporativos têm um custo muito alto, e o desenvolvimento de nativos puros toma muito tempo. Recursos qualificados capazes de desenvolver aplicativos 100% nativos são difíceis de encontrar e podem ser caros. Aplicativos nativos complexos podem exigir vários profissionais técnicos, e os problemas entre plataformas podem aumentar ainda mais os custos. Além do desenvolvimento inicial, atualizações contínuas do sistema operacional requerem atualizações contínuas dos aplicativos, que devem ser submetidos à aprovação novamente para voltar para as lojas.
  • Por outro lado, aplicativos da web completos, baseados em HTML5, CSS3 e JavaScript™, ou que usam estruturas no lado do cliente, como Dojo e jQuery, fornecem um modo simples de criar websites convenientes para dispositivos móveis. Normalmente os custos de desenvolvimento são muito mais baixos, porque as qualificações gerais em UI web são mais fáceis de encontrar. As atualizações dos sistemas operacionais dos dispositivos normalmente não afetam os websites remotos, que podem ser desenvolvidos de forma a funcionar em dispositivos de vários fornecedores. Os aplicativos da web construídos com esses padrões comuns da web também permitem a reutilização do código em diversos dispositivos e reduzem a manutenção e o custo total de propriedade. Além disso, não é preciso se preocupar sobre processos de revisão das lojas de aplicativos ou limitações que podem atrasar ou parar as atualizações.

    As duas principais desvantagens dessa abordagem são:

    • você só tem acesso aos recursos nativos que o navegador oferece. Por exemplo: em dispositivos iOS, você tem acesso ao potenciômetro, acelerômetro e GPS, mas não à câmera.
    • Graficamente, só se pode fazer o que é possível em HTML/CSS/JavaScript. Consequentemente, alguns recursos de fidelidade e UI que estão disponíveis no espaço nativo não estão à disposição no espaço do navegador.
  • Aplicativos híbridos oferecem o melhor dos dois mundos. Você tem a simplicidade do desenvolvimento com HTML/CSS/JavaScript, mas pode complementar isso com serviços nativos e produzir um aplicativo para as lojas. Com uma tecnologia como o Apache Cordova (o Worklight usa essa tecnologia e vem de fábrica com ela), é possível chamar recursos nativos com JavaScript a partir da marcação da web. Por exemplo: é possível chamar a câmera usando uma linha simples de JavaScript, como: navigator.camera.takeSnapshot.

Solução amostra

Este artigo descreve as etapas para construir uma solução amostra que integra o Worklight 5.0 e o WebSphere Portal 8.0 por meio de um aplicativo híbrido. Esta seção examina os componentes envolvidos nessa solução e os pré-requisitos necessários para realizar essas etapas.

Componentes

  • Worklight

    A plataforma Worklight inclui um conjunto de componentes que permitem gerenciar todo o ciclo de vida de aplicativos nativos, híbridos e da web entregues a diversas plataformas remotas, como iOS, Android, BlackBerry e Windows® Phone. O IBM Worklight Developer Edition 5.0 é um ambiente de desenvolvimento remoto integrado eficiente e flexível, que você pode obter por download e usar gratuitamente. O Worklight Developer Edition é usado neste artigo para desenvolver o aplicativo de amostra que acessa o WebSphere Portal.

  • WebSphere Portal

    O WebSphere Portal é líder de mercado na entrega de uma estrutura de website para aplicativos de desktop e remotos. O WebSphere Portal fornece navegação no site e identidade visual (branding), para que você possa personalizar o site para os seus negócios. A estrutura entrega conteúdo dirigido com analítica para medir a efetividade do site. O acesso baseado em função e o conteúdo acionado pelo contexto também são recursos-chave. Os pontos fortes do WebSphere Portal derivam de sua base, que é o WebSphere Application Server. O WebSphere Portal tem uma lista variada de recursos que englobam segurança, gerenciamento integrado de conteúdo da web, direcionamento de conteúdo, portais virtuais, etc. O maior valor do WebSphere Portal é a capacidade de agregar aplicativos no site com seu ambiente de recursos.

  • Design da web responsivo

    A criação de uma experiência excepcional na web, otimizada para diversos dispositivos, é essencial para os negócios de hoje. Atualmente, os usuários esperam poder navegar na web com os smartphones com a mesma facilidade que eles têm ao fazer isso em um computador desktop. No entanto, o direcionamento para dispositivos móveis geralmente começa com uma conversa sobre aplicativos nativos. Como já foi mencionado, o custo de propriedade desses aplicativos é alto e a reutilização do código é limitada. Outra solução é criar um website alternativo especificamente para um dispositivo móvel, mas isso não é muito prático porque você pode acabar tendo muitos recursos de código para manter.

    A web responsiva (consulte Recursos) é uma solução prática para o panorama mutável de dispositivos e tamanhos de tela, porque cria websites flexíveis, fluentes e adaptáveis. O uso de conceitos de design da web responsiva oferece um meio para que a interface com o usuário seja otimizada automaticamente para a resolução da tela, a orientação ou recursos para aplicativos da web ricos e aplicativos híbridos. Isso garante que você aproveite ao máximo o esforço de design da web.

  • Opções de topologia

    Você encontrará opções de topologia de servidor ao planejar a implementação do Worklight e do WebSphere Portal. Para que o IBM Worklight Server acesse o WebSphere Portal, é necessário ter um proxy. Esta amostra foi testada com os servidores do WebSphere Portal e do Worklight servers colocalizados na mesma máquina de desenvolvimento; a Listagem 3 mostra que o endereço IP na URL do WebSphere Portal é usado para acessar a página inicial. É necessário ter um proxy para implementar esta amostra quando os servidores estão em sistemas diferentes. O módulo 45 na documentação Getting started with IBM Worklight trata de como usar um website remoto, como um que está hospedado em um servidor do WebSphere Portal.

Outros produtos IBM também podem suprir as suas necessidades ligadas à construção de aplicativos da web ou híbridos. Por exemplo: o IBM Rational® Application Developer e o IBM Web Experience Factory são outras opções para desenvolver aplicativos.

Pré-requisitos

Para desenvolver a amostra de aplicativo remoto híbrido descrita aqui, é necessário ter estes produtos de software e recursos instalados corretamente e funcionando:

  • WebSphere Portal 8.0

    Consulte a documentação do WebSphere Portal para obter as instruções de instalação.

  • Eclipse

    Faça o download do Eclipse. Esta amostra se baseia no Eclipse 3.7.2 (Indigo) e foi testada com o IDE Eclipse for Java™ EE Developers. (O Eclipse Classic e o IDE Eclipse for Java Developers também podem funcionar, mas não foram testados com esta amostra.)

Tenha em mente que o aplicativo descrito aqui só funcionará com dispositivos Android. As partes subsequentes desta série irão abordar a integração do Worklight com sistemas operacionais Android e iOS.

  • Android SDK

    Com o Eclipse instalado, a próxima etapa é incluir o Android SDK. Esta amostra foi testada com o Android SDK 2.3.3 (API 10).

    O Oracle Java JRE é um pré-requisito para o Android SDK. Após a instalação, pode-se configurar a instância do Eclipse para usar o JRE navegando para Window > Preferences > Java > Installed JREs (Figura 1).

    Figura 1. Configure o Oracle JRE no Eclipse
  • Worklight

    Esta amostra requer o IBM Worklight 5.0 ou posterior e não irá funcionar com versões anteriores. É possível fazer o download do IBM Worklight Developer Edition 5.0 para usar no desenvolvimento gratuitamente. Detalhes sobre como atualizar o Eclipse com o plugin estão disponíveis nos módulos Setup da documentação Getting started with IBM Worklight .

    O Worklight instala o servidor como parte do Eclipse. Talvez você precise atualizar o eclipse.ini para mudar a porta de 8080 para outro valor, como 8085. O servidor do Worklight inicia automaticamente quando você inicia o Eclipse. A Listagem 1 mostra um exemplo de conteúdo do arquivo eclipse.ini com -Dworklight_port configurado.

    Listagem 1. eclipse.ini
    -startup
    plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
    --launcher.library
    plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502
    -showsplash
    org.eclipse.platform
    --launcher.XXMaxPermSize
    256m
    --launcher.defaultAction
    openFile
    -vmargs 
    -Dworklight.port=8085
    -Xms40m
    -Xmx384m
  • Cliente WebDAV

    Para atualizar o tema do WebSphere Portal com o Worklight Javascript, é necessário um cliente do WebDAV. Esta amostra foi desenvolvida usando o AnyClient. É possível usar qualquer cliente do WebDAV que o WebSphere Portal suporta. Consulte Connecting to the Portal WebDAV with 8.0 para obter detalhes.

  • Tema customizado

    É necessário criar seu próprio tema customizado antes de aplicar o Worklight Javascript ao seu tema. A cópia do tema do WebSphere Portal garante que o seu tema contenha todos os elementos necessários para o seu funcionamento e que as suas alterações não sejam sobrescritas por um fix pack. Não modifique o tema do WebSphere Portal diretamente, porque ele pode ser atualizado pelos fix packs de serviço. Em seguida, siga as instruções neste artigo para criar uma cópia do tema.


Crie o aplicativo do Worklight

  1. Inicie o Eclipse. No console do Worklight, pode-se ver que o servidor iniciou (Figura 2).
    Figura 2. O servidor do Worklight iniciou
  2. Para começar a construir o aplicativo, é necessário criar um novo projeto do Worklight. A partir do Eclipse, navegue para New > Other > Worklight Project e, em seguida, clique em Next (Figura 3).
    Figura 3. Crie um novo projeto do Worklight
  3. Dê um nome ao projeto. Na Figura 4, o projeto é chamado WLPortal. Mantenha Hybrid Application selecionado como padrão e clique em Next.
    Figura 4. Dê um nome ao projeto do Worklight
  4. Dê um nome ao aplicativo híbrido no projeto do Worklight — neste caso, WLPortalApp. Não há pacote de JavaScript nesta amostra, mas você tem a opção de incluir um nesse painel (Figura 5).
    Figura 5. Dê um nome ao aplicativo híbrido
  5. Clique em Finish. O projeto e os artefatos de aplicativo são criados. Isso pode levar alguns minutos. Quando isso estiver concluído, pode ser que você receba a solicitação de alternar para a perspectiva Design e visualizar o projeto no Project Explorer (Figura 6).
    Figura 6. Projeto exibido no Eclipse
  6. Em seguida, é conveniente criar um ambiente do Worklight para desenvolver o aplicativo híbrido. Clique com o botão direito no WLPortalApp na pasta de aplicativos e, em seguida, selecione New > Worklight Environment (Figura 7).
    Figura 7. Crie um novo ambiente do Worklight
  7. O painel New Worklight Environment é exibido (Figura 8). Já que esta amostra específica é somente para um aplicativo Android híbrido, selecione Android phones and tablets. Se você precisasse criar ambientes para outros sistemas operacionais de dispositivos, você especificaria essas opções adicionais neste painel. Clique em Finish.
    Figura 8. Ambiente do Worklight exibido no Eclipse
  8. O Worklight Studio constrói e atualiza o projeto com um aplicativo nativo (Figura 9). O projeto nativo tem o nome Worklight Project/WorklightApplication/Platform. O Worklight Studio gerencia o ciclo de vida desse aplicativo — não faça alterações nele. Quando o aplicativo da web que você criou inicialmente no projeto for construído e implementado, o aplicativo nativo será sobrescrito pelas mudanças no aplicativo.
    Figura 9. O aplicativo nativo é construído
  9. Agora que o aplicativo foi configurado, certifique-se de que ele seja desenvolvido e implementado. Como se pode ver na Figura 10, o comando Build All and Deploy significa que o aplicativo nativo será reimplementado com base nas mudanças no aplicativo da web. É possível executar o comando Build All and Deploy clicando com o botão direito no aplicativo e selecionando Run As > Build All and Deploy.
    Figura 10. Selecionando para desenvolver e implementar

    Quando o processo de desenvolvimento começa, é possível ver o progresso no banner de status no canto inferior direito do Eclipse. Quando o processo concluir, você deverá ver a mensagem Application 'YourApp' deployed successfully with all environments no console do Worklight (Figura 11).

    Figura 11. Mensagem de êxito exibida no log

Crie um dispositivo virtual Android antes de tentar executar seu novo aplicativo Android. Consulte este artigo sobre o uso de dispositivos de hardware para ver detalhes sobre AVDs.

  1. Para executar esse aplicativo Android, clique com o botão direito no projeto WLPortalWLPortalAppAndroid no Project Explorer e selecione Run As > Android Application. Essa ação ativa o Android Emulator (se ele ainda não estiver em execução) e carrega uma nova instância do aplicativo. Talvez você precise abrir a tela inicial do emulador para ver o aplicativo. A Figura 12 mostra uma visualização do aplicativo que você desenvolveu.
    Figura 12. Aplicativo renderizado no emulador

Em seguida, você irá incluir código no seu aplicativo para chamar uma página do WebSphere Portal.


Atualize o tema do WebSphere Portal com o Worklight JavaScript

  1. A primeira etapa para integrar o WebSphere Portal e o Worklight é exibir o portal dentro do aplicativo Android. Para fazer isso, crie um aplicativo híbrido que se conecta ao WebSphere Portal dentro do wrapper nativo. No Eclipse, abra a classe Java que inicializa o aplicativo (Listagens 2a e 2b), localizado em \WLPortal\apps\WLPortalApp\android\native\src\com\WLPortalApp\WLPortalApp.java.
    Listagem 2a. WLPortalApp.java no Worklight versão 5.0.5
    package com.WLPortalApp;
    
    import android.os.Bundle;
    
    import com.worklight.androidgap.WLDroidGap;
    
    public class WLPortalApp extends WLDroidGap {
    	@Override
    	public void onCreate(Bundle savedInstanceState) {
    	   super.onCreate(savedInstanceState);
    	   //DeviceAuthManager.getInstance().setProvisioningDelegate(
    	   <Use default ProvisioningDelegateImpl class or replace 
    	   with your IProvisioningDelegate implementation>);
    	   super.loadUrl(getWebMainFilePath());
    	}		
    	}
    Listagem 2b. WLPortalApp.java no Worklight versão 5.0.6
    package com.WLPortalApp ;
    
    import android.os.Bundle;
    
    import com.worklight.androidgap.WLDroidGap;
    
    public class WLPortalApp extends WLDroidGap {
    	
    	@Override
    	public void onCreate(Bundle savedInstanceState){
    		super.onCreate(savedInstanceState);
    	}
    	
    	/**
         * onWLInitCompleted is called when the Worklight runtime 
         * framework initialization is complete
         */
    	@Override
    	public void onWLInitCompleted(Bundle savedInstanceState){
    		super.loadUrl(getWebMainFilePath());
    		// Add custom initialization code after this line
    	}
    }

O endereço IP neste exemplo deve ser o endereço do servidor do WebSphere Portal que você quer renderizar no aplicativo híbrido. Consulte a seção Componentes da solução amostra para obter mais informações sobre a instalação do Worklight e do WebSphere Portal.

  1. O aplicativo usa a classe mostrada nas Listagens 2a e 2b para encaminhar o controle para a página HTML localizada em \WLPortal\apps\WLPortalApp\common\WLPortalApp.html. É necessário mudar esse arquivo para que ele encaminhe para o endereço IP e a porta do WebSphere Portal. Para fazer isso no Worklight versão 5.0.5, é possível mudar o método onCreate para carregar a URL do WebSphere Portal e utilizar o gerenciador de cookies(Listagem 3a). Na versão 5.0.6, você irá mudar o método onWLInitCompleted (Listagem 3b).
    Listagem 3a. Método onCreate utilizando a URL do WebSphere Portal no Worklight versão 5.0.5
    public void onCreate(Bundle savedInstanceState) {
    	   super.onCreate(savedInstanceState);
    	   CookieSyncManager.createInstance(appView.getContext());
    	   CookieManager.getInstance().removeSessionCookie();
    	   super.loadUrl("http://9.99.999.999:10039/wps/portal",false);
    	   }
    Listagem 3b. Método onCreate utilizando a URL do WebSphere Portal no Worklight versão 5.0.6
    public void onWLInitCompleted(Bundle savedInstanceState){
    		CookieSyncManager.createInstance(appView.getContext());
    		CookieManager.getInstance().removeSessionCookie();
    super.loadUrl("http://9.99.999.999:10039/wps/portal",false);
    }
  2. Certifique-se de incluir as dependências de importação do CookieSyncManager e do CookieManager mostrados na Listagem 4.
    Listagem 4. Dependências do CookieSyncManager e do CookieManager
    import android.webkit.CookieSyncManager;
    import android.webkit.CookieManager;
  3. Por causa dos redirecionamentos, é necessário definir outro método para fazer as páginas autenticadas funcionarem. O método é mostrado na Listagem 5. O resultado dessas atualizações é mostrado nas Listagens 6a e 6b.
    Listagem 5. Inclua este método loadUrl
    public void loadUrl(String url) {
    	loadUrl(url,false);
    	}
    Listagem 6a. O conteúdo final de WLPortalApp.java no Worklight versão 5.0.5
    package com.WLPortalApp;
    
    import android.os.Bundle;
    import android.webkit.CookieSyncManager;
    import android.webkit.CookieManager;
    
    import com.worklight.androidgap.WLDroidGap;
    
    public class WLPortalApp extends WLDroidGap {
    	@Override
    	public void onCreate(Bundle savedInstanceState) {
    		   super.onCreate(savedInstanceState);
    		   CookieSyncManager.createInstance(appView.getContext());
    		   CookieManager.getInstance().removeSessionCookie();
    		   super.loadUrl("http://9.99.999.999:10039/wps/portal",false);
    	}	
    	
    	public void loadUrl(String url) {
    		loadUrl(url,false);
    	}
    	}
    Listagem 6b. O conteúdo final do WLPortalApp.java no Worklight versão 5.0.6
    package com.WLPortalApp ;
    
    import android.os.Bundle;
    import android.webkit.CookieSyncManager;
    import android.webkit.CookieManager;
    
    import com.worklight.androidgap.WLDroidGap;
    
    public class WLPortalApp extends WLDroidGap {
    	
    	@Override
    	public void onCreate(Bundle savedInstanceState){
    		super.onCreate(savedInstanceState);
    	}
    
    	@Override
    	public void onWLInitCompleted(Bundle savedInstanceState){
    		CookieSyncManager.createInstance(appView.getContext());
    		CookieManager.getInstance().removeSessionCookie();
    	super.loadUrl("http://9.99.999.999:10039/wps/portal",false);
    	}
    	
    	public void loadUrl(String url) {
    		loadUrl(url,false);
    	}	
    
    }
  4. Para garantir que todos os links sejam abertos com a visualização na web do contêiner híbrido, configure a preferência stay-in-webview no cordova.xml para o Worklight versão 5.0.5, localizado em \WLPortal\apps\WLPortalApp\android\native\res\xml\cordova.xml; na versão 5.0.6, o arquivo se chama config.xml e está localizado em \WLPortal\apps\WLPortalApp\android\native\res\xml\config.xml. Para fazer isso:

    <preference name="stay-in-webview" value="true" />

    Se você está usando um servidor de portal não-local, é possível modificar a política de segurança nesse local também. A política de segurança padrão é bloquear todo o acesso à rede. Em seguida, é possível declarar acesso a domínios e subdomínios de rede específicos dentro de cordova.xml. Este artigo fornece mais informações.

  5. Agora é possível clicar com o botão direito no aplicativo novamente e selecionar Build All and Deploy. Você verá o progresso no banner de status no canto inferior direito do Eclipse. Quando o processo for concluído, clique com o botão direito em WLPortalWLPortalAppAndroid e selecione Run As... > Android Application. Isso ativa o Android Emulator, e o aplicativo exibe o WebSphere Portal, mostrado na Figura 13.
    Figura 13. Emulador executando um aplicativo que exibe o WebSphere Portal
  6. Nesse ponto, você precisa do tema customizado, baseado no tema do WebSphere Portal 8.0 que você criou anteriormente. Você terá que usar um utilitário WebDAV para:
    • Atualizar o modelo do tema (theme.html).
    • Copiar os arquivos do Worklight JavaScript para o tema.
    • Criar módulos que serão definidos em um novo perfil de tema.

    Inicie o utilitário WebDAV (usamos o AnyClient para esta amostra) e conecte ao ponto de entrada fs-type1 . Quando ele carrega, exibe a estrutura de pasta mostrada na Figura 14.

    Figura 14. Estrutura da pasta WebDAV para o fs-type1
  7. Navegue para o tema customizado; por exemplo, fs-type1:themes/<customTheme>. Crie uma pasta com o nome worklight dentro do seu tema customizado (Figura 15).
    Figura 15. A pasta worklight foi criada
  8. Localize os arquivos JavaScript no Eclipse para as bibliotecas do Worklight que você irá carregar no WebSphere Portal. Essas pastas são chamadas wlclient e common e estão localizadas em: \WLPortal\apps\WLPortalApp\android\native\assets\www\default\. Copie as pastas wlclient e common para a pasta worklight que você criou no WebDAV.
  9. Abra o arquivo HTML principal que o aplicativo carregou antes de você inserir a URL do WebSphere Portal, em \WLPortal\apps\WLPortalApp\android\native\assets\www\default\WLPortalApp.html. Há duas partes neste arquivo que você precisa integrar ao WebSphere Portal, porque o aplicativo não usa mais esse arquivo.
    • O primeiro é o arquivo JavaScript estático incluído no elemento <head> (Listagem 7).
      Listagem 7. JavaScript estático incluído no elemento head de WLPortalApp.html
      <script type="text/javascript">
          // Define WL namespace.
          var WL = WL ? WL : {};
      
          /**
      
           * WLClient configuration variables.
      
           * Values are injected by the deployer that packs the gadget.
      
           */
      
          WL.StaticAppProps = {
          "APP_DISPLAY_NAME": "WLPortalApp",
          "APP_LOGIN_TYPE": "never",
          "APP_SERVICES_URL": "\/apps\/services\/",
          "APP_VERSION": "1.0",
          "ENVIRONMENT": "android",
          "LOGIN_DISPLAY_TYPE": "embedded",
          "LOGIN_REALM": null,
          "WORKLIGHT_ROOT_URL": "\/apps\/services\/api\/WLPortalApp\/android\/"
      };</script>
    • O segundo é o onload configurado no elemento <body>, que inicializa o cliente do Worklight (Listagem 8).
      Listagem 8. O método onload configurado no corpo para inicializar o Worlight JavaScript
      <body id="content" onload="WL.Client.init({})" style="display: none">

    Essas duas seções devem ser incluídas no tema como artefatos de um módulo. Tome o JavaScript deste arquivo HTML e inclua-o nos arquivos Javascript individuais de forma utilizável. Crie dois novos arquivos na pasta <customTheme>/worklight/common/js da biblioteca do Worklight, chamados init.js e staticprops.js (Figura 16) em: fs-type1:themes/<customTheme>/worklight/common/js/.

    Figura 16. Os novos arquivos init.js e staticprops.js são criados
  10. Copie para a máquina local o arquivo staticprops.js que você acabou de criar e abra o arquivo (Listagem 9). Copie o JavaScript estático da página HTML para esse arquivo.
    Listagem 9. Conteúdo do arquivo staticprops.js
    var WL = WL ? WL : {};
    WL.StaticAppProps = {
        "APP_DISPLAY_NAME": "WLPortalApp",
        "APP_LOGIN_TYPE": "never",
        "APP_SERVICES_URL": "\/apps\/services\/",
        "APP_VERSION": "1.0",
        "ENVIRONMENT": "android",
        "LOGIN_DISPLAY_TYPE": "embedded",
        "LOGIN_REALM": null,
        "WORKLIGHT_ROOT_URL": "\/apps\/services\/api\/WLPortalApp\/android\/"
    };

    Copie o arquivo staticprops.js atualizado de volta para a pasta <customTheme>/worklight/common/js no WebDAV.

  11. Copie para a máquina local o arquivo init.js que você acabou de criar e abra o arquivo (Listagem 10). A API i$, incluída no tema do WebSphere Portal, é usada aqui para criar uma função onload que substitui o onload sequencial configurado na página HTML.
    Listagem 10. Conteúdo do arquivo init.js
    i$.addOnLoad(function(){	
    	WL.Client.init({});
    });

    Copie o arquivo init.js de volta para a pasta <customTheme>/worklight/common/js no WebDAV.

    Consulte os WebSphere Portal 8.0 Javadocs para saber mais sobre a API i$, e o wiki do WebSphere Portal para saber mais sobre criar módulos usando a estrutura de otimização do tema.

  12. O último artefato necessário criar antes de definir os novos módulos do tema é a amostra que testa o Worklight JavaScript. Essa amostra testa a disponibilidade da API Cordova dentro do tema do WebSphere Portal e se baseia no exemplo configurado na API Cordova.

    Já que o objetivo dessa amostra é apenas testar o uso da API no WebSphere — e, portanto, seu valor de reutilização é limitado — não é necessário criar um módulo para o código da amostra. Coloque o fragmento de código diretamente no modelo do tema e, em seguida, copie o modelo de tema localizado para a sua máquina. O modelo do tema está no WebDAV localizado no tema customizado fs-type1:themes/<customTheme>/nls/theme_en.html (Figura 17).

    Figura 17. O modelo do tema localizado para incluir o código de amostra
  13. Abra o modelo do tema e localize o elemento de conteúdo dinâmico <a rel="dynamic-content" href="co:config"></a> , localizado na parte inferior do modelo. Coloque o exemplo deviceready da API Cordova depois desse local de conteúdo dinâmico, como mostra a Listagem 11.
    Listagem 11. Amostra para testar a API Cordova no WebSphere Portal
    <div class="wpthemeComplementaryContent" 
            id="wpthemeComplementaryContent" 
    		role="region" 
    		aria-labelledby="wpthemeComplementaryContentText">
      <span class="wpthemeAltText" id="wpthemeComplementaryContentText">
    	Complementary Content
      </span>
      <a rel="dynamic-content" href="co:config"></a>
      <script type="text/javascript">
      document.addEventListener("deviceready", onDeviceReady, false);
      function onDeviceReady() {	
            var element = document.getElementById('deviceProperties');
            element.innerHTML = 'Device Name: '     + device.name + '<br/>' + 
                                'Device Version: '  + device.version;
      }
      <script>
    </div>
  14. Depois que o JavaScript estiver preparado para testar a Cordova, é necessário inserir um elemento dentro do modelo do tema que irá mostrar as informações do dispositivo. Diretamente abaixo do elemento <body>, coloque um elemento com ID de "deviceProperties" no modelo do tema. A Listagem 12 mostra um exemplo.
    Listagem 12. Elemento de propriedades do dispositivo no modelo do tema
    <p id="deviceProperties">Loading device info</p>
  15. Com o modelo do tema abaixo, inclua um ID no elemento <body> com o valor "content" (Listagem 13). O método init do Worklight precisa disso.
    Listagem 13. Inclua o novo ID no elemento de corpo
    <body id="content" class="lotusui30dojo tundra locale_en">
  16. Agora que os itens da página HTML e uma amostra para testar o Worklight JavaScript estão incluídos como arquivos individuais no tema, é possível defini-los como artefatos em novos modelos. Para fazer isso, registre as novas contribuições de tema como um arquivo de configuração de JSON na pasta contributions sob o novo tema customizado no WebDAV. O sistema varre automaticamente os arquivos dessa pasta, e as contribuições definidas são registradas no tema que as define. (Para saber mais sobre a criação de contribuições específicas para temas, consulte Registering theme specific contributions.)
    1. Abra a pasta contributions sob o tema customizado e crie um arquivo chamado worklight.json. Esse arquivo deve definir dois novos módulos para o seguinte:
      • Arquivos de biblioteca do Worklight JavaScript
      • Onload de inicialização do Worklight

      Esses dois módulos serão identificados como wl_client e wl_init, respectivamente.

    2. Copie o arquivo worklight.json para a sua máquina local e coloque o conteúdo da Listagem 14 nesse arquivo.
      Listagem 14. Conteúdo do arquivo worklight.json
      {
         "modules":[{
            "id":"wl_client",
            "contributions":[{
               "type":"config",
                  "sub-contributions":[
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/common/js/staticprops.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/cordova.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/common/js/wljq.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/common/js/base.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/messages.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/common/js/wlcommon.js"}]
                  },				
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/diagnosticDialog.js"}]
                  },
                  {
                     "type":"js",
                     "uris":
                        [{"value":"/worklight/wlclient/js/deviceAuthentication.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/window.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/worklight.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/wlclient.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/wlfragments.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/encryptedcache.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/checksum.js"}]
                  },
                  {
                     "type":"js",
                     "uris":[{"value":"/worklight/wlclient/js/wlgap.android.js"}]
                  }]
              }]
         },
         {
            "id":"wl_init",
            "prereqs":[{
               "id":"wl_client"
            },{
               "id":"wp_client_main"
            },{
               "id":"wp_client_ext"
            }],
            "contributions":[{
               "type":"config",
               "sub-contributions":[{
                  "type":"js",
                  "uris":[{
                     "value":"/worklight/common/js/init.js"
                  }]
               }]
            }]
         }
         ]
      }
    3. Copie o arquivo worklight.json de volta para a pasta <customTheme>/contributions no WebDAV.
  17. Agora as bibliotecas do Worklight JavaScript estão definidas em módulos do tema. A amostra para testar o JavaScript foi colocada diretamente no modelo do tema para facilitar a sua remoção depois do teste, mas o código de amostra não requer nenhum módulo no perfil. A última etapa é criar módulos e defini-los em um perfil de tema. Crie um novo perfil abrindo o perfil leve localizado no tema customizado em fs-type1:themes/<customTheme>/profiles/profile_lightweight.json. Copie esse arquivo para a sua máquina local e renomeie-o como profile_worklight.json.
  18. Abra o arquivo profile_worklight.json e inclua os módulos wl_client e wl_init que você definiu como contribuições (Listagem 15).
    Listagem 15. Exemplo de array de IDs de módulo definido no perfil
    "moduleIDs": [
    		"wp_theme_portal_80",
    		"wp_portlet_css",
    		"wp_one_ui",
    		"wp_one_ui_dijit",
    		"wp_legacy_layouts",
    		"wp_client_ext",
    		"wp_status_bar",
    		"wp_theme_menus",
    		"wp_theme_skin_region",
    		"wp_theme_high_contrast",
    		"wp_layout_windowstates",
    		“wl_client”,
    		“wl_init”
    	],
  19. Renomeie o perfil de modo que você possa identificá-lo facilmente ao selecionar do diálogo de propriedades da página. Para fazer isso, localize o título em inglês (ou no código de idioma com o qual você pretende trabalhar) e mude o título de “Lightweight” para “Worklight” (Listagens 16 e 17).
    Listagem 16. Título do perfil antes da mudança
    {
    	"value":"Lightweight",
    	"lang":"en"
    },
    Listagem 17. Título do perfil depois da mudança
    {
    	"value":"Worklight",
    	"lang":"en"
    },
  20. Copie o arquivo profile_worklight.json de volta para o diretório <customTheme>/profiles/ no WebDAV. Limpe o cache do navegador e reinicie o WebSphere Portal para garantir que o novo perfil esteja habilitado.

    Todos os artefatos de tema necessários para aplicar o IBM Worklight JavaScript no WebSphere Portal estão em ordem. Agora é possível pegar o perfil que definiu os módulos para incluir os artefatos do Worklight e aplicá-los a uma página. Crie uma página com o seu tema aplicado, caso você ainda não tenha feito isso. (Consulte Page creation and navigation para saber mais sobre a criação de páginas.)

    Há duas formas de aplicar o perfil à página e visualizar as alterações no Worklight. É possível:

    • Configurar o perfil como padrão do tema.
    • Configurá-lo especificamente para uma determinada página.

    As duas opções funcionam para você ver as mudanças, mas é mais fácil configurar o perfil em uma página específica. Para fazer isso, abra o diálogo Page Properties que está disponível na prateleira de customização e localize o menu suspenso referente aos perfis de tema disponíveis em na guia Advanced (Figura 18). (Consulte Changing the theme profile para obter mais informações.)

    Figura 18. O menu do perfil no diálogo de propriedades da página

Teste o aplicativo híbrido com o Android Emulator

Agora que você aplicou o perfil a uma página do WebSphere Portal, é possível testar a amostra usando o Android Emulator:

  1. Mais uma vez, desenvolva e implemente o aplicativo clicando com o botão direito no aplicativo e selecionando Build All and Deploy. É possível ver o progresso no banner de status no canto inferior direito do Eclipse.
  2. Quando o processo for concluído, clique com o botão direito em WLPortalWLPortalAppAndroid e selecione Run As... > Android Application. Isso irá ativar o Android Emulator e o aplicativo exibirá o WebSphere Portal.
  3. Depois que o aplicativo tiver renderizado o aplicativo do WebSphere Portal, efetue login e navegue para a página, se a nova página à qual você aplicou o perfil do Worklight não tiver acesso anônimo. O carregamento das configurações do dispositivo demora um pouco, mas você irá vê-las na parte superior da página, como mostra a Figura 19.
    Figura 19. Aplicativo do Worklight exibindo informações no WebSphere

Conclusão

O IBM Worklight facilita a ativação de aplicativos da web em diversos canais para interagir com o dispositivo e os canais de entrega do dispositivo. O shell do Worklight é uma camada thin de código de cliente nativo no dispositivo que manipula aspectos como autenticação, segurança, ativação de aplicativos e notificações e pode ser ajustado para as necessidades específicas de uma organização ou negócios. O shell serve para ativar o conteúdo da web (a parte mais importante do aplicativo). O IBM WebSphere Portal pode agregar portlets que incluem uma marcação que usa os serviços nativos do Worklight, juntamente com outros portlets. Para fazer isso, o shell do Worklight é entregue de forma padrão e aponta para os websites gerenciados pelo WebSphere Portal. O shell do Worklight também pode ser empacotado em um distribuível que pode ser publicado na loja de aplicativos ou implementados MDM, se necessário. O resultado é a ampliação dos recursos completos de gerenciamento de websites em diversos canais do WebSphere Portal para incluir serviços para dispositivos nativos.

Artigos subsequentes desta série tratarão da utilização de recursos nativos dentro do tema do WebSphere Portal, configuração da autenticação entre o Worklight e o WebSphere Portal, fornecimento de integração nativa aos serviços sociais do dispositivo via Worklight e gerenciamento de conteúdo da web e aumento dos portlets do IBM Rational Application Developer e do IBM Web Experience Factory usando o Worklight.


Downloads

DescriçãoNomeTamanho
Sample portal theme filesWLPortalApp-theme_files.zip8 KB
Sample applicationWLPortalApp.zip1 KB

Recursos

Aprender

Obter produtos e tecnologias

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=Lotus, WebSphere, Desenvolvimento móvel
ArticleID=838042
ArticleTitle=Proporcione uma Experiência de Web Móvel Excepcional Usando o WebSphere Portal e o IBM Worklight V5.0, Parte 1: Integrando um aplicativo remoto híbrido com páginas do WebSphere Portal
publish-date=11012013