iava – aplicaÇÃo web para disponibilizar...

UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO

IAVA – APLICAÇÃO WEB PARA DISPONIBILIZAR

RECURSOS DO AVA NO DISPOSITIVO MÓVEL IPHONE

FERNANDA SAMPARA

BLUMENAU 2010

2010/1-11

FERNANDA SAMPARA



Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciência da Computação — Bacharelado.

Prof. Dalton Solano dos Reis, M.Sc. - Orientador

BLUMENAU 2010

2010/1-11



Por

FERNANDA SAMPARA

Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:

______________________________________________________ Presidente: Prof. Dalton Solano dos Reis, M.Sc. – Orientador, FURB

______________________________________________________ Membro: Prof. Paulo César Rodacki Gomes, Dr. – FURB

______________________________________________________ Membro: Prof. Oscar Dalfovo, Dr – FURB

Blumenau, 05 de julho de 2010

Dedico este trabalho a toda a minha família e amigos, pelo incentivo, cooperação e apoio, durante o período da realização deste.

AGRADECIMENTOS

A meus pais, Roberto e Nilda Sampara, e a meu irmão, Luciano Sampara, que sempre

me ajudaram e me apoiaram em todas as etapas de minha vida, principalmente durante todo o

período de faculdade.

A meu noivo, Rafael de Oliveira, pela compreensão, ajuda, apoio e incentivo para a

realização deste trabalho.

Aos meus amigos, pela paciência, bom humor e apoio.

Ao meu orientador, Dalton Solano dos Reis, por ter me ajudado em todas as

necessidades, pelo comprometimento e atenção.

A empresa, Senior Sistemas, por permitir o horário flexível quando fora necessário.

A todos meu carinho e muito obrigado.

Não importa quais sejam os obstáculos e as dificuldades. Se estamos possuídos de uma inabalável determinação, conseguiremos superá-los independentemente das circunstâncias.

Dalai Lama

RESUMO

Este trabalho descreve o desenvolvimento de uma aplicação web, que será visualizada por um dispositivo móvel iPhone. A aplicação desenvolvida trata-se de uma nova aplicação que apresenta os recursos já utilizados no Ambiente Virtual de Aprendizagem, uma ferramenta já existente para o público desktop, que proporciona a comunicação entre a comunidade acadêmica, pela internet. Sendo assim, o objetivo do trabalho é a preocupação em utilizar recursos próprios para o iPhone e manter o máximo da estrutura e das funcionalidade da aplicação original. A aplicação, também classificada como uma Web App, roda em um servidor Tomcat e utiliza das tecnologias Java, JSP, Java Script e CSS. Os dados da aplicação são obtidos através de mensagens Web Services por um servidor de dados, também desenvolvido neste trabalho. Como resultado do trabalho tem-se a construção de uma aplicação web, preparada para atender usuários com ambiente iPhone, contando com alguns recursos do AVA e tendo como administrador dos dados um servidor acessado via Web Services.

Palavras-chave: iPhone. Dispositivos móveis. Web services.

ABSTRACT

This paper describes the developer of a web application, that will be available in a iPhone. The developed application is a new application that shows the appeals already existents on the Ambiente Virtual de Aprendizagem, a tool already existent to de desktop public, that provides the communication between the academic community through the internet. So, the challenge is the care in utilize own appeals to iPhone and keep the max of original application's structures and functionalities. The application, also called as Web App, runs in a Tomcat server and uses the technologies Java, JSP, Java Script and CSS. The application's data is obtained from the Web Services, from a data server, also developed in this paper. The paper's result, we have the construction of a web application, developed to support users with iPhone ambient, with some recourses of AVA and a server, accessed by web services for data administrator.

Key-words: iPhone. Mobile device. Web services.

LISTA DE ILUSTRAÇÕES

Figura 1 - Exemplificação do funcionamento de Web Services...............................................17

Figura 2 - Áreas ativas em cada uma das orientações do iPhone .............................................19

Quadro 1 - Definir a largura de uma tela para web...................................................................19

Figura 3 - Propriedades para ajustes de tamanho da tela e zoom em uma página para iPhone20

Figura 4 - Tipos de fontes recomendadas para uso em iPhone Web Apps...............................22

Figura 5 - Interface do programa Xcode IDE ...........................................................................23

Figura 6 - Interface do programa Interface Builder ..................................................................24

Figura 7 - Interface do programa iPhone Simulator .................................................................25

Figura 8 - Interface do programa Dashcode .............................................................................26

Figura 9 - Aplicações: (a) produtividade - Mail, (b) utilitário - Weather e (c) imersivo -

NexHockey ............................................................................................................29

Figura 10 - Opções para seleção em aplicativos do iPhone......................................................32

Figura 11 – Divisões da tela do iPhone ....................................................................................34

Figura 12 - Barra de abas de uma aplicação que contém várias opções para se mostrar um

relógio ....................................................................................................................36

Figura 13 – Barra de ferramentas num aplicativo de e-mail.....................................................37

Figura 14 – Mensagens: alertas, fichas de ações e visões modais ...........38

Figura 15 - Padrões de ícones utilizados na Barra de Ferramentas.............................39

Figura 16 - Padrão de botões utilizados em Barras de Navegação ...............................40

Figura 17 – Padrão de botões utilizados em Barras de Abas...........................................40

Figura 18 – Padrão de botões utilizados em linhas dos elementos de uma tabela ...............41

Figura 19 – Estrutura de um sistema utilizando Web Services ................................................42

Figura 20 - Tela inicial da aplicação iWebKit ..........................................................................43

Figura 21 - Tela inicial da aplicação Jqtouch ...........................................................................44

Figura 22 – Casos de uso da aplicação iAVA...........................................................................47

Quadro 2 – Caso de uso UC01..................................................................................................48








Quadro 10 – Caso de uso UC09................................................................................................55

Quadro 11 – Caso de uso UC10................................................................................................56

Figura 23 – Diagrama de classe do recurso de arquivos...........................................................57

Figura 24 – Diagrama de classe do recurso de material ...........................................................58

Figura 25 – Diagrama de classe do link....................................................................................59

Figura 26 – Diagrama de classe do recurso de texto colaborativo ...........................................60

Figura 27 – Diagrama de classe do recurso fórum ...................................................................61

Figura 28– Diagrama de seqüência para a criação de arquivos na aplicação ...........................63

Figura 29 – Diagrama de navegação do login do aplicativo.....................................................64

Figura 30 - Ilustração do uso de Web Service na aplicação .....................................................65

Figura 31 - Estrutura de tabelas da aplicação (MER) ...............................................................66

Figura 32 - Diagrama de classe da estrutura MVC da aplicação..............................................68

Figura 33 - Diagrama de classe do padrão Command utilizado na aplicação ..........................69

Figura 34 - Diagrama de classe do padrão Singleton utilizado na aplicação .....................69

Quadro 12 – Classes CSS utilizadas na implementação...........................................................70

Quadro 13 – Classe que define os métodos Web Services .......................................................71

Quadro 14 – Classe que chama o Web Service ........................................................................72

Quadro 15 – Copiar arquivos da internet..................................................................................73

Figura 35 - Tela de login do aplicativo.....................................................................................74

Figura 36 - Tela de área de estudo do aplicativo ......................................................................75

Figura 37 - Tela de área de estudo do aplicativo ......................................................................76

Figura 38 - Tela de adicionar recursos utiliza o recurso visão modal do teclado.....................77

Figura 39 - Tela de adicionar recursos utiliza o recurso de seleção picker ..........................78

Figura 40 - Tela do recurso material e seus itens......................................................................79

Figura 41 - Adicionar um link e associar um arquivo no recurso material...............................80

Figura 42 - Recurso texto colaborativo.....................................................................................81

Figura 43 - Tela de comparação entre históricos no texto colaborativo ...................................82

Figura 44 - Tela do recurso fórum temático .............................................................................83

Figura 45 - Tela de arquivos do usuário ...................................................................................84

Figura 46 - Comportamento do componente file no iPhone ................................................86

LISTA DE SIGLAS

AVA – Ambiente Virtual de Aprendizagem

CSS – Cascading Style Sheets

HTML – HyperText Markup Language

HTTP – HyperText Transfer Protocol

IAB – Interactive Advertising Bureau

IDE – Integrated Development Environment

IHC – Interação Humano Computador

MER – Modelo, Entidade e Relacionamento

MVC – Modelo, Visão e Controle

PHP – Hypertext Preprocessor

SDK – Software Development Kit

SMTP – Simple Mail Transfer Protocol

UML - Unified Modeling Language

URL - Uniform Resource Locator

XHTML – eXtensible HyperText Markup Language

XML – eXtensible Markup Language

WIFI – WIreless FIdelity

SUMÁRIO

1 INTRODUÇÃO..................................................................................................................13

1.1 OBJETIVOS DO TRABALHO.........................................................................................14

1.2 ESTRUTURA DO TRABALHO ......................................................................................14

2 FUNDAMENTAÇÃO TEÓRICA ....................................................................................15

2.1 AMBIENTE VIRTUAL DE APRENDIZAGEM .............................................................15

2.2 IPHONE 3GS.....................................................................................................................15

2.3 WEB SERVICES...............................................................................................................16

2.4 INTERAÇÃO HUMANO COMPUTADOR ....................................................................17

2.5 IPHONE WEB APPS ........................................................................................................18

2.6 FERRAMENTAS ..............................................................................................................22

2.6.1 Xcode...............................................................................................................................22

2.6.2 Interface Builder..............................................................................................................23

2.6.3 iPhone Simulator .............................................................................................................24

2.6.4 Dashcode .........................................................................................................................26

2.7 IPHONE HUMAN INTERFACE GUIDELINES.............................................................27

2.7.1 Recomendações Gerais aos Desenvolvedores.................................................................27

2.7.2 Ícones...............................................................................................................................31

2.7.3 Opções de Seleção...........................................................................................................31

2.7.4 Divisões da tela................................................................................................................33

2.7.4.1 Barra de Status ..............................................................................................................34

2.7.4.2 Barra de Navegação ......................................................................................................35

2.7.4.3 Barra de Abas................................................................................................................35

2.7.5 Mensagens de Atenção ao Usuário..................................................................................37

2.7.6 Utilização dos Botões ......................................................................................................39

2.8 TRABALHOS CORRELATOS ........................................................................................41

2.8.1 Sistema utilizando Web Services ....................................................................................41

2.8.2 iWebKit ...........................................................................................................................42

2.8.3 Jqtouch.............................................................................................................................43

3 DESENVOLVIMENTO ....................................................................................................45

3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO.......................45

3.2 ESPECIFICAÇÃO.............................................................................................................46

3.2.1 Diagrama de casos de uso................................................................................................46

3.2.1.1 UC01 – Login .............................................................................................................47

3.2.1.2 UC02 – Manter Arquivo........................................................................................48

3.2.1.3 UC03 – Manter Link...............................................................................................49

3.2.1.4 UC04 – Manter Pasta ............................................................................................50

3.2.1.5 UC05 – Manter Material .....................................................................................51

3.2.1.6 UC06 – Manter Texto Colaborativo .............................................................52

3.2.1.7 UC07 – Manter Fórum ............................................................................................53

3.2.1.8 UC08 – Postar Fórum ............................................................................................54

3.2.1.9 UC09 – Carregar Disciplinas .........................................................................55

3.2.1.10 UC010 – Editar Texto Colaborativo ....................................................56

3.2.2 Diagrama de classes ........................................................................................................56

3.2.2.1 Recurso Arquivos .....................................................................................................56

3.2.2.2 Recurso Material .....................................................................................................58

3.2.2.3 Recurso Link ...............................................................................................................59

3.2.2.4 Recurso Texto Colaborativo .............................................................................60

3.2.2.5 Recurso Fórum.............................................................................................................61

3.2.3 Diagrama de seqüência....................................................................................................62

3.2.4 Diagrama de navegação...................................................................................................64

3.2.5 Web Service.....................................................................................................................64

3.2.6 Banco de Dados...............................................................................................................65

3.3 IMPLEMENTAÇÃO.........................................................................................................67

3.3.1 Técnicas e ferramentas utilizadas....................................................................................67

3.3.1.1 Modelo, Visão e Controle .............................................................................................67

3.3.1.2 Design Patterns.............................................................................................................68

3.3.1.3 Classes de estilos...........................................................................................................70

3.3.1.4 Recuperação de dados via Web Service .......................................................................70

3.3.1.5 Copiar um arquivo da internet ......................................................................................72

3.3.2 Operacionalidade da implementação...............................................................................73

3.4 RESULTADOS E DISCUSSÃO.......................................................................................84

4 CONCLUSÕES ..................................................................................................................88

4.1 EXTENSÕES.....................................................................................................................89

REFERÊNCIAS BIBLIOGRÁFICAS..................................................................................90

13

1 INTRODUÇÃO

A internet vem crescendo em passos largos no Brasil e no mundo. Uma prova disso

está na pesquisa feita pelo Interactive Advertising Bureau (IAB), que espera para o final de

2009 cerca de 28 milhões de internautas residenciais no Brasil, 20% a mais do que o ano de

2008 (ALVES, 2009). Isso desperta o interesse em outras tecnologias utilizarem também este

recurso em expansão, sendo uma delas a telefonia móvel. No Brasil a telefonia móvel tem um

forte e acelerado crescimento. Um exemplo de sucesso entre a junção da internet com a

telefonia móvel pode-se apresentar o portal Terra, que com a chegada das tecnologias 3G e

iPhone ao Brasil, teve um aumento em seus acessos de cerca de 160% (FORESTA, 2009).

Um dos causadores do sucesso da telefonia móvel com a internet são os aparelhos

smartphones, que segundo Redação IDG Now! (2010), o acesso a sites por meio de

smartphones cresceu 600% entre dezembro de 2008 e dezembro de 2009. Estes aparelhos

trazem algumas funcionalidades de um computador, por exemplo conexão a Internet e rodar

sistemas operacionais, em um dispositivo que tem o tamanho de um celular

(MENTALIDADE, 2010).

O iPhone é um smartphone desenvolvido pela Apple, que contempla as

funcionalidades de um celular com câmera, além de poder se conectar a internet WIreless

FIdelity (WIFI), executar o sistema operacional MAC OS X e interagir com o usuário através

de toques na tela (touch screen), isso é, não possui teclado. A venda de iPhones no Brasil e no

mundo está crescendo de maneira rápida. Um exemplo se tem quando compara-se as vendas

