Oito Etapas para Desenvolvimento de Aplicativos Remotos com IBM Worklight

Como se preparar antes de adotar uma estratégia para dispositivos móveis

Este artigo descreve o que precisa ser feito em preparação para o desenvolvimento de aplicativos remotos multiplataformas usando a plataforma de aplicativos remotos IBM® Worklight™. As principais etapas que uma organização precisa levar em conta e realizar durante cada fase do processo de desenvolvimento de aplicativos remotos estão aqui, incluindo planejamento, desenvolvimento e produção. Entender esse processo geral, que é significativamente diferente do desenvolvimento de aplicativos tradicionais, ajuda uma empresa a estruturar adequadamente seu processo organizacional em torno do ciclo de vida de desenvolvimento remoto multiplataforma. Este conteúdo é parte do IBM WebSphere Developer Technical Journal.

Gang Chen, Senior Certified Consulting I/T Specialist, IBM

Gang ChenGang Chen é World Wide Tech Practice Lead de Serviços de Software IBM e WebSphere para Modelo de Programação Remota e de WebSphere. Gang tem larga experiência com arquitetura, design, desenvolvimento, implementação no sistema distribuído, SOA, sistema de mensagens, computação em nuvem, web 2.0 e tecnologia remota. Gang é IBM Senior Certified IT Specialist. Tem se dedicado a várias tecnologias emergentes recentemente, como computação em nuvem e desenvolvimento de aplicativos remotos.



Fang Wang, IBM Certified IT Specialist, IBM

Fang Wang é Consulting I/T Specialist e Senior Software Engineer em IBM Software Services for WebSphere (ISSW). Fang é especialista em ajudar clientes corporativos com seus aplicativos e sistemas voltados para o cliente, especialmente os de central de atendimento, como aplicativos de resposta de voz interativa (IVR) de autoajuda, roteamento de chamada e integração entre telefonia e computação (CTI). Fang é IBM Certified IT Specialist. Ela tem se dedicado a tecnologias emergentes recentemente, como o desenvolvimento de aplicativos remotos.



Anton Aleksandrov, Worklight R&D lead, IBM

Anton é líder da equipe de pesquisa e desenvolvimento do IBM Worklight.



26/Nov/2012

Introdução

Obtenha o Worklight agora

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

Os aplicativos remotos tornaram-se parte integral de nossa rotina profissional e pessoal. Por isso, são usados por muitas organizações, em quase todos os setores, para ampliar seu alcance e interagir com clientes, parceiros e funcionários remotamente. Estima-se que a rápida adoção da tecnologia remota, alimentada pelo contínuo crescimento de smartphones no mercado, continuará aumentando em proporção e irá tornar-se um dos principais canais usados pelos usuários para realizar tarefas diárias, acessar informações e realizar transações comerciais.

Dado que existem elementos do desenvolvimento de aplicativos remotos que diferem significativamente do desenvolvimento de aplicativos corporativos tradicionais, as organizações que querem adotar uma estratégia abrangente para dispositivos remotos precisam planejar e ter certeza de que todas as partes interessadas necessárias entendam o processo de alto nível necessário para esse tipo de aplicativo. Para orientar o leitor, este artigo apresenta uma visão geral das oito principais etapas no desenvolvimento, implementação e publicação de aplicativos para plataformas remotas, como iOS e Android, usando a plataforma de desenvolvimento remoto IBM® Worklight™.

1. Processo de descoberta

A primeira etapa começa com entender os requisitos de negócios para dispositivos móveis e definir a estratégia da empresa para o setor. A fase de descoberta tem um importante papel no ciclo de vida geral de desenvolvimento de aplicativos remotos. Ela define as visões e estratégias para dispositivos móveis ao analisar os desafios, objetivos e restrições.

Por exemplo, é necessário identificar os tipos de aplicativos remotos que serão desenvolvidos, que podem ser da web móvel, nativos, híbridos ou uma combinação desses. Também é preciso decidir as plataformas remotas para as quais haverá suporte, por exemplo, iOS, Android, Blackberry, Windows® Phone, etc. A Figura 1 destaca as áreas que devem ser levadas em consideração ao definir uma estratégia para dispositivos móveis.

Figura 1. Considerações da estratégia de dispositivos móveis
Considerações da estratégia de dispositivos móveis

O outro resultado da fase de descoberta é identificar os casos essenciais de presença remota e ativação de aplicativo para os negócios. Esses casos de uso ou ideias de aplicativos devem ser conceitualizados em protótipos, bastidores de fio e esboços sequenciais de aplicativos remotos.


