Os aspectos básicos do desenvolvimento de um aplicativo remoto de ponta a ponta usando IBM Worklight e Dojo Mobile

Este artigo descreve coisas que aprendemos através de nossa experiência usando IBM® Worklight Studio e Dojo Mobile para desenvolver um aplicativo remoto de ponta a ponta para bancos de varejo. Além de informações fundamentais sobre essas ferramentas de desenvolvimento e sobre o desenvolvimento de aplicativos remotos em geral, incluímos código fonte de amostra para ilustrar e ajudar o leitor a aplicar essas dicas no desenvolvimento de seu próprio aplicativo. Este conteúdo é parte do IBM WebSphere Developer Technical Journal.

Denzil Menezes, IT Specialist Coop, IBM

Denzil Menezes tem mais de cinco anos de experiência em desenvolvimento e integração de sistemas J2EE. Atualmente ele trabalha em soluções de aplicativos remotos no IBM Global Solution Center, usando principalmente IBM Worklight e dojo mobile.



Karl Bishop, Senior Software Engineer, IBM

Karl Bishop é Senior Software Engineer na equipe IBM Web Enablement and Support. Ele trabalha nas florestas da Carolina do Norte. Karl trabalha em vários aplicativos internos e externos de Web 2.0 e remotos. Ele é especializado em soluções baseadas em Dojo, Dojo Mobile e Worklight.


nível de autor Contribuidor do
        developerWorks

Biao Hao, Senior IT Architect, IBM

Biao Hao é Certified Senior IT Architect no IBM Global Solution Center, em Dallas. Atualmente ele lidera o desenvolvimento de soluções e demonstrações financeiras remotas, usando tecnologia IBM Mobile Foundation. Ele tem mais de 15 anos de experiência com middleware e ferramentas de integração usando produtos e arquitetura de solução WebSphere, e desenvolvimento para o segmento de mercado financeiro e de seguros.



08/Out/2012

Introdução

Obtenha já o Worklight

Faça o download do IBM Worklight Developer Edition 5.0 sem custo e sem data de expiração!

A equipe IBM Global Solution Center em Dallas desenvolveu um aplicativo remoto para bancos de varejo. O aplicativo incluída muitas funções desse setor, como localização de agências e caixas eletrônicos, contato, saldos e atividades de conta, transferências de fundos e mais. Projetado para e implementado em smartphones iOS e Android, o aplicativo foi desenvolvido usando IBM Worklight Studio com uma abordagem híbrida. Dojo Mobile, uma estrutura JavaScript para desenvolver aplicativos remotos para várias plataformas, foi usado como o kit de ferramentas principal para implementar a interface com o usuário remota, junto com widgets Worklight.

Este artigo descreve os principais aspectos técnicos do design e desenvolvimento do aplicativo remoto, incluindo: design e implementação da interface com o usuário remota usando Dojo Mobile; otimização de estrutura e ambiente do projeto Worklight; o uso do Dojo para reduzir o esforço de desenvolvimento de artefatos de um ambiente específico; e a maneira de desenvolver um adaptador do Worklight - um componente essencial para integrar o aplicativo com sistemas corporativos. A integração com sistemas corporativos é ilustrada no código de amostra incluído, usando um serviço REST que simula os dados da conta em um sistema financeiro. A implementação de um mecanismo de segurança usando autenticação do Worklight para proteger recursos (como adaptadores do Worklight) também é discutida. Código de amostra (desenvolvido e testado com Worklight Studio Developer Edition v5.0.0.0), como um subconjunto do aplicativo remoto geral, é incluído para ilustração.

Aqui são incluídas informações para que você comece a fazer o seguinte:


Implementando uma interface de usuário remota usando Dojo Mobile

A Figura 1 mostra a tela inicial do aplicativo financeiro no iPhone. Nessa tela, o usuário pode acessar dados da conta e iniciar transações, localizar um caixa eletrônico ou agência e iniciar contato para ajuda.