entre os anos de 2008 e 2009, onde a diferença chega ao dobro, enquanto em 2008 respondeu

por 5,3%, em 2009 respondeu por 10,8%, em relação ao mercado mundial (APPLE MANIA,

2009).

Ocupando uma parcela cada vez maior do mercado, o smartphone está se tornado o

novo foco das empresas. Para atender esta faixa de usuários é preciso fazer modificações em

estilos, layout e recursos a serem utilizadas nas construções de sites Web, pois, uma página

focada para ser vista em um computador (desktop ou notebook) não está adaptada para ser

vista por uma tela pequena e interagir com o usuário através de toques na tela.

Com isso, propõe-se criar uma nova aplicação do Ambiente Virtual de Aprendizagem

(AVA) para ser acessado por um dispositivo móvel, no caso o iPhone. Esta aplicação é

disponibilizada por um servidor Tomcat, onde os dados da aplicação são obtidos através de

mensagens Web Services por um servidor de dados, também desenvolvido neste trabalho.

14

1.1 OBJETIVOS DO TRABALHO

O objetivo deste trabalho é desenvolver o sistema iAVA, isso é, uma aplicação que

contém os recursos do Ambiente Virtual de Aprendizagem sendo visualizada em um

dispositivo móvel iPhone.

Os objetivos específicos do trabalho são:

a) visualizar a aplicação e permitir cadastrar recursos utilizando um aparelho iPhone;

b) definir um servidor de dados que disponibilize Web Services para o servidor de

interface poder recuperar e persistir dados na base de dados;

c) utilizar na estrutura e na aparência da aplicação, as recomendações feitas pela

Apple (2010) para aplicações voltadas ao dispositivo móvel iPhone.

1.2 ESTRUTURA DO TRABALHO

A estrutura deste trabalho está apresentada em quatro capítulos, sendo que o segundo

capítulo contém a fundamentação teórica necessária para o entendimento deste trabalho.

O terceiro capítulo apresenta como foi desenvolvida a aplicação para o dispositivo

móvel iPhone. Os casos de uso que a aplicação segue, diagrama de classe, enfim toda a

especificação que define a aplicação. Ainda no terceiro capítulo são apresentadas as partes

principais da implementação e também os resultados e discussões que aconteceram durante

toda a etapa de desenvolvimento do projeto.

Por fim, o quarto capítulo refere-se às conclusões do presente trabalho e sugestões para

trabalhos futuros.

15

2 FUNDAMENTAÇÃO TEÓRICA

Na seção 2.1 é apresentado o Ambiente Virtual de Aprendizagem que é o site

escolhido como cenário para o trabalho proposto. Na seção 2.2 apresenta-se as

funcionalidades e particularidades do dispositivo móvel iPhone da Apple. Nas seções 2.3, 2.4

e 2.5 são apresentados os conceitos fundamentais de Web Services, IHC e Web App,

respectivamente. Na seção 2.6 são listadas as ferramentas utilizadas para a implementação do

trabalho proposto. Na seção 2.7 são vistos os elementos e as recomendações para se criar uma

Web App para o iPhone. Por fim, na seção 2.8 são apresentados três trabalhos correlatos do

trabalho proposto.

2.1 AMBIENTE VIRTUAL DE APRENDIZAGEM

O Ambiente Virtual de Aprendizagem é uma ferramenta que proporciona a

comunicação entre a comunidade acadêmica, pela internet. Nos recursos disponibilizados

pode-se citar fóruns de debate, galerias de imagens, conteúdo das aulas, o compartilhamento

de arquivos entre outros.

A FURB criou o AVA-FURB que é o ambiente de aprendizagem voltado para as

exigências e requisitos da instituição. Segundo AVA (2009), o acesso ao sistema é

disponibilizado para todas as pessoas que possuem vínculo ativo com a instituição, podendo

estar matriculadas no curso da graduação, pós-graduação, ETEVI, idiomas ou até sendo

servidores.

O site AVA é desenvolvido com a linguagem de programação Hypertext Preprocessor

(PHP) e hoje ainda não está homologado para ser visto no navegador Safari, que é o

navegador utilizado no iPhone (AVA, 2009).

2.2 IPHONE 3GS

O iPhone desenvolvido pela Apple é um telefone celular que possui um dispositivo

16

para acesso a internet, além de outras funcionalidades como tocador de música, câmera,

contém aplicativos de mapas, acelerômetro, entre outros (APPLE, 2009a).

Em sua nova versão, o iPhone 3GS chegou ao Brasil em agosto de 2009 contendo

melhorias e novidades. Em comparação a versão antiga observa-se que está 2,1 vezes mais

rápido ao enviar mensagens e 2,9 mais rápido em abrir páginas web. Nas novidades tem-se a

gravação de vídeos, câmera de 3 Mega Pixels e recurso de controle por voz (REDAÇÃO

TERRA, 2009).

Conforme as especificações do aparelho, segundo Apple (2009b), o iPhone trás

diversas facilidades para os usuários e também possui diversas limitações para os

desenvolvedores de sistemas.

Dentre as facilidades pode-se citar:

a) mobilidade: por se tratar de um aparelho pequeno, pesando 135 gramas e que mede

4,5 x 2,4 polegadas (APPLE, 2009c);

b) rapidez: em comparação com a versão antiga, o iPhone 3GS deve ser 2 vezes mais

rápido (APPLE, 2009b);

c) tela multi-toque: segundo Apple (2009d), pode-se controlar o iPhone dando toques,

deslizando ou percorrendo com os dedos sobre a tela.

Pode-se citar dentre as limitações:

a) tamanho da tela: o iPhone está disponível com uma tela de 3,5 polegadas com

480x320 pixels e com uma densidade de 163 ppi (pixels per inch) (APPLE,

2009c);

b) teclado virtual: para interação com o usuário o iPhone fornece um tecado virtual,

quando necessário. É possível utilizar o teclado com o aparelho na horizontal, para

as teclas ficarem maiores (APPLE, 2009e).

2.3 WEB SERVICES

"O principal objetivo do Web Services é permitir um ambiente distribuído, em que

qualquer número de aplicativos ou componentes de uma aplicação, para que possam

interoperar através de uma linguagem neutra. Isso traz a possibilidade de interoperabilidade e

heterogeneidade do mundo da computação distribuída uma vez por todas" (CHAPPELL;

JEWELL, 2002).

17

Segundo Chappell; Jewell (2002), o Web Services pode ser definido como um pedaço

de lógica de negócios, localizada em algum lugar na Internet, que é acessível através de

protocolos de Internet baseados em padrões tais como HyperText Transfer Protocol (HTTP)

ou Simple Mail Transfer Protocol (SMTP).

As principais características de um Web Service:

a) capacidade de ser síncrono ou assíncrono;

b) fracamente acoplado: um sistema de acoplamento forte significa que o cliente e o

servidor possuem forte ligação uns aos outros, o que implica que se as mudanças

de interface devem ser atualizadas em ambos. Adoção de uma arquitetura de baixo

acoplamento tende a tornar os sistemas de software mais gerenciável e permite a

simples integração entre diferentes sistemas;

c) permitem as aplicações se comunicarem utilizando eXtensible Markup Language

(XML) e web.

Segundo IMasters (2004), pode-se exemplificar o funcionamento do Web Services

conforme apresentado na Figura 1.

Fonte: IMasters (2004).

Figura 1 - Exemplificação do funcionamento de Web Services

Na Figura 1 o cliente requisita os dados para um Web Service e este é responsável por

fazer a busca dos dados no banco de dados e retornar a resposta ao cliente. A comunicação

entre o cliente e o Web Service é feita através de mensagens XML.

2.4 INTERAÇÃO HUMANO COMPUTADOR

Segundo Silva Filho (2003), a Interação Humano Computador (IHC) é uma disciplina

que abrange as áreas de ciência da computação, psicologia, fatores humanos, lingüística, entre

outros. Consiste no desenvolvimento das disciplinas para encontrar maneiras de fazer

interfaces amigáveis ao usuário (user-friendly), estudando formas e maneiras da comunicação

entre o ser humano e um computador. Nestes estudos são verificadas as limitações da

18

capacidade humana e também as restrições das tecnologias existentes.

Quando se trabalha a IHC nos sistemas, um dos pontos que se dá maior destaque é a

capacidade humana de percepção através dos sentidos. Sabendo-se utilizar deste fator, a

interface pode ficar muita mais intuitiva e dedutiva para o usuário. A maioria da IHC ocorre

através do sentido da visão, onde são utilizados gráficos e relatórios, por exemplo.

Embora haja uma tendência para se utilizar comunicação gráfica no projeto de

interface, muito da informação visual ainda é apresentada na forma textual. Mesmo nestes

casos, para uma leitura rápida e para melhor entendimento do usuário, podem ser utilizados

diferentes tipos de fontes, cores e tamanhos para o texto, onde facilitará o processo da leitura.

Segundo Ponte (2006), a IHC é muito mais do que seguir regras e passos sempre

utilizados. Cada usuário tem sua particularidade e cada sistema tem seu estilo. Não se pode

utilizar padrões porque eles já deram certo com outros usuários ou em outros sistemas. Deve-

se programar de forma centrada no usuário, sendo assim, ele é quem deverá escolher o estilo e

formas que o sistema deve possuir.

2.5 IPHONE WEB APPS

Segundo Developer Apple (2010h) iPhone Web Applications - ou iPhone Web Apps –

são aplicativos que utilizam as tecnologias da Web 2.0 para oferecer uma solução

concentrada, que pareça e se comporte como uma aplicação para o iPhone. iPhone Web Apps

funcionam no navegador Safari do iPhone, este fornece recursos completos de navegação web

para o iPhone baseado em dispositivos que respondem ao toque baseado em gestos.

O conceito que deve ser de grande importância ao se trabalhar com o iPhone é o visor.

Deve ser verificado a cada página que será construída para o dispositivo móvel, desde a

remodelação web mais simples até a mais complexa (ALLEN; APPELCLINE, 2009, p. 57).

Com a dimensão da tela do iPhone sendo de 480x320 (vice-versa) dependendo da

orientação do dispositivo, o mapeamento da janela que será mostrado é muito maior, isso

porque a página pode ser rodada diretamente no Safari, fora do iPhone. O padrão da janela

virtual ou janela de exibição é de 980 pixels de largura que é então reduzida por fator de cerca

de 3 por 1 ou 2 por 1 (ALLEN; APPELCLINE, 2009, p. 58).

A Figura 2 detalha o que isso implica na janela mostrando o conteúdo não

dimensionado que podem aparecer na área ativa de cada uma das orientações do iPhone.

19

Fonte: Allen, Appelcline (2009).

Figura 2 - Áreas ativas em cada uma das orientações do iPhone

A Figura retrata as diferenças de tamanho entre o navegador Safari sendo acessado em

um ambiente desktop e em um ambiente iPhone. Por exemplo, a largura no modo retrato,

onde no ambiente desktop o tamanho será de 980 pixels, acessado pelo iPhone o tamanho será

de 320 pixels.

Segundo Allen e Appelcline (2009, p. 59), para não se prender ao tamanho que a janela

irá ocupar, pode-se proceder de duas maneiras. A primeira é que toda página web que estiver

destinada a um servidor de domínio .mobi, isto é, próprio para aparecer somente em celulares

e dispositivos móveis, ou que contenham a marcação eXtensible Hypertext Markup Language

(XHTML), utilizam por padrão uma janela de exibição com 320 pixels. A segunda maneira

seria alterar a página, colocando em seu cabeçalho o valor da largura que será adotada,

conforme exemplo no Quadro 1.

<meta name = "viewport" content = "width =

500">

Quadro 1 - Definir a largura de uma tela para web

A definição da importância do tamanho da tela do iPhone foi definida como: “Na

verdade você deve olhar para a dimensão da tela como uma oportunidade. Num mundo de

navegadores em desktop, você não tem idéia do tamanho da janela do navegador que o

usuário pode abrir, mas no iPhone você pode controlar toda a tela exatamente.” (ALLEN;

APPELCLINE, 2009, p. 59).

Além do visor, outros dois elementos podem causar problemas ao migrar um site

comum para ser visto no iPhone: gráficos e fontes muito pequenos (ALLEN; APPELCLINE,

20

2009, p. 59).

Os gráficos são os problemas mais comuns, se forem usados para a navegação ou

descreverem qualquer outra informação crítica, provavelmente o gráfico não ficará legível se

a escala for de 3 por 1 na visualização da tela.

As fontes tendem a ser um problema, pois quando se define o tamanho no Cascading

Style Sheets (CSS) relacionando o tamanho da fonte com o tamanho da tela de apresentação,

assim como a tela do iPhone é menor que uma tela desktop, a fonte irá acompanhar esse

tamanho, fazendo então a leitura ficar ilegível em um aparelho iPhone. Mas o problema

encontrado nas fontes é de fácil resolução alterando o arquivo CSS da página web, para ficar

própria para o dispositivo móvel.

Para modelar a página no iPhone e solucionar problemas de tamanho e zoom na tela, o

dispositivo reconhece um total de seis propriedades, que visam auxiliar o desenvolvedor na

minimização de problemas dentre a diferença de uma página para desktop e uma página

voltada para o dispositivo móvel. Na Figura 3, podemos observar as propriedades e suas

funcionalidades (ALLEN; APPELCLINE, 2009, p. 60).

Property Default Minimum Maximum Constants

height Calculated 223 10,000 device-height, device-width

width 980 200 10,000 device-height, device-width

initial-scale 1.0 minimum-scale maximum-scale

minimum-scale .25 >0 10.0

maximum-scale 1.6 >0 10.0

user-scalable Yes N/A N/A yes, no Fonte: Allen, Appelcline (2009).

Figura 3 - Propriedades para ajustes de tamanho da tela e zoom em uma página para iPhone

Analisando a Figura 3, na primeira coluna tem-se o nome da propriedade. A segunda

coluna mostra o valor inicialmente atribuído para a propriedade, sendo que se este valor não

for mudado na programação da página, a propriedade assumirá este valor. Na terceira e quarta

coluna são informados os valores mínimos e máximos possíveis para a propriedade

respectivamente. Na quinta coluna são constantes que podem ser usadas na programação para

atribuir valores para as propriedades.

Sobre as propriedades identificadas na figura, height e width referem-se à altura e

21

largura respectivamente da página a ser apresentada no iPhone.