2. Registrar-se como desenvolvedor nas plataformas remotas suportadas

Para poder implementar ou publicar um aplicativo por meio das várias lojas de aplicativos remotas (como a App Store da Apple ou Google Play), todas as plataformas remotas exigem o registro da organização ou pessoa. Apenas desenvolvedores registrados podem enviar aplicativos para a loja de aplicativos de uma plataforma. Por isso, é necessário registrar-se nesses programas de plataforma no estágio inicial do ciclo de vida do desenvolvimento.

  • iOS: Para testar um aplicativo em um dispositivo iOS real ou preparar o aplicativo para release na App Store, é necessário cadastrar-se no Programa de Desenvolvedor do iOS da Apple como desenvolvedor individual ou empresa. O registro requer o pagamento de uma taxa.
  • Android: Para poder publicar um aplicativo Android no Google Play, o desenvolvedor ou sua organização precisa criar uma conta do Google Play. Esse processo tem três etapas: criar o perfil de desenvolvedor, concordar com o Contrato de Distribuição do Desenvolvedor e pagar uma taxa de registro usando Google Checkout.
  • Blackberry: Para poder publicar um aplicativo Blackberry no Blackberry App World, é preciso primeiro ter uma conta de fornecedor. Desenvolvedores sem uma conta de fornecedor não podem enviar aplicativos para publicação no BlackBerry App World.
  • Windows Phone: Da mesma forma, é necessário ser desenvolvedor registrado do Windows Phone para enviar aplicativos para o Windows Phone Marketplace. O registro pode ser realizado em Microsoft App Hub.

3. Preparar o ambiente de desenvolvimento de aplicativos remotos do Worklight

A configuração correta do ambiente de desenvolvimento do Worklight é uma etapa vital para o desenvolvimento e teste de aplicativos remotos. Em resumo, você irá instalar Eclipse e IBM Worklight Studio como IDE de desenvolvimento para aplicativos remotos do Worklight. Os SDKs das plataformas remotas suportadas também precisam ser instalados. Opcionalmente, pode ser útil criar um ambiente de desenvolvimento de equipe para gerenciamento de controle de fonte.

Worklight Studio é um IDE baseado em Eclipse. É necessário instalar Eclipse na estação de trabalho antes de instalar o Worklight Studio. O Worklight Studio pode ser executado nos sistemas operacionais Windows, Mac OS e Linux®. É possível desenvolver aplicativos do Worklight para ambientes iOS em qualquer um desses sistemas operacionais. No entanto, devido a restrições impostas pela Apple, um projeto de iOS pode ser compilado apenas em uma máquina Mac OS.

  1. Instalando Eclipse

    A versão atual do Worklight Studio requer Eclipse Indigo (3.7.2). É possível fazer o download da IDE Eclipse sem custo.

  2. Instalando IBM Worklight Studio

    É possível instalar o IBM Worklight Studio após instalar o Eclipse. Há três edições disponíveis do Worklight Studio: Developer (disponível para download gratuito, para começar a usar), Consumer e Enterprise. Worklight Studio pode ser instalado a partir do Eclipse Marketplace, usando IBM Installation Manager, ou como um plugin de Eclipse. Para detalhes da instalação, consulte a biblioteca do produto IBM Worklight.

  3. Instalando SKDs de dispositivos móveis

    Para desenvolver aplicativos remotos híbridos ou nativos com Worklight, é necessário instalar e configurar os SDKs (e IDEs de desenvolvimento) para as respectivas plataformas móveis. Os procedimentos podem variar dependendo da plataforma, mas estas são as etapas mais comuns entre as plataformas móveis populares.

    • iOS: É necessário fazer o download do Xcode, um IDE da Apple para desenvolver aplicativos iOS e Mac. O Xcode pode ser usado para gerenciar dispositivos de teste, usar um simulador de iPhone ou iPad e instalar aplicativos nesses dispositivos.
    • Android: É necessário instalar o Android SDK e plug-in Android Development Tools (ADT) para Eclipse. O SDK Android fornece as ferramentas e APIs necessárias para desenvolver aplicativos na plataforma Android usando a linguagem de programação Java™. O plug-in ADT para Eclipse é um ambiente integrado, no qual é possível criar aplicativos Android complexos.
    • BlackBerry: O desenvolvimento de aplicativos WebWorks requer o download e instalação de Blackberry Ripple Emulator, Blackberry WebWorks SDK e Blackberry Simulator.
    • Windows Phone: É necessário fazer o download e instalação de Microsoft Visual Studio 2010/2012 e Windows Phone SDK. Também é necessário fazer o download e instalação do software Zune no ambiente de desenvolvimento para executar os aplicativos em um telefone portátil Windows Phone.
  4. Prepare o ambiente de desenvolvimento da equipe

    Preparar o ambiente de desenvolvimento usando, por exemplo, IBM Rational® Team Concert, é uma excelente ideia para o desenvolvimento de aplicativos remotos dinâmicos. Lembre-se, no entanto, que ao gerenciar aplicativos Worklight com um sistema de controle de fonte, alguns arquivos gerados por projetos do Worklight não devem ser incluídos no sistema. (ConsulteRecursos)


