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

2.3. App Cliente 29 resumo da viagem. O pedido é desta natureza pois tem que ser feita a submissão de uma nova viagem, no corpo da mensagem e enviado o Id do táxi escolhido, as coordenadas de origem e destino e o Id do cliente, entre outros elementos necessários como o custo e os quilómetros da viagem.

Figura 2.10: Estados das interações de uma viagem

Após este pedido a aplicação aguarda uma mensagem GCM por parte da central. Pode ser negativa caso o taxista recuse a viagem, então o utilizador tem a opção de escolher um táxi novo, ou o utilizador pode não escolher e a viagem é cancelada, terminando o processo. Se a mensagem for positiva, a aplicação aguarda pela mensagem com a informação que o táxi chegou, esta é a ligação número 3 na figura 2.10. A mensagem também pode informar que o taxista cancelou a viagem, neste caso acontece como na ligação anterior em que o utilizador pode escolher um novo. Enquanto espera o cliente pode cancelar a viagem, enviando um pedido à central e termina o processo.

Quando o táxi chega à morada de origem (ligação número 6) o cliente é notificado e aguarda que a viagem termine. No fim da viagem (ligação número 8) é enviada uma mensagem a indicar o fim da mesma. Neste momento, o utilizador tem três escolhas diferentes, mas todas enviam um pedido à central. Cada escolha envia um diferente, correspondente a cada opção disponível. No caso do pagamento a dinheiro envia o pedido que lhe corresponde, com o Id do cliente e a central responde quando o taxista informar que recebeu o montante. Se for utilizado o método de pagamento via Paypal, o corpo do pedido contém o Id e a confirmação do sucesso da transação. Finalemte, se for a crédito é só enviado o Id, neste caso a aplicação não tem que aguardar uma confirmação para avançar.

30 Capítulo 2. MyNetTaxi A figura2.10 é um esquema com todas as possíveis interações entre a aplicação e a central durante uma viagem. É considerado uma viagem a partir do momento que o utilizador começa a escolher a morada de origem. Mas é só a partir do ponto de escolher o táxi que são realizados pedidos HTTP ao servidor. Uma viagem consiste em pedidos enviados pela aplicação e também nas mensagens GCM enviadas pela central. Estas interações estão representadas no esquema através de setas e são de cores diferentes, de forma diferenciar quando é o servidor a enviar a mensagem (cor azul) ou quando é a aplicação a fazer o pedido (cor vermelha). Na legenda está descrito cada pedido e mensagem para entender melhor as ligações em cada momento de uma viagem.