As outras quatro propriedades referem-se ao zoom adotado no iPhone. Initial-scale

valor inicial do zoom ao abrir a tela. O valor inicial é 1, que significa que a tela esta sem

zoom adotado. Caso o valor seja mudado para menos que 1, os dados serão ampliados,

focando a tela para a esquerda e mostrando parte da tela no iPhone, caso o valor seja maior

que 1, os dados da tela aparecerão de forma minimizada. User-scalable valor condicional

que define a possibilidade da página ter ou não zoom conforme o usuário faz um pinch1 na

tela do iPhone. As propriedades minimum-scale e maximum-scale definem o mínimo e o

máximo de zoom que o usuário poderá fazer na tela do iPhone fazendo pinch (ALLEN;

APPELCLINE, 2009, p. 60).

Outro problema que pode ser encontrado ao se criar iPhone Web Apps são os plugins

não suportados e os eventos JavaScript que não estão habilitados para o dispositivo (ALLEN;

APPELCLINE, 2009, p. 61). Dentre os plugins não suportados no iPhone, pode-se citar: Flash

e o Java.

Para os eventos JavaScript que não funcionam perfeitamente, ou de maneira esperada

no iPhone, podemos citar: onkeydown, onkeypress, onsubmit, onselect, ondblclick,

entre outros. Também se deve lembrar que no iPhone não utiliza-se mouse e sim os dedos,

mas o evento das mãos não são interpretados como o mouse em um computador desktop, com

isso os eventos por exemplo hover em CSS, específicos para o mouse, não funcionarão no

iPhone (ALLEN; APPELCLINE, 2009, p. 62).

Ainda relatando sobre a diferença entre a ação do usuário a partir de toque com o dedo

ou com o mouse, esse ponto é muito importante ser lembrado na criação de links e de botões

para iPhone nas Web Apps. Visto que o ponteiro do mouse aponta somente para um pixel e o

toque dos dedos abrangem vários pixels na tela, terá melhor uso e melhor resultado se os links

criados tiverem um razoável espaço entre eles, para não ocorrer do usuário querer selecionar

um link, mas acabar clicando em outro (ALLEN; APPELCLINE, 2009, p. 64).

Como boas práticas em como criar um bom CSS para o iPhone, podemos citar as

seguintes sugestões, segundo (ALLEN; APPELCLINE, 2009, p. 64 e 65):

a) não utilizar a propriedade position: absolute mas sim position: relative;

b) para tamanhos de fontes utilizar valores em percentuais, como exemplo 80% ou

120% e não valores fixos como 10pt ou 12px;

c) verificar a utilização da propriedade position. O valor absolute funcionará na

1 Pinch - consiste no ato de tocar a tela em dois pontos e aproximá-los (APPLE, 2008).

22

página web, porém irá forçar esta página a usar o tamanho padrão do Safari (980

pixels). Também o posicionamento configurado para o iPhone tem suas

peculiaridades que devem ser verificadas para cada página criada. Além de no

iPhone o posicionamento do tipo fixed não está habilitado para uso;

d) com o iPhone tendo uma série de tipos de fontes habilitadas para uso, recomenda-se

utilizar alguma fonte sugerida na Figura 4.

Fontes no iPhone Exemplo de uso

AmericanTypewriter

Arial

Arial Rounded MT Bold Courier New Includes Courier

Georgia Helvetica Includes Helvetica Neue Marker Felt Times New Roman Includes Times Trebuchet MS Verdana

Zapfino (Zapfino)

Fonte: Allen, Appelcline (2009). Figura 4 - Tipos de fontes recomendadas para uso em iPhone Web Apps

2.6 FERRAMENTAS

Abaixo se encontram algumas possíveis ferramentas para se trabalhar na criação de

aplicativos WEB para iPhone.

2.6.1 Xcode

O Xcode é um conjunto de ferramentas disponibilizadas pela Apple para ajudar

desenvolvedores a criar aplicações para ambientes Mac e iPhone. Está na versão 3.2.2 e as

23

principais ferramentas disponibilizadas no conjunto são: Xcode Integrated Development

Environment (IDE), Interface Builder, iPhone Simulator (DEVELOPER APPLE , 2010c).

O Xcode IDE contém uma interface para ajudar o usuário a criar e gerenciar seus

projetos. Faz a integração entre a interface e o código fonte, fazendo possível o usuário

visualizar os dois ambientes ao mesmo tempo. Compila o código em etapas e permite depurar

a execução do código (DEVELOPER APPLE , 2010c).

Com a ajuda do Software Development Kit (SDK) do Iphone, o Xcode permite conectar

no dispositivo em tempo real, controlando os pontos de interrupção como o aplicativo é

controlado no aparelho. Com isso é possível simular e testar com fidelidade o aplicativo onde

ele realmente irá rodar (DEVELOPER APPLE , 2010c).

Na Figura 5 é apresentada a interface do programa Xcode IDE.

Figura 5 - Interface do programa Xcode IDE

2.6.2 Interface Builder

Interface Builder é um editor gráfico desenvolvido pela Apple, cujo objetivo é facilitar

a criação, edição e o design de componentes de interfaces para aplicações do OS Mac e do OS

iPhone (DEVELOPER APPLE , 2010c).

24

Segundo Developer Apple (2010e) “Usando o ambiente gráfico de Interface Builder,

você monta janelas, visões, controles, menus e outros elementos de uma biblioteca de objetos

configuráveis. Você pode organizar estes itens, definir seus atributos e estabelecer conexões

entre eles”.

Na Figura 6, pode-se verificar a interface do programa Interface Builder.

Figura 6 - Interface do programa Interface Builder Ao salvar o documento no Interface Builder deve-se usar a extensão XML Xib, que

são destinados somente durante o desenvolvimento do projeto. Durante a implantação da

aplicação os arquivo Xibs são convertidos para NIBs, que contém a versão binária dos dados

do documento o que faz com que o aplicativo seja carregado em tempo de execução

(DEVELOPER APPLE , 2010d).

2.6.3 iPhone Simulator

O ambiente de simulação iPhone permite construir e executar o aplicativo do iPhone

no computador. De acordo com Developer Apple (2010f) a ferramenta é utilizada para:

a) encontrar e resolver os principais problemas da aplicação durante o inicio do

projeto e testes;

25

b) conhecer mais sobre o desenvolvimento da ferramenta Xcode e o ambiente de

desenvolvimento para iPhone antes de se tornar um membro o iPhone Developer

Program;

c) executar testes de funcionalidades e layout do aplicativo;

d) medir a utilização de memória do aplicativo no iPhone.

Na Figura 7, pode-se ver a interface de apresentação do iPhone Simulator.

Figura 7 - Interface do programa iPhone Simulator Segundo Developer Apple (2010g) o iPhone Simulator permite simular a maioria das

ações que o usuário pode executar em seu dispositivo. Algumas das ações disponibilizadas

pelo simulador:

a) rodar para esquerda;

b) rodar para a direita;

c) início: retorna a tela inicial do dispositivo;

d) lock: bloquear simulador;

e) simular aviso de pouca memória;

f) alterna a barra de status entre seu estado normal e seu estado de chamada.

Segundo Developer Apple (2010g) a ferramenta também permite a escolha da versão

26

do iPhone que será simulada.

2.6.4 Dashcode

Dashcode é uma ferramenta desenvolvida pela Apple que já está em sua versão 3.0.1.

Permite criar aplicativos do tipo widgets e Web, este último focando para ambiente Safari,

iPhone ou ambos (DEVELOPER APPLE, 2010b).

Para a criação dos widgets, isto é, aplicações leves que executam uma única tarefa, e

dos aplicativos Web, o Dashcode suporta arquivos de código do tipo HyperText Markup

Language (HTML), Cascading Style Sheets (CSS) e JavaScript (DEVELOPER APPLE,

2010a).

Na Figura 8, pode-se ver a interface do programa Dashcode.

Figura 8 - Interface do programa Dashcode Segundo Developer Apple (2010b) por padrão ao selecionar a criação de aplicações

Web, o Dashcode cria um projeto único, que produz dois produtos, um funcionará para o

Safari desktop e o outro para o iPhone. Isso permite usar os mesmos dados e grande parte do

código, mas com o desenho de uma interface de usuário diferente para cada produto.

27

2.7 IPHONE HUMAN INTERFACE GUIDELINES

Nesta seção serão listadas as variedades de tipos de aplicações e conteúdo web que

pode-se desenvolver para o iPhone, assim como a utilização de estilos conforme princípio

homem-interface para o dispositivo móvel. Também serão mostrados como se pode projetar

uma interface para um usuário superlativo, um usuário que possui vasta experiência no

aplicativo a ser criado (APPLE, 2010, p. 11).

2.7.1 Recomendações Gerais aos Desenvolvedores

Segundo Apple (2010, p. 16) o tamanho reduzido do iPhone é uma vantagem para o

dispositivo em relação a sua mobilidade, mas nem sempre é fácil para os desenvolvedores

conseguirem que as aplicações tenham uma interface amigável com os usuários. Deve-se

sempre pensar como motivar o usuário a focar na interface que esta sendo projetada, por isso

a tela deve haver somente as funções necessárias. Em um aplicativo para iPhone não há

espaço para incluir elementos que não são necessários para a aplicação e mesmo que houvesse

espaço, estaria abrindo a oportunidade de seu aplicativo ser difícil de entender e

desinteressante.

Aos desenvolvedores de aplicativos para o iPhone a memória é um recurso crítico que

se deve ter muito cuidado em seu uso. O gerenciamento desta memória é crucial, isto ocorre

porque o iPhone não inclui em sua memória virtual o espaço em disco. O aplicativo deve

sempre garantir que não haja vazamento de memória e evitar "alocar" mais recurso que o

disponível pelo dispositivo. Quando as condições de pouca memória ocorrem o iPhone avisa

o aplicativo em execução, e caso o aplicativo não tome as devidas providências o sistema

operacional do iPhone pode terminar a aplicação (APPLE, 2010, p.16).

Outra grande diferença entre uma aplicação em desktop e uma aplicação executada no

iPhone é o "paradigma de janelas". No dispositivo móvel, a não ser em casos de tela modal, o

usuário verá sempre apenas uma janela da aplicação de cada vez. O aplicativo pode ter

diferentes telas (janelas), mas o usuário do iPhone somente poderá vê-las seqüêncialmente e

não simultaneamente (APPLE, 2010, p.16).

Até a versão 3.1.3 do Mac OS do iPhone não era permitido multi-tarefas, ou seja, uma

atividade era executada de cada vez. Isto é, se o usuário está em um determinado aplicativo e

28

passa a usar o telefone, o aplicativo será finalizado. Já com a nova versão, o Mac OS 4, o

desenvolvedor pode ter acesso a sete serviços de multi-tarefas, permitindo que tarefas sejam

executadas em background (LATAM, 2010).

Mas mesmo assim é recomendável que ao criar uma aplicação para o iPhone, o

desenvolvedor não deve contar com a ação do usuário de clicar em Sair para finalizar o

aplicativo. Desta forma, o sistema deve sempre estar preparado para salvar as informações

obtidas pelo usuário o mais rápido possível, assim salvando o estado atual da aplicação no

mais alto nível de detalhe. Por exemplo, se o aplicativo tiver uma barra de rolagem, ao

finalizar a aplicação recomenda-se salvar a posição da rolagem atual (APPLE, 2010, p. 16).

Outro ponto que deve ser verificado numa aplicação para dispositivo móvel é a

questão da utilização de tela de ajuda no sistema. Os usuários móveis não têm tempo para ler

um monte de conteúdo explicativo antes que eles possam utilizar o aplicativo. Além disso,

não há espaço suficiente para mostrar de forma clara e com todos os itens suficiente de ajudas

que garantam o ensinamento do uso do aplicativo. Com isso a concepção dos aplicativos para

o iPhone são baseados em facilidades de uso e funções óbvias (APPLE, 2010, p. 17). Para

tentar atingir estes objetivos existem algumas ações que devem ser seguidas:

a) sempre que possível, usar comportamentos que os usuários já estão familiarizados;

b) certificar que caminhos e informações são lógicos e fáceis de serem entendidos

pelo usuário.

Também é importante identificar em qual grupo o aplicativo a ser desenvolvido se

enquadra. De uma forma geral, no iPhone os aplicativos são classificados em três tipos:

produtividade, utilitários e imersivos.

As aplicações de produtividade permitem tarefas que são baseadas na organização e

manipulação de informações mais detalhadas. Geralmente são utilizados para realizar tarefas

mais importantes. Por exemplo, uma aplicação que permite visualizar e-mail (Figura 9a) é um

bom exemplo de uma aplicação de produtividade. A seriedade de propósito na aplicação não

significa que as aplicações de produtividade devem ter uma interface simples e fornecer os

dados de forma "seca". Mas sempre as aplicações de produtividade devem tentar manter o

usuário concentrado na tarefa atual, de forma que as pessoas possam rapidamente encontrar o

que precisam (APPLE, 2010, p. 20).

Já um aplicativo utilitário executa uma tarefa simples, que requer um mínimo de

entrada do usuário. Utiliza-se uma aplicação utilitária para ver resumo de informações ou

executar uma tarefa muito simples. O aplicativo que mostra a previsão do tempo (Figura 9b) é

considerado um aplicativo utilitário. São visualmente atraentes mas sem perder o foco na

29

demonstração da informação (APPLE, 2010, p. 20).

E por fim, os aplicativos do tipo imersivos oferecem uma tela cheia, um ambiente

visualmente rico, focados para os usuários que já tem experiência no conteúdo. Um jogo é

classificado como uma aplicação imersiva (Figura 9c)(APPLE, 2010, p. 23).

Figura 9 - Aplicações: (a) produtividade - Mail, (b) utilitário - Weather e (c) imersivo - NexHockey

Mas independente da sua classificação, como em qualquer outro aplicativo, as

interfaces para o iPhone devem ser ricas e ter princípios determinados e fundamentais. Uma

interface desinteressante, complicada ou sem lógica pode tornar de um aplicativo simples algo

difícil de ser usado. Não se deve subestimar o poderoso efeito que a interface tem sobre os

usuários. Uma interface bem definida enriquece muito o aplicativo e inspira um apego

emocional positivo nos usuários, ganhando a sua lealdade (APPLE, 2010, p. 30).

Para enriquecer a tela de um aplicativo e ajudar os usuários iniciantes a se

