IAVA – APLICAÇÃO WEB PARA DISPONIBILIZAR...
Transcript of 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
IAVA – APLICAÇÃO WEB PARA DISPONIBILIZAR
RECURSOS DO AVA NO DISPOSITIVO MÓVEL IPHONE
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
IAVA – APLICAÇÃO WEB PARA DISPONIBILIZAR
RECURSOS DO AVA NO DISPOSITIVO MÓVEL IPHONE
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 3 – Caso de uso UC02..................................................................................................49
Quadro 4 – Caso de uso UC03..................................................................................................50
Quadro 5 – Caso de uso UC04..................................................................................................51
Quadro 6 – Caso de uso UC05..................................................................................................52
Quadro 7 – Caso de uso UC06..................................................................................................53
Quadro 8 – Caso de uso UC07..................................................................................................54
Quadro 9 – Caso de uso UC08..................................................................................................55
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.
Quadro 3 – Caso de uso UC02
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';
2. Volta ao passo 4 do cenário principal.
Pós-condição Link cadastrado, alterado ou excluído no aplicativo iAVA.
Quadro 4 – Caso de uso UC03
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;
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';
2. Volta ao passo 4 do cenário principal.
Pós-condição Pasta cadastrada, alterada ou excluída no aplicativo iAVA.
Quadro 5 – Caso de uso UC04
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
1. No passo 1 do cenário principal, o usuário poderá clicar no botão 'Editar'
material;
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';
2. Volta ao passo 4 do cenário principal.
Pós-condição Recurso material cadastrado, alterado ou excluído no aplicativo iAVA.
Quadro 6 – Caso de uso UC05
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.
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 texto colaborativo;
3. Clicar em 'Adicionar';
4. Sistema mostrará a lista de recursos disponibilizados na disciplina inclusive o
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;
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';
2. Volta ao passo 4 do cenário principal.
Pós-condição Recurso texto colaborativo cadastrado, alterado ou excluído no aplicativo iAVA.
Quadro 7 – Caso de uso UC06
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.
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 fórum;
3. Clicar em 'Adicionar';
4. Sistema mostrará a lista de recursos disponibilizados na disciplina inclusive o
novo componente fórum.
Cenário
Alternativo
1. No passo 1 do cenário principal, o usuário poderá clicar no botão 'Editar'
fórum;
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';
2. Volta ao passo 4 do cenário principal.
Pós-condição Recurso fórum cadastrado, alterado ou excluído no aplicativo iAVA.
Quadro 8 – Caso de uso UC07
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.
Pré-condição Usuário deve estar logado no aplicativo.
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.
Quadro 9 – Caso de uso UC08
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.
Pré-condição Usuário deve estar logado no aplicativo.
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.
Quadro 11 – Caso de uso UC10
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.