Há duas abordagens de design de UI comuns que podem ser usadas para permitir que um usuário navegue entre funções:

  • A abordagem de barra de guias usa uma lista de funções comuns, cada uma mostrada como um botão na barra de guias que está disponível na maioria das telas. O usuário toca em um botão para navegar para uma função específica. Essa abordagem fornece navegação rápida, com um único clique, para a maioria das funções. A desvantagem é o espaço adicional na tela usado para a barra de guias, o reduz o espaço disponível para a área funcional.
  • A abordagem de lista de funções lista a maioria das funções (se não todas) como botões na tela. A vantagem é que cada função tem mais espaço na tela A principal desvantagem é que são necessários mais cliques para navegar, mesmo para funções de uso frequente.

Ambas as abordagens são usadas no aplicativo remoto de amostra descrito aqui. A abordagem de lista de funções é mostrada na Figura 1, na qual as três principais funções (My Accounts, Locations e Contact) são listadas como botões. Quando o usuário navega para My Accounts após a autenticação, funções frequentes, como Accounts, Cash e Transfer, são listadas como botões na barra de guias inferior, mostrada na Figura 2. Para exibir mais funções, o usuário clica na guia More.

Figura 1. Tela inicial
Tela inicial
Figura 2. Tela Accounts
Tela Accounts

Dojo Mobile é uma estrutura remota JavaScript™ de HTML5, que permite rápido desenvolvimento de aplicativos da web remotos com uma aparência nativa em dispositivos móveis, como iPhone, iPod Touch, iPad e em smartphones e tablets Android e RIM. Usando uma abordagem híbrida, um aplicativo Dojo Mobile pode usar APIs nativas, como localização por GPS ou varredura de código de barras, e pode ser empacotado facilmente como um aplicativo nativo usando IBM Worklight Studio.

A Figura 3 mostra a tela Accounts implementada usando widgets do Dojo Mobile (todos os widgets citados nesta seção são parte do pacote dojox.mobile):

  • A visualização geral (não mostrada) é dojox.mobile.View, que contém um ScrollableView na parte superior e um TabBar na parte inferior.
  • O ScrollableView superior mostra uma lista deslizável de contas, com Heading na parte superior e um EdgeToEdgeList na parte inferior.
  • O Heading mostra o título "Accounts" e contém um botão Back e um ToolBarButton, "Logout".
  • O EdgeToEdgeList contém uma lista de ListItem, cada um mostrando o resumo de uma conta.
  • O TabBar inferior contém uma lista de TabBarButton, cada um representando uma função comum, como Accounts, Cash, Transfer.
Figura 3. Tela Account com widgets Dojo Mobile
Tela Account com widgets Dojo Mobile

A Listagem 1 mostra o código usado para implementar esses widgets nessa tela.

Listagem 1. Código para tela Accounts na Figura 3
<div data-dojo-type="dojox.mobile.View" id="LoggedInView" class="mobileClass"  
 style="height: 100%;">
 <div id="AccountsView" data-dojo-type="dojox.mobile.ScrollableView"
  data-dojo-props="selected:true" class="mobileClass">
  <h2 data-dojo-type="dojox.mobile.Heading"
   data-dojo-props="fixed:'top', back:'Back', moveTo:'IndexView', fixed:'top'"
   style="font-size: 19px;" align="center">Accounts
    <div id="logoutBtn" data-dojo-type="dojox.mobile.ToolBarButton"
     data-dojo-props="label:'Logout', moveTo:'IndexView',  
     transition:'slide',transitionDir:'-1'"
     style="width: 45px; float: right;" class="mblColorBlue"></div>
  </h2>
  <ul id="accountContainer" style="margin-top: 40px;"
   data-dojo-type="dojox.mobile.EdgeToEdgeList" class="indexListStyle">
   <!-- List of Accounts will be populated at runtime using the custom widget template
    defined under folder 'custom/AccountWidget' -->
  </ul>