familiarizarem com as funções, deve-se sempre levar em conta o uso das metáforas. Isso faz

com que o mundo real esteja presente nos aplicativos, por exemplo, as pastas são uma

metáfora clássica nos softwares. O que no mundo real as pessoas organizam seus papéis e

documentos em pastas, facilmente entendem que no computador pode-se organizar seus dados

em pastas (APPLE, 2010, p. 31).

Segundo Apple (2010, p. 32) outro aspecto a ser sempre considerado é que um

aplicativo deve conter sempre retorno imediato ao usuário depois que for tomada uma ação

pelo mesmo. A aplicação deve responder com algumas alterações visíveis, por exemplo, ao

selecionar uma linha em uma tabela, a linha selecionada pode ficar de cor diferenciada das

demais linhas. Também pode ser utilizado um retorno de áudio, mas não pode ser um retorno

único, pois os usuários podem estar em lugares onde não é possível barulho, e então, não irão

identificar o retorno do aplicativo. Também é esperado que um aplicativo no iPhone não deve

demorar para ser iniciado permitindo que os usuários comecem a utilizar sem demora.

Ainda segundo Apple (2010, p. 45) ao iniciar, a aplicação deve:

a) especificar o estilo de barra de status adequado;

30

b) exibir uma imagem que se assemelha a primeira página do aplicativo. Isso

diminui o tempo de percepção do carregamento da aplicação;

c) evite exibir uma janela sobre a aplicação, dificultando o usuário a utilizar a

aplicação de imediato;

d) por padrão utilize o dispositivo na posição Retrato;

e) o aplicativo deve ser carregado no mesmo estado que foi finalizado pela última

vez, lembrando que o iPhone executa uma atividade de cada vez (até a versão

3.1.3), conforme já descrito anteriormente.

Após o aplicativo ter iniciado recomenda-se exibir somente as possibilidades de

configurações que são necessárias. Cuidando para que as configurações que tem menos

chances de sofrer modificações devem ficar em um lugar fácil de localizar mas não

necessitam estar na página principal do aplicativo. Já as configurações que possuem maior

tendência a modificações, devem estar bem visíveis na tela do aplicativo (APPLE, 2010, p.

46).

Outra particularidade do iPhone é que o mesmo pode ser visto com a orientação em

modo de paisagem ou retrato. O usuário ao girar o dispositivo deseja que o aplicativo

responda adequadamente conforme a posição atual do aparelho. Para saber a orientação atual

do aparelho, o aplicativo deve conhecer as propriedades do acelerômetro no dispositivo. Não

é recomendado criar um botão ou teclas de atalho para que o usuário gire a orientação do

aplicativo. Para os aplicativos que devem ser vistos somente com uma orientação, deve-se

mostrar o aplicativo na orientação correta, independente da orientação que se encontra o

dispositivo no momento atual que foi iniciado o aplicativo. Isso irá forçar o usuário a girar

fisicamente o aparelho, para então ver o aplicativo de maneira correta (APPLE, 2010, p 46).

Para facilitar a utilização da mesma aparência e funcionalidades dos elementos nos

aplicativos do iPhone, recomenda-se utilizar o Framework UIKit (APPLE, 2010, p. 53).

Alguns pontos positivos na escolha de UIKit para o desenvolvimento no iPhone são:

a) os usuários já estão acostumados com a aparência e comportamentos dos

elementos. Isso faz com que seja mais fácil para o usuário a adaptação e o

conhecimento sobre o aplicativo;

b) se a aparência e os comportamento do UIKit for modificada, terá pouco ou nenhum

retrabalho na ferramenta, para a adaptação.

Além da utilização do Framework UIKit deve-se também ser considerado outros

aspectos relacionados com a aplicação, como: o ícone, opções de seleção, divisão da tela,

barra de status, barra de navegação, barra de ferramentas, barra de abas, mensagens de

31

atenção ao usuário e a utilização dos botões.

2.7.2 Ícones

Um ícone do aplicativo é uma imagem que fica na tela de entrada (Home) do iPhone,

quando o aplicativo tem um atalho na tela principal do aparelho. O aplicativo fica como um

botão, um atalho, e toda vez que é clicado a aplicação inicia (APPLE, 2010, p. 107). Devido a

sua importância o ícone deve ser:

a) atraente, para que os usuários o queiram manter em sua tela principal;

b) distintivo, para que os usuários possam facilmente encontrá-lo entre os outros

ícones.

Ao adicionar o ícone na área de trabalho do iPhone, o dispositivo já adiciona efeitos

próprios da estética do dispositivo, tais como:

a) cantos arredondados;

b) sombra;

c) brilho reflexivo (propriedade para criar um brilho sobre uma imagem).

Para garantir que o ícone ficará de forma clara e funcional na área de trabalho do

iPhone, recomenda-se algumas características na imagem como ter o formato PNG, medir 57

x 57 pixels e não possuir brilho.

2.7.3 Opções de Seleção

No iPhone as opções de seleção são diferentes do que em uma aplicação desktop, por

isso, opções como radio buttons e menus não são recomendados para uso. Recomenda-se

utilizar os padrões já conhecidos por um usuário de iPhone e não tentar reinventar formas de

controle ou aparência para as opções do aplicativo. O iPhone oferece três tipos de elementos

recomendados para demonstrar as opções ao usuário, no caso as Listas, Pickers e Switch

Controls (APPLE, 2010, p. 48). Na Figura 10 tem-se um exemplo dos três tipos.

32

Fonte: Apple Inc. (2008). Figura 10 - Opções para seleção em aplicativos do iPhone

As opções chamadas Listas, assim como o nome sugere, apresentam ao usuário uma

lista de opções, na qual se usa uma barra de rolagem caso tenha uma grande quantidade de

opções. O usuário deve clicar em uma linha para selecionar a opção desejada. São adequadas

para mostrar qualquer número de opções ou escolhas do usuário.

Outra opção de seleção são os Pickers que apresentam as opções ao usuário como se

fosse uma roda, quando existem mais opções a serem mostradas na página, o usuário gira a

roda e essas opções então, são mostradas na tela. É recomendada para quando se deve fazer

uma seleção de data ou tempo. Segundo Apple (2010, p. 92) um picker não é recomendado

quando existe uma quantidade muito grade de opções. Isso porque a barra de rolagem ficará

muito grande e achar a opção desejada pode se tornar uma ação lenta. Nessas situações

recomenda-se usar uma lista (opção Lista). Um picker também não é muito adequado para

itens que o usuário desconhece totalmente. Isso porque ele vai ter que rolar toda a barra e

percorrer todos os itens para então descobrir a opção. No caso da seleção de mês, o usuário já

sabe que os valores possíveis compreendem 1 até 12, o que torna a utilização de picker

adequada.

Já a opção Switch Controls para escolha de uma opção que deva ter como resposta

um valor binário, ligado ou desligado, verdadeiro ou falso. Sempre apresenta dois botões ao

usuário para cada uma das opções possíveis.

É importante lembrar que ao mostrar elementos pré-definidos onde o usuário deve

apenas escolher a opção desejada, minimiza as chances de erros nas informações dadas pelo

usuário, o controle de verificação de campos é menor, além de diminuir o uso do teclado do

dispositivo, que pode tornar a aplicação difícil de usar e nada prática (APPLE, 2010, p. 32).

33

2.7.4 Divisões da tela

No iPhone se tem o espaço principal, que ocupa a maior parte da tela e fica

centralizado. Além dele, o iPhone possuem quatro principais áreas, que se utilizadas, devem

exercer funções já determinadas e conhecidas pelos usuários do iPhone (APPLE, 2010, p. 52).

Estas áreas são:

a) Barra de Status: fica no topo da tela do iPhone. Esta é uma área que

tecnicamente não faz parte da janela do aplicativo, apesar de um aplicativo poder

personalizar a aparência desta barra;

b) Barra de Navegação: localizada abaixo da Barra de Status e pode incluir

títulos, botões e controles segmentados. É uma barra opcional para os aplicativos

do iPhone;

c) Barra de Abas: localiza-se no canto inferior da tela do iPhone. Também é uma

barra opcional para os aplicativos e contém segmentos que ativam diferentes

modos da aplicação;

d) Barra de Ferramentas: assim como a Barra de Abas, localiza-se no canto

inferior da tela e também é opcional. A diferença é que na Barra de

Ferramentas são executadas ações no aplicativo atual e na Barra de Abas

mudanças na visualização do aplicativo.

Na Figura 11, pode-se ver sendo utilizados numa aplicação para o iPhone além da

parte principal do aplicativo, três outras divisões da tela. Note que se fosse utilizado a Barra

de Ferramentas ela estaria no lugar da Barra de Abas. Mais detalhes destas barras serão

descritos a seguir.

34

Fonte: Apple Inc. (2008).

Figura 11 – Divisões da tela do iPhone

2.7.4.1 Barra de Status

Segundo Apple (2010, p. 55) a Barra de Status apresenta dentre outras coisas a

situação da bateria no aparelho, sinal de WiFi e relógio. Ela está sempre presente na tela do

iPhone, porém o desenvolvedor de um aplicativo pode optar por esconder a barra em seu

aplicativo. Essa opção não é recomendada já que as informações da barra são fundamentais

para o aparelho. Em certas e raras situações, esconder a Barra de Status é aceitável. Um

exemplo seria quando se deve apresentar uma imagem ou foto em tela cheia. Contudo a

aplicação deve esconder a barra somente quando o usuário demorar alguns segundos para

mexer no aparelho, quando o usuário voltar a interagir com o aplicativo, a barra deve voltar.

Apesar de ter pouco controle sobre o conteúdo da Barra de Status, você pode

personalizar sua aparência e, em certa medida, o seu comportamento. Especificamente, você

pode:

a) definir se o indicador de atividade de rede deve estar visível;

b) especifique a cor da barra de status. Você pode escolher cinza (a cor padrão), preto

35

opaco ou translúcido (alfa de 0,5);

c) definir se a mudança da cor atual da Barra de Status para a nova cor deve ser

feita de forma animada, modificando a cor da barra suavemente.

2.7.4.2 Barra de Navegação

Já a Barra de Navegação é geralmente útil para as aplicações de produtividade que

devem organizar o conteúdo em forma de hierarquia (APPLE, 2010, p.56). Neste caso esta

barra assume duas finalidades:

a) permitir a navegação entre as diferentes telas de um aplicativo;

b) fornecer os controles que administram os itens em uma exibição.

Caso sua aplicação não seja do tipo hierárquico, esta barra pode servir para inserir um

botão de ação, por exemplo, para editar os dados do aplicativo.

Quando a aplicação está na tela inicial, esta barra normalmente possui somente o nome

da tela. Ao entrar em um novo nível de hierarquia do aplicativo, a barra mostrará um botão

para o retorno a última página e o nome da página atual.

Embora você possa especificar uma fonte para todo o texto exibido em uma Barra de

navegação, é recomendável que você utilizar a fonte de máxima legibilidade. Quando você

utiliza o plugin UIKit a fonte do sistema é usado automaticamente para exibir o título.

2.7.4.3 Barra de Abas

Segundo Apple (2010, p. 60) se o aplicativo fornecer perspectivas diferentes sobre o

mesmo conjunto de dados, ou subtarefas diferentes relacionadas para a função global do

aplicativo, pode-se usar uma Barra de Abas.

Por exemplo, a aplicação Relógio usa uma Barra de Abas para permitir o usuário o

acesso às quatro funções desta aplicação: World Clock, Alarm, Stopwatch e Timer

(Figura 12). Deve ser observado que a Barra de Abas permanece visível nas quatro funções

do relógio, isto faz com que seja fácil para o usuário ver o modo que está e as outras opções

que ele pode escolher.

36

Fonte: Apple Inc. (2008). Figura 12 - Barra de abas de uma aplicação que contém várias opções para se mostrar um relógio

A Barra de Ferramentas serve para fornecer uma série de ações que o usuário

poderá fazer sobre o objeto que está sendo mostrado na tela do dispositivo. Vale lembrar que

não se trata de mudar a forma de apresentação da tela, pois neste caso utiliza-se a Barra de

Abas, mas sim executar alguma ação sobre o contexto atual da tela. A Barra de

Ferramentas aparece no canto inferior da tela e contém botões que executam ações

relacionadas aos objetos na visão atual (APPLE, 2010, p. 58).

Por exemplo, conforme Figura 13 quando o usuário visualizar uma mensagem no e-

mail, o aplicativo fornece uma Barra de Ferramentas que contém as opções para apagar,

responder, e mover a mensagem, além de verificar se há novos e-mails e compor uma nova

mensagem. Desta forma, o usuário pode permanecer dentro do contexto da visualização da

mensagem e ainda ter acesso aos comandos de que necessitam para administrar seus e-mails.

37

Fonte: Apple Inc. (2008). Figura 13 – Barra de ferramentas num aplicativo de e-mail

A Barra de Ferramentas exibe os itens de opções igualmente espaçados em toda a

largura da tela. Recomenda-se restringir o número de itens exibidos nesta barra, para que o

usuário possa facilmente selecionar a opção desejada. Deve-se lembrar que o tamanho de um

elemento de interface com o usuário é recomendado para ser de 44 x 44 pixels, então no

máximo deve-se ter cinco Barra de Ferramentas (APPLE, 2010, p. 59).

2.7.5 Mensagens de Atenção ao Usuário

Segundo Apple (2010, p. 63), no iPhone os alertas, fichas de ações e visões

modais (Figura 14) são formas de enviar uma mensagem ou sinalizar alguma tomada de ação

importante para o usuário. Estas mensagens de atenção são usadas quando algo exige a

atenção do usuário, ou quando as escolhas ou funcionalidades adicionais precisam ser

oferecidas. Todas as mensagens são modais, isto é, exigem uma resposta imediata do usuário

para que então o aplicativo continue sendo executado. Por este motivo, se deve tomar cuidado

ao utilizar os recursos, pois o seu uso em excesso pode tornar a aplicação irritante o usuário.

38

Fonte: Apple Inc. (2008). Figura 14 – Mensagens: alertas, fichas de ações e visões modais

Para os alertas o cuidado deve ser grande, pois o uso em excesso faz com que os

usuários confirmem as mensagens sem ler, apenas para tirar do caminho. Quanto mais raro o

aparecimento dos alertas, maior a seriedade que os usuários darão a eles (APPLE, 2010, p.

63).

Quanto à utilização, podemos caracterizar os alertas como mensagens normalmente