4. Projetar e desenvolver aplicativos remotos

Agora, a parte divertida. Designers e desenvolvedores trabalham juntos para criar aplicativos remotos usando a plataforma de dispositivos móveis Worklight e as ferramentas de desenvolvimento de dispositivos móveis nativas.

Além de desenvolver aplicativos com Worklight no Worklight Studio, o desenvolvimento também é realizado usando tecnologias da web familiares, como HTML, CSS e JavaScript™, com suporte também para os recentes padrões HTML5 e CSS3. É possível usar o SDK do lado do cliente do Worklight para serviços de UI de vários ambientes (como acessar a barra de guias ou menu de um dispositivo móvel). Os desenvolvedores também podem usar suas bibliotecas JavaScript e conjuntos de ferramentas de UI preferidos.

Worklight não limita o processo de desenvolvimento apenas a código em tecnologia da web. Ele gera um projeto de aplicativo nativo para a plataforma remota de destino, para compilar o pacote nativo para distribuição em lojas de aplicativos. Código nativo de dispositivos específicos pode ser incluído nesses projetos de aplicativos nativos gerados e combinados com o código escrito usando tecnologias da web.


5. Teste de unidade no ambiente de desenvolvimento

Planeje testes de aplicativos remotos no início do desenvolvimento e em períodos frequentes. Isso porque o teste em dispositivos móveis é desafiador, dado o grande conjunto de dispositivos e plataformas mesmo para um único aplicativo. Abaixo estão alguns métodos e ferramentas de teste que podem ser usadas para aplicativos Worklight no ambiente de desenvolvimento. IBM Worklight Studio inclui um servidor de teste integrado que simplifica o teste de unidade.

  1. Simulador de navegador remoto e visualização de aplicativo

    IBM Worklight Server oferece um serviço de visualização de aplicativos que permite simular artefatos da web remotos em um navegador da web no desktop. A visualização de aplicativos também permite a simulação de APIs clientes do Worklight. A visualização de aplicativo está disponível no console do servidor de teste do Worklight Studio.

    No ambiente de desenvolvimento do Worklight Studio, é possível visualizar e testar o aplicativo remoto usando o simulador de navegador remoto. O simulador contém um quadro que simula um dispositivo de destino. É possível alterar o quadro para emular diferentes resoluções de tela, fatores de forma e orientações para Android, iPad, iPhone, Blackberry e outros dispositivos móveis. Essa visualização está disponível apenas quando o plug-in com.ibm.imp.worklight.simulation.ui está ativado. A interface com o usuário de simulação da API Apache Cordova inclui o simulador de navegador remoto. Através da API Cordova, muitos recursos do dispositivo (como localização geográfica, bússola, bateria etc.) podem ser simulados.

    Uma das conveniências do teste de unidade do aplicativo com o simulador de navegador remoto é que não é necessário instalar o SDK nativo do fornecedor do dispositivo. Também oferece atualização mais rápida do aplicativo, o que torna os testes repetitivos mais eficientes. Mas a simulação de UI nem sempre é igual à aparência da UI real do dispositivo físico que está sendo emulado, especialmente em relação ao espaçamento de texto e outros elementos. Por isso, esse tipo de teste de unidade é mais adequado para o estágio inicial de teste das posições gerais de quadro e widget. Também é uma ferramenta eficiente para testar o fluxo de lógica no aplicativo remoto.

    Ao testar no ambiente do navegador da web de desktop, o desenvolvedor tem acesso a várias ferramentas de depuração populares, como a ferramenta integrada do Chrome e Firebug do Firefox. Essas ferramentas permitem definir pontos de interrupção no JavaScript, visualizar as regras de CSS aplicadas ao código HTML gerado e visualizar o tráfego de rede entre o aplicativo local e o servidor. Também é altamente recomendável usar navegadores baseados em webkit, como Chrome e Safari. Weinre, outra ferramenta útil de depuração de aplicativos da web móvel, também merece menção.

  2. Simulador de SDK para dispositivo móvel

    Esse tipo de teste de unidade envolve um simulador de SDK de dispositivo móvel nativo. Quando um projeto nativo gerado pelo Worklight para uma plataforma nativa é iniciado (através do Worklight Studio ou da ferramenta de desenvolvimento do fornecedor), aparece uma janela nativa do SO que executa o simulador com o código de aplicativo remoto mais recente. Diferente de um simulador de navegador remoto, que tenta simular as características de muitos dispositivos, um simulador de SDK remoto oferece uma UI simulada que é quase idêntica à do dispositivo real. No entanto, o desempenho do aplicativo, como o tempo de resposta ao toque, será um pouco diferente do dispositivo real. Isso é devido à diferença no poder de cálculo do dispositivo real e da estação de trabalho de desenvolvimento. Para obter o teste de experiência do usuário mais realista, é necessário testar os aplicativos nos próprios dispositivos móveis.

  3. Dispositivo real

    Esse tipo de teste, o máximo para aplicativos móveis, deve ser realizado nos dispositivos de destino para garantir que a UI e o desempenho do aplicativo sejam consistentes entre todos os dispositivos de destino. É preciso garantir que o dispositivo real fique na mesma rede wireless que a estação de trabalho de desenvolvimento, para que possa acessar o servidor de teste integrado no Worklight Studio.

    • Quando um dispositivo Android é conectado ao computador através de um cabo USB, o plug-in ADT do Eclipse reconhece-o imediatamente e tenta implementar aplicativos nele.

      Para um dispositivo Android cujo driver não esteja listado (como Kindle Fire), o arquivo .apk integrado no projeto Android nativo gerado pelo Worklight pode ser colocado no dispositivo através da conexão USB. O utilitário de instalação do dispositivo pode ser usado para instalar o arquivo apk nele.

    • Para implementar um aplicativo iOS em um dispositivo iOS real, é necessário ter um perfil de fornecimento, obtido ao cadastrar-se no Programa de Desenvolvedor do iOS da Apple. Geralmente, o desenvolvedor começa com um perfil de fornecimento de desenvolvimento que permite ao Xcode reconhecer o dispositivo iOS conectado através de um cabo USD e instalar o aplicativo nele. Em uma fase posterior (como na fase de teste de integração ou produção), o desenvolvedor passa para um perfil de fornecimento de distribuição, que permite criar, colocar em archive e empacotar o aplicativo em um arquivo .ipa, com assinatura apropriada, que pode ser implementado no dispositivo através do iTunes ou do centro de aplicativos.