</div>
 <ul data-dojo-type="dojox.mobile.TabBar" data-dojo-props="fixed:'bottom'" style="height:
   11%; overflow-x: hidden;">
  <li data-dojo-type="dojox.mobile.TabBarButton" id="accountsTab" style="width: 20%"
   data-dojo-props="icon1:'./images/tabs/icon_128x128_accounts.png', 
   icon2:'./images/tabs/icon_128x128_accounts_blue.png', selected:'true'">Accounts</li>
  <li data-dojo-type="dojox.mobile.TabBarButton" style="width: 20%"
   data-dojo-props="icon1:'./images/tabs/icon_128x128_cash_gradient.png', 
   icon2:'./images/tabs/icon_128x128_cash_blue.png'">Cash</li>
  <li data-dojo-type="dojox.mobile.TabBarButton" style="width: 20%"
   data-dojo-props="icon1:'./images/tabs/icon_128x128_transfer_solid.png', 
   icon2:'./images/tabs/icon_128x128_transfer_solid_blue.png'">Transfer</li>
  <li data-dojo-type="dojox.mobile.TabBarButton" style="width: 20%"
   data-dojo-props=" icon1:'./images/tabs/icon_128x128_billPay.png', 
   icon2:'./images/tabs/icon_128x128_billPay_blue.png'">Bill Pay</li>
  <li data-dojo-type="dojox.mobile.TabBarButton" style="width: 20%"
   data-dojo-props="icon1:'./images/tabs/icon_128x128_more.png', 
   icon2:'./images/tabs/icon_128x128_more_blue.png'">More</li>
 </ul>
</div>

Estrutura de projeto do Worklight usando Dojo

O Worklight Studio é um ambiente de desenvolvimento integrado para aplicativos remotos multiplataformas. A estrutura do projeto do Worklight contém uma pasta apps que pode conter um ou mais aplicativos. Um aplicativo pode ter vários ambientes do Worklight, dependendo das plataformas a serem suportadas pelo aplicativo. OpenFNApp na Figura 4 contém uma pasta common e ambientes android e iphone para criação de aplicativos a serem implementados em dispositivos Android e iPhone. A pasta dojo é incluída automaticamente ao criar um aplicativo para Dojo no Worklight.

Figura 4. Estrutura de projeto do Worklight
Estrutura de projeto do Worklight

A pasta common na Figura 5 contém artefatos que serão compartilhados por todos os ambientes. Ela contém um arquivo HTML principal (OpenFNApp.html), que é carregado na inicialização do aplicativo, e outras pastas de recursos da web típicos, como js, css e images.

Figura 5. Estrutura da pasta common
Estrutura da pasta common

Os arquivos de ambientes específicos devem ser incluídos na pasta iphone ou android, conforme for o caso. Essas pastas têm a mesma estrutura que a pasta common. Por exemplo, se há alguns estilos que precisam ser aplicados a um ambiente específico de um dispositivo, um arquivo CSS pode ser criado na pasta apropriada com o mesmo nome que o arquivo correspondente na pasta common/css. Quando o projeto nativo for construído, o Worklight irá, ao gerar o código nativo, anexar arquivos css de um ambiente específico aos arquivos css comuns com os mesmos nomes. Os estilos de ambientes específicos têm precedência sobre os estilos incluídos na pasta common. Da mesma forma, se o arquivo HTML principal for colocado na pasta android ou iphone, ele irá substituir o arquivo HTML principal na pasta common e será usado pelo Worklight para desenvolver o aplicativo nativo. Arquivos JavaScript de ambientes específicos com nomes iguais serão anexados uns aos outros. No aplicativo descrito aqui, devido aos recursos multiplataforma do Dojo, a maior parte do código está na pasta common e é compartilhado entre os ambientes iphone e android. Código de um ambiente específico é incluído apenas quando necessário. Por exemplo, os arquivos OpenFN.css nos ambientes android e iphone contêm regras diferentes de altura para AccountsView (Listagem 1), enquanto todos os estilos comuns de aplicativo são definidos no arquivo common/css/OpenFN.css.

Figura 6. Arquivo de ambiente específico
Arquivo de ambiente específico

Um widget customizado, AccountWidget, é usado para exibir informações de conta dentro do aplicativo. Esse widget é incluído na pasta common/custom (consulte Recursos para detalhes sobre a implementação de widgets customizados). A Listagem 2 mostra o código JavaScript para carregar o widget customizado.

Listagem 2. Código para carregar widget customizado
<script>
 var base = location.href.split("/");
 base.pop();
 base = base.join("/");
 var dojoConfig = {
 isDebug : false,
 async : true,
 parseOnLoad : false,
 packages : [ {
  name : "custom",
  location : base + "/custom"
 } ]
};	
</script>

Para desenvolvimento de aplicativos multiplataformas, o módulo dojox/mobile/deviceTheme (Listagem 3) detecta automaticamente o dispositivo e inclui as folhas de estilo necessárias para renderizar nele. Isso facilita a existência de uma aparência nativa no aplicativo independente da plataforma, usando a mesma base de código.