inesperadas, porque geralmente informam os usuários sobre um problema ou uma mudança

da situação do aplicativo que poderá exigir uma medida ao usuário. As fichas de ações dão

aos usuários opções de ações que devem ser tomadas, por exemplo, a exclusão de arquivo,

deve ter a confirmação do usuário. Visões modais fornecem funcionalidades para o contexto

da tarefa atual, por exemplo, o teclado do iPhone aparece quando o usuário precisa digitar

informações em um campo textual da tela (APPLE, 2010, p. 64).

Segundo Apple (2010, p. 65) não se recomenda o uso de alertas quando:

a) mostra o processo de uma ação que está ocorrendo normalmente, ao invés, deve ser

usado uma visão de progresso ou um indicador de atividade para proporcionar ao

usuário o andamento do progresso;

b) confirma ações tomadas para o usuário, por exemplo, exclusão de um arquivo, para

este tipo de caso recomenda-se utilizar as fichas de ações;

c) mostra problemas ou erros nos quais o usuário não possa fazer nada. Se o problema

for muito crítico, sugere-se que seja apresentado na própria interface do sistema,

39

um exemplo é se a aplicação depender de um servidor e ele falhar. Neste caso

deve-se inserir no aplicativo o indicador de falha com o servidor.

Segundo Apple (2010, p. 65) as fichas de ações não necessitam conter uma

mensagem explicativa, pois os nomes dos botões devem ser claros para a sua funcionalidade,

para que quando o usuário queira executar uma ação e a ficha de ação apareça, ele saiba a

função de cada botão.

2.7.6 Utilização dos Botões

Conforme anteriormente relatado, é sempre bom usar os padrões já utilizados no

iPhone, para facilitar o entendimento das ações dos usuários e o familiarizar com todos os

aplicativos para o dispositivo. A seguir serão mostrados os padrões utilizados, para cada área

ou situação específica no iPhone (APPLE, 2010, p. 103 - 106).

A Figura 15 apresenta o padrão de botões utilizados em uma Barra de Ferramentas.

Fonte: Apple Inc. (2008). Figura 15 - Padrões de ícones utilizados na Barra de Ferramentas

Na Figura 16, são apresentados os padrões de botões utilizados nas Barras de

40

Navegação, apesar não utilizar imagens, já tem um sentido e características próprias, que

devem ser respeitadas em sua utilização.

Fonte: Apple Inc. (2008). Figura 16 - Padrão de botões utilizados em Barras de Navegação

Na Figura 17, apresenta os botões padrões para a Barra de Abas.

Fonte: Apple Inc. (2008). Figura 17 – Padrão de botões utilizados em Barras de Abas

Por fim, na Figura 18, são apresentados os padrões de botões utilizados nas linhas das

tabelas de um aplicativo para o iPhone.

41

Fonte: Apple Inc. (2008). Figura 18 – Padrão de botões utilizados em linhas dos elementos de uma tabela

2.8 TRABALHOS CORRELATOS

Aplicações destinadas a apresentar informações para a interface iPhone como os

aplicativos iWebKit e Jqtouch e aplicação que utiliza Web Services para gravar e recuperar

dados, serão listados a seguir como trabalhos correlatos ao trabalho desenvolvido.

2.8.1 Sistema utilizando Web Services

O trabalho “Sincronização de dados em dispositivos móveis utilizando Web Services”

feito por Souza (2006) relata a solução para uma empresa que cuida de uma fazenda de

criação de animais ovíparos. A empresa possuía dificuldades em controlar e sincronizar os

dados da produção de ovos e também a quantidade de trabalho de seus funcionários.

O trabalho tinha como objetivo demonstrar, através de implementação, a possibilidade

de integração entre dispositivos móveis com diversos outros sistemas através da utilização de

Web Services.

Na solução deste trabalho foi utilizado como Hardware o aparelho Palm One Zire 21,

que é onde fica instalada a aplicação criada. Esta aplicação faz a sincronização com um

computador que serve como o servidor de dados, onde são guardados os dados de todos os

colaboradores e todas as informações referentes à fazenda.

Cada colaborador recebe o Palm, com o respectivo sistema, e é nele que o colaborador

42

irá registrar os horários de entrada e saída de turno, que seriam as horas trabalhadas por ele, e

também faz os cadastros dos ovos que foram contabilizados. A vantagem do sistema é que o

colaborador não precisa deslocar-se até a matriz da fazenda para poder fazer a marcação do

ponto e também não utiliza papel para contabilizar os ovos, o que pode ocorrer muitos erros.

A estrutura do sistema é apresentada na Figura 19.

Fonte: Souza (2006). Figura 19 – Estrutura de um sistema utilizando Web Services

Na Figura 19 pode-se entender como Usuário, o colaborador que irá informar os

dados em um dispositivo móvel. Palm seria o dispositivo móvel que terá o aplicativo de

marcação de ponto do colaborador e de cadastros de ovos. Sistema Externo seria o servidor

que contém todos os dados referentes a fazenda e que irá prover os dados ao aplicativo

disponibilizando um Web Service.

2.8.2 iWebKit

O pacote iWebKit que está em sua versão 5.04, consiste em vários arquivos projetados

para ajudar a criar páginas e aplicações web para iPhone, iPod touch e iPad (IWEBKIT,

2010).

Este projeto é composto por vários exemplos de elementos e estilos utilizados em uma

aplicação para iPhone. Sua utilidade está em permitir que o usuário “copie” e “cole” estes

elementos e estilos deixando sua Web App própria para interface do iPhone.

Não há um arquivo executável onde se cria uma nova aplicação já utilizando os

padrões do pacote. O pacote tem o objetivo de que o usuário escreva sua própria Web App e

combine os elementos e textos que queira que a aplicação possua. Após isso, o desenvolvedor

irá utilizar o pacote iWebKit para utilizar os estilos dos elementos, fazendo com que eles

tenham a interface compatível com o dispositivo iPhone, por exemplo.

O pacote inclui elementos como, por exemplo, listas, pickers, estilos de botões e

43

barras, campos de seleção, entre outros, descritos na seção 2.7. A Figura 20 apresenta uma das

telas do iWebKit na qual o usuário pode copiar seu estilo.

Figura 20 - Tela inicial da aplicação iWebKit

2.8.3 Jqtouch

Jqtouch é um plugin jquery para desenvolver aplicações web para aparelhos móveis.

Está na versão 1 e tem uma versão 2 em testes (JQTOUCH, 2010).

O plugin traz animações nativas de navegação automática e temas para browsers de

dispositivos móveis, como iPhone, G1 e Pre.

Assim como o iWebKit (seção 2.8.2) o pacote Jqtouch trata-se de exemplos de

utilização do plugin no qual recebe o nome. Estes exemplos, são mais focados em estilos e

44

animações, baseados em Java Script, dos elementos na tela do iPhone. Uma das telas

demonstrativas do pacote é demonstrada na Figura 21.

Figura 21 - Tela inicial da aplicação Jqtouch

45

3 DESENVOLVIMENTO

Neste capítulo são abordadas as etapas do desenvolvimento do projeto. São ilustrados

os principais requisitos, a especificação, a implementação e por fim são listados os resultados

e discussões.

3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO

Os requisitos apresentados abaixo se encontram classificados em Requisitos

Funcionais (RF) e Requisitos Não Funcionais (RNF). O sistema iAva deve:

a) garantir a segurança dos dados, verificando senha e permissões do usuário

conectado na aplicação (RF);

b) verificar qual o tipo de cliente que está acessando a aplicação, caso desktop

redirecionar a página web para a aplicação já existente do AVA, se for iPhone,

direcionar para a página de login do aplicativo (RF);

c) disponibilizar na aplicação o recurso do AVA Texto Colaborativo (RF);

a) disponibilizar na aplicação o recurso do AVA Material (RF). Deve conter a opção

para o usuário administrador da disciplina optar por deixar ou não os usuários que

não são administradores manter os itens do recursos. Os tipos de itens deste

recurso, que também são disponibilizados na aplicação, são: - pastas, - links, - arquivos do usuário;

d) disponibilizar na aplicação o recurso do AVA Fórum Temático (RF);

e) disponibilizar na aplicação o recurso do AVA Pasta (RF);

f) disponibilizar na aplicação o recurso do AVA Arquivos do usuário (RF);

g) permitir acessar o servidor de banco de dados através de Web Services, onde este

deve disponibilizar uma porta para persistência e outra para leitura dos dados da

aplicação (RF);

h) utilizar o banco de dados embarcado Derby (RNF);

i) utilizar as linguagens Java, Java Script, HTML e CSS, para desenvolver a

46

aplicação (RNF);

j) disponibilizar a aplicação de interface e os Web Services através de servidores

Tomcat (RNF);

k) utilizar ambiente de programação Eclipse (RNF).

3.2 ESPECIFICAÇÃO

A especificação do presente trabalho foi desenvolvida utilizando alguns dos diagramas

da Unified Modeling Language (UML) em conjunto com a ferramenta Enterprise Architect

5.00.766 para elaboração dos casos de uso, diagramas de classe e diagramas de seqüência.

3.2.1 Diagrama de casos de uso

O trabalho cria uma nova maneira de apresentação e estilo do portal AVA, tendo como

público os usuários que acessam a aplicação via um aparelho iPhone. Para os casos de uso e

diagramas, refere-se ao usuário administrador como um professor, que pode criar ações em

disciplinas habilitadas a ele. Os alunos são visualizadores dos recursos disponibilizados pelos

professores e só podem executar ações quando o recurso permitir.

Na Figura 22 é apresentado o diagrama de casos de uso da aplicação.

47

Figura 22 – Casos de uso da aplicação iAVA

3.2.1.1 UC01 – Login

Neste caso de uso é feito o acesso e controle da segurança do aplicativo. Como

segurança tem-se a validação do nome e senha do usuário. Como controle é feita a verificação

do ambiente pelo qual o usuário está acessando o aplicativo, somente deve apresentar a

48

aplicação iAVA caso o usuário o esteja acessando pelo dispositivo iPhone ou seu simulador

(aplicativo iPhone Simulator), caso contrário, o usuário deve visualizar o portal AVA. Isso

porque o iAVA não está preparado para ser visualizado em uma janela de um desktop, os

estilos e a forma de apresentação serão inadequadas para o browser.

No Quadro 2 é apresentado o cenário para o caso de uso UC01.

UC01 - Login: Controlar os dados e acesso ao aplicativo iAVA.

Pré-condição Não há.

Cenário

Principal

1. Usuário acessa pelo browser o endereço da internet que está disponibilizado

o aplicativo iAVA;

2. Usuário informa campo Nome;

3. Usuário informa campo Senha, sistema deve mostrar os caracteres de forma

protegida, substituindo as letras pelo caractere '*';

4. Usuário clica no botão Entrar;

5. Sistema valida dados informados pelo usuário.

Cenário

Alternativo

1. No passo 1 do cenário principal, se o usuário estiver acessando de um

browser que não seja do iPhone, o sistema irá redirecionar a página, para o

portal do AVA.

2. No passo 5 do cenário principal, caso os dados do usuário não sejam

validados, o sistema deverá mostrar a mensagem 'Usuario ou senha incorretas!

Tente novamente'. Voltar ao passo 2 do cenário principal.

Pós-condição Usuário logado no aplicativo iAVA.

Quadro 2 – Caso de uso UC01

3.2.1.2 UC02 – Manter Arquivo

A definição de como os usuários poderão inserir arquivos no iAVA é listado neste caso

de uso. Os arquivos serão obtidos através da rede e serão copiados para o aplicativo. Isso para

que quando o usuário queira abrir um arquivo, ele verá os dados persistidos na base de dados

e não a referência do arquivo na internet.

No Quadro 3 será apresentado o cenário do caso de uso UC02.

49

UC02 - Manter Arquivo: Mantém arquivos do usuário.

Pré-condição Usuário deve estar logado no aplicativo

Cenário

Principal

1. Usuário seleciona a aba 'Área Pessoal'.

2. Usuário clica no botão '+ Meus Arquivo'.

3. Sistema irá listar todos os arquivos já cadastrados por este usuário.

4. Usuário clica no botão 'Adicionar Arquivo';

5. Usuário informa o nome do arquivo;

6. Usuário informa no campo 'Arquivo de rede' um arquivo disponibilizado na

rede/internet. Extensão aceitas para arquivo: pdf, gif, png, jpg, txt;

7. Usuário clica em Salvar;

8. Sistema copia o arquivo da rede e guarda no banco de dados;

9. Sistema mostra ao usuário a lista de todos os arquivos cadastrados por ele.

Cenário

Alternativo

1. No item 4 do cenário principal, o usuário poderá clicar no botão 'Editar'

arquivo, que irá abrir a tela com os detalhes do arquivo.

2. Vai para o passo 5, do cenário principal.

Cenário

Alternativo 1

1. No item 2 do cenário alternativo, o usuário poderá escolher a opção 'Excluir'.

2. Vai para o item 9 do cenário principal.

Exceção 1. No passo 6 do cenário principal, caso o usuário escolha um tipo de arquivo

não suportado pelo sistema, o mesmo lançará uma mensagem na tela

referindo-se as extensões suportadas e não concluirá a adição do arquivo.

Pós-condição Arquivos do usuário cadastrados.


3.2.1.3 UC03 – Manter Link

Caso de uso que define como o usuário poderá manter os links do recurso material. Os

links são vinculados diretamente no recurso material e o usuário Aluno, só poderá criar links

caso o recurso material habilite essa opção ao usuário.

No Quadro 4 será apresentado o cenário do caso de uso UC03.

50

UC03 - Manter Link: Mantém links vinculados a um recurso material do iAVA.

Pré-condição

Usuário deve estar logado no aplicativo;

Para o usuário poder adicionar links, ou ele deve ser um usuário administrador

da disciplina, ou, deve existir para o usuário um recurso material, habilitando o

usuário a adicionar links.

Cenário

Principal

1. Usuário deve clicar no botão '+ Link';

2. Usuário informa nome e URL do link;

3. Usuário clica no botão 'Salvar'

4. Sistema mostra ao usuário a lista de recursos vinculados ao material,

inclusive as modificações do link.

Cenário

Alternativo

1. No passo 1 do cenário principal, o usuário poderá clicar no botão 'Editar' link;

2. Volta ao passo 2 do cenário principal.

Cenário

Alternativo 1

1. No passo 2 do cenário alternativo, o usuário pode clicar no botão 'Excluir';


