Criando uma Aplicação para Celular

Este estudo de caso está dividido em duas fases: a Fase 1 compreende o uso do DemoTool como ferramenta de descoberta de aplicativos; e a Fase 2 busca experimentar a criação de software de celular em ambiente real e cotidiano.

4.3.3.1 Fase 1: uso do DemoTool

Inicialmente, procurou-se refletir que tipo de aplicação seria interessante desenvolver, e como posteriormente poderia distribuir o aplicativo no mercado de celular (PEv-01). Considerando as aplicações mais baixadas do portal iTunes do AppStore (vide Tabela1.2), podemos observar que dos 10 mais baixadas, 5 são da categoria de games. Assim ficou resolvido que o aplicativo eleito deveria ser também um jogo.

Considerando o ciclo de desenvolvimento de software para celular (vide Seção3.2), devemos percorrer inicialmente pelas fases de codificação e construção. No entanto, surge a necessidade de planejar o game que se pretende implementar antes de iniciar o processo de codificação (PEv-02, PM-01).

Através do DemoTool, pode-se observar que existem aplicações demos, e que estes, podem ser testados para avaliar o seu uso. Entretanto, usando o Motodev Studio for Java, no qual o DemoTool foi incorporado, em nenhum momento essa informação é transmitida para o desenvolvedor, não permitindo assimilar que tal ferramenta estáacessível (PM-02). Essa percepção foi evidenciada no contexto de utilização dos primeiros cenários de uso (PM-03). Em consequência, faz com que o desenvolvedor tenha que descobrir por conta própria (PEv-03).

Quando a ferramenta do DemoTool foi executada pela primeira vez, observou-se que a posição inicial da tela (também conhecido no Eclipse como View) encontra-se na área inferior da janela principal da IDE. Essa perspectiva ilustra e destaca bem a sua aparição. Entretanto, quase não se percebe que existe uma lista de demos no canto esquerdo da view do DemoTool (PM-04). Ao clicar sobre um demo (por exemplo AcronymSearch

4.3. ESTUDO DE CASO: MOBILE PIANO LEARNING

MIDlet Suite), não se pode notar todas as informações da tela conforme a (Figura4.2) (PM-05). Esse cenário, impossibilita a leitura das informações descritivas dos exemplos de aplicativos de quaisquer demos subsequentes, e por mais que se clique nos outros demos existentes, não se pode perceber que tais informações estavam escondidas (PM-06). Redimensionando o tamanho da área da View do DemoTool, pode-se então, perceber que existem vários demos, e que eles possuem várias descrições.

Diante da necessidade de desenvolver o jogo, procurou-se na listagem existente, que tipo de aplicações demos havia no sistema. Observou-se que existem 23 demos, sendo que 5 podem ser considerados exemplos de jogos. Porém, para descobrir essa informação foi necessário abrir e executar todos os demos para somente então, enquadrá-los nesta categoria, de acordo com a expertise do desenvolvedor (PM-07).

Durante o processo de procura nos demos existentes, observou-se o recurso de screenshots, que permite ver uma prévia do aplicativo, sem a necessidade de ter que importar o demo. Todos os demos têm telas (de screenshots), porém, todos iniciam exibindo a tela de “launch", que é a tela inicial que o emulador exibe durante a simulação do aplicativo (PM-08). Constatou-se que as telas de screenshots mais interessantes aparecem como última opção de escolha, o que acaba por escondê-las dos usuários (PM-09).

Ao percorrer a listagem dos demos, foi utilizado o botão central de rolagem do mouse (a fim de obter a rolagem da tela), para tentar descer e subir nas opções disponíveis. Mas aconteceu a mudança na opção de “Filter By", e não no lugar esperado (lista de demos) (PM-10). O recurso de filtragem então foi descoberto (PM-11).

Após utilizar o recurso de “Filter By”, sentiu-se falta de nomes mais apropriados. Ao invés de “jsr-75”, poderia usar os nomes das API (neste caso “File Connection API (jsr-75)”) (PM-12).

De todos os demos consultados o MobilePiano MIDlet Suite foi escolhido por sua característica de um game de entretenimento, com uso de som e imagem, tal como um jogo utiliza. O recurso de importar o demo específico foi utilizado. Neste momento, ao clicar no botão “import”, observou-se que a barra de progresso não aparece (PM-13), deixando o desenvolvedor confuso por determinado tempo. Mas em seguida, o demo foi importado corretamente para dentro da IDE.

A partir desse ponto, podemos encerrar a Fase 1 deste estudo. Foram encontrados 13 Pontos de Melhoria e 3 Pontos de Evidência. Os pontos observados são analisados no próximo capítulo. Além disso, como resultado desta fase optou-se por fazer um jogo voltado para entretenimento (descrito na próxima seção). A seguir, apresentamos a Fase

4.3. ESTUDO DE CASO: MOBILE PIANO LEARNING

2, que apresenta o ciclo de desenvolvimento do jogo em ambiente real.

4.3.3.2 Fase 2: ciclo de desenvolvimento do aplicativo

Nesta seção, buscamos vivenciar as experiências reais no processo do ciclo de desenvolvi- mento de software para celular, conforme abordado na Seção3.2.

Após ter importado o demo MobilePiano MIDlet Suite para dentro da IDE Motodev Studio for Java, iniciou-se a fase de codificação e construção (a). Decidiu-se que o nome original do demo deveria ser alterado para Mobile Piano Learning. O nome foi formulado a partir do reuso da funcionalidade do demo anterior (PEv-04) e do seu nome proposto (“Mobile Piano)”, e estendido para tornar-se mais atrativo.