Listagem 3. Carregando módulos do Dojo
<script type="text/javascript">
 require(// module identifiers
  ["dojo/parser", "dojo/_base/connect", "dojox/mobile",
    "dojox/mobile/deviceTheme", "dojox/mobile/compat",
    "dojox/mobile/Button", "dojox/mobile/TabBar", "dojox/mobile/TabBarButton",
    "dojox/mobile/ScrollableView"],
     // Callback function invoked on dependencies evaluation results
     function(parser, connect) {
      dojo.ready(function() {
      parser.parse();
      dojo.style("content", "display", "");
      connect.connect(dijit.byId("myAccountsListItem"), "onClick", null, getAccounts);
      });
     });
</script>

Desenvolvendo adaptadores do Worklight

Adaptadores do Worklight são uma interface única para comunicação de um aplicativo cliente com sistemas de backend. Há vários tipos de adaptadores, incluindo conexões HTTP, dispositivos SOAP, chamadas de banco de dados SQL e mais. Esses adaptadores podem ser protegidos e monitorados.

Um AccountsAdapter é usado aqui para chamar um serviço REST que recupera as informações da conta do usuário. O adaptador consiste nestes arquivos (Figura 7):

  • Um arquivo XML de configuração para especificar opções de conectividade e listar os procedimentos expostos ao aplicativo cliente ou a outros adaptadores.
  • Um arquivo JavaScript para implementar procedimentos declarados no arquivo XML de configuração.
  • Arquivos XSL opcionais para transformar os dados XML brutos recuperados.
Figura 7. Arquivos do adaptador Worklight
Arquivos do adaptador Worklight

O arquivo XML de configuração de AccountsAdapter (Listagem 4) especifica os detalhes de conexão (como política de conexão que inclui protocolo, domínio e porta) de que o adaptador precisa para a conexão para recuperar os dados da conta. O recurso de adaptador é protegido pelo uso de uma região definida no atributo authenticationRealm, que garante que o usuário está autenticado antes de o procedimento do adaptador ser chamado. (A proteção de autenticação é configurada na próxima seção.)

Listagem 4. Configurando XML para AccountsAdapter
<xml version="1.0" encoding="UTF-8"?>
<wl:adapter name="AccountsAdapter" authenticationRealm="AccountsAuthRealm"
. . . . . . . 
 <displayName>AccountsAdapter</displayName>
 <description>AccountsAdapter</description>
 <connectivity>
   <!--The configuration below assumes the REST service is deployed 
	on localhost with port 9080 --> 
   <connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
    <protocol>http</protocol>
    <domain>localhost</domain>
    <port>9080</port>
   </connectionPolicy>
  <loadConstraints maxConcurrentConnectionsPerNode="2" />
 </connectivity>
<procedure name="getAccounts" requiresAuthentication="true"/>
</wl:adapter>

O arquivo JavaScript do adaptador (Listagem 5) contém o código de implementação para o procedimento definido no arquivo XML de configuração. O procedimento getAccounts chama um serviço REST que recupera dados de conta de um usuário autenticado. Não é necessário que o aplicativo cliente passe as informações sobre o usuário para o procedimento do adaptador, pois elas podem ser obtidas usando WL.Server.getActiveUser() quando o usuário estiver autenticado. O serviço REST de dados da conta é chamado pela chamada WL.Server.invokeHttp, que retorna os dados ao aplicativo cliente em formato JSON.

Listagem 5. Código de JavaScript do adaptador
function getAccounts() {
 . . . . 	
 var userObj = WL.Server.getActiveUser();
 var serviceURL = "/OFNWebServices/rest/account/getAccounts";
 . . . . .
 
 return WL.Server.invokeHttp({
	 method : 'get',
	 returnedContentType : 'json',
	 path : serviceURL,
	 parameters : {
	  username : userObj.userId
	 }
        });
 }

Implementando autenticação do Worklight