Pós-condição Link cadastrado, alterado ou excluído no aplicativo iAVA.


3.2.1.4 UC04 – Manter Pasta

Caso de uso que define tanto a criação de pastas diretamente a uma disciplina quanto

ao recurso material. As pastas são organizadoras de assuntos. Para associar uma pasta a uma

disciplina o usuário deve ser administrador da disciplina. Para associar uma pasta a um

recurso material o usuário ou deve ser administrador da disciplina ou o recurso material deve

estar habilitado para deixar os alunos adicionarem pastas.

O Quadro 5 apresenta o cenário do caso de uso UC04.

51

UC04 - Manter Pasta: Mantém pastas vinculadas a uma disciplina ou em um recurso

material do iAVA.

Pré-condição

Usuário deve estar logado no sistema;

Para adicionar as pastas na disciplina, somente é habilitado para os usuários

do tipo administrador;

Para o usuário poder adicionar pastas no recurso material, ou ele deve ser um

usuário administrador da disciplina, ou, deve existir para ele o recurso material

habilitando a inserção de pastas.

Cenário

Principal

1. Usuário deve clicar no botão '+ Pasta';

2. Usuário informa nome da pasta;

3. Usuário clica no botão 'Salvar'

4. Sistema mostra ao usuário a lista de recursos vinculados ao material,

inclusive as modificações da pasta.

Cenário

Alternativo

1. No passo 1 do cenário principal, o usuário poderá clicar no botão 'Editar'

pasta;


Cenário

Alternativo 1



Pós-condição Pasta cadastrada, alterada ou excluída no aplicativo iAVA.


3.2.1.5 UC05 – Manter Material

Caso de uso que define a criação do recurso material do iAVA. Este recurso assim

como no AVA, deve permitir na disciplina os professores postarem arquivo e links para

ajudarem no entendimento da disciplina. O recurso também pode dar a opção dos alunos

postarem arquivos ou trabalhos da disciplina.

O Quadro 6, apresenta o cenário do caso de uso UC05.

52

UC05 - Manter Material: Mantém recurso material associado as disciplinas no iAVA.

Pré-condição Usuário deve estar logado no aplicativo.

Usuário deve ser administrador da disciplina.

Cenário

Principal

1. Usuário deve selecionar a opção 'Editar' na disciplina;

2. Usuário deve informar o nome do novo recurso, nome completo e selecionar

o tipo material;

3. Clicar em 'Adicionar';

4. Sistema mostrará a lista de recursos disponibilizados na disciplina inclusive o

novo componente material;

5. Ao selecionar o novo material e clicar em 'Editar', o usuário poderá adicionar

uma descrição ao item e a possibilidade de deixar um aluno adicionar links,

pastas e arquivos no recurso material.

Cenário

Alternativo


material;

2. Volta ao passo 2 do cenário principal

Cenário

Alternativo 1



Pós-condição Recurso material cadastrado, alterado ou excluído no aplicativo iAVA.


3.2.1.6 UC06 – Manter Texto Colaborativo

Recurso que compartilha um mesmo texto entre professor e os alunos. Este caso de uso

refere-se a criação, alteração ou exclusão do recurso texto colaborativo.

O Quadro 7, apresenta o cenário do caso de uso UC06.

53

UC06 - Manter Texto Colaborativo: Mantém recurso texto colaborativo associado as

disciplinas no iAVA.



Cenário

Principal



o tipo texto colaborativo;



novo componente texto colaborativo.

Cenário

Alternativo

1. No passo 1 do cenário principal, o usuário poderá clicar no botão 'Editar' texto

colaborativo;


Cenário

Alternativo 1



Pós-condição Recurso texto colaborativo cadastrado, alterado ou excluído no aplicativo iAVA.


3.2.1.7 UC07 – Manter Fórum

Caso de uso que define a criação do recurso fórum no iAVA. O Quadro 8, apresenta o

cenário do caso de uso UC07.

54

UC07 - Manter Texto Colaborativo: Mantém recurso fórum associado as disciplinas

no iAVA.



Cenário

Principal



o tipo fórum;



novo componente fórum.

Cenário

Alternativo


fórum;


Cenário

Alternativo 1



Pós-condição Recurso fórum cadastrado, alterado ou excluído no aplicativo iAVA.


3.2.1.8 UC08 – Postar Fórum

Para uma disciplina que tenha vinculado o recurso do tipo fórum, o caso de uso 08

relata como os usuários podem postar contribuições. Qualquer usuário poderá contribuir no

fórum, desde que o fórum já esteja criado. Quadro 9, apresenta o cenário do caso de uso UC08.

55

UC08 - Postar Fórum: Define como os usuários podem postar contribuições em um fórum

no aplicativo iAVA.


Usuário deve ter uma disciplina que contenha o recurso fórum

Cenário

Principal

1. No recurso Fórum o usuário poderá clicar no botão 'Adicionar Tema';

2. Usuário deve informar o assunto do tema e uma descrição e clicar em

'Salvar';

3. O sistema irá listar todos os temas criados no fórum;

4. O usuário poderá selecionar um tema;

5. Usuário poderá clicar em 'Adicionar Contribuição';

6. Usuário informa o assunto e a contribuição para o tema e clicar em 'Salvar';

7. O sistema listará todas as contribuições do tema, inclusive a recém

cadastrada.

Pós-condição Tema e contribuições adicionados em um fórum do aplicativo iAVA.


3.2.1.9 UC09 – Carregar Disciplinas

Este caso de uso trata da recuperação dos dados armazenados do aplicativo. Toda vez

que o usuário acessar, o aplicativo chamará um web service que retornará os dados das

disciplinas habilitadas para o usuário. Associada a disciplina, virão os recursos criados nela,

como por exemplo pastas, materiais, textos colaborativos, entre outros.

No Quadro 10 será detalhado o cenário do caso de uso UC09.

UC09 - Carregar Disciplinas: Obtém os dados do usuário, persistidos em um banco de

dados. Pré-condição UC01 deve ter sido executado com sucesso.

Cenário

Principal

1. Sistema chama através de um Web Service, o serviço que irá retornar as

disciplinas vinculadas ao usuário logado;

2. O Web Service retorna as disciplinas habilitadas para o usuário, com seus

respectivos recursos e a verificação se o usuário é administrados da disciplina;

3. Sistema lista para usuário as disciplinas habilitadas a ele.

Pós-condição Disciplinas que são habilitadas para o usuário logado, carregadas no aplicativo

via Web Service. Quadro 10 – Caso de uso UC09

56

3.2.1.10 UC010 – Editar Texto Colaborativo

Para o recurso texto colaborativo, neste caso de uso define como um usuário contribui

e edita o texto colaborativo. O Quadro 11 apresenta o cenário do caso de uso UC10.

UC10 - Editar Texto Colaborativo: Define como os usuários podem modificar o texto

colaborativo de uma disciplina no aplicativo iAVA.


Usuário deve ter uma disciplina que contenha o recurso texto colaborativo

Cenário

Principal

1. No recurso Texto Colaborativo o usuário poderá clicar no botão 'Editar Texto';

2. Mostrará um editor de texto com o texto atual, onde o usuário poderá editar o

texto como quiser;

3. Usuário clica em 'Salvar';

4. Sistema mostra o exto colaborativo conforme a edição do usuário e adiciona

nos históricos do recurso a nova edição.

Pós-condição Edição de um texto colaborativo.


3.2.2 Diagrama de classes

A seguir serão apresentados os diagramas de classe dos principais recursos

disponibilizados no aplicativo iAVA.

3.2.2.1 Recurso Arquivos

O recurso Arquivo do aplicativo é constituído pelas classes que controlam a interface,

a classe que modela os atributos do recurso e as classes que fazem a persistência e leitura dos

objetos do banco de dados. A Figura 23 apresenta o diagrama de classe referente ao recurso de

arquivos.

57

Figura 23 – Diagrama de classe do recurso de arquivos

A classe Arquivo define os atributos do recurso do iAVA, que herda da classe

BaseDataModel o atributo codigo, presente na grande maioria das classes de modelo do

aplicativo.

A classe ArquivoManager é responsável por persistir e excluir registros de arquivos no

banco de dados, através dos métodos salvar e remove respectivamente.

As classes que são responsáveis pela interface do recurso arquivo, são as classe que

implementam a classe abstrata Command. Estas classes fazem ações específicas e chamam um

arquivo JSP passando os atributos necessários para a montagem da tela. Cada classe Command

é responsável por apenas uma tela, por exemplo, o comando para listar todos os arquivos

vinculados no usuário logado na aplicação chamará a classe CommandListarMeusArquivos.

O comando que irá remover um arquivo é o CommandDelMeusArquivos.

Nem as classes de comando e nem as classes com final Manager possuem variáveis

globais, isto é, uma variável disponível para a classe inteira. Estas classes apenas utilizam

variáveis locais, isto é, que são acessadas somente dentro de cada método. Já as classes de

modelo, por exemplo Arquivo, possuem variáveis globais, porém os métodos destas classes

são apenas métodos de acesso a estas variáveis, os métodos gets e sets.

58

3.2.2.2 Recurso Material

O recurso material, tem como objetivo disponibilizar um lugar onde professores e

alunos insiram arquivos de conteúdos diversos em uma disciplina. Pode ser somente um lugar

onde os professores coloquem arquivos para estudos dos alunos e pode ser também um

repositório de trabalhos e documentos para os alunos. A figura 24, retrata o diagrama das

classes que implementaram no iAVA o recurso material.

Figura 24 – Diagrama de classe do recurso de material

59

3.2.2.3 Recurso Link

Este recurso tem como objetivo agregar em um recurso do tipo material de uma

disciplina, um link da internet. Este link pode ser de qualquer tipo de site ou conteúdo. Para os

administradores da disciplina este recurso é sempre habilitado, e também somente os

administradores liberam o recurso de manter um link, para os alunos da disciplina.

Na Figura 25, é apresentado o diagrama de classe do recurso Link.

Figura 25 – Diagrama de classe do link

Assim como toda a implementação do projeto, as classes que estendem Command,

foram utilizadas para receber requisições e chamar JSPs, montar a interface em si.

A classe LinkManager fica com a responsabilidade de salvar e remover os objetos do

banco de dados. E a classe Link, define os atributos necessários para o recurso. Estende a

classe BaseDataModel, que é a classe base de todas as classes de modelo, na qual fica o

atributo codigo, necessário a todos os objetos implementados.

60

3.2.2.4 Recurso Texto Colaborativo

Um recurso do tipo texto colaborativo, assim como o próprio nome sugere, representa um

arquivo de texto pelo qual qualquer pessoa da disciplina, poderá alterar. Onde fica sempre apenas

uma versão final do texto, mas preserva-se um histórico das alterações. Na Figura 26, tem-se o

diagrama das classes utilizadas para montar o recurso no aplicativo.

Figura 26 – Diagrama de classe do recurso de texto colaborativo

61

As classes estendendo de Command criam e mantém a interface com o usuário, como

também gerenciam os parâmetros passados pelo usuário na tela do aplicativo. A classe

TextoColaborativoManager, é responsável em salvar e remover o recurso da base de dados,

assim como manter seus históricos persistidos no banco.

A classe TextoColaborativo, define os atributos do recurso e a classe

HistoricoTextoColaborativo define os atributos dos históricos de um texto. Um texto

colaborativo tem vários históricos, e também armazena em um atributo separado, o histórico

atual, que seria a última versão que foi modificada do texto.

3.2.2.5 Recurso Fórum

O recurso fórum, assim como vários outros fóruns disponibilizados na internet, tem

como intuito ter um assunto base e conforme as pessoas acessam, podem contribuir com o que

sabem sobre o respectivo assunto. A Figura 27 apresenta as classes utilizadas no aplicativo, para

montarem este recurso.

Figura 27 – Diagrama de classe do recurso fórum

62

Seguindo o padrão dos demais recursos, tem-se as classes estendendo Command

responsáveis pela interface no aplicativo. A classe ForumManager é responsável por manter

no banco de dados o recurso fórum, seus temas e suas contribuições. A classe

ForumTematico, contém os atributos necessário para o recurso, nele também contém a lista

de temas e em cada tema suas diversas contribuições, cada qual armazenando o usuário que

publicou o tema ou a contribuição.

3.2.3 Diagrama de seqüência

Na Figura 28, tem-se o diagrama de seqüência da aplicação. O diagrama apresenta o

processo de criação de um novo arquivo do usuário. No diagrama, pode-se ver a importância

das classes Command conforme vistas na seção 3.3.1.2.1. que cada classe tem funções

específicas e distintas umas das outras. A Interface representada no diagrama, refere-se as

classes JSP que montam a interface específica para o usuário conforme os dados apresentados

ou persistidos por ele no banco de dados.

63

Figura 28– Diagrama de seqüência para a criação de arquivos na aplicação

64

3.2.4 Diagrama de navegação

A Figura 29, apresenta a navegação, iteração entre classes JSP e as classes Java na

aplicação. A leitura deve iniciar pela imagem indicativa Início. O arquivo index.jsp faz a

verificação do ambiente que está acessando a aplicação, caso não estiver acessando via

iPhone, o sistema irá chamar o portal AVA original, senão a tela de login do aplicativo iAVA

será mostrada. Na classe iAVA-login-telaInicial.jsp, após informar os dados e clicar no

botão para acessar o aplicativo, será chamado o Servlet iAVA, este, invocará o Command

correspondente a ação que será tomada, no caso o comando para validar os dados de login

CommandLogariAVA. Após a validação de login, CommandLogariAVA invocará diretamente o

CommandAreaEstudo, que ficará responsável por obter os dados do banco de dados, dos

registros do usuário. E por fim, o CommandAreaEstudo irá chamar a tela areaEstudo.jsp que

mostrará todas as disciplinas habilitadas para o usuário.

Figura 29 – Diagrama de navegação do login do aplicativo

3.2.5 Web Service

Como explicado na seção 2.3 sobre como funciona um Web Service, nesta seção será

explicada a utilização deste componente no aplicativo iAVA. Os demais diagramas

apresentados abstraem esta parte, pois na verdade não faz parte de classes ou de métodos,

65

apenas as chamadas entre as classes, são feitas de maneiras diferentes.

A aplicação divide-se em dois lados, um com a parte da interface e o outro lado com a

parte de modelagem dos dados e acesso ao banco de dados. Na Figura 30, é exemplificada a