Consulte Recursos para mais informações sobre o centro de aplicativos incluído no Worklight.


6. Teste de integração em ambiente de servidor remoto do Worklight

Para testar o aplicativo remoto com integração completa no sistema corporativo de backend, é preciso que ele esteja instalado em um ambiente de integração ou QA que esteja prontamente disponível para qualquer testador autorizado.

IBM Worklight Server está disponível apenas nas edições Consumer e Enterprise do Worklight.

  1. Prepare o ambiente de integração

    Os testes de integração e QA são geralmente realizados em um ambiente remoto do servidor Worklight. IBM Worklight Server usa um banco de dados para armazenar informações de notificação push, estatísticas para relatórios e analítica e metadados exigidos pelo servidor no tempo de execução. Portanto, a preparação do ambiente requer a configuração do servidor Worklight e do banco de dados.

    A instalação do IBM Worklight Server é realizada através do IBM Installation Manager. (Se você estiver conectado à Internet durante a instalação, IBM Installation Manager pode fazer download dos fix packs mais recentes.) O assistente de instalação do servidor configura automaticamente um servidor de aplicativo e um banco de dados, resultando em um servidor IBM Worklight totalmente funcional. É necessário escolher qual banco de dados e servidor de aplicativos usar. As opções de bancos de dados incluem:

    • IBM DB2 V9.7 ou posterior
    • MySQL v5.1 ou posterior
    • Oracle v11g ou posterior
    • Apache Derby (incluído na imagem de instalação, apenas para fins de teste)

    As opções do servidor de aplicativos incluem:

    • WebSphere Application Server Liberty Profile V8.5 ou posterior (incluído na imagem de instalação)
    • WebSphere Application Server V7.0 ou posterior
    • Apache Tomcat v7 ou posterior

    Consulte Worklight Administration Guide para instruções de instalação detalhadas.

  2. Prepare o projeto do Worklight para implementação

    Há geralmente algumas diferenças de configuração entre o ambiente de desenvolvimento local e o ambiente de integração. Antes de desenvolver o projeto para o ambiente de integração, essas configurações precisam ser ajustadas para refletir as configurações do ambiente de dispositivo móvel. As configurações que geralmente precisam ser ajustadas incluem:

    • worklightServerRootURL, que deve refletir a configuração de protocolo, host, porta e contexto do servidor Worklight remoto.
    • Tipo de banco de dados, URL JDBC, nome de usuário e senha.
    • Outras propriedades que possam ser diferentes, como recursos de segurança.

    Após fazer todas as modificações necessárias na configuração do projeto do Worklight, é possível desenvolver o aplicativo, adaptador ou ambos. Essa tarefa cria um arquivo WAR que pode ser usado para implementar a configuração do projeto para um servidor remoto. O aplicativo do Worklight e o código de adaptador em JavaScript são empacotados em arquivos .wlapp e .adapter, respectivamente.

  3. Implemente o aplicativo Worklight e o adaptador no ambiente de integração

    Para implementar o arquivo WAR gerado no servidor de integração remoto, siga o procedimento padrão de instalação de aplicativo corporativo do servidor de aplicativos selecionado. Após o arquivo WAR ter sido implementado, é possível abrir o console do Worklight em um navegador através do endereço http://seu-servidor-remoto:porta-do-servidor/<nome-raiz-do-contexto>/console. No console, é possível fazer upload e implementar os arquivos .wlapp e .adapter gerados a partir do diretório de projetos do Worklight diretamente. O aplicativo remoto agora está pronto para ser testado no ambiente de integração.

  4. Teste no ambiente de integração/QA

    É possível usar os três tipos de métodos e ferramentas de teste descritos na etapa 5 para testar o aplicativo remoto implementado no ambiente de integração. No entanto, como o simulador de navegador remoto não está disponível no Worklight Server remoto, não há uma exibição de dispositivo ao visualizar os diferentes ambientes do aplicativo remoto no console do Worklight. Todos os ambientes são visualizados como aplicativo da web móvel. Por isso, esse tipo de teste não é muito usado como teste de integração.

    Quer usem os simuladores de SDK de dispositivos móveis ou os próprios dispositivos, os testadores autorizados precisarão do arquivo de empacotamento nativo (.apk ou .ipa) para instalar inicialmente o aplicativo remoto. Esses arquivos podem ser distribuídos manualmente ou através do centro de aplicativos incluído no produto Worklight.

    Nas iterações posteriores dos testes, se o aplicativo remoto não possuir atualizações de código nativo, não será necessário instalar novos arquivos .apk ou .ipa no dispositivo. Através do recurso de atualização direta do Worklight Server, a nova versão do aplicativo será automaticamente transferida por download para o dispositivo quando o aplicativo for continuado ou iniciado novamente no dispositivo.

    Se for necessário apontar para diferentes servidores remotos, é possível atualizar a URL de raiz do servidor diretamente no dispositivo ou simulador:

    • Android: para acessar as configurações, pressione a tecla Menu enquanto o aplicativo estiver sendo executado.
    • iOS: as configurações podem ser acessadas nas configurações gerais do iOS, na entrada de aplicativos.