Entidades como adaptadores do Worklight podem ser protegidos por um processo de autenticação que define medidas a serem tomadas antes que uma entidade seja acessada. AccountsAdapter é protegido; o usuário deve estar autenticado para poder recuperar os dados da conta usando o serviço REST de backend. A autenticação do Worklight é usada para implementar essa medida de segurança:

  1. Primeiro, uma região de autenticação é definida no arquivo authenticationConfig.xml na pasta server/conf. A região chamada AccountsAuthRealm (Listagem 6) especifica os atributos da função de login e de logout. Esses atributos definem os métodos de adaptador a serem chamados quando as funções de login e logout são realizadas no lado do servidor.
    Listagem 6. Região de autenticação em authenticationConfig.xml
    <realm name="AccountsAuthRealm" loginModule="AccountsAuthModule">
     <className>com.worklight.integration.auth.AdapterAuthenticator</className>
     <parameter name="login-function" value="AuthenticationAdapter.onAuthRequired" /> 
     <parameter name="logout-function" value="AuthenticationAdapter.onLogout" />
    </realm>
  2. Em seguida, um módulo de login é definido no mesmo arquivo authenticationConfig.xml. Na Listagem 7, AccountsAuthModule usa com.worklight.core.auth.ext.NonValidatingLoginModule, indicando que a autenticação será realizada por um processo definido pelo desenvolvedor dentro do adaptador.
    Listagem 7. Módulo de login em authenticationConfig.xml
    <loginModule name="AccountsAuthModule" canBeResourceLogin="true"
     isIdentityAssociationKey="false">
     <className>com.worklight.core.auth.ext.NonValidatingLoginModule</className>
    </loginModule>

    As funções de login e logout são definidas no adaptador chamado AuthenticationAdapter (Listagem 8).

    Listagem 8. Funções onAuthRequired e onLogout em AuthenticationAdapter-impl.js
    function onAuthRequired(headers, errorMessage){
     errorMessage = errorMessage ? errorMessage : null;
     return {
      authRequired: true,
      errorMessage: errorMessage
     };
    }
    function onLogout(){
     WL.Logger.debug("Logged out");
    }
  3. Na Listagem 9, o procedimento submitAuthentication é definido no arquivo AuthenticationAdapter.xml. Esse procedimento será chamado a partir do aplicativo cliente para validar as credenciais do usuário.
    Listagem 9. submitAuthentication em AuthenticationAdapter.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <wl:adapter name="AuthenticationAdapter"
     . . . . 
     <procedure name="submitAuthentication"/>	
    </wl:adapter>

    O procedimento submitAuthentication (consulte a Listagem 10) toma como parâmetros o nome de usuário e senha, que podem ser validados com relação a um registro do usuário. Se houver sucesso, o objeto userIdentity é criado e colocado no conjunto de usuários ativos usando o método WL.Server.setActiveUser(). Um objeto JSON com o parâmetro authRequired:false também é retornado, indicando o sucesso da autenticação. Se o usuário não for autenticado, um objeto JSON com o parâmetro authRequired:true é retornado, indicando que a autenticação ainda é necessária.

    Listagem 10. submitAuthentication em AuthenticationAdapter-impl.js
    function submitAuthentication(username, password) {
     if ((username=="wl" && password == "wl") || (username=="worklight" && password ==
      "worklight") ){
      WL.Logger.debug("Auth :: SUCCESS");
      var userIdentity = {
       userId: username,
       displayName: username, 
       attributes: {}
     };
     WL.Server.setActiveUser("AccountsAuthRealm",userIdentity);
     return {
      authRequired: false
      };
     }else{
      WL.Logger.debug("Auth :: FAILURE");
      return onAuthRequired(null, "Invalid login credentials");
     }
    }
  4. Concluindo a autenticação no lado do servidor, AccountsAdapter é protegido pela especificação da região AccountsAuthRealm para o atributo authenticationRealm no XML AccountsAdapter (Listagem 11).
    Listagem 11. authenticationRealm em AccountsAdapter.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <wl:adapter name="AccountsAdapter" authenticationRealm="AccountsAuthRealm"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xmlns:wl="http://www.worklight.com/integration"
     xmlns:http="http://www.worklight.com/integration/http">
    . . . . 
    <procedure name="getAccounts" requiresAuthentication="true"/>
    </wl:adapter>