forma que o Web Service atua no aplicativo.

Figura 30 - Ilustração do uso de Web Service na aplicação

3.2.6 Banco de Dados

Para persistir e controlar os dados do aplicativo, foi utilizado um banco de dados. O

banco utilizado foi o Apache Derby, versão 10.5.3.0, que é um subprojeto do projeto Apache

DB, um banco de dados relacional open source, implementado em Java (DERBY, 2010).

Como vantagens ou razões por se optar por este banco tem-se:

a) Derby é baseado em Java, JDBC, padrões SQL;

b) Derby disponibiliza um driver JDBC embarcado que permite executar a aplicação

Java com o banco de dados embarcado;

c) facilidade de instalar, executar e utilizar;

d) possui documentação;

e) não precisa instalar nenhum aplicação a mais para executar o banco.

Na Figura 31 é ilustrado o Modelo, Entidade e Relacionamento (MER) do aplicativo.

66

Figura 31 - Estrutura de tabelas da aplicação (MER) Dentre as tabelas apresentadas no MER (Figura 31), tem-se as tabelas que guardam os

dados representados pelas classes modelos, como tabela Link, Pasta, Material,

HistoricoTextoColaborativo, entre outras. As tabelas ArquivoPasta,

ArquivoMaterial, AlunoDisciplina são exemplos de tabelas de associações MxM

(muitos para muitos).

Já as tabelas de associações Mx1 (muitos para 1) são criadas diferentemente da classe

modelo. Exemplo a ligação entre um texto colaborativo e seus históricos. Na classe modelo se

tem uma lista de historicos na classe TextoColaborativo. No MER podemos observar que

quem referencia o texto colaborativo são os históricos, através das tabelas

HistoricoTextoColaborativo e TextoColaborativo.

As classes de herança, são representadas pela tabela RecursoPrimario que guarda a

referencia para a tabela do objeto hierarquico e contém os atributos que são comuns entre os

objetos de sua hierarquia. Por exemplo Link, Pasta, Material onde todos eles devem

possuir um recurso pai e um usuário registrado.

67

3.3 IMPLEMENTAÇÃO

Esta seção apresenta as bibliotecas, técnicas e ferramentas utilizadas para o

desenvolvimento da Web App iAVA, junto com a descrição das principais telas e trechos de

código para um melhor entendimento.

3.3.1 Técnicas e ferramentas utilizadas

Para a criação da aplicação foram utilizadas as linguagens de programação JAVA, JSP,

Java Script e CSS. Para o desenvolvimento, foi utilizada a ferramenta Eclipse Java EE for

Web Developers na versão 3.5, ferramenta própria para os desenvolvedores de conteúdo web.

Para testes foi utilizada a aplicação iPhone Simulator descrito na seção 2.6.3 e o

próprio aparelho do iPhone com Mac OS 3.1.3. Para criação da interface e estilos foram

utilizadas as ferramentas Dashcode e Interface Builder descritos nas seções 2.6.4 e 2.6.2

respectivamente.

A seguir serão listados as técnicas da implementação do aplicativo.

3.3.1.1 Modelo, Visão e Controle

Nesta aplicação utilizou-se o padrão Modelo, Visão e Controle (MVC), demonstrado

na Figura 32 algumas classes que montam esta estrutura.

68

Figura 32 - Diagrama de classe da estrutura MVC da aplicação

3.3.1.2 Design Patterns

Para a implementação do aplicativo, foram utilizados dois padrões de Design Patterns,

o Command e o Singleton. Segundo Cooper (1998), uma classe pode encaminhar seus

pedidos a uma cadeia de outras classes, mas o comando padrão encaminha um pedido apenas

a um específico módulo. Inclui um pedido de uma ação específica dentro de um objeto e lhe

dá uma interface conhecida do público. Ele permite dar ao cliente a capacidade de fazer

pedidos sem saber nada sobre a ação real que será executada, e permite que você altere essa

ação, sem afetar o cliente. A Figura 33 apresenta a usabilidade do padrão Command na

implementação do aplicativo iAVA.

69

Figura 33 - Diagrama de classe do padrão Command utilizado na aplicação

Já o padrão Singleton, segundo Cooper (1998), é uma classe que não pode haver

mais de uma instância. Ele fornece um único ponto de acesso global a essa instância. Na

Figura 34 tem-se o padrão Singleton, aplicado na implementação do controle de dados do

iAVA.

Figura 34 - Diagrama de classe do padrão Singleton utilizado na aplicação

70

3.3.1.3 Classes de estilos

Todos os estilos utilizados na implementação, foram definidos através de classes CSS.

No Quadro 12 pode-se ver uma pequena amostra das classes CSS utilizadas. Na classe body,

que define a área central das telas do aplicativo, utiliza-se os padrões recomendados pela

Apple, vistas na seção 2.7 deste trabalho, como a propriedade position:relative. Deve-se

observar que as propriedades que iniciam com –webkit são próprias para o navegador Safari,

e por isso o aplicativo não obterá os estilos corretos se for rodado em outro navegador, assim

como o Firefox por exemplo.

Quadro 12 – Classes CSS utilizadas na implementação

3.3.1.4 Recuperação de dados via Web Service

Assim como relatado na seção 3.2.5 a parte onde armazena os dados do aplicativo, é

chamada via Web Service. Fazendo com que, de um lado fique a aplicação com o servidor de

controle das telas, e do outro fique o servidor que controla o acesso aos dados e a modelagem

das classes.

No Quadro 13, tem-se o exemplo da classe que define os métodos do Web Service. A

anotação @WebMethod define os métodos que serão disponibilizados no serviço e a anotação

@WebService na classe define que ela será a classe correspondente do Web Service.

71

Quadro 13 – Classe que define os métodos Web Services

No método autenticar, o Web Service verifica se os parâmetros login e senha

passados são compatíveis a algum usuário cadastrado no aplicativo no banco de dados. Já no

método remover, tem como parâmetro o tipo de objeto que irá ser removido e seu código no

banco de dados. O método salvar recebe uma String com o objeto que será persistido na

base de dados representado em XML.

No Quadro 14, é apresentada a classe que faz a chama do Web Service. Ela também

contém os três métodos do Web Services. Na classe é instanciado o objeto stub, objeto de

controle do caminho e porta do Web Service a ser chamado. Este atributo que contém todos

os métodos do serviço, que então são chamados de forma simples, como stub.autenticar

e stub.remover.

72

Quadro 14 – Classe que chama o Web Service

3.3.1.5 Copiar um arquivo da internet

Como já anteriormente relatado, o recurso Arquivo do iAVA, permite o usuário

selecionar um arquivo da internet. Este recurso faz uma cópia do arquivo selecionado pelo

usuário e o guardará no banco de dados da aplicação. No Quadro 15, mostra a forma de como

o arquivo selecionado é obtido do local original.

73

Quadro 15 – Copiar arquivos da internet

O método getArquivoRede do Quadro 15 cria uma Uniform Resource Locator (URL) da

internet, com a URL do arquivo que será copiado, e todos os bytes através do método conn.getInputStream().

São copiados um a um para um novo arquivo File. Vários problemas podem ocorrer durante

essa operação, dentre eles a URL passada não ser válida, ou a conexão com a internet dar problemas,

entre outras. Quando um destes problemas ocorrer, o sistema somente lançará o problema que

ocasionou o erro para o log do servidor da aplicação, não parando totalmente a aplicação. Para evitar

problemas de controle de sites na rede onde está sendo executado o aplicativo, entre as linhas 80 até a

linha 84 são anexados a URL os dados de um usuário da rede.

3.3.2 Operacionalidade da implementação

Nesta seção serão apresentadas algumas telas do sistema, bem como suas

funcionalidades. Inicialmente tem-se na Figura 35 a tela de acesso ao aplicativo. O usuário

informa os dados e clica em 'Entrar'. Os botões construídos no aplicativo não são pequenos

74

para não causar problemas ou inviabilidades na seleção do mesmo, conforme orientações da

Apple (2010) para ícones de seleção descritos na seção 2.7.2.

Figura 35 - Tela de login do aplicativo

Assim como no portal AVA, após o acesso ao sistema o usuário tem 4 principais áreas

de acesso: Estudo, Pessoal, Backup e Monitoria. Na aplicação iAVA foram implementadas

somente as áreas Estudo e Pessoal. Para selecionar a área desejada a lista de opções fica no

rodapé da página, na barra de abas, conforme explicado na seção 2.7.3.4. Na barra de abas,

conforme a barra selecionada seu texto ficará com cor azul, senão, ficará com a cor branca.

Na Figura 36, tem-se a tela de Área de Estudo. Nesta tela tem-se a lista de disciplinas

na qual o usuário tem acesso. Na lista de disciplinas, cada item contém o ícone de flecha no

75

canto direito da linha, este ícone também é um padrão indicado pela Apple (2010), indicado

na seção 2.7.6, que caracteriza que a linha tem itens que serão mostrados em uma nova tela.

Figura 36 - Tela de área de estudo do aplicativo

Na Figura 37, se tem a tela de uma matéria selecionada na Área de Estudo. Nesta tela

tem-se a disciplina e todos os recursos vinculados a ela. Deve ser notado que no topo da tela,

na barra de navegação, indica qual disciplina está selecionada, já que na aplicação se pode ver

somente uma disciplina de cada vez. Também na barra de navegação contém o ícone de Home

para a tela principal do aplicativo, neste caso a tela de Área de Estudo.

Utilizou-se para cada recurso implementado do AVA, o ícone utilizado no portal

original, isto para manter a identidade e para o usuário associar os ícones com cada tipo de

76

recurso. Na Figura 37 é listado para a mesma disciplina os 4 tipos de recursos que o aplicativo

iAVA oferece.

Nesta tela contém em sua barra de abas 3 opções de seleção, porém nesta versão do

aplicativo somente a opção Aulas foi implementada, no caso a opção que mostra os recursos

da disciplina.

Figura 37 - Tela de área de estudo do aplicativo

Na Figura 38, se tem a tela de cadastro de recursos do iAVA. Nesta tela de recurso o

usuário pode inserir qualquer um dos recursos disponibilizados na aplicação: Material, Pasta,

Fórum e Texto Colaborativo. Para acesso a esta tela o usuário deve ser do tipo administrador

da disciplina.

Para a escrita dos valores é acionado o recurso que apresenta o teclado para o usuário

77

poder inserir os dados, uma visão modal comentado na seção 2.7.4.

Figura 38 - Tela de adicionar recursos utiliza o recurso visão modal do teclado

Na mesma tela de criação de recursos, tem-se a opção de escolha do tipo picker,

conforme citado na seção 2.7.2. O recurso é utilizado na aplicação e apresentado na Figura

39.

78

Figura 39 - Tela de adicionar recursos utiliza o recurso de seleção picker

A Figura 40 apresenta o recurso material. No recurso apresentado na figura ele contém

os três tipos de itens que o recurso disponibiliza: link, pasta e arquivos do usuário. A barra de

opções que aparece no topo da página, é habilitada para usuários do tipo administrador da

disciplina ou quando o recurso permite que um usuário do tipo Aluno adicione itens.

Para os itens do tipo arquivos do usuário, eles são vinculados com o recurso material,

sendo assim, quando no material é clicado no excluir do recurso, na verdade somente o

vínculo foi desfeito, sendo que para o usuário que adicionou este arquivo em seus itens, ele

ainda permanece lá.

79

Figura 40 - Tela do recurso material e seus itens

Para as ações dos botões no recurso material apresentado na Figura 40, são

disponibilizadas novas telas ao usuário, assim como mostradas na Figura 41. A primeira tela

refere-se a inclusão de um item Link no material. A segunda tela mostra a forma de associar

um recurso arquivo do usuário, onde é criado na sua Área Pessoal, disponibilizando-o para ser

visto por todos os membros da disciplina.

80

Figura 41 - Adicionar um link e associar um arquivo no recurso material A Figura 42 apresenta o recurso texto colaborativo. O recurso disponibiliza um texto

em comum para todos os usuários habilitados na disciplina e permite a alteração deste mesmo

texto por qualquer usuário.

Na figura são apresentadas 3 telas do recurso onde a primeira tela retrata os históricos

de modificações do recurso, na segunda tela o bloqueio do texto para que somente um usuário

faça modificações de cada vez e por fim, na terceira tela a página principal do recurso.

Para cada histórico do texto é listada a sua versão, a data e hora da modificação e o

usuário que modificou. O botão visualizar serve para mostrar o texto completo de cada

versão. O bloqueio do texto colaborativo é configurado para cada recurso, ele garante que não

haja 2 usuários mexendo na mesma versão do texto no mesmo tempo. Na tela principal do

recurso é listada a última versão do texto, juntamente com a data e hora da modificação, o

autor e a descrição completa do texto.

81

Figura 42 - Recurso texto colaborativo Na Figura 43 apresenta o recurso de comparação entre dois históricos do texto

colaborativo. Onde o texto que foi removido fica em vermelho, o item em verde são as

palavras inseridas na nova versão e , apesar de não conter no exemplo, os itens em preto são

palavras que não foram modificadas dentre a versão selecionada e a sua versão anterior.

82

Figura 43 - Tela de comparação entre históricos no texto colaborativo

Na Figura 44 apresenta o recurso fórum onde no primeiro momento deve-se cadastrar

os temas que serão abordados no fórum e ao selecionar um tema, os usuários poderão inserir

as suas contribuições nele. Tanto os temas como as contribuições podem ser feitas por

qualquer usuário da disciplina onde o fórum está disponibilizado.

83

Figura 44 - Tela do recurso fórum temático Para a Área Pessoal o aplicativo disponibiliza manter os arquivos do usuário. Este

recurso é habilitado para qualquer tipo de usuário. Todo o arquivo criado em sua Área Pessoal

pode somente ser visto pelo usuário que o criou. Para compartilhar um arquivo com outras

pessoas da disciplina, ele deve ser associado a um recurso material, apresentado na Figura 41.

Na Figura 45 apresenta num primeiro momento a lista de todos os materiais que o

usuário já cadastrou e na segunda tela o cadastro de um novo arquivo. Para adicionar um novo

arquivo o usuário deve informar uma descrição e um arquivo de rede. isto é, uma URL que

tenha o arquivo que será adicionado.

84

Figura 45 - Tela de arquivos do usuário

3.4 RESULTADOS E DISCUSSÃO

O presente trabalho, apresentou o projeto e desenvolvimento de um aplicativo que trata