O demo permite reproduzir os sons de um piano, permitindo que o usuário toque sons usando o recurso de touchscreen. O demo foi cuidadosamente analisado pelo desenvolvedor (PEv-05), pois todo o seu ciclo de vida precisou ser entendido. Através da ferramenta de depuração (PEv-06) do Eclipse, pode-se tirar vários dúvidas dos pontos de código de complexidade alta (devido ao uso da JSR-135 - Mobile Media API).

Em seguida optou-se por transformar o demo em um jogo para aprendizado de notas musicais usando o piano e reusando suas funcionalidades básicas (idem PEv-04). Dentro das novas funcionalidades implementadas, destacamos a possibilidade do usuário usar também as teclas numéricas do dispositivo, bem como, visualizar a nota musical que está sendo tocada (Do, Ré, Mi, Fá, Só, Lá, Si e sustenidos respectivos). Foi adicionado também, uma tela de Sobre (About), com uma descrição do que o MIDlet faz e uma foto do desenvolvedor.

A fase de teste (b), foi percorrida sem maiores dificuldades através da execução do emulador (PEv-07). A Figura4.9, exibe o aplicativo sendo simulado no emulador da Motorola. As funcionalidades foram testadas e implementadas de acordo com as funcionalidades reusadas e planejadas.

As fases seguintes foram assinatura (c) e distribuição (d). A fase assinatura (c), não requerer obrigatoriamente a sua utilização, que consiste na assinatura digital do aplicativo, assim, passou-se para a etapa seguinte (PEv-08): a distribuição (d) do aplicativo.

Tentou-se instalar o aplicativo desenvolvido em diferentes modelos de celular (PEv- 09). As tentativas percorridas, bem como, os seus resultados são descritos a seguir:

• Nokia N95 (Symbian): Sucesso de instalação e execução do aplicativo. Porém, a última tecla (#), não tocou o som conforme esperado (nota “Si”);

4.3. ESTUDO DE CASO: MOBILE PIANO LEARNING

Figura 4.9 Testando aplicativo Mobile Piano Learning no emulador

• ROKR EM35 (Motorola Linux OS) : Sucesso de instalação e insucesso na exe- cução (PEv-10);

• W510 (P2K ou Motorola OS): Sucesso de instalação e insucesso na execução (idem PEv-10);

• Moto Q 9h (Windows Mobile): Sucesso de instalação e insucesso na execução (idem PEv-10).

Com as execuções falhando nos diferentes celulares citados (PEv-10), inicialmente pensou-se que o aplicativo estivesse com algum bug (PEv-11). Então o aplicativo foi novamente para a fase de codificação e construção (PEv-12), visando re avaliar e analisar os pontos críticos. Foi observado que não havia um tratamento de exceções adequado (PEv-13). O jogo então foi remodelado para contemplar o tratamento de exceções (amigável).

As fases de codificar e construir, bem como testar, precisam ser percorridas novamente (PEv-14). Após realizar alguns testes no emulador e gerar uma versão atualizada do aplicativo, foi percorrido as instalações nos celulares reais novamente (PEv-15). No entanto, descobriu-se que para tocar o som da JSR-135 (Mobile Media API), a PSC do fabricante requer o suporte de codecs9de áudio específicos.

4.3. ESTUDO DE CASO: MOBILE PIANO LEARNING

Para garantir que essa era mesmo a razão do problema do aplicativo, levou-se mais um tempo de investigação em fóruns técnicos, bem como, documentações específicas encontradas na internet (site especializados como o forum.nokia.com), para confirmar a razão técnica (PEv-16). Foi confirmado que a versão do Symbian do celular N-95 possuía suporte ao codec necessário para a execução do aplicativo, justificando o fato de ter sido o único modelo testado que funcionou (vide Figura4.10).

Figura 4.10 Mobile Piano Learning rodando no modelo Nokia N-95

Os demais modelos de celular testados não funcionaram exatamente no momento de instanciar o recurso da JSR-135 (Mobile Media), especificamente no uso da instrução ( Manager.createPlayer(. . . ) ). Para se descobrir tal fato, foi necessário estudar as documentações técnicas do fabricante Motorola a fim de entender o processo de depuração diretamente dentro do celular real (debugging on a device) (PEv-17).

Sabemos que o jogo desenvolvido Mobile Piano Learning somente possui compat- ibilidade com os dispositivos da Série 60 (com versão da PSC Symbian 9.2) (PEv-18). Entretanto, outras plataformas não testadas, tais como as abordadas no Capítulo2, pre- cisam ser testadas em seus diferentes dispositivos para garantir portabilidade nessas tecnologias (PEv-19).

Por fim, tentou-se ofertar o aplicativo nos canais conhecidos de distribuição e disponibilizá-lo em canais gratuitos ou a custos reduzidos (PEv-20).

Um desses canais de compartilhamento gratuito de aplicativos foi o portal Nokia Mosh (http://mosh.nokia.com/). No entando, a Nokia encerrou as atividades do portal, informando que o site foi descontinuado, centralizando as operações no OVI (http://store.ovi.com/). Um fato curioso, segundo informado no site do portal Mosh, o número de download atingiu a marca de 137.623.934 downloads de aplicativos.

4.3. ESTUDO DE CASO: MOBILE PIANO LEARNING

Ao acessar o portal OVI, observou-se a necessidade de realizar um cadastro (na forma de contrato), onde o desenvolvedor paga uma taxa inicial. Após a efetividade do acordo, os uploads de aplicativos ficam liberados (PEv-21). O aplicativo desenvolvido não foi distribuído.