Agora vamos examinar a autenticação implementada no lado do cliente.

  1. Um arquivo JavaScript auth.js é gerado automaticamente para fornecer esqueletos de método para implementar a autenticação do Worklight. A função init (Listagem 12) é usada para inicialização. Um manipulador de eventos é definido para o clique no botão Sign On (com ID submitAuthBtn). A função de manipulação de eventos chama o procedimento do adaptador de autenticação AuthenticationAdapter.submitAuthentication, repassando o nome de usuário e senha dos campos de entrada. Da mesma forma, o manipulador de eventos do clique no botão Logout (com ID logoutBtn) também é definido por uma chamada a WL.Client.logout(‘AccountsAuthRealm’).
    Listagem 12. função init em js/auth.js
    init : function() {
     // Authenticator initialization code
     require([ "dojo", "dojo/_base/connect" ],
      function(dojo, connect) {
       connect.connect(dojo.byId("submitAuthBtn"),"onclick",null,function() {
       var username = document.getElementById("usernameInputField").value;
       var password = document.getElementById("passwordInputField").value;
       var invocationData = {
       adapter : "AuthenticationAdapter",
         procedure : "submitAuthentication",
         parameters : [ username,password ]
       };
       WL.Client.invokeProcedure(
         invocationData,
         {onSuccess : signOnSuccess,
          onFailure : signOnFailure
       });
     });
      connect.connect(dojo.byId("logoutBtn"), "onclick", null, function() {
       WL.Client.logout('AccountsAuthRealm');
      });
     });
    }
  2. A função isLoginFormResponse() (Listagem 13) é chamada quando uma resposta é recebida do lado do servidor. A função retorna uma variável booleana, indicando se a autenticação teve sucesso ou não.
    Listagem 13. Função isLoginFormResponse em js/auth.js
    isLoginFormResponse : function(response) {
     if (!response || !response.responseJSON || response.responseText == null) {
      return false;
     }
     return response.responseJSON.authRequired;
     }
  3. A função onBeforeLogin() (Listagem 14) é usada para limpar campos de entrada e preparar para a exibição de uma visualização de autenticação. A visualização de autenticação pode ser uma página de login com entradas para nome de usuário e senha.
    Listagem 14. Função onBeforeLogin em js/auth.js
    onBeforeLogin : function(response, username, onSubmit, onCancel) {
     // clean up the input login fields
     document.getElementById("usernameInputField").value = "";
     document.getElementById("passwordInputField").value = "";
     document.getElementById("AuthInfo").innerHTML = response.responseJSON.errorMessage;
     }
  4. A função onShowLogin() ou onHideLogin() (Listagem 15) exibe ou oculta a página de login. Elas são chamadas automaticamente com base na variável booleana retornada por isLoginFormResponse. Quando a autenticação é bem-sucedida, onHideLogin é chamada. Do contrário, onShowLogin é chamado. Neste exemplo, a função onHideLogin não faz nada. A função de retorno de chamada signOnSuccess() é especificada para chamar o adaptador de autenticação (Listagem 12). A função signOnSuccess() chama outra função, getAccounts(), para alterar a tela da visualização de login para a de conta.
    Listagem 15. Função onShowLogin / onHideLogin em auth.js
    onShowLogin : function() {
     require([ "dijit" ], function(dijit) {
      var currentView = dijit.byId("LoginView").getShowingView();
      var currentViewId = currentView.get("id");
      if (currentViewId != "LoginView") {
       currentView.performTransition("LoginView", 1, "slide", null);
      }	
     });
    },
    onHideLogin : function() {
    }
    . . . . 
    function signOnSuccess(response) {
     getAccounts();
    }

Conclusão

Este artigo descreveu experiências no uso do Worklight e Dojo Mobile para desenvolver um aplicativo remoto de ponta a ponta. Foram descritos tópicos técnicos, como a implementação de uma interface com o usuário móvel usando Dojo Mobile, desenvolvimento do adaptador do Worklight e autenticação do Worklight.


Agradecimentos

Agradecemos aos colegas Rod Fleming e Catherine McCauley por seu apoio, que levou ao sucesso desse projeto.


Download

DescriçãoNomeTamanho
Code sampleOFNProjectSampleCode.zip30 MB

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=Desenvolvimento móvel, WebSphere
ArticleID=839152
ArticleTitle=Os aspectos básicos do desenvolvimento de um aplicativo remoto de ponta a ponta usando IBM Worklight e Dojo Mobile
publish-date=10082012