7. Implementando para produção

Para o componente do lado do servidor do Worklight, a implementação no ambiente de produção é muito semelhante à do ambiente de integração. O processo de criação manual pode ser substituído por um script Ant para maior simplicidade. (ConsulteWorklight Administration Guide.)

A Figura 2 mostra uma topologia típica de uma instância do Worklight no ambiente de produção.

Figura 2. Instância do Worklight em produção
Instância do Worklight em produção

Observe que vários servidores do Worklight estão configurados em ambiente de cluster, compartilhando o mesmo banco de dados. Quando um arquivo .wlapp ou .adapter é implementado em um dos servidores em um cluster, é automaticamente sincronizado nos outros servidores. O mesmo vale ao excluir o aplicativo ou adaptador de um servidor no cluster. No entanto, o arquivo .war é parte da customização do servidor de aplicativos e deve, portanto, ser implementado manualmente em cada servidor no cluster.

Enquanto o aplicativo remoto do Worklight estiver sendo empacotado para o ambiente de produção, o pacote do aplicativo nativo deve ser montado e publicado para distribuição ao público. Para dispositivos iOS, o processo de publicação geralmente demora mais, devido ao processo de análise e aprovação da Apple para a App Store. Portanto, não se esqueça de começar o envio do pacote nativo com bastante tempo de avanço.

