Abstract
This professional internship report was developed with the purpose of obtaining the Masters Degree in Network and Systems Engineering of the Faculty of Sciences - University of Porto. It describes the activities carried on Spotfokus, Lds in an eight month internship.
The initial project, which was proposed in this internship, was to create an application for smartphones with the Android operating system. The main goal was to allow the clients to order a taxi. It was requested by a taxi company based in Luxembourg, the application was meant to be used together with their car fleet. The elements of the main project are the dispatch system and the driver’s application, which were previously developed. This project was ordered to keep up with technological developments and the apps which are rivals to the taxi companies. The project consisted in the development of the client’s application following the layout requested by the company. It was necessary to work on the driver’s app in order to make some corrections. In addition it was also important to work on the web service since we needed to create the methods which would interact with the main application.
Besides the main project it was also proposed to work on a secondary one. Which was the development of a taxi trip simulator. The main goal was to produce a platform to be used by the customers in order to inform them of the costs of a trip in any time fo the day. This was a web page which would allow the users to insert the origin and destination address. The simulator would calculate the final price of the trip. The project should be implemented according to the city of Porto and its fares.
Resumo
Este relatório, elaborado no âmbito do Estágio Curricular para conclusão do Mestrado em Engenharia de Redes e Sistemas Informáticos da Faculdade de Ciências da Universidade do Porto, tem como intuito a descrição das atividades desenvolvidas na Spotfokus, Lda durante os oito meses de estágio.
O projeto principal foi realizar uma aplicação para smartphones, com o sistema operativo Android. O objetivo é permitir aos utilizadores solicitar um táxi. O projeto é constituído por uma central de despacho e uma aplicação para ser utilizada pelos motoristas, esta já tinha sido desenvolvida previamente. A aplicação proposta, seria para ser utilizada em conjunto com os serviços já existentes. O projeto foi encomendado por uma empresa, para acompanhar os avanços tecnológicos e as aplicações que são concorrentes das empresas de táxi. O trabalho consistiu no desenvolvimento da aplicação, tendo em conta o layout pretendido pela empresa. Também foi necessário trabalhar na aplicação para motoristas, para fazer pequenas correções e também no serviço web, para criar os métodos que interagiam com a aplicação cliente.
Além do projeto principal, foi proposto também, trabalhar num projeto secundário. Este consistia na criação de um simulador de viagens de táxi. Esta plataforma seria para ser utilizada pelos clientes, para os informar do preço da viagem que estes pretendem fazer. O simulador seria uma página web, onde os utilizadores inserem a morada de origem e destino e o mesmo calcula o preço, tendo em conta a cidade do Porto.
Agradecimentos
Este trabalho não seria possível sem a ajuda da Spotfokus e seus sócios, quero agradecer ao André Almeida e à Vânia Gonçalves por oferecerem uma posição dentro da empresa para eu realizar o meu estágio curricular. Também tenho que agradecer às minhas colegas de trabalho e principalmente à minha orientadora no seio da empresa, a Cátia Marques que ajudou-me em todos os momentos que requisitei a sua ajuda e também pelo que me ensinou sem ter que pedir.
Quero também ao professor Sérgio Crisóstomo, por ter aceite ser o meu orientador da FCUP e por toda a ajuda que forneceu para a elaboração deste relatório.
Quero agradecer à minha irmã Mafalda por toda a ajuda que me deu durante a escrita deste relatório e ao meu namorado André por todo o apoio dado desde sempre.
Por último tenho que agradecer à minha Mãe, que de tudo fez para eu ter uma boa educação e por toda a ajuda que me deu durante os momentos mais complicados. Sempre me mostrou o que eu conseguiria alcançar. Sem ela eu não estaria onde estou hoje, não teria escrito este relatório e nem estaria a acabar o mestrado.
Um muito obrigada a todos.
Dedico às três pessoas mais importantes da minha vida
Conteúdo
Abstract i Resumo iii Agradecimentos v Conteúdo ix Lista de Figuras xiLista de Blocos de Código xiii
1 Introdução 1 1.1 Objetivos . . . 2 1.2 Organização do relatório . . . 2 2 MyNetTaxi 5 2.1 Enquadramento/Estado de arte . . . 7 2.1.1 Consumo Colaborativo. . . 7 2.1.2 Empresas Modelo. . . 8 2.1.3 Uber . . . 9 2.2 Arquitetura Geral . . . 10 2.2.1 Central de Despacho . . . 11 2.2.1.1 Servidor. . . 11 vii
2.2.1.2 Base de dados . . . 12
2.2.2 Google Cloud Messaging. . . 13
2.2.3 Google API . . . 15
2.2.4 Aplicação Cliente . . . 15
2.2.5 Aplicação Motorista . . . 17
2.2.6 Interação entre Entidades . . . 18
2.2.6.1 Aplicação Cliente e Central de despacho. . . 18
2.2.6.2 Aplicação Cliente e Google APIs . . . 18
2.2.6.3 Aplicação Cliente e API Paypal . . . 19
2.2.6.4 Aplicação Motorista e Central de Despacho . . . 19
2.3 App Cliente . . . 20
2.3.1 Arquitetura geral e Funcionamento . . . 20
2.3.1.1 Mapa Aplicação . . . 21
2.3.2 Interações com outras Entidades . . . 25
2.3.2.1 API Paypal . . . 25
2.3.2.2 API Google . . . 27
2.3.2.3 Central de Despacho. . . 28
2.3.3 Implementação . . . 30
2.4 Conclusão . . . 35
3 Simulador Viagens Táxi 37 3.1 Enquadramento/Estado de arte . . . 38
3.1.1 Sites Similares Globalmente . . . 39
3.1.2 Sites Similares em Portugal . . . 39
3.2 Arquitetura e Especificação . . . 40
3.2.1 Estrutura e Funcionamento . . . 41
3.2.2 Interação com Google API. . . 43
3.2.3 Cálculo Tarifas e Possíveis Trajetos. . . 45
3.2.3.1 Viagem urbana – começa e termina dentro . . . 45
3.2.3.2 Viagem sem retorno – começa dentro e termina fora . . . 46
3.2.3.3 Viagem com retorno – começa fora e termina dentro . . . 46
3.2.3.4 Viagem sem retorno – começa e termina fora . . . 47
3.2.4 Implementação . . . 48 3.3 Conclusão . . . 54 4 Conclusões 57 Bibliografia 59 A Acrónimos 61 ix
Lista de Figuras
2.1 Estrutura Arquitetura Geral . . . 11
2.2 Amostra das ligações da tabela cliente . . . 12
2.3 Amostra das ligações da tabela viagem . . . 13
2.4 Arquitetura do sistema GCM . . . 14
2.5 Marcadores no mapa Google. . . 16
2.6 View das opções do taxista . . . 17
2.7 Mapa do processo de uma mensagem . . . 22
2.8 Mapa do processo da escolha de uma viagem . . . 23
2.9 Mapa do processo de uma viagem. . . 24
2.10 Estados das interações de uma viagem . . . 29
2.11 Estados recebidos pela aplicação e enviados pelo servidor . . . 34
3.1 Estrutura Arquitetura do Simulador . . . 40
3.2 Página web do simulador . . . 41
3.3 Página web, viagem com várias paragens . . . 42
3.4 Página web, API Places em funcionamento . . . 43
3.5 Página Google Maps, exemplo da visualização de uma rota . . . 44
3.6 Simulação de uma viagem urbana . . . 46
3.7 Simulação de uma viagem sem retorno . . . 47
3.8 Simulação de uma viagem com retorno . . . 48
3.9 Simulação de uma viagem sem retorno especial . . . 49
Lista de Blocos de Código
2.1 Inicialização Paypal . . . 25
2.2 Tratamento resultado Paypal . . . 26
2.3 Inicialização do Google API Client . . . 27
2.4 Métodos HTTP na classe Singleton . . . 30
2.5 Pedido HTTP na classe para criar uma viagem . . . 31
2.6 Tratamento da resposta do pedido HTTP na classe para criar uma viagem . . . . 32
2.7 Excerto do método de tratamento de mensagens GCM . . . 34
3.1 Inicialização do mapa e caixa de pesquisa . . . 49
3.2 Função para verificar se ponto dentro ou fora do polígono . . . 50
3.3 Excerto para tratamento de novas rotas . . . 51
3.4 Pedido para uma rota . . . 51
3.5 Excerto para o tratamento do resultado de um pedido . . . 52
3.6 Excerto para o calculo do preço 1 . . . 53
3.7 Excerto para o calculo do preço 2 . . . 53
Capítulo 1
Introdução
A evolução da web para a versão 2.0, permitiu o crescimento da Internet. Neste momento qualquer pessoa tem acesso através de um smartphone ou computador. As operadoras móveis modificaram os seus planos para acompanharem esta evolução. Agora no mercado, existe pacotes de telemóvel em que o mais importante é a quantidade de tráfego, que fornecem aos utilizadores. É nestas mudanças que se percebe, que cada vez mais, os utilizadores navegam na Internet usando o telemóvel ou utilizam aplicações que requerem uma ligação à Internet. Com esta evolução, deu-se a criação de vários mercados baseados em plataformas móveis e na web.
O mercado das aplicações tem crescido a um ritmo exponencial, em grande parte deve-se ao sucesso dos smartphones. Em 2008 foram vendidos cento e trinta e nove milhões em todo o mundo. Ao longo dos anos este número não parou de crescer, em 2013 foram vendidos mais de novecentos milhões de smartphones e espera-se que em 2017 aumente em 34% [1]. Este crescimento tão elevado refletiu-se no mercado das aplicações, em Fevereiro de 2016 foram contabilizadas dois milhões de aplicações, disponíveis na loja para dispositivos Android. Com mais de vinte mil milhões de downloads [2]. Estes números, mostram o interesse dos utilizadores pelas aplicações móveis, o fácil acesso a dados móveis permite que muitas destas aplicações corram utilizando a Internet.
Os mercados baseados em aplicações móveis surgiram do crescimento anterior. A mais recente versão de jogos são gratuitos, mas para ter certos prémios ou desbloquear níveis mais rapidamente, é necessário pagar. Este tipo de aplicações tornaram-se muito comuns no mercado e rentáveis. A empresa Zynga, fundada em 2007, é focada na criação de jogos deste tipo, em 2013 fez mais de oitocentos e setenta milhões de dólares em lucro [5].
Surgiram outros tipos de aplicações, para serem utilizadas em conjunto com outros serviços, como a Uber e a Cabify, que são usadas para requisitar um transporte. Este tipo de mercado encontra-se em grande crescimento. As empresas de táxi quiseram aproveitar o exemplo e implementar uma aplicação, para utilizar em conjunto com os seus táxis. O facto de ainda ser um mercado em expansão, é uma mais valia para este tipo de empresas.
O crescimento da Internet também permitiu a evolução de serviços e empresas. Nesta altura 1
2 Capítulo 1. Introdução quase todas as empresas possuem um website, onde mostram informações e catálogos. Existe muitas empresas que cresceram a partir de um website. Como por exemplo a Farfetch, foi criada em 2008 e é um site para venda de roupa. Nunca teve uma loja física, desde a sua fundação que as vendas são feitas a partir do site. A Internet tornou-se um mercado e um local de suporte a muitas empresas. O simulador desenvolvido integra-se neste último, utiliza o seu site como mecanismo, para informar e melhorar o serviço prestado aos seus clientes. A empresa em questão decidiu criar uma ferramenta, que informa os clientes dos preços das viagens e por consequência mais clientes utilizarão os seus serviços.
1.1
Objetivos
A aplicação MyNetTaxi foi criada para entrar no mercado das aplicações móveis, em conjunto com o serviço de táxis que a empresa, que está sediada no Luxemburgo, possuí. Esta foi criada para fornecer aos clientes, uma maneira simples de fazer uma viagem de táxi. Em poucos minutos e usando o seu telemóvel, um cliente pode pedir um veículo e ser avisado automaticamente quando ele chega ao local onde se encontra. No fim tão comodamente como pediu o táxi, pode pagar a viagem. Isto permite ao utilizador ganhar minutos no seu dia e eliminar intermediários, que tornam o processo de pedir um táxi demorado. Com esta aplicação, não é necessário ligar para uma central de despacho ou dirigir-se a uma praça de táxis. O objetivo principal desta, é ocupar o lugar que a Uber criou noutros países, mas que ainda não fez a transição para o Luxemburgo. Acima de tudo, pretende melhorar o seu serviço, para satisfazer os clientes e atrair novos.
O simulador implementado, foi requisitado por uma empresa de táxis da cidade do Porto. Tinha como objetivo criar uma plataforma para tornar o serviço mais transparente. Este pretendia que um utilizador, tivesse a oportunidade de saber sempre, quanto vai pagar no final de uma viagem, em qualquer altura do dia. O serviço de táxi como é conhecido hoje em dia, não evoluiu muito. Com a ajuda das novas tecnologias, pode evoluir para beneficiar os seus clientes. Este é o objetivo principal do simulador criado.
1.2
Organização do relatório
Ao presente capítulo introdutório seguem-se dois capítulos que abordam os vários trabalhos desenvolvidos durante o tempo de estágio, nomeadamente a aplicação Android MyNetTaxi e o simulador web para viagens de táxis. De seguida, irei resumi-las de forma estruturada.
No capítulo 2, é feita a descrição do trabalho realizado para a implementação da aplicação MyNetTaxi. Este começa com um introdução sobre o mercado em que esta se insere. Posterior-mente é feito um enquadramento e explicado o estado de arte, este fala sobre o crescimento do mercado e as aplicações existente que tiveram mais influencia para a criação deste projeto. No subcapítulo seguinte é explicada a arquitetura geral de todo o sistema onde a aplicação se insere
1.2. Organização do relatório 3 e as suas entidades e como interagem. A seguir é explicada a aplicação em si, quais são as suas funcionalidades e como está estrutura. Também é explicado com que entidades interage e como é feita essa interação. Por último é detalho o processo para a implementação desta aplicação e são apresentadas as conclusões em relação ao trabalho desenvolvido.
No capítulo 3, é apresentado o simulador de viagens de táxi. Começa com uma introdução, onde é explicado o mercado dos táxis e sua evolução. Depois é feito o enquadramento deste simulador no seu mercado e também são explicadas as alternativas existentes. O subcapítulo que se segue explica a tecnologia por trás do simulador, a sua arquitetura, interações com outros serviços. Além destes é também explicado o algoritmo para calcular o custo e como foi realizada a sua implementação. Este capítulo termina com uma conclusão.
Por último, no capítulo 4, é feita a conclusão de todo o trabalho realizado na empresa, que não são só os apresentados neste relatório. Também foram realizados alguns trabalhos de menor importância e dificuldade, como websites estáticos para mostrar conteúdo.
Capítulo 2
MyNetTaxi
A evolução do smartphone e das redes móveis [1] permitiu a criação e desenvolvimento de novos serviços. Estes permitiram não só ajudar os seus utilizadores em tarefas do dia à dia mas também permitiu a criação de alternativas a serviços já existentes. Devido ao rápido crescimento das tecnologias móveis, muitas das grandes industrias mais antigas não acompanharam este crescimento e novos serviços mais atuais e de fácil uso para os consumidores foram criados. Estes, em muitos casos, são uma melhor alternativa aos serviços já existentes e são uma concorrência. Um dos serviços que enfrenta este problema é o de táxi. Manteve-se mais ou menos estático desde a sua criação até esta era. Com a evolução dos carros utilizados e os serviços de despacho, pouco mais foi alterado neste serviço.
As novas tecnologias criaram uma nova forma de economia, uma economia de partilha peer-to-peer. Por exemplo, as plataformas collaborative consumption ou on-demand economy apareceram depois do crescimento da Internet e redes móveis e por consequência dos smartphones. Estas reinventaram os comportamentos dos mercados tradicionais, as plataformas nesta área da economia correspondem diretamente às necessidades do cliente na hora, fornecendo bens ou serviços.
Neste momento existe um grande crescimento destas economias na área da partilha de carros. Existem agora vários serviços que são uma alternativa segura, cómoda e mais prática que os táxis. Estas plataformas no mercado dos transportes não inventaram nada. Apenas melhoraram um serviço com o uso dos smartphones e da internet. Isto gerou uma grande controvérsia dentro da industria dos táxis e foi o sinal necessário para começar a melhorar e juntarem-se às novas tecnologias.
Estes novos serviços foram criados recentemente e ainda não tem a segurança e exposição do serviço de táxi. Os táxis remontam ao século 17 [8] e ainda são muito utilizados nos dias de hoje. Isto é uma grande vantagem em relação aos novos serviços, pois não são tão conhecidos nem existem em tantas cidades do mundo como os táxis. Neste momento a grande falha e desvantagem em relação aos novos serviços, é a falta de tecnologias ligadas aos táxis, é mais fácil pedir um carro através um aplicação da Uber do que pedir um táxi.
6 Capítulo 2. MyNetTaxi Devido a esta falha tecnológica e por consequência perda de clientes, foi criada a aplicação MyNetTaxi, a pedido de uma empresa de táxis sediada na cidade Luxemburgo. Para utilizar um táxi, antes da aplicação, era necessário ligar para a empresa e requisitar um veiculo ou ir até uma praça de táxis. Este modo de utilização é uma grande desvantagem para os novos serviços, pois nestes basta ligar a aplicação, indicar o destino e passado poucos minutos o carro que se encontrava mais próximo aparece na localização do utilizador. É bastante mais fácil e prático utilizar este método pois elimina intermediários desnecessários.
O grande problema do serviço de táxi atual, em relação às aplicações de car-sharing, é a necessidade do utilizador ter de procurar por um táxi ou telefonar a pedir um. Nas grandes cidades os táxis estão parados à espera de serviço em locais de grande procura, como o aeroporto, estação de comboios ou centros comerciais. Isto faz com que muitos locais na cidade tenham pouca oferta. Sendo necessário pedir um táxi através da central, o veículo pedido pode nem chegar ao cliente, pois aceita outro cliente no caminho. Ou o cliente original pode chamar um táxi livre que passe na rua. As aplicações tipo Uber ou Lyft eliminaram esta necessidade de procura.
O objetivo do desenvolvimento da aplicação MyNetTaxi é melhorar essa procura, utilizando um serviço regularizado e bem implementado na sociedade Sendo o serviço de táxi bastante utilizado e conhecido, é uma grande vantagem para a implementação da aplicação. A criação desta aplicação torna este serviço mais moderno, mais fácil e cómodo para os utilizadores, pois podem pedir um táxi em casa e receber um notificação que o condutor já chegou à origem ou até saber que o condutor cancelou e assim pedir outro.
Neste capítulo irá ser descrito a implementação da aplicação MyNetTaxi. Começando por um enquadramento e estado de arte, em que irá ser falado das aplicações já existentes e que influenciaram o desenvolvimento da aplicação em questão. Terá uma descrição da arquitetura geral de todo o sistema, do qual faz parte a aplicação para os clientes. Também será explicado todas as entidades que fazem parte do sistema e suas interações com a aplicação do cliente mas também com a aplicação utilizada pelos taxistas.
Com mais detalhe será explicado a aplicação cliente, onde se falará com mais pormenor da arquitetura e funcionamento da mesma, também nesta secção será explicado com detalhe a interação do cliente com todas as entidades com as quais tem que comunicar e irá ser descrito a implementação da mesma. Também terá uma descrição da aplicação utilizada pelos taxistas, pois esta é uma parte fundamental em todo o sistema. E por fim irão ser apresentados os resultados e a conclusão do capítulo.
2.1. Enquadramento/Estado de arte 7
2.1
Enquadramento/Estado de arte
2.1.1 Consumo Colaborativo
O desenvolvimento da Web 2.0 permitiu o crescimento em massa da partilha de conteúdos, pois este deu ao utilizador a possibilidade de participar, cada um pode contribuir com conteúdos e ligaram-se uns aos outros. Com esta nova facilidade de partilha surgiu uma nova economia de partilha e um novo conceito de consumo. [4]
O avanço nas tecnologias web, permitiu a criação do conceito consumo colaborativo dentro da economia de partilha. Esta economia é um fenómeno que emergiu a partir do desenvolvimento tecnológico da informação e das comunicações, também das comunidades e comércios web. O consumo colaborativo faz parte da economia quotidiana e tem por base a partilha entre dois indivíduos de bens ou serviços. Este modelo é usado em mercados online através de plataformas, onde os utilizadores geram e partilham o seu próprio conteúdo ou então contribuem no conteúdo de outros. [9]
Esta nova forma de consumo é operada através de plataformas tecnológicas, como um website ou uma aplicação de smartphone. No entanto depende bastante da dinâmica social para haver a partilha e a colaboração. [9]
O crescimento em massa da partilha começou a partir de sites como o Napster, uma plataforma de partilha digital de músicas e filmes, os ficheiros eram transferidos via peer-to-peer. Apesar de ilegal, mais tarde foi encerrado. Este site despoletou a criação de várias alternativas. Como por exemplo, sites que utilizam o protocolo Bittorrent ou então evoluíram para plataformas de partilha legais, como o Spotify ou o iTunes. [4]
A Internet permitiu a origem de diversas formas de partilha [4], como o Youtube. Este fornece aos utilizadores um espaço online onde partilhar os seus vídeos. O Facebook e o Twitter, são páginas web de partilha social, de fotos ou apenas pensamentos. Existem muitos outros métodos de partilha sem fins lucrativos ou troca de bens para os utilizadores.
Por outro lado a atualização da web permitiu o sucesso de websites, como o Ebay [4] ou o OLX que permite a venda de bens em segunda mão. O Airbnb possibilita aos usuários listar a sua casa ou arrendar uma. Por fim foram criadas várias plataformas para a partilha de transporte, tais como o Blablacar, Uber ou Cabify. É nesta última economia, que se vai focar este capítulo, visto que é onde se enquadra a aplicação desenvolvida.
Na última década a partilha de carros tornou-se um fenómeno mundial, é uma ótima alternativa à compra do mesmo. Consiste num grupo de indivíduos que pagam o acesso a uma frota de automóveis, são usados quase exclusivamente para viagens curtas. [3]
A Zipcar foi uma das primeiras empresas a utilizar o poder do smartphone em conjunto com a inovação mencionada anteriormente. Para utilizar é necessário registar no site e posteriormente
8 Capítulo 2. MyNetTaxi recebe um cartão que serve de chave automática para abrir as portas de cada veículo. Quando quiser alugar um carro, através da aplicação pode escolher o mesmo no local de pick up mais próximo e dirigir-se a ele com o cartão que será associado a esse veículo. Os custos podem ser diários, mensais ou anuais e todas as despesas estão incluídas. Todo o processo é automático através da aplicação, sem envolver qualquer responsável da empresa. [3]
O crescimento exponencial da Zipcar, desde a sua fundação registou um crescimento de mais de 100% todos os anos. Isto despoletou o interesse das grandes marcas de automóveis que oferecem os seus carros, incluindo a Daimler Bnez’s (Mercedes), Car2Go, BMW Drivenow, entre outros [4]. A razão para esta atenção, deve-se não só ao exemplo da Zipcar, mas também a falta de vontade dos jovens em adquirir uma viatura [4].
Mas este tipo de aplicações exigem a compra e manutenção de veículos, é neste ponto que empresas como a Uber, Cabify, Lyft e Blablacar inovam. Porque são os donos dos carros que os alugam e conduzem.
Estas empresas pensaram numa solução para de melhorar um mercado bastante rentável. Para tal eliminaram os custos da aquisição de veículos e por consequência não tem custos de armazenamento ou manutenção. São estas plataformas as que mais se enquadram no conceito de consumo colaborativo e na economia partilha de automóveis. Elas são a definição do conceito, pois para funcionar é necessário uma aplicação móvel e a dinâmica social está presente, de outra forma não existem veículos disponíveis para requisitar.
2.1.2 Empresas Modelo
Com o desenvolvimento da economia de partilha dos transportes foram surgindo novas plataformas e alternativas [14]. As mais predominantes no mercado neste momento são a Blablacar, Uber e Lyft.
Apesar do conceito um pouco diferente, a Blablacar foi das primeiras empresas a surgir no mercado e desde então cresceu bastante. Com uma comunidade de mais de 25 milhões de membros espalhados por 22 países [14]. É uma plataforma, cujo objetivo é conectar condutores e passageiros que viajarão para o mesmo local e desta forma partilhar custos. Não existe qualquer retorno monetário para o condutor ou para a empresa. Esta plataforma é uma prova real do crescimento da economia dos transportes.
As grandes referências e exemplos da aplicação desenvolvida são, a Uber e a Lyft. É nestas duas, mais especificamente na Uber, que se vai focar explicação seguinte. De forma a entender a base da ideia do desenvolvimento da aplicação.
Ambas as aplicações fornecem vantagens e preços mais baixos, comparando com o sistema tradicional de despacho de táxis. São as duas bastante similares no seu funcionamento com os utilizadores. Quando um passageiro quer uma viagem, utiliza a aplicação para submeter um pedido com o destino pretendido. O pedido é encaminhado para o condutor mais próximo
2.1. Enquadramento/Estado de arte 9 disponível. Enquanto o passageiro espera pode ver vários dados relativos ao condutor, como o seu nome, o tipo de carro que conduz, a sua localização em tempo real e quanto tempo demora a chegar. Na próxima subsecção, irá ser descrito com mais pormenor o sistema e a arquitetura da aplicação da Uber.
2.1.3 Uber
A Uber, neste momento, está presente em quinhentas e sete cidades, distribuídas por sessenta e seis países. Segundo a revista de negócios Forbes está avaliada em sessenta e oito mil milhões de dólares [7]. A sua significativa expansão obrigou a uma atualização da arquitetura e tecnologias back-end, de modo a conseguir acompanhar o crescimento da empresa.
Como muitas empresas a Uber começou com uma arquitetura rudimentar [17], criada para funcionar numa única cidade. No início, uma simples arquitetura, usando um único código base fazia sentido, pois completava as tarefas pedidas e era de fácil manutenção.
Mas o rápido crescimento para novas cidades e a introdução de novos componentes, tornou a simples arquitetura deficiente. Ter que adicionar novos serviços e corrigir bugs num único repositório tornou-se bastante laborioso. Para melhorar toda a plataforma e torna-la facilmente escalável, os engenheiros da Uber, reescreveram todo o sistema numa arquitetura orientada a serviços (SOA) [19].
Uma SOA permite que os componentes de uma aplicação funcionem como serviços, que são ligados através de protocolos de comunicação. Esta proporciona que cada área da aplicação seja escrita com uma framework específica e tenha a sua base de dados dedicada.
O crescimento originou um problema de espaço na base de dados, esta estava desenhada em PostgreSQL e armazenava toda a informação. Mais de metade da capacidade era usada para viagens. No início esta lotação era suficiente para o número de viagens executadas, todavia com a expansão para novas cidades e países o espaço disponível tornou-se limitado.
Toda a informação das viagens é guardada para estudos posteriores, de modo a fornecer melhor suporte aos condutores e passageiros, prevenir fraudes e desenvolver novas funcionalidades. Consequentemente o armazenamento destes dados é fundamental para melhorar o serviço. Conforme os vários testes efetuados, a nova base de dados tinha que ser robusta, sem perda de dados e ter uma manutenção fácil. Devido ao constante crescimento da empresa deveria ser escalável em termos de armazenamento e número de operações.
A única tabela PostgreSQL estava tão extensa que para adicionar uma coluna ou índice era necessário ficar offline. Por conseguinte a nova base de dados necessitava ser desenhada de forma a que a sua atualização fosse simples, de modo a não perturbar os serviços. Os engenheiros da Uber decidiram dividir as duas bases de dados, uma PostgreSQL para toda a informação não relacionada com viagens e outra base de dados schemaless para as viagens.
10 Capítulo 2. MyNetTaxi fulcrais, para o bom funcionamento das viagens e manutenção de dados. O facto de ser fragmentada, permite distribuir os fragmentos em múltiplos servidores, estes correspondem a espaços de tabelas MySQL. Outro aspeto é o facto de ser um modelo append-only, o que significa que não permite modificar células depois de escritas, isto evita a corrupção de dados. [17]
Um dos serviços inovadores da Uber é a estimativa do tempo de chegada (ETA) da viagem, ou seja fornecem o tempo estimado que irá demorar a chegar ao destino. Nos primeiros anos usavam uma combinação de mecanismos de roteamento [13]. Combinavam estes com um serviço próprio, que fazia ajustes à estimativa original, usando um histórico de dados de viagens similares no mesmo tempo e espaço. Um dos problemas deste método acontecia nas novas cidades, uma vez que não tinham dados suficientes para melhorar a ETA.
Este foi criado em 2014, continuam em estudos e melhorias de um novo motor de roteamento que suporta o estado do trânsito em tempo real. Toda a rede de estradas está modelada através de um grafo, em que os nós são intersecções e as arestas ruas. Estas têm pesos que representam a métrica: distância do segmento ou tempo que demora a atravessar esse segmento. Este novo motor é um misto de vários algoritmos de pesquisa combinados com uma pré-computação dos nós. Divide o grafo em fragmentos para uma maior rapidez de resposta, consegue também atualizar o estado do trânsito através dos pesos das arestas. [13]
A Uber neste momento está presente em inúmeras cidades, mas não existe em Luxemburgo. Daí a ideia para complementar um serviço de táxi já existente com um serviço como o da Uber que já mostrou ser eficaz e produtivo.
2.2
Arquitetura Geral
A aplicação desenvolvida insere-se num sistema com um arquitetura estruturada, que está dividida em back-end e front-end. Tanto a aplicação do cliente como a do motorista fazem parte do front-end, visto que são duas interfaces com interação por parte dos utilizadores e não tem qualquer relação com o processamento das tarefas requisitadas.
No back-end é onde se processa toda a informação e pedidos, este contém todos os serviços necessários para o correto funcionamento das aplicações e todas as funcionalidades que oferecem. É constituído pela central de despacho e APIs externas que são usadas em momentos específicos. A central de despacho é a componente mais importante de todo o sistema, uma vez que é o centro de ligação das duas aplicações. É na central, mais concretamente na base de dados, que são armazenados todos os dados. Para a central comunicar com as aplicações e desta forma ligar ambas as partes que constituem o sistema, é utilizado o serviço Google Cloud Messaging. Este permite enviar informação do servidor (central de despacho) até uma aplicação num dispositivo com o sistema operativo Android (aplicações cliente e táxi).
2.2. Arquitetura Geral 11
Figura 2.1: Estrutura Arquitetura Geral
2.2.1 Central de Despacho
A central de despacho, como foi mencionado anteriormente, é o centro de todas as operações. Esta serve de intermediário entre ambas as aplicações e é também onde é armazenada toda a informação. Desde a informação dos utilizadores registados, à informação e estado dos motoristas e todos os dados relacionados com as viagens.
2.2.1.1 Servidor
O servidor da central foi escrito na linguagem PHP e é neste que estão escritos e estruturados todos os métodos que realizam os pedidos das aplicações. A comunicação entre o servidor e as aplicações é realizada através do protocolo HTTP. É um protocolo pedido-resposta entre um cliente e um servidor, os pedidos são em formato Hypertext. São mensagens de texto estruturadas como o HTML ou, no caso deste servidor, no formato JSON, é um formato de mensagens leve com uma estrutura de pares nome/valor. O HTTP tem vários tipos de pedidos, mas o servidor PHP só utiliza dois tipos, o GET e o POST. Ambos executam tarefas diferentes de acordo com a estrutura do método requisitado.
Um pedido GET, serve somente para a visualização de dados e não tem qualquer efeito ou ação [15]. Tendo como exemplo, saber a posição geográfica de um dado motorista, é utilizado o pedido GET no método getInfoDriver(), que retorna como resposta várias informações, incluindo as coordenadas GPS.
12 Capítulo 2. MyNetTaxi pelo respetivo método e retribui uma resposta de sucesso ou erro [16]. Como por exemplo, guardar novos dados numa tabela da base de dados, o método para registar um cliente recebe os dados inseridos pelo mesmo e guarda-os na respetiva tabela.
2.2.1.2 Base de dados
A outra componente da central, é a base de dados MySQL. É nela que é guardada toda a informação submetida por ambas as aplicações. É uma base de dados relacional, isto é os dados estão organizados em várias tabelas com uma chave única para identificar as linhas. Uma tabela representa uma entidade tipo, como o utilizador ou motorista, as linhas representam instâncias dessa entidade.As colunas apresentam os valores atribuídos à entidade.
Para aceder à base de dados é utilizada a linguagem SQL. Esta permite introduzir, eliminar, atualizar ou consultar dados numa determinada tabela. Se o método for efetuado com um pedido GET, este vai realizar uma query de consulta a uma determinada tabela, que retribui como resultado a lista de linhas que estão de acordo com a pesquisa. No caso de um pedido POST, dependendo do método escolhido, podem ser realizadas três queries distintas, inserir, atualizar ou apagar dados de uma determinada linha de uma tabela. Por exemplo, o método para criar um novo cliente, insere uma nova linha na tabela clientes com os dados inseridos pelo mesmo no formulário de registo da aplicação.
Figura 2.2: Amostra das ligações da tabela cliente
A estrutura está construída de forma a suportar toda a arquitetura do sistema. Armazena todas as informações referentes aos clientes e cada mensagem ou sugestão que escreveram. Os dados são distribuídos por várias tabelas que se relacionam com a tabela cliente através do ID, como é possível visualizar na imagem 2.2. As contas dos motoristas estão também desenhadas
2.2. Arquitetura Geral 13 na base de dados e relacionam-se com as viagens, mas nunca com os clientes.
A tabela das viagens junta um cliente a um motorista numa dada viagem, esta é constituída por várias tabelas que contem toda a informação da mesma. Existe uma tabela com toda a informação inicial, como a posição geográfica da origem, o Id do cliente e do motorista e também o custo da viagem. Uma viagem passa por vários estados, como tal existe uma tabela para o estado das viagens. Por fim uma com o pagamento, que inclui o custo e o tipo de pagamento, na imagem2.3 é possível ver essas mesmas ligações, onde a tabela gges_request é a tabela das viagens. Também é possível verificar a ligação à tabela das reservas, pois quando uma fica ativa, ela torna-se numa viagem.
Figura 2.3: Amostra das ligações da tabela viagem
2.2.2 Google Cloud Messaging
Neste sistema existem dois tipos de comunicação entre as várias plataformas. A comunicação HTTP é feita entre o cliente e o servidor para realizar várias tarefas incluindo iniciar uma viagem ou o login do cliente. Para a aplicação do motorista comunicar com o servidor é utilizado o serviço Google Cloud Messaging. A aplicação envia periodicamente as suas coordenadas GPS, que são enviadas utilizando mensagens GCM. Este serviço é utilizado para atualizar a posição, mas também durante todo o processo de uma viagem. Tanto na comunicação do servidor com o motorista, como também na comunicação servidor e cliente.
14 Capítulo 2. MyNetTaxi servidores e aplicações. As mensagens podem ser enviadas em ambas as direções, do servidor para o cliente (downstream) ou o oposto (upstream). Permite enviar notificações push ou uma mensagem com dados, até 4KB de tamanho. O serviço faz todo o tratamento de escalonamento para a entrega das mensagens.
Figura 2.4: Arquitetura do sistema GCM
A arquitetura do serviço, quando implementado funciona em conjunto com a aplicação e a central de despacho, sendo o servidor GCM de ligação, o intermediário. Quando uma aplicação motorista fica online esta regista-se no servidor GCM e recebe um Id de registo, por consequência envia esse para a central de despacho que tem de o autenticar através do serviço de autenticação no servidor GCM. Quando todas as autenticações forem concluídas é possível começar a enviar mensagens. As mensagens são enviadas com o Id de registos para verificar a autenticidade do utilizador.
Quando é efetuado um pedido de viagem pelo utilizador, a central envia uma mensagem ao motorista escolhido. O Id de registo de cada motorista é guardado na base de dados em conjunto com o seu Id e dados. A partir deste momento toda a comunicação até ao ponto do pagamento é feita através destas mensagens.
2.2. Arquitetura Geral 15 2.2.3 Google API
Quando um cliente pretende inserir uma origem, ele pode escrever a morada na caixa de procura ou selecionar um ponto no mapa, o resultado gera as coordenadas. De forma a este processo funcionar é necessário utilizar uma API externa, o Google Places e Maps respetivamente.
Foram escolhidos estes serviços do Google no projeto porque são gratuitos até um limite, tem bastante documentação e permitem obter os mais diversos dados de uma rota ou um local. Com a API Maps é possível escolher entre a rota mais curta ou mais rápida, rotas sem portagens ou até calcular uma rota secundária. O limite existente não é relevante, pois o Google Maps para Android é ilimitado no plano gratuito e o Google Places tem um limite de mil pedidos por dia. O que neste momento inicial, é um número elevado dado que a aplicação ainda não tem muitos utilizadores.
O Google Maps é responsável pela renderização do mapa nas views para escolher uma origem, destino e táxi. Quando o utilizador escolhe dois pontos, a API retribui as suas coordenadas e respetivas moradas. Posteriormente calcula a rota mais rápida, os quilómetros e a duração da viagem. Na view para escolher o táxi é também a API que permite criar marcadores personalizados com imagens dos táxis, como se vê na imagem 2.5e colocar o respetivo marcador nas coordenadas GPS enviadas por cada uma das aplicações de táxi ativas.
A API Google Places tem a função de retribuir a morada introduzida na caixa de procura. Esta tem várias características de procura, como visualizar a informação de um local ou criar um novo local. No entanto as características relevantes neste projeto são o autocomplete, quando o utilizador começa a escrever uma morada, a função mostra todas as opções possíveis de acordo com o que está a ser escrito. A outra característica utilizada é o Place picker, o utilizador escolhe um ponto no mapa e este retribui a morada.
Em comparação com o sistema da Uber, o processo para calcular a rota e o tempo estimado de chegar, é mais rudimentar. Mas para uma aplicação em funcionamento numa única cidade, num país pequeno como o Luxemburgo, o serviço que a Google disponibiliza é suficiente e bastante completo para o bom funcionamento da aplicação. Dado que oferece todas as funcionalidades num só sistema e deste modo é mais fácil juntar todas num só.
2.2.4 Aplicação Cliente
A aplicação Android para ser utilizada pelos clientes que pretendem viajar de táxi é o elemento com mais foco. Como foi descrito anteriormente, esta aplicação teve como ideia base, o sistema da Uber. O objetivo não era melhorar esse mesmo sistema, que por si só é muito superior e com maior número de engenheiros dedicados. Apesar da Uber já se encontrar em muitos países, ainda não se encontra em Luxemburgo. Então o objetivo da aplicação é criar um sistema idêntico mas utilizando o serviço táxi já existente e por consequência melhorar esse mesmo.
16 Capítulo 2. MyNetTaxi
Figura 2.5: Marcadores no mapa Google
que se vai realizar a curto prazo ou então reservar um táxi para uma viagem com um período de espera maior, como dois dias ou uma semana. Tanto um como o outro, funcionam exatamente da mesma forma, exceto quando se inicia uma viagem, o motorista é imediatamente notificado. Na reserva a viagem é guardada e o utilizador é notificado que a viagem foi reservada com sucesso.
Para escolher uma viagem, a primeira view serve para escolher a origem, pode escolher um ponto no mapa ou inserir uma morada. Ao carregar em continuar a aplicação mostra a view para inserir um destino, que funciona exatamente da mesma forma que a anterior. Depois tem a opção de escolher um táxi disponível no mapa 2.5 ou continuar sem escolher, neste caso será atribuído o táxi mais próximo do local de origem. A escolha da viagem acaba com o resumo da mesma e a possibilidade de inserir comentários, como o local em que o cliente se encontra.
Quando o utilizador carrega em chamar táxi, é iniciado todo o processo da viagem. Começando por ver quanto tempo demora o táxi a chegar e os dados do táxi escolhido ou atribuído para aquela viagem em específico. Quando o motorista chega, a view é alterada para o modo em
2.2. Arquitetura Geral 17 viagem e a partir deste momento, o cliente não pode mais cancelar a viagem. Quando o motorista chega ao destino, a aplicação mostra o preço e as várias opções de pagamento. Depois do pagamento o utilizador pode avaliar o motorista e regressar ao menu principal da aplicação.
2.2.5 Aplicação Motorista
Quando o motorista entra ao serviço tem que entrar e ativar a aplicação. A partir deste momento é feito o registo GCM e começa a enviar as suas coordenadas GPS periodicamente. Se receber um pedido, aparece no ecrã todos os dados dessa viagem, a morada de origem e destino, o nome do cliente e as observações que o mesmo inseriu.
Se aceitar, dá início a uma viagem e por consequência deixa de estar disponível e visível aos outros clientes. No ecrã aparece a morada de origem da viagem e três botões distintos, a figura
2.6mostra o mesmo. Caso o motorista se atrasar devido a trânsito ou outras razões, ele carrega no botão de atraso e insere os minutos extra que vai demorar a chegar ao cliente. Este atualiza imediatamente na aplicação do cliente em questão. Os outros botões têm a função de cancelar a viagem e o outro para informar que já chegou e que o cliente já se encontra no automóvel, ao carregar neste último a viagem para o destino é iniciada. O ecrã é alterado para mostrar a morada do destino e um botão para carregar ao chegar ao mesmo. No fim tem que aguardar a informação de pagamento. Se o utilizador pagar a dinheiro, no ecrã mostra o valor e tem que carregar no botão, que informa que recebeu o dinheiro, para concluir todo o processo. Se o utilizador escolher uma das outras opções de pagamento automático, o motorista é notificado e a aplicação volta ao ecrã inicial e fica novamente disponível.
Figura 2.6: View das opções do taxista
18 Capítulo 2. MyNetTaxi central de despacho e só tem a função de realizar viagens, sendo bastante simples de utilizar.
2.2.6 Interação entre Entidades
O sistema comunica entre as entidades de diferentes formas e protocolos, na imagem2.1é possível visualizar que nem todas as entidades comunicam diretamente ou nem comunicam de todo. A central de despacho é o cento da comunicação, todavia quem cria a interação entra as diversas entidades são as aplicações Android. São estas que, por exemplo iniciam a interação quando um cliente entra ou quando um motorista fica ativo.
2.2.6.1 Aplicação Cliente e Central de despacho
A principal interação é com a central de despacho, sem esta a aplicação torna-se inútil, uma vez que é impossível um cliente registar-se ou fazer login. A interação baseia-se em pedidos HTTP, para receber informações específicas ou para enviar informações para a central, para registar ou atualizar a base de dados.
As comunicações HTTP são todos os pedidos de informação até ao momento em que é enviada uma solicitação para iniciar uma nova viagem, a partir deste momento a interação passa a ser via mensagens GCM. Estas mensagens são maioritariamente da central para a aplicação, excluindo a que é enviada se o utilizador cancelar, esta é enviada por HTTP. Isto é, todas as interações da aplicação cliente para a central são feitas usando o protocolo HTTP. Por outro lado a central responde aos pedidos igualmente via HTTP, ou no caso de uma viagem comunica inteiramente via mensagens GCM. Ao contrário dos pedidos HTTP em que a central responde, no caso de uma mensagem GCM, esta só é enviada quando receber uma mensagem de atualização por parte da aplicação motorista.
2.2.6.2 Aplicação Cliente e Google APIs
Para ter acesso ao mapa e às rotas é necessário a interação com a API do Goggle, neste caso é utilizada a API Maps e Places. O Google oferece uma API dedicada para ser utilizada em sistemas Android. Existe por exemplo uma ferramenta para inserir o mapa automaticamente no layout de uma view. Para utilizar esta API é necessário uma chave fornecida pelo Google, que faz a ligação entre os serviços utilizados e a conta de desenvolvedor.
A vantagem deste serviço é o facto de fornecer os dados e tratar do parsing da informação através das várias funções das APIs. A API Maps permite selecionar pontos e rotas entre eles, sem ser necessário desenvolver algo extra para retirar e interpretar as informações. Esta devolve a rota para os pontos escolhidos e através das suas funções é possível obter os quilómetros e a duração da viagem. A API Places for criada para facilitar ainda mais o desenvolvimento, esta permite procurar latitudes e longitudes através da morada inserida. Para além disso completa
2.2. Arquitetura Geral 19 uma morada que um utilizador insira, mostrando as várias opções para completar o que começou a ser escrito.
2.2.6.3 Aplicação Cliente e API Paypal
Para fazer o pagamento automático é utilizada a plataforma online Paypal. É um sistema que permite a transferência de dinheiro entre indivíduos e negociantes. O Paypal tem uma API que permite adicionar um modo de pagamento através do sistema.
Para integrar na aplicação, é necessário primeiro criar uma conta de negociante e depois utilizar as funções oferecidas pela API, nomeadamente associar a conta criada à aplicação. Quando um utilizador pretende pagar via Paypal, é aberta uma ligação ao site. O utilizador vê o valor que tem de pagar, o nome da empresa e tem que inserir os dados de login para aceitar a transação.O Paypal devolve uma confirmação. Caso seja mal sucedida tem a opção de tentar novamente, de modo a conseguir completar o pagamento. Para um cliente pagar via Paypal tem que ter uma conta normal com dinheiro ou com um cartão multibanco associado.
2.2.6.4 Aplicação Motorista e Central de Despacho
A aplicação de motorista tem uma única interação em todo o sistema e é com a central de despacho. Se for necessário passar a informação para outros dispositivos é a central que está encarregue dessa tarefa. Ao contrário da aplicação cliente não necessita de mapas, já que quando o motorista recebe uma rota, esta vem na forma de morada tanto para a origem como para o destino.
Um motorista possui credenciais para fazer login na aplicação, desde o momento em que se registou na empresa. Estas estão associadas a um Id na base de dados, que contém toda a informação do mesmo. No momento em que a aplicação de um motorista fica ativa, primeiramente é feito o registo GCM para obter o Id GCM, que será autenticado pela central e guardado na base de dados durante a sessão, até o motorista desligar. A partir deste momento são enviadas mensagens GCM para a central, que contém as coordenadas GPS do dispositivo, estas mensagens são enviadas periodicamente porque o motorista está em movimento e as coordenadas têm que ser atualizadas.
Quando existe uma requisição, o motorista escolhido recebe a mensagem e aceita respondendo. Todas estas mensagens e as seguintes, até ao fim de uma viagem são GCM. A única interação entre estas duas entidades que não é GCM, é a interação para o login, esta é feita via HTTP, em que são enviadas as credenciais e a central confirma a sua autenticidade.
20 Capítulo 2. MyNetTaxi
2.3
App Cliente
A aplicação cliente é a aplicação principal deste projeto, pelo motivo de ter sido foi desenvolvida na íntegra, enquanto que os outros elementos já estavam concluídos e só foi necessário fazer pequenos updates ou alterações para funcionarem em conjunto com a aplicação cliente.
2.3.1 Arquitetura geral e Funcionamento
Como já foi referido várias vezes ao longo deste relatório, esta é a aplicação utilizada pelos consumidores que querem utilizar a rede de táxis, esta pretende facilitar esse processo tornando-o mais automático e rápido. Com esta aplicação é possível fazer um pedido para uma viagem imediata, ou então reservar um veículo para uma viagem futura. Ambos os pedidos funcionam de igual forma, o cliente escolhe o ponto de origem e de destino e depois pode escolher um dos táxis disponíveis no mapa ou seguir sem escolher, neste caso é selecionado o veículo mais próximo. Por fim, aparece o resumo da viagem e a possibilidade de inserir observações. Se estiver a ser criada uma reserva aparece a opção para escolher o dia e a hora, a aplicação tem em conta a hora e o dia naquele momento e não permite selecionar uma viagem com menos de uma hora de diferença para a hora atual. Ao criar a reserva é enviada a confirmação e a aplicação regressa ao início.
Se o utilizador estiver a criar uma viagem, quando ele carrega no botão para chamar táxi, é imediatamente enviada a notificação ao condutor selecionado e inicia-se o processo. Inicialmente aparece os dados do motorista e quanto tempo ele demora a chegar à morada de origem, quando o táxi chegar mostra que está em viagem e para aguardar. No fim, a aplicação mostra o preço e as opções de pagamento, se o utilizador escolher dinheiro tem que aguardar que o motorista confirme na aplicação dele que recebeu o pagamento. No caso de escolher o pagamento via Paypal, é direcionado para o website do Paypal para confirmar a comissão. Se escolher o modo de pagamento a crédito, a aplicação passa diretamente para a avaliação do motorista, isto porque só mostra esta opção aos utilizadores registados nesse serviço. Depois de todas as verificações aparece a opção para avaliar o motorista, esta pode ir de zero a cinco. No fim o utilizador é redirecionado para o menu principal da aplicação e o processo é dado como concluído no lado da aplicação e da central de despacho.
Há vários pontos a ter me consideração durante o processo de uma viagem ou reserva. Estes são funcionalidades que existem ou métodos que garantem o bom funcionamento e fluidez das viagens, tanto para os utilizadores como para os motoristas. Quando um usuário escolhe a origem ou destino, tem a opção de escolher a partir do seu histórico. Quando ele completa uma viagem as moradas de origem e destino são guardadas automaticamente na base de dados e qualquer uma pode ser escolhida durante a criação de uma viagem. Na view de selecionar um táxi, aparecem no mapa todos os táxis ativos naquele momento e encontram-se no local em que o seu ponto se encontra no mapa. Ao carregar em qualquer um deles, é possível visualizar as suas informações, como o número do táxi, o nome, a média de todas as avaliações que recebeu e o número de avaliações que já recebeu. Se o utilizador quiser selecionar aquele táxi em específico
2.3. App Cliente 21 basta, carregar no botão para chamar táxi ou então carrega em fechar para regressar ao mapa. Um dos pontos importantes acontece quando o cliente fecha a aplicação depois de chamar um táxi, quando ele voltar a abrir, apresenta um aviso que tem uma viagem a decorrer e é forçado a ir para a view da mesma, no ecrã aparece o estado da viagem naquele momento. Sempre que a aplicação é aberta é realizada uma verificação para ver se existe alguma viagem em curso ou se existe alguma reserva que vai começar ou já começou. Se o utilizador abrir a aplicação e uma reserva ficar ativa, ele é forçado a ir para a view de viagem, que é um processo exatamente igual ao de uma viagem normal.
Para cancelar uma reserva é exclusivamente através do site. É possível aceder a este no painel “escondido” no menu inicial. Neste painel, os utilizadores podem enviar uma mensagem ou sugestão ou então sair da conta. As mensagens e sugestões são enviadas diretamente para o administrador do serviço e é possível visualizar o histórico das enviadas anteriormente. Quando um utilizador abre a aplicação pela primeira vez ou quando não existe nenhuma conta aberta, o menu principal são dois botões. Um para entrar com uma conta, em que o utilizador tem que inserir as credenciais para entrar, que são o email de registo e a palavra passe escolhida. No caso de ser um cliente novo, ele seleciona o botão de registo, onde insere todos os dados requisitados e só depois é que pode passar para o formulário de login.
2.3.1.1 Mapa Aplicação
A aplicação foi desenhada para ser de fácil interação por parte do utilizador, o objetivo principal é criar novas viagens ou reservas. Por esta razão o menu principal é inteiramente dedicado a essas funcionalidades. Como é uma aplicação simples, com um objetivo claro, não foram criadas muitas mais opções aos utilizadores. As funcionalidades extras existem para dar ao cliente a hipótese de comunicar diretamente com um responsável, dado que um utilizador pode querer uma dúvida ou até mesmo, pode ter uma sugestão para melhorar o sistema.
No canto superior esquerdo do menu principal, existe um botão para mostrar as opções menos importantes, é possível visualizar na primeira imagem da figura 2.7. A partir deste menu é possível aceder à área pessoal do utilizador que redireciona para o site, em que pode alterar os seus dados ou cancelar reservas. Também pode sair da conta na aplicação, ao carregar em logout. Se selecionar o botão mensagens, exibe o histórico de mensagens enviadas e o botão para criar uma nova mensagem. Que consiste numa view com uma caixa de texto e um botão para enviar. O menu de sugestão tem um layout igual, a diferença está no local onde as mensagens são guardadas na base de dados e o título que aparece na mensagem que o administrador recebe. A separação dos destes dois tipos de mensagens foi por uma questão de organização por parte do administrador.
Quando um utilizador quer iniciar uma viagem ou fazer uma reserva, carrega nos respetivos botões no menu principal. Como é possível visualizar na imagem 2.8, ambos os caminhos são iguais até ao momento do resumo da viagem.
22 Capítulo 2. MyNetTaxi
Figura 2.7: Mapa do processo de uma mensagem
A primeira janela tem a função de escolher a origem, para tal basta arrastar o mapa para o sítio pretendido. A morada é atualizada na barra ou o utilizador pode escrever uma morada na caixa de procura. É nestas views que entram os serviços do Google. No canto inferior esquerdo existe o botão do histórico, este é diferente para a origem e destino mas a estrutura e método de utilização são iguais. No canto inferior direito está o botão para continuar e mostrar o mapa, para escolher o destino. Este é igual à origem com a exceção de que aparece a caixa da origem com a morada previamente escolhida, também existe no mapa o marcador da origem.
Depois de escolher uma morada de origem e destino, é dada ao utilizador a opção de selecionar um táxi na view seguinte. Se este não pretender, basta carregar em continuar e ser-lhe-á atribuído o mais próximo. No mapa aparecem todos os táxis disponíveis naquele instante, ao carregar num qualquer aparece os vários dados dele e as opções para chamar o táxi ou fechar.
Ao chamar o táxi aparece o resumo da viagem, se o utilizador selecionou um táxi apresenta o nome e a imagem do mesmo. Se não escolheu, não aparece nada, pois só vai ser designado um táxi quando se fizer a verificação do veículo mais próximo. Esta é feita quando se inicia o
2.3. App Cliente 23
Figura 2.8: Mapa do processo da escolha de uma viagem
processo da viagem. Se o utilizador estiver a criar uma reserva, da mesma forma, aparece a opção para escolher a hora e dia e no próximo passo é enviada a reserva e a aplicação regressa ao início.
A partir do momento em que um utilizador carrega em chamar táxi é iniciada uma viagem, a figura 2.9é o mapa do processo de uma. Inicialmente é enviada uma mensagem para o motorista em questão, enquanto este não aceita aparece no ecrã para aguardar, em conjunto com a opção de cancelar, é possível visualizar em 2.9 fig. 1. Se o motorista rejeitar o pedido, o cliente é
24 Capítulo 2. MyNetTaxi
Figura 2.9: Mapa do processo de uma viagem
notificado e pode escolher entre cancelar a viagem ou procurar outro táxi. Se o motorista aceitar, a view muda para informar que o táxi está a caminho e qual é o seu nome, está representado na imagem 2.9fig. 2. Mostra também o tempo estimado que o motorista demora a chegar à morada de origem. O utilizador também tem a opção de cancelar a viagem. Quando o táxi chega o ecrã mostra um aviso e informa que a mesma está a decorrer. A partir deste ponto o utilizador não tem a opção de cancelar a viagem, é o que retrata a 2.9 fig. 3.
No fim da viagem, o cliente pode ver o custo total e as várias opções de pagamento, como é possível verificar na 2.9fig 4. Sendo a dinheiro, através do Paypal ou caso seja um utilizador a crédito, aparece a opção para pagar usando esta variante. Ao escolher uma das opções é feita a
2.3. App Cliente 25 verificação necessária e por fim aparece a view para avaliar o motorista numa escala de zero a cinco, que é a última imagem da figura2.9.
Todo o funcionamento da aplicação é de fácil utilização e intuitivo. A aplicação foi desenhada para que qualquer utilizador, de qualquer faixa etária, consiga utilizar sem dificuldades e sem explicação prévia. O mapa da mesma foi desenhado à imagem da aplicação Android da Uber, com algumas diferenças devido à diferença da estrutura do back-end e às funcionalidades extra que a Uber oferece. A estrutura da aplicação é muito idêntica, a Uber permite iniciar uma viagem sem destino, que pode ser introduzido posteriormente pelo cliente ou pelo motorista. No fim de uma viagem não existe a opção de pagamento, visto que é feito de forma automática. Quando é feito o registo na aplicação da Uber é obrigatório introduzir um cartão de crédito ou uma conta Paypal. Na aplicação MyNetTaxi foi escolhido oferecer várias opções de pagamento ao utilizador, incluindo pagar a dinheiro.
2.3.2 Interações com outras Entidades
Como é possível verificar na imagem2.1 a aplicação do cliente comunica com várias entidades, sendo a mais importante a interação com a central de despacho. As restantes também tem um valor significativo, dado que sem os mapas seria impossível escolher as moradas. Enquanto que a interação com a API Paypal não tem muita influência no bom funcionamento da aplicação, uma vez que é meramente mais uma opção de pagamento.
2.3.2.1 API Paypal
Existem muitas opções que podem substituir o Paypal, como introduzir diretamente o cartão de crédito ou outros serviços similares a este. Contudo se fosse utilizado o cartão, tinham que ser criados mecanismos de segurança para proteger os dados dos clientes. A API do Paypal sobrepõe-se a todos os serviços similares, visto que possui uma API dedicada ao sistema Android e um modo Sandbox, que permite criar negociantes e compradores fictícios para realizar testes sem a necessidade de utilizar dinheiro e contas reais.
1
2 private static final String CONFIG_ENVIRONMENT = PayPalConfiguration.ENVIRONMENT_PRODUCTION; 3 private static final String CONFIG_CLIENT_ID =
"AbkIf_5-BBBDn2OinS1f59n4hrbLvRqHLKGSDFLc..."; 4
5 private static PayPalConfiguration config = new PayPalConfiguration() 6 .environment(CONFIG_ENVIRONMENT)
7 .clientId(CONFIG_CLIENT_ID) 8 .merchantName("GCC");
26 Capítulo 2. MyNetTaxi As ferramentas dedicadas ao Java permitem alternar entre o modo Sandbox e o ambiente real. Quando um negociante se regista na plataforma, a conta dele é associada a um Id de cliente. É este que serve de ligação entre a aplicação e a conta de negociante, uma conta no modo Sandbox também tem um Id de cliente. Para alternar entre os dois modos é necessário alterar o Id e o ambiente no código fonte. No código2.1está a porção do código de inicialização da configuração com a ligação ao Paypal, neste caso é o estado final portanto o Id de cliente é o da conta real. A variável da linha 2 é a que define qual o ambiente a utilizar, se fosse o modo de teste em vez de PRODUCTION seria SANDBOX. A configuração consiste numa variável do tipo PayPalConfiguration, que contém as variáveis mencionadas anteriormente e também informações do negociante, que neste caso é só o nome da empresa. A variável de configuração é chamada quando o utilizador escolhe o modo Paypal, esta inicia a janela para introduzir os dados e que contém a informação de pagamento.
Por fim quando o processo terminar, se for com sucesso é criada uma variável com a confirmação que serve como prova de pagamento. É esta a enviada como referência, para o servidor. O bloco de código2.2, mostra a implementação da API para obter a confirmação do pagamento. Na linha 4 é extraído o resultado sob a forma de variável do tipo PaymentConfirmation. Na linha 9 é iniciado o processo para enviar o pedido HTTP, que inclui a variável da linha 5 e o Id do cliente em questão. O servidor recebe e guarda na base de dados e encerra a viagem, com o pedido concluído a aplicação avança para o próximo menu. Nas linhas 19 e 21 é feito o tratamento de erros, no caso de ser cancelado pelo utilizador ou acontecer um erro respetivamente.
A interação com o Paypal como foi explicado, é toda feita através da API. É esta que faz o tratamento das ligações e transações. Só é necessário implementar os métodos corretos para realizar e completar com sucesso o processo do pagamento automático
1
2 protected void onActivityResult(int requestCode, int resultCode, Intent data) { 3 if (requestCode == REQUEST_CODE_PAYMENT) { 4 if (resultCode == Activity.RESULT_OK) { 5 PaymentConfirmation confirm = data.getParcelableExtra(PaymentActivity.EXTRA_RESULT_CONFIRMATION); 6 if (confirm != null) { 7 try { 8
9 utils.initRequest(15, Main_FinishTrip.this); 10 long id =utils.getSP().getLong("id_req", -1); 11 utils.json.addParameter("id",""+id);
12 utils.json.addParameter("ref",
confirm.getProofOfPayment().toJSONObject().getString("id").toString()); 13 utils.startRequest();
14
15 } catch (JSONException e) {
16 Log.e(TAG, "an extremely unlikely failure occurred: ", e);
17 }
18 }
2.3. App Cliente 27 20 Log.i(TAG, "The user canceled.");
21 } else if (resultCode == PaymentActivity.RESULT_EXTRAS_INVALID) {
22 Log.i(
23 TAG,
24 "An invalid Payment or PayPalConfiguration was submitted. Please see the docs.");
25 }
26 }
27 }
Bloco de Código 2.2: Tratamento resultado Paypal
2.3.2.2 API Google
Tal como a API do Paypal, que faz o tratamento dos dados dos pagamentos e retribui os resultados, a API do Google funciona da mesma forme. O Google fornece uma API dedicada aos dispositivos Android. De modo a associar a aplicação a uma conta Google é necessário gerar uma chave. A chave é obrigatória, visto que sem ela não é possível identificar o responsável da aplicação. Como a chave serve de identificador os acessos e pedidos ao mapa são associados à mesma e por consequência à conta Google do responsável. O número de pedidos é guardado uma vez que, como foi explicado anteriormente, o serviço é limitado e é através da conta que é feita a contabilização dos pedidos.
O mapa é desenhado em três views diferentes, nas views para escolher as moradas e na última para escolher o táxi. O mapa faz parte de um dos layout disponíveis no desenvolvimento, portanto não é necessário gerar um, através de código, como acontece por exemplo em páginas HTML. O mapa por si só não é suficiente para obter as moradas e coordenadas GPS, portanto é necessário inicializar o Google API Client, é o construtor para ter acesso às várias APIs, como é possível observar no código 2.3. Nas linhas 6 e 7 é associado ao construtor os elementos da API Places. Esta permite usar a função para completar uma morada ou lugar, se a morada existir é possível retirar a latitude e longitude e mover o mapa para o ponto escolhido.
1
2 protected synchronized void buildGoogleApiClient() { 3 mGoogleApiClient = new GoogleApiClient.Builder(this) 4
5 .addApi(LocationServices.API) 6 .addApi(Places.GEO_DATA_API)
7 .addApi(Places.PLACE_DETECTION_API) 8 .enableAutoManage(this, this) 9 .addApi(AppIndex.API).build();
10 }
Bloco de Código 2.3: Inicialização do Google API Client
28 Capítulo 2. MyNetTaxi encontra ou se a localização do dispositivo estiver, desligada centra no último local guardado. Se ambos estiverem desativados, é utilizada a morada mais recente do histórico e o mapa é centrado nessas coordenadas.
As views com o objetivo de escolher as moradas, a estrutura é bastante simples. Consiste no mapa, as caixas de pesquisa e os marcadores. A view seguinte é um pouco mais complexa, pois é necessário desenhar um número limitado de marcadores personalizados. Periodicamente é necessário redesenhar os táxis que mudaram de localização ou apagar ou desenhar os que ficaram inativos ou ativos respetivamente. Antes de iniciar o mapa e os seus marcadores, primeiro é necessário obter os dados do servidor através de um pedido HTTP. Com esses dados criam-se diversos marcadores personalizados, cada um localizado nas coordenadas recebidas, a figura 2.5é um exemplo desse mapa. Para atualizar a posição dos marcadores, é executado um processo periódico que realiza uma nova solicitação. Se as coordenadas forem diferentes para um certo marcador, ele é removido e desenhado no novo local.
Todos estes mecanismos, que servem para usar as funções que o mapa oferece, são oferecidos pela API. Os métodos dos marcadores são próprios para criar no mapa e para os personalizar com uma imagem e nome diferente. Esta simplifica muitos processos, pois junta vários elementos num só. Não existe mais nenhum serviço com uma API tão documentada e explicada, que ofereça tantas opções a quem está a desenvolver.
2.3.2.3 Central de Despacho
Como já foi explicado anteriormente, a ligação à central de despacho é o elemento mais importante de todas as interações da aplicação cliente. A comunicação é realizada através do protocolo HTTP, que responde com mensagens do tipo JSON. Estas tem um formato estruturado em coleções de pares nome/valor, que pode ser um objeto que consiste num conjunto não ordenado de pares. As mensagens com este formato são de fácil leitura e criação.
As interações com a central de despacho começam com um cliente novo, têm que se registar na central para poder começar a utilizar o serviço. É necessário preencher um formulário de registo na aplicação, a sua submissão implica o envio da informação através de um pedido POST. Para fazer login é igualmente enviado um pedido HTTP, todos os processos da aplicação que necessitem de informação relativa ao cliente ou a um ou todos os taxistas, são processos que fazem um pedido HTTP à central.
No caso do processo para criar uma viagem a aplicação faz uma série de solicitações para obter informações. Ou recebe mensagens GCM enviadas pela central, que informam sobre o estado da viagem. A figura 2.10mostra um esquema com o processo de uma viagem visto através dos pedidos e mensagens que a aplicação envia ou recebe. O primeiro é um pedido GET para receber a informação com os táxis ativos no momento. Este é feito quando o cliente está na fase de escolher um táxi, os dados recebidos são utilizados para desenhar os marcadores personalizados no mapa. O pedido seguinte é um POST, é feito quando o utilizador chama um táxi no menu do