de uma nova forma a estrutura e apresentação do portal AVA, voltada para usuários que

utilizem o iPhone. Alguns recursos bem como suas funcionalidades, foram reimplementados

para que fosse possível sua utilização pelo dispositivo móvel. Os recursos implementados

foram:

a) material, com seus subrecursos: - pastas, - links, - associação com arquivos do usuário;

85

b) pasta;

c) texto colaborativo;

d) arquivos do usuário;

e) fórum temático.

Durante a implementação e construção do trabalho, foi-se deparado com dificuldades

para a realização dos objetivos e outras que se foi necessário tomarem decisões de contorno

para a situação.

Dentre as dificuldades encontradas, pode-se citar a integração com o ambiente AVA.

Constatou-se que o portal AVA não possui hoje nenhum Web Service pronto para ser

utilizado. Em questionamento com as pessoas responsáveis pelo portal, chegou-se a conclusão

que seria interessante criar e utilizar Web Service em seu sistema. Para estar preparado e

facilitar a integração com o portal AVA original, o sistema busca os dados via uma solicitação

Web Service. Isso tendo em vista que quando houver a construção dos Web Services do portal

AVA, o sistema já estará preparado esta integração.

Tendo em vista que o portal AVA não possui Web Service e o aplicativo construído

espera por dados, construiu-se então um Web Service para esta versão da ferramenta. Ele

gerencia e suporta operações básicas de dados como salvar, remover e carregar objetos da

base de dados. A forma de funcionamento do Web Service bem como a estrutura de dados do

banco de dados utilizado foi descrita nas seções 3.2.5 e 3.2.6.

Em princípio, o Web Service criado neste trabalho não iria funcionar utilizando banco

de dados e sim somente com dados em memória. Porém com a estrutura de classes de

modelos possuindo muitas classes de herança (hierarquias), tiveram-se muitos problemas em

controlar a normalização dos dados. Por exemplo, no modelo de classes se tem a classe Link

estendendo a classe Recurso Secundário. Sem utilizar o banco de dados, o servidor de

interface da aplicação deveria mandar para o servidor de dados via Web Service, o objeto que

seria armazenado, no caso Link, e ter de retorno o mesmo objeto Link como retorno, com o

controle de código e associações feitas. Ocorria que o objeto Link era passado, mas de

retorno tinha um objeto do tipo RecursoSecundario.

Para solucionar este problema foi utilizado um banco de dados. Isso fez com que os

objetos precisassem somente ser enviados para o servidor de banco de dados, e receber de

retorno somente o código do objeto, isso porque não é mais necessário o servidor de interface

ter os mesmos dados do servidor de banco de dados, visto que quando inicia a aplicação, os

dados são resgatados do banco de dados e passados para o servidor de interface via XML.

Verificando os recursos criados no aplicativo, pode-se destacar o recurso arquivos do

86

usuário. No portal AVA original este recurso possibilita os usuários selecionarem arquivos

disponiveis localmente em seu computador. Porém o iPhone, não suporta o componente

HTML input type="file", sendo que ele desabilita este recurso na tela no iPhone. Pode-se

verificar este problema na Figura 46. Para este problema, modificou-se a forma de

funcionamento do recurso onde, no aplicativo, o usuário informa o endereço de um arquivo

disponível na rede ou internet. Ao informar o recurso da rede o aplicativo faz uma cópia do

arquivo e persiste na base de dados. Isso para que toda vez que o recurso seja selecionado por

um usuário, o sistema não referencie a URL do arquivo original, mas sim, abra a copia do

arquivo que está na base de dados.

Figura 46 - Comportamento do componente file no iPhone

87

Para a construção do recurso chat, teve-se o problema de verificar quando um usuário

mandou uma mensagem para outro, pois sua tela deverá ser atualizada automaticamente. Com

isso a necessidade seria a criação de um centralizador das mensagens do chat no servidor da

aplicação e possibilitar que a tela atualize quando perceber as modificações.

88

4 CONCLUSÕES

A motivação para que fosse realizado este trabalho foi a de mostrar uma aplicação já

existente na WEB, para ser visualizada em um dispositivo iPhone. Este processo, que tende a

ser cada vez mais presente nas empresas de informática, consiste em atender e buscar o

mercado dos aparelhos móveis, dentre eles o iPhone.

A aplicação conta com 2 servidores um que controla a interface e o outro os dados do

aplicativo. O servidor de interface se comunica com o outro servidor através de chamadas

Web Services. Pode-se acessar o servidor de interface através de um caminho de URL por

um dispositivo iPhone.

Como base teve-se o portal AVA, descrito na seção 2.1, é um portal que integra a

comunidade acadêmica da FURB. Utilizando JAVA, Java Script, JSP e CSS, foram

construídos no aplicativo os recursos: pasta, material, texto colaborativo, fórum e arquivo de

usuário. Todos utilizando características de layouts e elementos próprios ou que melhor se

adéqüem ao dispositivo iPhone.

Para auxiliar no desenvolvimento do aplicativo, teve-se como base para os modelos de

apresentação e layouts os trabalhos correlatos. Com eles, em especial o iWebKit (seção 2.8.2),

se pôde verificar como se devem ser usados os componentes específicos do iPhone, como as

listas, os pickers e a navegação entre as telas de hierarquia.

A fundamentação teórica, principalmente as recomendações da Apple (2010) foram

seguidas a fim de estruturar de forma organizada e funcional o aplicativo. Dicas como opção

de seleção, ícones e apresentação dos dados, foram importantes para garantir as estruturas

próprias de um aplicativo no iPhone e também deixar as informações claras e com facilidade

em seu entendimento.

Como resultado final, conclui-se que uma interface voltada para o iPhone torna-se

muito diferente da interface para um desktop. Sem perda de dados mas com tipos de

elementos e estruturas diferentes, cada aplicação que tem um foco (desktop ou iPhone) deve

ser construída em separado. Para atender de forma integral e com todos os requisitos e

expectativas o que cada tipo de usuário deseja. A aplicação desenvolvida disponibiliza para

ser visualizado num ambiente iPhone, os recursos:

a) material, com seus subrecursos: - pastas, - links,

89

- associação com arquivos do usuário; b) pasta;

c) texto colaborativo;

d) arquivos do usuário;

e) fórum temático.

4.1 EXTENSÕES

Para extensões do projeto, pode-se citar a integração real com o portal AVA, seja

fazendo o servidor da interface conectar diretamente em um Web Service disponibilizado pelo

AVA, ou melhorar o Web Service atual da aplicação iAVA para sincronizar os dados com a

aplicação original.

A implementação de outros recursos do portal AVA para a ferramenta iAVA também

pode ser uma extensão do trabalho atual, tais como o chat, a galeria de imagens, a bolsa e as

funções dos outros menus, como por exemplo, o menu diário, contendo a lista de membros

da disciplina, ou como o menu backup, com a lista de disciplinas dos semestres passados.

90

REFERÊNCIAS BIBLIOGRÁFICAS

ALLEN, Christopher; APPELCLINE, Shannon. iPhone in action: introduction to web and SDK Development. Greenwich: Manning Publications Co., 2009.

ALVES, Victor H. C. Ti inside online: Brasil fechará o ano com 68,5 milhões de internautas, aponta IAB. [S.l.], 2009. Disponível em: <http://www.tiinside.com.br/News.aspx?ID=124478&C=265>. Acesso em: 22 ago. 2009.

APPLE. Alta tecnologia. [S.l.], 2009a. Disponível em: <http://www.apple.com/br/iphone/iphone-3g/>. Acesso em: 02 set. 2009.

______. Apresentamos o iPhone 3GS. [S.l.], 2009b. Disponível em: <http://www.apple.com/br/iphone/iphone-3gs/>. Acesso em: 02 set. 2009.

______. Especificações técnicas. [S.l.], 2009c. Disponível em: <http://www.apple.com/br/iphone/specs.html>. Acesso em: 02 set. 2009.

______. iPhone features. [S.l.], 2008. Disponível em: <http://www.apple.com/br/iphone/iphone/features/>. Acesso em: 11 mar. 2010.

______. iPhone human interface guideline. [S.l.], 2010. Disponível em: <http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/MobileHIG.pdf>. Acesso em: 15 abr. 2010.

______. Por que você vai se apaixonar pelo iPhone. [S.l.], 2009d. Disponível em: <http://www.apple.com/br/iphone/why-iphone/>. Acesso em: 02 set. 2009.

______. Teclado. [S.l.], 2009e. Disponível em: <http://www.apple.com/br/iphone/iphone-3gs/keyboard.html>. Acesso em: 02 set. 2009.

APPLE MANIA. Mercado mundial do iPhone dobrou no 1º trimestre de 2009, diz Gartner. [S.l.], 2009. Disponível em: <http://applemania.info/?p=3833>. Acesso em: 22 ago. 2009.

AVA. Requisitos para acesso. [S.l.], 2009. Disponível em: <http://ensino.furb.br/ava/portal/ava/requisitos.htm>. Acesso em: 25 ago. 2009.

CHAPPELL, David; JEWELL, Tyler. Java Web Services. O'Reilly, 2002.

DERBY. Apache Derby. [S.l.], 2009. Disponível em: <http://db.apache.org/derby/>. Acesso em: 15 maio 2010.

91

DEVELOPER APPLE. Dashcode user guide: introduction to Dashcode user guide. [S.l.], 2010a. Disponível em: <http://developer.apple.com/iphone/library/documentation/AppleApplications/Conceptual/Dashcode_UserGuide/Contents/Resources/en.lproj/Introduction/Introduction.html>. Acesso em: 14 mar. 2010.

______. Dashcode user guide: starting a project . [S.l.], 2010b. Disponível em: <http://developer.apple.com/iphone/library/documentation/AppleApplications/Conceptual/Dashcode_UserGuide/Contents/Resources/en.lproj/WidgetProjects/WidgetProjects.html>. Acesso em: 13 mar. 2010.

______. Developer tools. [S.l.], 2010c. Disponível em: <http://developer.apple.com/technologies/tools/xcode.html>. Acesso em: 09 mar. 2010.

______. Interface builder user guide: interface builder basic concepts. [S.l.], 2010d. Disponível em: <http://developer.apple.com/iphone/library/documentation/DeveloperTools/Conceptual/IB_UserGuide/ApplicationBasics/ApplicationBasics.html#//apple_ref/doc/uid/TP40005344-CH3-SW1>. Acesso em: 11 mar. 2010.

______. Interface builder user guide: introduction. [S.l.], 2010e. Disponível em: <http://developer.apple.com/iphone/library/documentation/DeveloperTools/Conceptual/IB_UserGuide/Introduction/Introduction.html>. Acesso em: 10 mar. 2010.

______. iPhone development guide: using iPhone simulator. [S.l.], 2010f. Disponível em: <http://developer.apple.com/iphone/library/documentation/Xcode/Conceptual/iphone_development/125-Using_iPhone_Simulator/iphone_simulator_application.html#//apple_ref/doc/uid/TP40007959-CH9-SW1>. Acesso em: 11 mar. 2010.

______. iPhone development guide: using iPhone simulator. [S.l.], 2010g. Disponível em: <http://developer.apple.com/iphone/library/documentation/Xcode/Conceptual/iphone_development/125-Using_iPhone_Simulator/iphone_simulator_application.html>. Acesso em: 12 mar. 2010.

______. iPhone Web App. [S.l.], 2010h. Disponível em: <http://developer.apple.com/safari/library/referencelibrary/GettingStarted/GS_iPhoneWebApp/index.html#//apple_ref/doc/uid/TP40008134>. Acesso em: 29 abr. 2010.

FORESTA, Tatiana. Os números da internet: canais móveis serão estratégicos em 2009. [S.l.], 2009. Disponível em: <http://www.osnumerosdainternet.com.br/canais-moveis-serao-estrategicos-em-2009/>. Acesso em: 22 ago. 2009.

IMASTERS. Web services in Java. [S.l.], 2004. Disponível em: <http://imasters.uol.com.br/artigo/1863/java/web_services_in_java/>. Acesso em: 09 set. 2009.

IWEBKIT. [S.l.], 2010. Disponível em: <http://iwebkit.net/>. Acesso em: 20 abr. 2010.

92

JQTOUCH. A jQuery plugin for mobile WebKit development. [S.l.], 2010. Disponível em: <http://code.google.com/p/jqtouch/>. Acesso em: 20 abr. 2010.

LATAM. Apple apresenta prévia do iPhone OS 4. [S.l.], 2010. Disponível em: <http://latam.apple.com/pr/articulo/?id=1640&r=br>. Acesso em: 15 maio 2010.

MENTALIDADE. Smartphone é o aparelho celular com funcionalidade mais inteligente do mercado. [S.l.], 2010. Disponível em: <http://www.mentalidade.com/smartphone-e-o-aparelho-celular-com-funcionalidade-mais-inteligente-do-mercado>. Acesso em: 15 abr 2010.

PONTE, Karina A. G. Ambientalização e usabilidade do cyber espaço. [S.l.], 2006. Disponível em: <http://imasters.uol.com.br/artigo/4882/usabilidade/ambientalizacao_e_usabilidade_do_cyber_espaco>. Acesso em: 01 set. 2009.

REDAÇÃO IDG NOW! Telecon: acesso à internet cresceu 600% em 2009. [S.l.], 2010. Disponível em: <http://computerworld.uol.com.br/telecom/2010/02/19/acesso-a-internet-via-smartphones-cresceu-600-em-2009/>. Acesso em: 15 abr 2010.

REDAÇÃO TERRA. Celular & wireless. Novo iPhone 3GS chega ao Brasil em agosto. [S.l.], 2009. Disponível em : <http://tecnologia.terra.com.br/interna/0,,OI3813018-EI4796,00-Novo+iPhone+G+S+chega+ao+Brasil+em+agosto.html>. Acesso em: 15 set. 2009.

SILVA FILHO, Antonio M. Percepção humana na interação humano-computador. [S.l.], 2003. Disponível em: <http://www.espacoacademico.com.br/025/25amsf.htm>. Acesso em: 01 set. 2009.

SOUZA, Julio C. Sincronização de dados em dispositivos móveis utilizando Web Services. [S.l.], 2006. Disponível em : <http://www.dainf.cefetpr.br/~cristina/SINC_DISPMOVEIS.pdf>. Acesso em: 08 set. 2009.

iava – aplicaÇÃo web para disponibilizar...

Documents