Para dispositivos Android, não há processo de análise e aprovação, portanto, a publicação é bem rápida.

Consulte Recursos para ver as diretrizes de publicação da plataforma.

O link a seguir contém as diretrizes do processo de publicação da Apple: https://developer.apple.com/appstore/guidelines.html O link a seguir contém as diretrizes do processo de publicação: http://developer.android.com/distribute/googleplay/publish/preparing.html


8. Gerenciar o aplicativo remoto do Worklight

O gerenciamento de um aplicativo remoto do Worklight consiste em duas partes:

  • O pacote nativo, gerenciado através da loja de aplicativos da plataforma.
  • Os recursos da web do aplicativo, que são empacotados e implementados através do console do Worklight.

Para o gerenciamento de atualização de pacote nativo, cada loja de aplicativos tem suas próprias diretrizes (consulte Recursos). Para o gerenciamento de recursos da web do aplicativo do Worklight, há alguns bons recursos do Worklight que permitem controlar versões de aplicativo com os usuários.

  • Atualização direta: enviando atualizações de aplicativos a dispositivos móveis

    Usando a atualização direta, as organizações podem atualizar o conteúdo da web de aplicativos HTML5 e híbridos implementados diretamente a partir do servidor do Worklight, na inicialização do aplicativo. Quando o aplicativo conecta-se ao servidor do Worklight, ele detecta a nova atualização automaticamente e começa o download dos novos recursos após receber confirmação do usuário. Essa opção está disponível para aplicativos do iPhone, iPad e Android.

  • Bloqueando um aplicativo: evitando a reimplementação de recursos da web de um aplicativo

    Para evitar que desenvolvedores ou administradores atualizem acidentalmente um aplicativo, é possível bloqueá-lo no console do Worklight. Essa opção está disponível para aplicativos do iPhone, iPad e Android.

  • Negando acesso a versões anteriores do aplicativo

    Às vezes, é útil negar ao usuário o acesso a uma versão específica do aplicativo, devido a uma política de descontinuação ou por questões de segurança presentes na versão antiga. No console, é possível negar o acesso a uma versão específica do aplicativo em um sistema operacional remoto específico e exibir uma mensagem customizada para o usuário. Junto com a mensagem, é possível especificar uma URL para a nova versão do aplicativo (geralmente na loja de aplicativo relevante). O usuário recebe a mensagem e é obrigado a fechar o aplicativo, ou atualizar para a versão mais recente.

  • Exibindo uma mensagem de notificação na inicialização do aplicativo

    Da mesma forma, é possível definir uma mensagem de notificação a ser exibida para o usuário quando o aplicativo inicia, mas que não faz com que ele seja encerrado. Esse tipo de mensagem é útil para exibir mensagens temporárias aos usuários, como tempo de inatividade planejado do sistema.

  • Controlando o teste de autenticidade de um aplicativo

    Quando um aplicativo se conecta pela primeira vez ao servidor do Worklight, este último testa a sua autenticidade. Esse teste ajuda a proteger os aplicativos contra ataques de malware e reempacotamento. Essa opção está disponível para aplicativos do iPhone, iPad e Android. É necessário configurar o aplicativo para ativar teste de autenticidade.


Conclusão

Este artigo descreveu as etapas fundamentais para o desenvolvimento de aplicativos remotos multiplataformas usando a plataforma de desenvolvimento de aplicativos remotos da IBM. Também descreveu muitos dos desafios enfrentados por desenvolvedores de aplicativos remotos em geral e apresentou vários recursos do IBM Worklight que lidam especificamente com esses desafios. Esperamos que esta pequena visão do processo de desenvolvimento de aplicativos remotos não apenas ajude-o a planejar corretamente sua estratégia para dispositivos remotos, mas que também acelere-a.

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=Desenvolvimento móvel, WebSphere
ArticleID=846982
ArticleTitle=Oito Etapas para Desenvolvimento de Aplicativos Remotos com IBM Worklight
publish-date=11262012