Após a análise das diferentes plataformas móveis, tendo em conta as estatísticas de utiliza- ção, de crescimento e as suas características funcionais, a plataforma Android da Google e o iOS da Apple destacaram-se para o desenvolvimento da aplicação. Realçam-se das restantes pelas cotas de mercado e pelo crescimento no número de utilizadores ano após ano. Adicionalmente, disponibilizam documentação e ferramentas de desenvolvimento completas.
O ambiente de desenvolvimento (IDE) de aplicações para iOS, designado por XCode, dispo- nibiliza um conjunto abrangente de ferramentas e a sua interface é atrativa, intuitiva e funcio- nal. Realçam-se alguns pontos fortes em relação ao Eclipse, IDE oficial de desenvolvimento de aplicações para Android, nomeadamente a simplicidade, a disponibilização de ferramentas que conduzem à criação de interfaces visualmente apelativos de forma intuitiva e rápida. No Eclipse o processo para atingir o mesmo resultado demonstra-se mais demorado e trabalhoso, além disso são necessários conhecimentos de XML para controlar totalmente a criação do interface.
Contudo, o desenvolvimento da aplicação para iOS não foi possível, devido a condiciona- mentos tecnológicos que a plataforma impõe e ao modelo de negócio da Apple.
A disponibilização das aplicações para iOS é controlada pela Apple através de uma política rígida, que permite apenas a instalação de aplicações através da loja oficial App Store. O custo da licença para desenvolver e publicar aplicações na App Store da Apple (80 Euros/ ano), é uma desvantagem em relação à plataforma Android, em que o desenvolvimento é gratuito e a disponibilização no Google Play tem um custo de aproximadamente 20 Euros, valor pago uma única vez com duração vitalícia. Adicionalmente, dado que as aplicações para Android podem ser instaladas livremente, podem ser disponibilizadas através de um web site sem qualquer custo.
Além destas questões, o desenvolvimento para iOS foi inviabilizado por completo pelo facto da Apple impedir a utilização de APIs privadas para o acesso à recolha das informações das redes Wi-Fi, que são de elevada importância para este projeto. Em 2010, a Apple baniu da App Store várias aplicações que utilizavam API privadas para obter as informações das redes Wi-Fi[And10], não permitindo no entanto a utilização da API nativa para que os developers tenham acesso a essa informação.
A Google não é tão rígida nos critérios de aprovação de aplicações para a sua loja online Google Play e fornece todas as APIs necessárias. Além disso as aplicações submetidas ficam rapidamente disponíveis aos utilziadores.
Acresce a estes factos o custo dos equipamentos, sendo possível adquirir um smartphone Android, equipado com Wi-Fi, Bluetooth e GPS, com razoáveis capacidades de processamento
e memória, por valores que rondam ≈100 Euros. Em relação aos dispositivos iOS, não é
possível adquirir um equipamento por menos de ≈490 euros[TMN12], não existindo uma gama de baixo custo. Apesar das características dos dispositivos Android mais baratos não poderem ser comparadas às do iPhone, para o desenvolvimento da maioria das aplicações, excluindo certos jogos que requerem outro tipo de hardware, os dispositivos mais acessíveis dão resposta às necessidades dos developers.
Após esta análise, a plataforma Android é a que melhor se adapta aos objetivos do pro- jeto, sendo por isso a escolhida para o desenvolvimento da aplicação. Permite a utilização dos recursos tecnológicos necessários, o desenvolvimento e a disponibilização da aplicação de forma livre e gratuita, sendo ainda a plataforma com mais utilizadores e maior índice de cresci- mento no mercado. Os aspetos fundamentais da análise comparativa entre as duas plataformas encontram-se resumidos na tabela 6.1.
Acessível. Desde ≈100€ Elevado. Desde ≈490€
Custo dos smartphones Permissão para utilização de
todas as APIs necessárias
Apenas na App Store (80.00€/ ano) Custo de desenvolvimento
23%
Gratuito (Utilizadores de Mac OS X Lion e Moutain Lion)
No Google Play (20€ uma vez) e por outros meios
Não Gratuito
Cota de mercado 1º Trimestre 2012 segundo a IDC
Sim Disponibilização
59%
Aspectos Android iOS
Tabela 6.1: Resumo da análise das plataformas Android e iOS
1.1.1 Android – Arquitetura e Componentes
Após a eleição da plataforma Android para o desenvolvimento da aplicação móvel, é im- portante realizar uma análise mais pormenorizada da sua arquitetura e funcionamento (Fi. 6.1). LINUX KERNEL LIBRARIES APLICATION FRAMEWORK APLICATION LAYER ANDROID RUNTIME Android Libraries
Dalvik Virtual Machine Media SQLite Graphics (OpenGL, SGL, FreeType) libc SSL & WebKit Surface Manager Hardware Drivers
(USB, Display, Bluetooth, etc) Power Management Process Management Memory Management Content Providers P2P/IM Location-Based Services Telefony Window Manager Notifications Package Manager Resource Manager Activity Manager Views Native Apps
(Contacts, Maps, Browser, etc) Thrid Party Apps Developer Apps
• Linux Kernel: Permite a abstração entre o hardware e o resto da stack. É responsável pelos drivers dos dispositivos (Bluetooth, Wi-Fi, etc), pela gestão de recursos, de energia, de segurança e de rede.
• Libraries: Bibliotecas nativas implementadas em C/C++, responsáveis pela gestão dos gráficos, reprodução de áudio e vídeo, SSL e WebKit para integrar segurança na navegação e suporte para bases de dados SQL Lite.
• Android Runtime: Inclui as bibliotecas Core que disponibilizam a maioria das funci- onalidades da API Java e bibliotecas adicionais especificas do Android. Incluí ainda a máquina virtual Dalvik, que executa cada aplicação num processo separado, criando a sua própria instância da máquina virtual Dalvik.
• Aplication Framework: Fornece as classes necessárias para desenvolver uma aplicação Android e a abstração com o acesso ao hardware. A API Java da biblioteca principal do Android inclui os serviços de telefone, provedores de conteúdos (dados), gestão de atividades, gestão do ciclo de vida das aplicações, gestão de localização e de recursos UI, para a criação de interfaces.
• Aplication Layer: Todas as aplicações, nativas ou desenvolvidas/ descarregadas são criadas sobre a camada de aplicação, utilizando a mesma API.
Componentes de uma Aplicação Android
Uma aplicação Android é constitutiva por componentes. Os componentes, são os blocos es- senciais de construção da aplicação, ligados através do manifesto do projeto. Cada componente desempenha um papel específico, ajudando a definir o comportamento geral da aplicação.
Cada tipo de componente tem uma finalidade distinta e um ciclo de vida diferente, que define como o componente é criado e destruído[And12b]. Existem quatro tipos diferentes de componentes:
• Activities: Uma activity ou atividade é implementada pela sub-classe Activity, repre- sentando um único ecrã ou menu da interface da aplicação com o utilizador. A maioria das aplicações têm várias activities. As activities são independentes umas das outras, apesar de quando unidas criarem ao utilizador a experiência de navegação na aplicação. A navegação para outro ecrã da aplicação consiste em iniciar uma nova activity. Para a navegação entre ecrãs é utilizada a classe Intent, que permite, para além de outras
funções, passar dados de uma activity para outra. Uma aplicação pode utilizar uma acti-
vity de outra aplicação, por exemplo uma aplicação pode utilizar a activity da galeria de
fotografias de modo a importar uma foto.
• Services: Os serviços são utilizados para executar regularmente uma determinada tarefa, que deve continuar mesmo quando a activity ou a própria aplicação é terminada, como por exemplo fazer a verificação de novos emails. Um serviço não tem interface de utili- zador e trabalha de forma independente da aplicação, no entanto é possível às aplicações comunicarem com o serviço.
• Broadcast Receivers: Permite que uma aplicação possa responder a um evento externo que ocorre no sistema, através da análise dos Broadcast Intents, que correspondem a um determinado filtro. Pode ser utilizado o Notification Manager para alertar o utilizador de algum evento sem interromper a activity atual. Uma aplicação não necessita de estar em execução para que um Broadcast Receiver seja acionado, apenas é necessário que o
Broadcast Receiver esteja definido no manifesto da aplicação, para que este seja executado.
• Content Providers: Permitem armazenar e partilhar dados entre aplicações. Os dados podem ser armazenados em bases de dados SQLite. O Android permite o acesso a alguns
Content Providers nativos, como por exemplo os contactos.
Ciclo de Vida das Aplicações Android
É importante entender o ciclo de vida das aplicações, de modo a definir a melhor forma de implementação do módulo GeoAnúncios e do módulo de recolha de dados. Dependendo dos componentes utilizados, a prioridade do processo executado pode ser:
• Foreground (Prioridade crítica): Quando o utilizador está a interagir com a aplicação. Neste estado o Android tenta manter a aplicação fluída atribuindo-lhe recursos.
• Visible (Prioridade alta): Neste estado, a aplicação perdeu o foco de interação, ficando em pausa. Por exemplo, quando uma activity que não utiliza o ecrã inteiro é chamada, a anterior continua visível. Neste estado, a activity mantém as informações, mas pode ser terminada pelo sistema por falta de recursos.
• Service (Prioridade alta): Os serviços não possuem interface com o utilizador, por este motivo recebem prioridade inferior em relação às activities em interação com o utilizador. No entanto, os serviços tem um elevado grau de importância, sendo apenas terminados em casos extremos de falta de recursos.
• Background (Prioridade baixa): São activities que estão completamente ocultas por outras, ou em background. Deste modo, podem ser terminadas sem impacto direto para o utilizador. O sistema quando necessita de recursos termina estes processos, utilizando uma lista que dá prioridade aos processos utilizados recentemente.
• Empty (Prioridade baixa): É um processo que não tem qualquer atividade. Estes pro- cessos podem ser mantidos como cache para que uma próxima iniciação seja mais rápida, sendo terminados sempre que necessário.
Após a análise do ciclo de vida das aplicações, foi possível perceber que a aplicação desen- volvida deveria ser baseada em dois tipos de processos. O módulo GeoAnúncios, baseado em
activities, com interface de utilizador. A recolha de dados, executada como Service, obtendo
assim um prioridade alta e constante, sendo o seu funcionamento independente da aplicação GeoAnúncios.
Esta opção será novamente abordada, de forma pormenorizada, mais à frente neste capítulo, na implementação da recolha de dados.