3.5 Ferramentas de Desenvolvimento de Software
3.5.1 SDK da Nokia
A ferramenta da Nokia é chamada de S60 3rd Edition SDK for Symbian OS Support- ing Feature Pack 1, for MIDP(S60 SDK). Uma das mais completas ferramentas para desenvolvimento Java ME e aplicações Symbian disponíveis.
Com o S60 SDK o desenvolvedor pode implementar aplicações Java ME para a plataforma de smartphones S60 utilizando o PC. Juntamente com a IDE, o SDK fornece todas as funcionalidades necessárias para isso, inclusive APIs, exemplos de códigos e toda a documentação necessária para o desenvolvimento de novas aplicações S60 MIDlets6, isto é, as aplicações que estão em conformidade com o perfil MIDP (vide Seção2.3.6).
A Figura3.5, apresenta a interface principal do emulador S60 da Nokia. O emulador S60 permite visualizar e testar aplicações no PC antes de instalar no celular real. Uma das grandes vantagens dessa ferramenta, em comparação com outras do mesmo propósito, é que a simulação do aplicativo é muito próximo das funcionalidades do celular real, sendo o seu grande diferencial.
Figura 3.5 Interface de usuário SDK S60
Uma série de exemplos de MIDlets são fornecidos junto com o SDK. Os MIDlets demonstram a variedade de aplicações que podem ser executados nos celulares da S60. O desenvolvedor pode criar e executar os MIDlets no emulador S60, bem como utilizá-los na criação de suas próprias aplicações. No entanto, essas aplicações ficam escondidas
3.5. FERRAMENTAS DE DESENVOLVIMENTO DE SOFTWARE
por assim dizer. O desenvolvedor precisa ler a documentação técnica para encontrar tais demos.
O emulador S60 SDK tem sido testado sobre o SO Microsoft Windows 2000 (SP4) e Microsoft Windows XP (SP2). Esses sistemas são oficialmente recomendados pelo fabricante Nokia, outros sistemas, como Windows Vista, podem funcionar mas não são garantidos.
A interface de comunicação suportada pelo emulador para interação com outras aplicações incluem: (1) suporte da especificação Universal Emulator Interface (UEI), permitindo rodar aplicativos diretamente da IDE; suporte para OTA7, muito utilizado para simular a instalações de aplicativos via sites externos.
As principais APIs suportadas pela S60 SDK de Java ME são apresentadas no Apêndice A. Os recursos identificados por letras de (a até o) são suportadas por essa tecnologia.
3.5.2
SDK da SUN
A Sun Java Wireless Tool Kit (conhecido como J2ME WTK), é um conjunto de ferramen- tas para criar aplicações Java que rodam sobre dispositivos genéricos, de acordo com as especificações da indústria da (Java Technology for the Wireless Industry - JTWI, JSR 185) e da (Mobile Service Architecture (MSA, JSR 248). Essa ferramenta, basicamnte é um conjunto de pequenos utilitários e dispositivos para simulação.
Figura 3.6 Interface de usuário da Sun Java Wireless Tool Kit 3.0
O foco desta ferramenta é a simulação, construção e a geração de código (deployment). Usando a sua interface de usuário (Figura 3.6), relativamente simples, pode-se criar,
3.5. FERRAMENTAS DE DESENVOLVIMENTO DE SOFTWARE
compilar e gerar o pacotes de distribuição, além disso, pode-se também, simular uma aplicação com assinatura digital, executar e depurar aplicações em tempo real.
A PDC Java ME da Sun é uma ferramenta bastante popular no meio dos desenvolve- doresEconomou et al.(2008);Cho and Jeon(2007), pois ela serve como referência para aprendizado da tecnologia Java ME. O SDK provê suporte de ferramentas e exemplos de implementações para as últimas APIs suportadas conforme a lista da JCP.
O SDK suporta integração com o dispositivo real sobre Windows Mobile ou emu- ladores de terceiros. O desenvolvedor pode usar o SDK para gerar aplicações e distribuir nos telefones reais, além dos recursos de depuração.
O SDK contém vários exemplos demos, assim como a SDK da Nokia. A lista completa de APIs suportadas deste SDK encontra-se no ApêndiceA.
3.5.3
SDK da Motorola
O SDK da Motorola, chamado de MOTODEV Studio for Java ME, é um conjunto de ferramentas para desenvolvimento, baseado na IDE Eclipse 3.4 (conhecido como ’Ganymede’)Motorola(2009), projetado para aplicações em Java ME.
Essa ferramenta unifica a IDE e o SDK da PDC dos produtos da PSC da Motorola. Com isso, o desenvolvedor pode implementar, testar e gerar aplicações para um grande leque de dispositivos da Motorola, integrados numa única ferramenta de desenvolvimento, que incluem as seguintes plataformas:
- Produtos SO Motorola: voltados para PSC proprietária P2K (ex. MOTO Z9/Z9n, MOTORAZR V3, W510) ;
- Produtos SO Linux : voltados para PSC baseado em Linux (ex. A910/A910i, MO- TOMING A1200/e/i/r, ROKR EM35);
- Produtos Motorola Symbian (UIQ): voltados para PSC baseado em Symbian UIQ da Motorola (ex. MOTO Z8 e MOTO Z10);
- Produtos SO Windows: voltados para PSC baseados em WM (ex. MOTO Q 11, MOTO Q 9h Family);
- Dispositivos Embarcados (Embedded Devices): voltados para sistemas embarcados (ex. EM330/MOTOROKR EM28, G24-J HMI).
Além disso, o ambiente oferece um conjunto de ferramentas, serviços e documen- tações integrados para o desenvolvedor simular as aplicações. Entre as principais fun- cionalidades podemos destacar:
- Demo Tool: permite visualizar informações e screenshots dos demo MIDlets disponíveis, bem como, importa-los diretamente para dentro da IDE como um projeto Java ME;
3.5. FERRAMENTAS DE DESENVOLVIMENTO DE SOFTWARE
- Network Monitor: permite monitorar e analisar os pacotes de dados de vários proto- colos de comunicação;
- Suporte MTJ8: com editor de configuração usando UI;
- Deployment Too: permite enviar e instalar aplicações nos celulares reais;
- On-Device Debugging: permite realizar depuração diretamente no celular real (platafor- mas Motorola OS e Linux);
- Multiplataforma: versões para Windows, Mac OS X, e Linux;
- Java ME Emulator: utiliza a JVM SE para simular aplicações Java ME no PC, utilizando skins para cada celular;
- Bluetooth Service: habilita simular a comunicação Bluetooth com múltiplos celulares; - WMA Test Server: permite múltiplos celulares simularem o envio e recebimento de
mensagens (SMS e MMS);
- Signing Tool: permite importar certificados e assinar aplicações MIDlets;
- Config Tool: provê funcionalidades para habilitar/desabilitar recursos de telefones reais (ex. habilitar depuração).
Figura 3.7 MOTODEV Studio rodando uma aplicação demo
A Figura3.7apresenta o ambiente Motodev em execução. O ambiente MOTODEV contém vários exemplos demos (distribuídos via DemoTool). A lista completa de APIs suportadas deste ambiente encontra-se no ApêndiceA. Os recursos identificados por letras
8Mobile Tools for Java (MTJ): um plugin com especificação aberta que permite integrar o SDK com a IDE, executar e testar aplicações MIDlets
3.6. COMPARATIVO ENTRE OS SDKS
de (a até o) são suportadas por essa tecnologia, no entanto, existem diferentes variações. A Motorola contém uma documentação interna chamada Device Matrix, contendo todas as compatibilidades.
3.6
Comparativo entre os SDKs
Nesta seção, faremos algumas comparações sobre as ferramdas das PDC estudadas, com relação às suas características. A Tabela3.2apresenta um resumo comparativo das três ferramentas vistas neste capítulo (SDK S60, WTK e Motodev Studio), com relação aos requisitos desejáveis propostas e apresentadas na (Seção3.4).
Legenda: Satisfaz: :); Satisfaz parcialmente: :|; Não satisfaz: :(.
Tabela 3.2 Requisitos desejáveis das Ferramentas de Desenvolvimento de Celular (adaptada de
Kurkovsky(2009);Loureiro et al.(2003);Economou et al.(2008))
Requisitos desejáveis SDK S60 SDK WTK SDK Motodev
1) Extensibilidade :| :) :( 2) Portabilidade :) :| :| 3) Inserção de código :) :) :) 4) Interface aberta :) :) :) 5) Sincronização :| :) :| 6) Suporte a protocolos: :) :) :) 7) Importação de dados :| :) :( 8) Depuração :) :) :) 9) Internacionalização :| :) :) 10)Curva de aprendizado :| :) :)
11) Rápida Codificação e Construção :| :) :) 12) Ferramentas GUIs p/ projetos :( :) :) 13) Suporte diferentes celulares :) :| :) 14) Suporte restrição poder comput. :) :) :|
Do requisito 1 (estensibilidade), pode-se dizer que o WTK é a melhor opção para o desenvolvedor, por não possuir celulares reais, e portanto, não haver preocupações de compatibilidades. O Motodev da Motorola, que possui cinco tipos de PSCs diferentes, tem vários riscos de ter problemas para considerar estensibilidade. O S60 se mantém na posição neutra (satisfaz parcialmente), pois também possui problemas de compatibil- idades com seus celulares. Porém, as suas APIs e seu emulador são mais estáveis por reproduzirem fielmente o comportamento da aplicação.
3.6. COMPARATIVO ENTRE OS SDKS
ferramentas. Embora esse último (suporte diferentes celulares) não se deva considerar o WTK, já que o mesmo não possui celulares reais.
Os pontos negativos ficaram nos requisitos 1 e 7, do Motodev Studio, pois no caso da Motorola, existem muitos dispositivos com muitas PSC, e isso dificulta a estensibilidade, além de sua tecnologia ser bastante voltada para recursos básicos. Da mesma forma, o requisito 12 prejudica a PSC do S60, pois não há muitas ferramentas ao não ser o próprio emulador.
Figura 3.8 Resultado da Comparação dos SDKs segundo requisitos desejáveis
A Figura3.8ilustra o resultado da comparação das ferramentas estudas e seus req- uisitos desejáveis. A ferramenta WTK obteve a melhor porcentagem para o critério satisfaz.
Sem dúvida, de forma geral, atende bem o papel de proporcionar aos desenvolvedores quase todos os recursos esperados por uma ferramenta voltada para as PDC Java. Por outro lado, o fato de não haver celulares reais fazem com que o WTK seja sugerido apenas para testes da aplicação, enquanto estiver em fase de desenvolvimento. Fases seguintes sugere-se testar na PDC do celular-alvo.
Observa-se ainda, que a ferramenta S60 SDK demonstra ser a mais estável, com relação a soma dos critérios Satisfaz e Satisfaz Parcialmente.
No caso dos emuladores (SDKs) investigados para as PDCs, mostram-se bastante úteis. Permitem que testes sejam executados localmente, ainda no ambiente de desenvolvimento, além de serem capazes de oferecer recursos extras (difíceis de reproduzir nos dispositivos reais) que facilitam a depuração.
3.6. COMPARATIVO ENTRE OS SDKS
das APIs disponíveis para o desenvolvedor. Por outro lado, tem suporte apenas a PSC do Windows Mobile. Logo, as execuções no seu emulador não garantirão portabilidade para outras plataformas. O WTK tem propósito geral para realizar testes de simulação usando seu emulador. Neste sentido, a ferramenta atinge bem os objetos. Por outro lado, não reproduz o comportamento com exatidão de celulares-reais.
O emulador S60 possui excelente documentação técnica, e reproduz muito bem as aplicações MIDlets, tal como se fosse ao celular real. Porém, os requisitos computacionais mínimos para rodar a ferramenta no PC, são bem elevados, exigindo uma máquina com um bom processador para execução do emulador.
A integração com a IDE da ferramenta da Motorola é excelente, pois a mesma já vem de fábrica com todas as ferramentas integradas. Além disso, possui versões para vários sistemas operacionais, enquanto o WTK e S60 SDK, somente para Windows, apesar de ter versões de Linux para o WTK (versão antiga).
Por fim, um critério não considerado, mas importante, são a quantidade de exemplos disponíveis (os demos) e a forma como eles são ilustrados para o desenvolvedor.
O WTK possui 28 demos e permite que o desenvolvedor (através da página inicial, vide Figura3.6), escolha o demo, clicando no link. O programa demo então é aberto o o emulador executa o mesmo imediatamente.
No S60 SDK são 21 demos, porém, o desenvolvedor só sabe que eles existem se ler a documentação técnica pelo help do sistema. Ou acessar pelo filesystem a suas localizações. Não há integração com IDE automática sem instalar plugins acidentais.
No Motodev Studio, existe a ferramenta DemoTool, que permite o desenvolvedor listar os demos e importar o mesmo para um projeto da IDE. No total são 23 demos.
Em avaliação de PDC similar, segundoEconomou et al.(2008), a escolha da tecnolo- gia adequada depende de fatores relacionados aos conhecimentos técnicos dos desen- volvedores, dos requisitos da aplicação, do celular-alvo, bem como, do cronograma e orçamento do projeto.
O capítulo seguinte apresenta a ferramenta DemoTool, concebida com base nas análises e comparações das características apresentadas (vide Tabela3.2) e integrada no SDK Motodev Studio for Java ME, da fabricante Motorola, Inc..
“O segredo da felicidade não é fazer sempre o que se quer, mas querer sempre o que se faz.”
Leon Tolstoi
4
DemoTool
Este capítulo apresenta a ferramenta DemoTool. Inicialmente são apresentados os requi- sitos que devem ser atendidos pela ferramenta, seguido pelas fases de análise, projeto, implementação e implantação. Depois, apresenta-se o desenvolvimento de um demo para entretenimento e aprendizado de notas musicais, intitulado Mobile Piano Learning. Ele foi construído com base no DemoTool, mostrando a maneira de como usar cada recurso produzido pela proposta, servindo como um estudo de caso.
4.1
Introdução
Existem hoje muitas aplicações de celulares disponíveis com diferentes propósitos e contextos de uso (vide Apêndice E). As diferentes formas de utilização podem ser complementadas através do desenvolvimento de aplicativos que permitam, cada vez mais, expandir os usos e capacidade dos dispositivos, tornando ainda mais acessível a utilização da computação para a sociedade.
Devido ao aumento crescente do tamanho e da complexidade dos sistemas computa- cionais, das problemáticas e desafios desta área (vide Seção 3.3), cada vez mais há a necessidade por parte dos desenvolvedores de aplicações móveis, utilizar ferramentas de desenvolvimento para minimizar o esforço de implementação, o custo e a complexidade. O uso de ferramentas, como emuladores, tende a trazer grandes benefícios como, por exemplo, testar os aplicativos dos celulares, sem no entanto, ter que possuir o celular-alvo da aplicação durante o processo de desenvolvimento.
Não obstante, a oferta de dados para celulares, tais como as que se apresentam nos dias atuais (vide Seção1.2.2), faz com que haja demandas por aplicativos e conteúdos móveis. Neste sentido, as Plataformas de Software de Celular (PSC) têm grande im- portância estratégica para empresas que desejam prover conteúdos, bem como, para os
4.1. INTRODUÇÃO
desenvolvedores de terceiros, pois são através dessas tecnologias que muitos serviços e conteúdos são construídos e ofertados para usuários de celular.
De maneira geral, os desenvolvedores de software e empresas do ramo, desejam que suas aplicações cheguem ao maior número possível de usuários de celular, no entanto, devido as diferentes tecnologias de celular existentes (vide Capítulo2), essa meta torna-se cada vez mais custosa, pois requer portar o software em ambientes incompatíveis entre si. Entretanto, o uso das ferramentas das Plataformas de Desenvolvimento de Software de Celular (PDC) contribuem para minimizar as dificuldades (vide Capítulo3).
A proposta desse trabalho se fundamenta no novo tipo de modelo de inovação no ecossistema de negócios para celular (vide Capítulo1.2), observada porZiv(2005);Ziv and Mulloth(2007), considerando as relações dos usuários com as principais entidades envolvidas no ecossistema da indústria de celular: os fabricantes de celular (Seção1.2.4), as operadoras de celular (Seção1.2.3) e os provedores de conteúdo (Seção1.2.5).
Neste sentido, uma das questões abordadas aqui visa investigar a relação das ferra- mentas de desenvolvimento (fornecidas por fabricantes de celular) e sua utilização no contexto da computação móvel, no qual acredita-se que os desenvolvedores utilizam as PDCs de maneira natural e de forma intuitiva, pois é inerente às práticas de conhecimento desses profissionais o manuseio de tais tecnologias. No entanto, os programadores inici- ais, ou aqueles que iniciam práticas de programação, tem maior chance de encontrarem dificuldades para produzir soluções, bem como, para resolver problemas da computação móvel através da utilização das PDC.
Figura 4.1 Modelo de inovação no ecossistema considerando o desenvolvedor (adptado deZiv and Mulloth(2007)
4.2. DESENVOLVIMENTO DO DEMOTOOL
A Figura4.1ilustra o modelo de inovação que se apresenta no ecossistema da indústria de celular (vide Seção1.2.5) considerando o desenvolvedor de software, com ênfase nas suas interações nos setores impactados. Desta maneira, o desenvolvedor pode interagir de forma menos restritiva com outras entidades relacionadas na indústria.
Por exemplo, o desenvolvedor pode ofertar um aplicativo ou serviço de dados para alguns usuários e realizar transações de dados sem requerer, necessariamente, autorização das operadoras dos clientes ou fabricante de celular dos usuários que estão usando o serviço interessado. Usuários podem então, instalar aplicações utilizando a rede das operadoras como uma ponte, no intuito de acessar a Internet, e assim, instalar diferentes aplicativos ou consumir diversos dados de provedores de conteúdo distintos. Da mesma maneira, a fabricante Motorola pode disponibilizar vários aplicativos para a comunidade de desenvolvedores, incentivando o desenvolvimento de aplicativos para usuários de seus celulares. Através deste cenário, pode-se aproximar o usuário desenvolvedor com a fabricante de celular utilizando essa ferramenta.
Investiga-se ainda, qual a importância dos fabricantes de celular para os desenvolve- dores de software, ao mesmo tempo em que, os desenvolvedores requerem as tecnologias (PSC, PDC, SDKs) para ofertar aplicativos diante deste paradigma. A construção da parceria das diferentes entidades envolvidas no ecossistema da indústria, junto com os desenvolvedores de software é de fundamental relevância para corroborarem entre si.
Assim, procuramos investigar o processo de desenvolvimento de aplicações para celular, como ilustrado na Figura4.1, acompanhando o uso do ferramental necessário e suas ferramentas de apoio. Foi proposto, desenvolvido e distribuído mundialmente, através do SDK da Motorola - Motodev Studio for Java (vide Seção3.5.3), o DemoTool, uma ferramenta que visa auxiliar a descoberta de aplicativos, permitindo integração do ambiente IDE com a PDC do fabricante.
O restante deste capítulo mostra o desenvolvimento da ferramenta DemoTool para o cenário acima descrito e do desenvolvimento do jogo Mobile Piano Learning, construído a partir do uso dessa ferramenta, servindo como um estudo de caso.
4.2
Desenvolvimento do DemoTool
O nome DemoTool1vem da característica que a ferramenta foi concebida, e no qual se propõe, ou seja, permitir a integração de demos2no ambiente de desenvolvimento.
1DemoTool pode ser executado instalando o ambiente Motodev Studio for Javahttp://developer. motorola.com/docstools/motodevstudio/javame/
4.2. DESENVOLVIMENTO DO DEMOTOOL
O DemoTool é um sistema para reuso de aplicações demos cujo objetivo é minimizar o esforço necessário para assimilar o processo de desenvolvimento de software para celular. Além disso, esse sistema possibilita a descoberta de aplicativos demonstrativos (na forma de demos), apresentando suas funcionalidades e recursos, bem como, permitir a integração do demo com o ambiente de desenvolvimento SDK do fabricante Motorola (Motodev Studio for Java ME - Seção3.5.3).
A utilização deste sistema possibilita a redução do tempo necessário para a assimilação do processo de desenvolvimento da PSC da Motorola, diminuindo a curva de aprendizado para familiarização do processo de desenvolvimento de software para celular. Isso ocorre porque o DemoTool permite reusar o conhecimento contido nos exemplos de aplicativos demonstrativos.
Os aplicativos demonstrativos foram cuidadosamente elaborados, com propósitos didáticos e com os seus respectivos códigos fontes, permitindo ao desenvolvedor estudar como os recursos foram implementados utilizando as diferentes bibliotecas (APIs), bem como, os vários contextos e cenários no qual se propõe.
Figura 4.2 Visão geral da ferramenta DemoTool
A Figura 4.2 apresenta a interface principal do DemoTool com as suas principais funcionalidades, que são listadas a seguir:
4.2. DESENVOLVIMENTO DO DEMOTOOL
Cada demo é representado por um ícone personalizado, ilustrando o possível contexto de uso. Quando o usuário clicar sobre o ícone, as informações são visualizadas na tela principal (B);
• Informações do demo (B): está tela permite visualizar as informações relevantes do demo selecionado, tais como: a versão, o tamanho do aplicativo, o distribuidor, a versão da configuração (CLDC) e do perfil (MIDP), bem como, as APIs que foram utilizadas neste demo. Além disso, uma breve descrição contextualiza o que a aplicação demo faz;
• Visualização de screenshots (C): esse recurso abre uma janela que permite a visualização das telas (screenshots) do demo selecionado, permitindo uma visão prévia da sua interface gráfica de usuário (GUI). Somente é acessado da tela principal (B);
• Importação do demo (D): permite importar o demo para a IDE Motodev Studio for Java, adicionando os seus arquivos para um projeto no ambiente de desenvolvi- mento. Este recurso somente está disponível sobre o demo selecionado;
• Filtragem por funcionalidades (E): limita a visualização da listagem dos demos (A), permitindo usar um critério de filtragem por API ou por funcionalidades. Para ver todos os demos que usam a JSR-135, por exemplo, deve-se selecionar o filtro por este critério e a listagem (A) será atualizada exibindo somente os demos que usam a biblioteca escolhida;
• Importação de vários demos (F): localizado no canto direito superior da tela, essa funcionalidade exibe uma janela com a listagem de todos os demos disponíveis, permitindo que o usuário selecione quais demos o usuário deseja importar.
A Figura4.3mostra o DemoTool integrado no ambiente Motodev Studio for Java, executando um aplicativo demo recentemente importado para o projeto da IDE Motodev Studio for Java e rodando o emulador para executar o demo.
4.2.1
Contexto de Implementação
A implementação desta ferramenta se insere no contexto da participação de um projeto Offshore3, patrocinada pela Motorola, Inc., e executado pela fábrica de software do Centro
3Offshore: designa os serviços prestados para clientes fora de suas fronteiras nacionaisFernandes (2007).
4.2. DESENVOLVIMENTO DO DEMOTOOL
Figura 4.3 DemoTool integrado no Motodev Studio/J executando o demo no emulador
de Estudos e Sistemas Avançados do Recife (C.E.S.A.R), bem como, das atividades de engenharia de software exercidas nesta empresa.
O C.E.S.A.R é um instituto privado de inovação, classificado como uma associação civil sem fins lucrativos, cujo suas principais frentes de atuação são a execução de projetos