Upload
hoangmien
View
220
Download
0
Embed Size (px)
Citation preview
INSTITUTO FEDERAL FLUMINENSE - IFFLUMINENSE
ISAAC LARRUBIA FERREIRA PONTES
SANDERSON SILVA CORRÊA
XAMARIN E O DESENVOLVIMENTO DE APLICAÇÕES MOBILE
MULTIPLATAFORMA: UM ESTUDO DE CASO COM GEOFENCE
CAMPOS DOS GOYTACAZES – RJ
MARÇO – 2018
ISAAC LARRUBIA FERREIRA PONTES
SANDERSON SILVA CORRÊA
XAMARIN E O DESENVOLVIMENTO DE APLICAÇÕES MOBILE
MULTIPLATAFORMA: UM ESTUDO DE CASO COM GEOFENCE
Trabalho de Conclusão de Curso apresentado à Coordenação de Informática do Instituto Federal Fluminense, como parte das exigências para obtenção de título de Bacharel em Sistemas de Informação. Orientador: Prof. D.Sc. Luiz Gustavo Lourenço Moura
CAMPOS DOS GOYTACAZES – RJ
MARÇO – 2018
ISAAC LARRUBIA FERREIRA PONTES
SANDERSON SILVA CORRÊA
XAMARIN E O DESENVOLVIMENTO DE APLICAÇÕES MOBILE
MULTIPLATAFORMA: UM ESTUDO DE CASO COM GEOFENCE
Trabalho de Conclusão de Curso apresentado à Coordenação de Informática do Instituto Federal Fluminense, como parte das exigências para obtenção de título de Bacharel em Sistemas de Informação.
Aprovada em ___ de ____________ de ______
___________________________________________________
Prof. D.Sc. Luiz Gustavo Lourenço Moura
Instituto Federal Fluminense – campus Campos Centro
___________________________________________________
Prof. D.Sc. Maurício José Viana Amorim
Instituto Federal Fluminense – campus Campos Centro
___________________________________________________
Prof. D.Sc. Fernando Luiz de Carvalho e Silva
Instituto Federal Fluminense – campus Campos Centro
CAMPOS DOS GOYTACAZES – RJ
MARÇO – 2018
AGRADECIMENTOS
Agradeço primeiramente a Deus, por tudo que sou e tenho, pelas bênçãos e
pelas pessoas maravilhosas que Ele colocou em minha vida e que tanto contribuíram
para que eu chegasse até aqui.
Aos meus pais, meus maiores exemplos, que sempre me apoiaram e que
fizeram com que eu me tornasse quem eu sou hoje. Ao meu irmão, que sempre esteve
comigo e, mesmo sem saber, me incentivava a ser uma pessoa melhor.
Aos meus amigos, com quem sempre pude contar tanto nos momentos de
alegria quanto nos de tristeza. E em especial àquela que é muito mais do que uma
amiga, Lívia, que fez tanto por mim que seria impossível descrever aqui.
Ao meu orientador Luiz Gustavo, sem o qual este trabalho não teria sido
concluído, por sua dedicação e compreensão. Também a todos os outros professores
do IF Fluminense, que me ajudaram durante essa jornada.
E por fim, mas não menos importante, ao IF Fluminense por tornar possível a
realização deste sonho.
Isaac Larrubia Ferreira Pontes
Gostaria também de agradecer à Deus pelas bênçãos e livramentos que me
tem dado, pois sem a permissão Dele este sonho não estaria sendo realizado.
Agradeço à minha família por estar sempre ao meu lado, apoiando os meus
sonhos e celebrando minhas conquistas. Um agradecimento especial ao meu pai que
sempre prezou pela minha educação, estando comigo nesta dura etapa que é a
graduação.
Aos amigos que fiz dentro desta instituição, que grande parte carregarei para
sempre em minha vida, amigos esses que foram essenciais nesta caminhada.
Agradeço também aos professores pela dedicação do trabalho que lhes foi
proposto, em especial ao nosso orientador Luiz Gustavo, à professora Maria Auciléia
que nos auxiliou neste trabalho e ao professor Fernando Carvalho que fez um papel
fundamental na construção do profissional que me tornei.
E agradeço ao IF Fluminense por nos ter dado à base para a conclusão desta
etapa.
Sanderson Silva Corrêa
RESUMO
A crescente popularidade dos dispositivos móveis nos últimos anos fez com
que as tecnologias disponíveis também avançassem rapidamente. Isso influenciou
diretamente, por exemplo, no mercado de aplicativos para estes dispositivos.
Contudo, como eles utilizam sistemas operacionais variados, é necessário que
os desenvolvedores busquem atingir o maior número de plataformas diferentes
possível.
O presente trabalho explora o desenvolvimento de aplicações multiplataforma
a fim de buscar uma alternativa que permite reduzir o custo, o tempo e os
conhecimentos necessários para o desenvolvimento. Foram abordados o
funcionamento e as características da ferramenta Xamarin e foi elaborado um estudo
de caso utilizando a tecnologia de geolocalização. Com isso foi possível entender o
quanto o Xamarin torna o processo de desenvolvimento mais eficiente.
Palavras-chave: Dispositivos móveis, desenvolvimento multiplataforma, Xamarin,
geolocalização.
ABSTRACT
The growing popularity of mobile devices in recent years has made the
technologies available also advance rapidly. This has directly influenced, for example,
the application market for these devices.
However, since they use a variety of operating systems, it is necessary for
developers to reach as many different platforms as possible.
The present work explores the development of multiplatform applications in
order to find an alternative that reduces the cost, time and knowledge required for
development. The operation and characteristics of the Xamarin tool were discussed
and a case study was developed using geolocation technology. With this it was
possible to understand how much Xamarin makes the development process more
efficient.
Keywords: Mobile devices, cross-platform development, Xamarin, geolocation.
Lista de Figuras
Figura 1 – Pilha de software do Android ................................................................ 15
Figura 2 – O processo de construção de um aplicativo Android ........................ 16
Figura 3 – Camadas do iOS ..................................................................................... 17
Figura 4 – Execução lado-a-lado do Mono CLR e da Dalvik VM .......................... 25
Figura 5 – Estrutura de uma aplicação Xamarin.iOS ............................................ 26
Figura 6 – Compilação de Código no Xamarin.iOS ............................................... 27
Figura 7 – Estrutura de um Projeto Shared ........................................................... 28
Figura 8 – Exemplo de Projeto Shared ................................................................... 29
Figura 9 – Estrutura de um Projeto PCL ................................................................ 30
Figura 10 – Exemplo de um Projeto PCL ............................................................... 31
Figura 11 – Modelo Model-View-ViewModel .......................................................... 37
Figura 12 – Estruturação de uma GeoFence ......................................................... 38
Figura 13 – Diagrama de Classes ........................................................................... 41
Figura 14 – Criação de um novo projeto do Xamarin ........................................... 44
Figura 15 – Gerenciador de pacotes do NuGet e o pacote Acr.Geofencing ....... 45
Figura 16 – Estrutura final do projeto .................................................................... 46
Figura 17 – Telas de listagem de promoções no Android e iOS .......................... 47
Figura 18 – Código utilizado para criar as abas e gerar as telas ........................ 47
Figura 19 – Código para retornar a posição do usuário e criar o mapa ............. 48
Figura 20 – Código para criação dos pins e da Geofence no mapa ................... 49
Figura 21 – Tela com mapa gerado ......................................................................... 49
Figura 22 – Tela com a lista das lojas .................................................................... 50
SUMÁRIO
1 Introdução ....................................................................................................................... 10
1.1 Objetivos ................................................................................................................... 11
1.2 Justificativa ............................................................................................................... 12
1.3 Organização do Trabalho ....................................................................................... 12
2 Fundamentação Teórica ............................................................................................... 13
2.1 Desenvolvimento para Dispositivos Móveis........................................................ 14
2.1.1 Android .............................................................................................................. 14
2.1.2 iOS...................................................................................................................... 17
2.2 Desenvolvimento Multiplataforma ........................................................................ 19
2.2.1 Modo Nativo ...................................................................................................... 20
2.2.2 Modo Híbrido .................................................................................................... 21
2.2.3 Ferramentas de Desenvolvimento ................................................................ 22
3 Xamarin ........................................................................................................................... 24
3.1 Arquitetura ................................................................................................................ 25
3.1.1 Xamarin.Android .............................................................................................. 25
3.1.2 Xamarin.iOS...................................................................................................... 27
3.2 Compartilhamento de Código................................................................................ 28
3.2.1 Projeto de Ativos Compartilhados ................................................................. 28
3.2.2 Biblioteca de Classes Portátil ........................................................................ 30
3.3 Desenvolvimento ..................................................................................................... 32
3.4 Publicação ................................................................................................................ 33
4 Método de Pesquisa ...................................................................................................... 36
4.1 Tecnologias e Conceitos Utilizados ...................................................................... 37
4.1.1 MVVM ................................................................................................................ 37
4.1.2 GeoFence e Mapas ......................................................................................... 38
5 Estudo de Caso .............................................................................................................. 41
5.1 Planejamento ........................................................................................................... 42
5.2 Execução .................................................................................................................. 44
5.2.1 Desenvolvimento.............................................................................................. 44
5.2.2 Telas do Aplicativo ........................................................................................... 47
6 Conclusão ....................................................................................................................... 52
6.1 Trabalhos Futuros ................................................................................................... 53
7 Referencial Bibliográfico ............................................................................................... 54
10
1 INTRODUÇÃO
Em toda a história a tecnologia é sempre lembrada como algo em constante
evolução. Essa evolução foi ocorrendo de forma sutil, porém acelerada, e em apenas
algumas décadas o uso da tecnologia tomou conta da vida das pessoas. Um exemplo
disso são os smartphones, que se tornaram uma ferramenta essencial e auxiliam nas
mais diversas tarefas, como assistir filmes e programas de TV, organizar finanças,
encontrar lugares e pessoas, ou até mesmo pedir comida. E tudo isso é possível
graças a inúmera variedade de aplicativos disponíveis para essas plataformas.
Esse cenário fez com que um novo mercado surgisse, o do desenvolvimento de
aplicações para dispositivos móveis. Uma pesquisa da empresa App Annie (APP
ANNIE, 2017), que analisa o mercado mundial, revelou em um relatório que no ano
de 2016 o mercado de aplicativos móveis movimentou cerca de US$ 61,8 bilhões.
Segundo essa mesma pesquisa, a previsão para o ano de 2017 é que este mercado
gire US$ 82,2 bilhões. Já para o ano de 2021, esse valor quase dobra, chegando à
US$ 139,1 bilhões, sendo US$ 35,1 bilhões relativo às Américas.
Cada vez mais empresas já consolidadas estão expandindo seus produtos e
serviços para plataformas móveis, e novas empresas surgem a todo momento
trazendo ideias e aplicativos inovadores. Dentro desse contexto, uma das tecnologias
que possui maior impacto comercial é a de geolocalização. Grandes nomes, como
Uber, utilizam geofences para saber quando os usuários entram em uma determinada
área, o que permite localizar clientes de forma proativa. Cerca de 12% dos aplicativos
ativos utilizam o recurso de localização (BIZNESSAPPS, 2017). Mas além de ter uma
ideia útil ao mercado também é necessário que ela seja bem executada na prática, e
para isso essas empresas precisam otimizar o processo de desenvolvimento dos
aplicativos.
Para o bom desenvolvimento de uma aplicação certos conhecimentos são
necessários, e o domínio ou não desses conhecimentos influenciará diretamente no
produto final. Um outro fator relevante é que existem diversos sistemas operacionais
atualmente disponíveis no mercado, logo, para atingir a maior parcela possível de
dispositivos é preciso desenvolver aplicações que funcionem em cada um deles.
Porém cada sistema operacional possui suas particularidades e exige um conjunto de
11
conhecimentos específicos, o que dificulta o desenvolvimento de aplicativos para mais
de um sistema operacional simultaneamente.
A partir disso surgem então diversas ferramentas para auxiliar no
desenvolvimento móvel multiplataforma, dentre as quais pode-se destacar pela sua
popularidade o PhoneGap, o React Native, o Appcelerator e o Xamarin
(TECHCRESENDO, 2017). Apesar de suas particularidades, todas elas permitem que
os desenvolvedores escrevam o código somente uma vez e consigam executá-lo em
dispositivos diferentes, independente do sistema operacional, otimizando o processo
de criação das aplicações multiplataforma.
1.1 OBJETIVOS
Este trabalho visa explorar o desenvolvimento de aplicativos multiplataforma que
fazem uso da tecnologia de geolocalização.
Aqui estarão reunidos conhecimentos sobre a utilização da plataforma e das
respectivas tecnologias, para que possam ser desenvolvidos projetos com maior
qualidade e que seus autores possam usufruir do máximo que lhes é proporcionado.
Ao decorrer deste documento, serão analisadas as principais características do
Xamarin, seu funcionamento, como é seu comportamento com funções de
geolocalização e o que é necessário para desenvolver uma única aplicação para
sistemas operacionais distintos. Também será realizado um estudo de caso aplicando
o conceito de geofences para colocar em prática os conhecimentos abordados.
Como objetivos específicos deste trabalho pode-se destacar:
• Entender o funcionamento e a estrutura de projetos desenvolvidos
com o Xamarin;
• Entender a arquitetura das plataformas Android e iOS e como
funciona a interação da plataforma Xamarin com as mesmas;
• Fazer deste documento um guia útil para desenvolvedores que
desejam explorar a tecnologia de geolocalização;
• Explorar as geofences e sua utilidade, bem como o seu
funcionamento juntamente com o Xamarin;
12
• Avaliar os conhecimentos abordados através da realização de um
estudo de caso, que facilitará o desenvolvimento de uma aplicação futura;
1.2 JUSTIFICATIVA
A forma mais direta de criar um aplicativo que funcione em múltiplas plataformas
é realizando todo o processo de desenvolvimento individualmente para cada sistema
operacional que se deseja alcançar. Porém isso aumenta consideravelmente a
quantidade de conhecimentos necessários, bem como o tempo e o custo do processo.
Levando em consideração essas dificuldades, projetos foram criados para
facilitar a vida dos desenvolvedores, mas são poucos os materiais que reúnem
conhecimento e prática, pois, sendo essas tecnologias bem recentes, suas próprias
documentações foram pouco exploradas. É necessário que profissionais da área
avaliem e testem esses projetos, para que se dissemine o conhecimento e que ambos
possam evoluir, colaborando assim para o crescimento da tecnologia.
A plataforma Xamarin se encaixa perfeitamente neste contexto, apresentando
uma solução adequada para o problema. Com ela é possível utilizar uma única
linguagem, C#, e compartilhar grande parte do código desenvolvido entre os
diferentes projetos individuais de cada sistema operacional que se deseja atingir. Além
disso, a aplicação desenvolvida utilizará as interfaces nativas dos respectivos
sistemas e para acessar os componentes de baixo nível de forma eficiente.
1.3 ORGANIZAÇÃO DO TRABALHO
No próximo Capítulo serão abordados os conceitos e ferramentas necessários
para o desenvolvimento do trabalho. O Capítulo 3 explora a plataforma Xamarin, sua
composição, seu funcionamento e outros tópicos relevantes para o processo de
desenvolvimento de aplicações. O quarto Capítulo apresenta a forma de pesquisa das
13
tecnologias mostradas e utilizadas. O Capítulo 5 trata sobre o estudo de caso
realizado, contendo a descrição de um cenário de desenvolvimento com um problema
e uma solução proposta e o desenvolvimento desta solução. Por fim, o sexto Capítulo
traz as conclusões e considerações do trabalho, bem como a proposição de possíveis
trabalhos futuros.
2 FUNDAMENTAÇÃO TEÓRICA
Para auxiliar no entendimento do campo de estudos em questão foram
destacados conceitos sobre desenvolvimento de aplicações para dispositivos móveis,
características específicas das plataformas Android e iOS, desenvolvimento
multiplataforma e sobre o Sistema de Posicionamento Global (GPS) e as geofences,
que serão utilizados no estudo de caso a ser realizado.
14
2.1 DESENVOLVIMENTO PARA DISPOSITIVOS MÓVEIS
Ao falar de desenvolvimento de software, seja ele desktop, web ou mobile, certas
coisas, como as linguagens, metodologias e ferramentas utilizadas, vêm à mente
quase que imediatamente. Esses são pontos importantes, porém, inicialmente, é
necessário atentar para outros fatores que influenciarão nas várias etapas do
processo de desenvolvimento. Tratando das aplicações para dispositivos móveis,
essas questões estão diretamente ligadas ao sistema operacional alvo.
Semelhante ao que ocorre com os desktops, existem diversos sistemas
operacionais para dispositivos móveis disponíveis no mercado. Atualmente os mais
conhecidos são o Android e o iOS, que alcançam, juntos, 98,95% da quota de mercado
(NET MARKET SHARE, 2018). Outros sistemas também citados nessa mesma
pesquisa, como o Windows Phone, com 0,85%, e o Symbiam, com 0,08%, também
são encontrados, porém com uma parcela insignificante do mercado. Cada um desses
sistemas possui diversas particularidades, algumas são mais visíveis, como a
interface nativa, enquanto outras podem passar despercebidas para o usuário final,
como a arquitetura e as linguagens utilizadas. Essas particularidades definem a forma
como uma aplicação será desenvolvida.
Considerando a divisão atual do mercado é perceptível que os sistemas
operacionais mais relevantes são o Android e o iOS, portanto ao desenvolver uma
aplicação para dispositivos móveis é natural que essas plataformas sejam priorizadas.
Portanto, ao abordar as particularidades dos sistemas operacionais para dispositivos
móveis este trabalho focará apenas nas características do Android e do iOS.
2.1.1 Android
O Android é o sistema operacional mais popular entre os dispositivos móveis,
abrangendo 68,39% dos dispositivos no mercado (NET MARKET SHARE, 2018). A
popularidade do Android faz com que o desenvolvimento de aplicativos para a
plataforma seja igualmente popular. Dados apontam que o número de aplicativos
15
disponíveis na Google Play Store em 2013 era de aproximadamente 1.000.000, e em
quatro anos esse número triplicou (STATISTA, 2017).
É uma plataforma baseada em Linux e sua arquitetura é composta de várias
camadas que formam uma pilha de software, como pode ser visto na Figura 1. A
camada mais baixa dessa pilha é o kernel Linux, que gerencia funcionalidades como
tela, câmera, encadeamento e gerenciamento de memória de baixo nível. Logo acima
se encontra a camada de abstração de hardware (HAL), que fornece interfaces padrão
que expõem as capacidades de hardware gerenciadas pelo kernel Linux para a
estrutura da API de maior nível (ANDROID, 2017).
O tempo de execução Android (Android Runtime, ou ART) é utilizado para
executar os processos de cada aplicativo, e isso é feito em instâncias individuais, ou
seja, para cada aplicativo haverá uma instância própria do ART. Ele é projetado para
executar várias máquinas através de arquivos DEX, um formato de bytecode
específico do Android (ANDROID, 2017). O ART suporta tanto compilação Ahead-of-
Time (AOT), que é realizada antes da execução, quanto Just-in-Time (JIT), que ocorre
durante a execução.
Figura 1 - Pilha de software do Android Fonte: Android (2017)
A linguagem de programação utilizada para o desenvolvimento de aplicações
para o Android é Java, porém o núcleo do próprio Android é escrito em C. Muitos
16
componentes e serviços principais, como SQLite, Webkit e OpenGL, são
implementados em código nativo, logo são necessárias as bibliotecas nativas
programadas em C/C++. Essas bibliotecas podem ser acessadas de duas formas:
diretamente, através do Android Native Development Kit (NDK), ou indiretamente,
utilizando as APIs do framework Java. Essas APIs também são responsáveis pelo
gerenciamento de diversos recursos mais superficiais do Android, como Activitys,
janelas, provedores de conteúdo, entre outros. A camada final refere-se ás próprias
aplicações do sistema, com as quais o usuário final interage diretamente.
Uma vez desenvolvido, o aplicativo Android passa por algumas etapas antes de
estar pronto para ser usado, esse processo é chamado de build, ou construção, e está
disposto na Figura 2. Primeiramente, os compiladores convertem o código fonte em
arquivos DEX (Dalvik Executable) e todo o resto em recursos compilados. Então, o
Empacotador de APK combina os arquivos DEX e os recursos compilados em um
único APK (Android Application Package), porém antes de ser instalado em um
dispositivo o APK precisa ser assinado. O próprio Empacotador assina o APK
utilizando uma chave de debug, caso a intenção seja testá-lo, ou de release, caso a
intenção seja publicá-lo. Antes de gerar o APK final o Empacotador também utiliza a
ferramenta zipalign para otimizá-lo para consumir menos memória ao rodar em um
dispositivo.
17
Figura 2 - O processo de construção de um aplicativo Android Fonte: Android (2017)
Todo o processo de codificação e teste, bem como a construção do APK, podem
ser realizados através do Android Studio, o Ambiente de Desenvolvimento Integrado
(IDE) oficial da plataforma. Ele é um software gratuito e multiplataforma com inúmeras
ferramentas, como editor de código inteligente, compiladores e emuladores dos
diversos dispositivos que suportam o Android.
2.1.2 iOS
A outra plataforma a ser abordada é o iOS, sistema operacional da empresa
Apple, alcançando 30.56% do mercado (NET MARKET SHARE, 2018). O iOS,
lançado em 2007 e antes chamado de iPhone OS, foi desenvolvido inicialmente para
iPhones, mas posteriormente foi usado também em outros dispositivos da Apple,
como iPads, Apple TVs e Apple Watches. Um dos motivos que fazem com que o iOS
18
detenha apenas uma pequena fatia do mercado, quando comparado com o Android,
é o fato da Apple não permitir a distribuição do sistema em aparelhos de terceiros.
O iOS é um sistema operacional de código fechado, desenvolvido utilizando
principalmente as linguagens C, C++ e Objective-C, e o seu kernel é baseado no
Mach. Assim como o Android ele é estruturado em camadas de abstração, porém
existem apenas quatro, Cocoa Touch, Media, Core Services e Core OS, como pode
ser visto na Figura 3. A camada mais baixa é o Core OS, ou Núcleo do SO, que contêm
os serviços e tecnologias nos quais as outras camadas são construídas sobre, como
o kernel, os drivers e os frameworks de interação com o hardware. Os Core Services,
ou Serviços Essenciais, são os frameworks e outras tecnologias de alto-nível
utilizados pelos aplicativos, como o Core Foundation Framework, um conjunto de
interfaces baseadas, o framework de localização, a biblioteca do SQLite, serviços de
conectividade, armazenamento iCloud, etc.
Figura 3 - Camadas do iOS Fonte: Apple (2014)
A camada media contém as tecnologias de gráficos, áudio e vídeo utilizadas para
implementar serviços de multimídia nos aplicativos. No topo encontra-se a camada
Cocoa Touch, que contém os recursos de mais alto-nível e os frameworks chave para
a construção dos aplicativos, como os frameworks de mapas, eventos jogos, e
recursos como auto layout, multitarefa, notificações, entre outros.
Vale ressaltar também que, devido a uma restrição de segurança da Apple em
sua loja de aplicativos, o iOS suporta somente compilação Ahead-of-Time (AOT), ou
seja, todo o código é compilado previamente para a linguagem de máquina nativa,
19
que nesse caso é ARM. Isso permite ganhos de performance, como no tempo de
inicialização das aplicações, e otimizações de código avançadas e complexas que não
seriam possíveis com a compilação Just-in-Time (JIT). Porém também existem
algumas limitações, como a impossibilidade de gerar código durante o tempo de
execução, que é possível com JIT.
Os aplicativos para iOS são desenvolvidos utilizando o Xcode, o IDE oficial para
as plataformas da Apple, e as linguagens Objective-C e Swift. Depois de desenvolvido
o próprio Xcode pode ser usado para exportar o aplicativo, e ao final do processo será
gerado um arquivo do tipo iOS App (IPA). Também é possível utilizar um perfil de
provisionamento de equipe ou ad hoc para assinar o seu aplicativo e registrar
dispositivos de teste, nos quais o aplicativo poderá ser instalado e executado.
2.2 DESENVOLVIMENTO MULTIPLATAFORMA
Levando em conta as diferenças entre plataformas utilizadas nos dispositivos e
a necessidade de atender a todos, inseriu-se o conceito de desenvolvimento
multiplataforma no cenário das aplicações móveis. O conceito é simples, consiste em
desenvolver aplicações que funcionem em mais de uma plataforma. Isto é importante
pois quando se decide por atingir somente um público consequentemente uma grande
parcela não será atingida, reduzindo os lucros obtidos com o aplicativo (CORRAL;
JANES; REMENCIUS, 2012).
No entanto, a aplicação prática deste conceito possui certas complexidades.
Sistemas operacionais possuem suas particularidades, como a linguagem em que ele
foi escrito e a forma como as aplicações são executadas. Por exemplo, o sistema
operacional Android é escrito, majoritariamente, em Java, C e C++ (OPENHUB, 2017),
e suas aplicações são executadas através de uma máquina virtual, enquanto o iOS é
escrito em Objective-C (APPLE, 2017) e é executado de forma direta.
Com isso, foram surgindo inúmeras plataformas e frameworks para viabilizar o
desenvolvimento multiplataforma. A partir de uma rápida busca em sites de tecnologia
é possível ver que nomes como PhoneGap, Xamarin, Ionic, Appcelerator, React
Native, entre outros, são comumente lembrados ao abordar este assunto.
20
Porém nem todos esses frameworks e plataformas trabalham do mesmo modo.
Ao tratar especificamente do desenvolvimento multiplataforma em dispositivos
móveis, existem duas abordagens que se destacam: o modo nativo e o modo híbrido.
2.2.1 Modo Nativo
Todos os sistemas operacionais para dispositivos móveis possuem uma
linguagem padrão suportada, como o Objective-C no iOS ou o Java no Android. Essa
linguagem é chamada de nativa. Portanto, uma aplicação nativa é aquela
desenvolvida para funcionar especificamente em um sistema operacional (ABED,
2016). Todas as funcionalidades da plataforma estão disponíveis, sem restrição, e
existem padrões de interface gráfica e experiência de usuário específicos que ajudam
o usuário a entender como aquele aplicativo funciona. Isso ocorre porque outros
aplicativos instalados no dispositivo seguem o mesmo padrão, ou seja, o usuário está
acostumado com uma lógica na localização dos componentes e uma alteração disso
pode ser mal visto pelo usuário (CORRAL; JANES; REMENCIUS, 2012). Com isso,
os aplicativos nativos possuem uma série de vantagens.
O código nativo é compilado diretamente, o que torna sua execução mais
eficiente, pois permite que as funcionalidades de hardware e software, como câmera,
GPS, cliente de e-mail, acelerômetro e outros, sejam acessadas mais rapidamente, já
que não dependem de nenhum intercessor externo como uma máquina virtual e fazem
chamadas diretas. Outro ponto positivo é que essas aplicações utilizam uma interface
de usuário (UI) nativa, ou seja, herdam a aparência do sistema operacional. Isso faz
com que o usuário aprenda a utilizar um novo aplicativo com mais facilidade e passa
uma sensação de integração com o sistema, resultando em uma melhor experiência
de uso, pois o aplicativo se utiliza de itens naturais do sistema, que já são conhecidos
pelo usuário.
Apesar disso, no que diz respeito ao processo de execução, existe um fato
interessante sobre o desenvolvimento nativo no Android envolvendo a linguagem Java
e que muitas vezes é mal interpretado, como explica o Engenheiro de Software da
Microsoft, Alexandre Chohfi, no podcast sobre Xamarin do Lambda3:
21
“Quando se tem uma aplicação Java rodando dentro do Android,
ele não é nativo, nativo seria o NDK (Native Development Kit) que é
escrito em C/C++, pois aplicativos em Java rodam em cima de uma
máquina virtual. Consideramos que um aplicativo escrito em Java é
nativo pois 99,9% dos aplicativos, desconsiderando os híbridos, são
feitos em Java. Eles são nativos porque a compilação do Android
final gera o bytecode para uma máquina virtual específica para o
sistema operacional, atualmente denominada Dalvik”.
2.2.2 Modo Híbrido
O modo híbrido consiste em desenvolver um mesmo código para plataformas
distintas. Este modo surgiu com a necessidade de atender simultaneamente a
diferentes tipos de dispositivos móveis, cada um com um sistema operacional
específico. Nesse tipo de situação, desenvolver aplicativos nativos de médio e grande
porte para cada um dos sistemas seria algo inviável, devido ao maior tempo e ao alto
custo de desenvolvimento e manutenção. De acordo com um estudo realizado pela
Forrester Research (2009, apud MRC, 2013), aplicativos podem levar até seis meses
para serem finalizados, e seu custo pode variar entre US$ 20.000 e US$ 150.000 para
o desenvolvimento em plataformas específicas.
Inicialmente os aplicativos híbridos eram majoritariamente Web Apps. Os Web
Apps são aplicações desenvolvidas em uma determinada linguagem, normalmente
diferente da nativa, e têm sua interface escrita em HTML, CSS e JavaScript. Uma vez
terminados, os Web Apps não serão executados diretamente pelo sistema, e sim
através de um navegador embutido no aplicativo, tendo parte ou total conteúdo
carregado na web (BUDIU, 2013). Resumidamente, enquanto as aplicações nativas
são compiladas os Web Apps são interpretados, o que é mais lento (CHARLAND;
LEROUX, 2011). Este modo não entrega aplicativos com uma interface nativa, e o
desenvolvedor, com o auxílio de um framework, precisara recriar os itens da mesma
forma que o modo nativo faria. Cada sistema operacional tem o seu modo de exibir os
itens na interface e o desenvolvedor deve respeitar isso para proporcionar um uso
mais agradável para o usuário. Neste modo não é possível ter acesso total às
22
funcionalidades da plataforma como acontece no modo nativo, e também não existe
um padrão de interface (UI) e de experiência do usuário (UX), podendo causar uma
sensação ruim na usabilidade e experiência de uso do aplicativo (CORRAL; JANES;
REMENCIUS, 2012).
Uma alternativa mais recente, utilizada para áreas mais específicas, são os
Responsive Apps. Estes não são de fato aplicativos, são sites responsivos que se
parecem com um aplicativo. Eles escondem os botões do navegador e os gestos de
navegação para ficarem semelhantes aos aplicativos reais. Inicialmente, os usuários
o acessam como fariam com um site normal. Lá encontrarão a opção “instalar”, que
na verdade criará apenas um atalho para aquela página. Esta opção é utilizada em
aplicações onde os usuários não as acessariam com frequência, visto que elas
possuem diversas limitações.
Muitas variáveis devem ser analisadas antes de escolher o modo de
desenvolvimento, se nativo ou híbrido. Por exemplo, quando existe a necessidade de
desenvolver uma aplicação que obtenha o máximo de performance ou utilize muitos
recursos de hardware é aconselhável que essa aplicação seja desenvolvida com a
linguagem nativa do aparelho. Já quando se tratar de uma aplicação simples e é
preciso priorizar a agilidade no desenvolvimento, ou uma maior gama de
compatibilidade, os aplicativos híbridos podem ser a melhor solução.
Muitas vezes as ferramentas de desenvolvimento multiplataforma apresentam
benefícios suficientes para serem consideradas uma opção viável ou até mesmo
melhor que a abordagem nativa, e a tendência é que, ao longo do tempo, as pequenas
desvantagens que existem sejam sanadas ou mitigadas (MATOS; SILVA, 2016).
2.2.3 Ferramentas de Desenvolvimento
Segundo Fayad e Schmidt (1997), um framework é um aplicativo reutilizável,
"semi-completo", que pode ser especializado para produzir aplicativos personalizados,
ou seja, são um conjunto de padrões dentro de um software capaz de lidar com
problemas já conhecidos e que possam ser reutilizados pelo desenvolvedor no
momento da compilação do seu produto final.
23
Os frameworks para desenvolvimento de aplicações híbridas separam-se em
dois tipos, os responsáveis pela interface de usuário (UI, ou User Interface), e aqueles
que empacotam a aplicação para as diferentes plataformas e permitem que ela acesse
os recursos do aparelho (PREZOTTO; BONIATI, 2014).
A ferramenta, ou framework, de UI é responsável pela interface na qual o usuário
terá acesso inicialmente. A organização da interface é importante para definir com
clareza o objetivo e as funcionalidades de uma aplicação. Um problema enfrentado
recentemente na fabricação de aplicativos em empresas é quando o cliente opta por
manter a mesma aparência do aplicativo em diferentes plataformas, o que é um erro,
como afirma Victor Cavalcante, pois os aplicativos devem respeitar o design que o
sistema operacional onde ele está instalado impõe (LAMBDA3, 2016).
Um dos frameworks mais usados para o desenvolvimento multiplataforma é o
Apache Cordova. Ele trabalha com o conceito de páginas web em aplicativos.
Aplicações desenvolvidas com Cordova são páginas web que executam em uma
WebView encapsulada em uma aplicação nativa para cada plataforma. Aplicativos
assim podem estar nas lojas como qualquer outro aplicativo nativo (TUBINO;
QUINCOZES; KAZIENKO, 2015). O desenvolvimento é feito com HTML, CSS e
JavaScript, e o acesso às funcionalidades nativas é feito por plugins. O Cordova
permite que aplicativos não nativos tenham acesso às funcionalidades nativas da
plataforma, mas apenas nos sistemas Android e iOS e a usabilidade e aparência ficam
semelhantes aos aplicativos nativos (BEZERRA; SCHIMIGUEL, 2016).
Para resolver o problema do Cordova com relação a usabilidade e aparência,
outras ferramentas foram desenvolvidas se baseando no código do Cordova, que é
Open Source (Apache Cordova), provendo bibliotecas HTML e CSS para que o front-
end se aproxime mais da realidade de uma aplicação nativa (BEZERRA;
SCHIMIGUEL, 2016).
Um exemplo de software baseado no Cordova é o Ionic. Além disso, este
software também se baseia no AngularJS, e conta com um conjunto de ferramentas
para auxiliar no desenvolvimento da aplicação (ESTUDO COMPARATIVO ENTRE O
DESENVOLVIMENTO DE APLICATIVOS MÓVEIS UTILIZANDO PLATAFORMAS
NATIVAS E MULTIPLATAFORMA, 2016, apud DRIFTY, 2016c), sendo esses os
diferenciais para o Cordova.
24
3 XAMARIN
O Xamarin é uma plataforma que oferece a possibilidade de desenvolver, de
forma nativa, aplicativos para iOS, Android e Windows Phone, utilizando um único
código base, escrito em C#. Com isso, os desenvolvedores conseguem tanto
aproveitar os benefícios da linguagem, como LINQ e async, quanto ter acesso aos
recursos específicos das plataformas móveis e ainda construir uma interface nativa
(RADI, 2016). Também é possível invocar diretamente bibliotecas em Java, Objective-
C, C e C++, permitindo o reaproveitamento de bibliotecas de terceiros já existentes
nessas linguagens.
O próprio Xamarin funciona em múltiplas plataformas, podendo ser utilizado no
Windows através do Visual Studio, e no Mac OS através do Xamarin Studio, IDEs que
incluem diversas ferramentas para auxiliar no desenvolvimento. A Microsoft, que é a
atual dona do Xamarin, também lançou o Visual Studio para Mac, que aos poucos
substituirá o Xamarin Studio para os usuários da plataforma da Apple. O Xamarin é
dividido em dois produtos principais, o Xamarin.iOS e o Xamarin.Android, que são
responsáveis pelo mapeamento e pela ligação com os respectivos sistemas
operacionais. Ao desenvolver com o Xamarin a maior parte do código que envolve a
parte lógica pode ser escrita somente uma vez e reaproveitada para os projetos
individuais, e as partes que exigem recursos e interações específicos são feitas
individualmente, através dos projetos Xamarin.Android e Xamarin.iOS.
Para a criação da interface de usuário (UI) o Xamarin também possui uma
alternativa ao desenvolvimento individual no Xamarin.iOS e Xamarin.Android, o
Xamarin.Forms. O Xamarin.Forms é um conjunto de ferramentas para construção de
UI que permite aos desenvolvedores criar interfaces que podem ser compartilhadas
entre Android, iOS, Windows e Windows Phone. Essas interfaces também são
nativamente apoiadas, ou seja, são renderizadas utilizando os controles nativos da
plataforma alvo, permitindo que o Xamarin.Forms retenha o visual e a sensação de se
estar utilizando uma aplicação nativa.
A escolha de qual método utilizar varia de acordo com o tipo de projeto em
questão. O Xamarin.Forms é mais adequado para aplicações baseadas em
formulários e entradas de dados, situações que priorizam o máximo compartilhamento
25
de código ou ainda aplicações que necessitam de poucos recursos e interações
específicos da plataforma. Nos outros cenários o ideal é utilizar o Xamarin.iOS e o
Xamarin.Android, pois estes permitem um maior aproveitamento de funcionalidades
específicas do sistema, bem como uma UI mais customizável.
3.1 ARQUITETURA
O Xamarin funciona no ambiente de execução Mono tanto no Android quanto no
iOS. Segundo Panigrahy (2015), o Mono é uma implementação multiplataforma e de
código aberto de um compilador C# e um tempo de execução de linguagem comum
(Common Language Runtime, ou CLR) compatível com o framework .NET. Porém, da
mesma forma que existem diferenças entre as arquiteturas do Android e do iOS,
existem diferenças na forma como as aplicações Xamarin.Android e Xamarin.iOS são
executadas em seus respectivos sistemas operacionais. Portanto, para um melhor
entendimento, essas duas plataformas serão abordadas separadamente.
No entanto, antes de seguir adiante, é importante definir dois conceitos
comumente utilizados ao se desenvolver com Xamarin, código gerenciado e código
nativo. Código gerenciado é aquele que tem a sua execução gerenciada pelo CLR do
framework .NET, ou, no caso do Xamarin, do tempo de execução do Mono. Já o código
nativo é aquele executado nativamente na plataforma específica, como o Objective-C
no iOS e o Java no Android.
3.1.1 Xamarin.Android
No Xamarin.Android o Mono CLR é executado ao lado da máquina virtual do
ART, e ambos são executados sobre o kernel Linux, como visto na Figura 4. As APIs
do .NET são parte do Mono CLR e disponibilizam diversas classes, como
System.Data, System.IO, etc, que permitem ao desenvolvedor acessar recursos e
26
dispositivos do SO. Contudo, no Android, recursos específicos, como Áudio, Telefonia
e OpenGL, não podem ser acessados diretamente pelas APIs do .NET, e para isso
são utilizadas as bibliotecas de ligação do Android (Android Binding Libraries) através
dos namespaces Android.* e Java.* (XAMARIN.ANDROID, 2017).
Figura 4 - Execução lado-a-lado do Mono CLR e da Dalvik VM Fonte: Packtpub (2017)
Essa ligação é possível graças a Interface Nativa Java (JNI), um framework que
permite que código escrito em outras linguagens, nesse caso C#, faça chamadas ou
seja chamado por código Java rodando dentro de uma JVM (PANIGRAHY, 2015). A
JNI possui os Managed Callable Wrappers (MCW), que funcionam como uma ponte
sempre que o código gerenciado precisa invocar código Android e também permite
implementar interfaces Java e sobrescrever métodos virtuais. Eles também são os
responsáveis pela conversão entre tipos gerenciados e do Android, e por invocar
métodos fundamentais da plataforma Android via JNI.
Os pacotes de aplicação Xamarin.Android possuem a mesma estrutura dos
pacotes de aplicação normais do Android, mas com a adição do código C# na forma
de assemblies, contendo IL (Intermediate Language), e do tempo de execução Mono
empacotado dentro do APK como uma biblioteca nativa.
27
3.1.2 Xamarin.iOS
Semelhantemente ao que ocorre no Xamarin.Android, no Xamarin.iOS as
aplicações são executadas pelo ambiente Mono, mas ao lado do tempo de execução
Objective-C, como pode ser visto na Figura 5. Ambos rodam sobre um kernel UNIX-
like e expõem aos desenvolvedores as diversas APIs, permitindo acessar os recursos
fundamentais nativos e gerenciados do sistema (XAMARIN.IOS, 2017).
Figura 5 - Estrutura de uma aplicação Xamarin.iOS Fonte: Xamarin.iOS (2017)
Normalmente, em uma aplicação Xamarin, o código C# é compilado para MSIL
(Microsoft Intermediate Language) pelo compilador Mono C#. Feito isso, o CLR .NET
compila a saída MSIL obtida para o código nativo compatível com a arquitetura
desejada utilizando JIT. Isso é o que ocorre com as aplicações Xamarin.Android, por
exemplo. Porém, como a Apple possui uma restrição de segurança que proíbe a
execução de código gerado dinamicamente durante a execução das aplicações no
iOS, o Xamarin.iOS utiliza um compilador AOT para compilar o código gerenciado.
Esse processo produz um binário nativo do iOS, que pode ser otimizado com LLVM,
e que é compatível com a arquitetura baseada em ARM dos processadores da Apple.
O diagrama da Figura 6 mostra como ocorre esse processo.
28
Figura 6 - Compilação de Código no Xamarin.iOS Fonte: Xamarin.iOS (2017)
3.2 COMPARTILHAMENTO DE CÓDIGO
Um dos pilares da plataforma Xamarin é a possibilidade de compartilhar o código
escrito entre diferentes plataformas, agilizando e simplificando o processo de
desenvolvimento. Logo, é preciso destacar que existem diferentes formas dentro do
próprio Xamarin para realizar esse compartilhamento de código. Essas formas
também definem a estrutura do projeto durante o desenvolvimento, portanto é
necessário dominá-las para entender qual é a mais adequada para cada tipo de
aplicação.
3.2.1 Projeto de Ativos Compartilhados
Os projetos de ativos compartilhados (Shared Assets Projects), ou simplesmente
projetos shared, são a forma mais simples de compartilhamento de código oferecida.
Neles é possível escrever o código das camadas de dados, de negócios, de acesso
aos dados e serviços em um projeto separado, e esse projeto será referenciado por
29
projetos individuais do Android e do iOS. Diferente de outros tipos de projeto, um
projeto shared não possui uma saída, que muitas vezes ocorre na forma de DLLs. Isso
acontece porque o código será inteiramente compilado como parte do projeto em cada
um dos projetos que o referencie, como pode ser visto na Figura 7.
Figura 7 - Estrutura de um Projeto Shared Fonte: Xamarin (2017)
Os projetos Shared também possuem um recurso que permite definir blocos de
código específicos de cada plataforma, as diretivas de compilador. Essas diretivas irão
habilitar ou desabilitar partes do código de acordo com o projeto que o está
compilando no momento, como também pode ser visto na Figura 7. Para utilizá-las
basta incluir “#if __PLATAFORMA__” na seção específica do código e indicar a
plataforma em que o código deverá ser compilado.
Vale destacar também que um projeto shared não pode ser compilado sozinho,
tampouco referenciar um outro projeto, existindo apenas para ser incluído nos projetos
criados com ele. Por fim, a Figura 8 apresenta a estrutura de um exemplo de projeto
shared dentro do Xamarin Studio, onde também é possível ver o projeto shared sendo
referenciado no projeto iOS.
30
Figura 8 - Exemplo de Projeto Shared Fonte: Xamarin (2017)
3.2.2 Biblioteca de Classes Portátil
O framework .NET possui uma biblioteca base de classes conhecida como BCL
(Base Class Library), e cada uma das diferentes plataformas que suportam o .NET
utiliza um conjunto de recursos diferente da BCL. Normalmente, ao criar uma
aplicação ou uma biblioteca de classes, a DLL obtida no fim do processo funcionará
somente na plataforma para a qual foi criada, porém é possível contornar isso através
das bibliotecas de classes portáteis (Portable Class Libraries). Ao criar uma biblioteca
de classes portátil, também conhecida como PCL, é possível escolher em quais
plataformas ela rodará através de um perfil identificador, que indica quais recursos
serão suportados ou não para que ela seja compatível com as plataformas desejadas.
31
Utilizando a PCL todo o código que será compartilhado, como os modelos de
objetos ou o acesso ao banco de dados, é escrito e testado em um projeto separado,
e uma DLL será gerada no fim do processo, diferente do que ocorre com o projeto
Shared. Essa DLL é usada pelos projetos individuais do iOS e do Android e também
pode ser facilmente utilizada em outros projetos de terceiros.
Projetos que utilizam uma PCL para compartilhamento de código podem
enfrentar algumas desvantagens, como a impossibilidade de referenciar algumas
bibliotecas específicas das plataformas, mas isso pode ser contornado através do uso
de injeção de dependência. A Figura 9 apresenta a estrutura de um projeto que utiliza
uma biblioteca de classes portátil, já a Figura 10 mostra como é a organização de
pastas em uma Solução do Visual Studio, onde também é possível ver a PCL sendo
referenciada no projeto Xamarin.iOS.
Figura 9 - Estrutura de um Projeto PCL Fonte: Xamarin (2017)
32
Figura 10 - Exemplo de um Projeto PCL Fonte: Xamarin (2017)
3.3 DESENVOLVIMENTO
Para iniciar a criação de um novo aplicativo com o Xamarin é preciso atender a
certos requisitos. Como o Xamarin utiliza os recursos da própria plataforma para
entregar aplicações nativas é necessário possuir os kits de desenvolvimento de
software (Software Development Kits, ou SDKs) das respectivas plataformas
instalados, nesse caso os SDKs do iOS e do Android. Caso o sistema operacional do
computador utilizado para o desenvolvimento seja Windows também é preciso ter um
computador Mac conectado pela rede para realizar a execução do aplicativo
(XAMARIN, 2017). Ao instalar o Visual Studio é possível instalar também todos os
SDKs e outros requisitos para o desenvolvimento, como maquinas virtuais e softwares
de terceiros.
33
Tendo todas as ferramentas necessárias para o início do desenvolvimento basta
criar um novo projeto no Visual Studio. Durante a criação do projeto serão definidas
as características do projeto, ou seja, a forma de compartilhamento de código e como
será realizada a criação da interface. Com o projeto criado já é possível começar a
codificar.
Durante o desenvolvimento com o Xamarin também é possível se beneficiar de
um dos recursos mais populares das plataformas que utilizam o .NET: o gerenciador
de pacotes NuGet, que permite produzir, compartilhar e consumir pacotes de código,
agilizando o processo desenvolvimento.
3.4 PUBLICAÇÃO
Tendo o aplicativo pronto, o processo de finalização é simples e automatizado,
assim como quando se desenvolve sem o Xamarin. Porém existe um detalhe
importante ao gerar um arquivo APK ou IPA. Como tratado anteriormente, o Xamarin
permite criar aplicações nativas para múltiplas plataformas utilizando apenas a
linguagem C#. Para isso, é necessário que os seus componentes, como o Mono e as
diversas bibliotecas, estejam incluídos no arquivo final, o que acaba fazendo com que
o tamanho resultante da aplicação aumente consideravelmente. Porém nem todos os
assemblies que são incluídos no arquivo final acabam sendo utilizados pela aplicação.
Um exemplo disso pode ser observado com uma simples aplicação “Hello, World!”,
que aparentemente deveria ser pequena, mas graças aos muitos assemblies inclusos
pode chegar a mais de 15 MB. (XAMARIN, 2017).
Para contornar esse problema o Xamarin possui o Linker, uma ferramenta para
otimizar o produto final, fazendo com que ele fique menor. O Linker realiza uma análise
estática de todo o código da aplicação em busca dos assemblies, tipos e membros
que realmente estão sendo utilizados, e então, após terminar a análise, todo o resto é
descartado. Ele funciona como um coletor de lixo, que é capaz de diminuir o tamanho
da aplicação para entre 20% a 30% do tamanho normal. Seguindo o exemplo citado
anteriormente, a mesma aplicação “Hello, World!” que, sem o Linker, podia ter mais
34
de 15 MB, com a utilização do mesmo, pode ser reduzida para aproximadamente 3
MB (XAMARIN, 2017).
O comportamento do Linker pode ser configurado de três formas diferentes,
através da opção Linking, no Visual Studio, ou Linker Behavior, no Xamarin Studio. A
primeira delas é quando ele fica desativado, ou seja, não realiza a otimização. Este
comportamento é particularmente importante para solucionar problemas no tempo de
execução, permitindo saber se o Linker é o responsável, mas não é uma opção
recomendada para o ambiente de produção. A segunda opção é a mais básica. Com
ela o Linker irá analisar apenas os assemblies da parte do Xamarin, todo o resto do
código, incluindo o do usuário, é mantido intacto.
A terceira opção de comportamento é a mais arriscada. Nela o Linker irá otimizar
toda a aplicação, ou seja, tanto os assemblies do Xamarin quanto os do usuário e de
terceiros, o que fará com que o tamanho seja o mínimo possível. Porém essa opção
possui uma desvantagem perigosa. Como a análise do código é feita de forma
estática, é possível que, caso não existam referências estáticas, o Linker remova parte
do código do usuário ou de terceiros que não deveria ser removida. Isso pode ocorrer
em situações como chamadas dinâmicas via System.Reflection, tipos instanciados
dinamicamente, ou serialização XML, por exemplo (XAMARIN, 2017).
Existem diferentes formas de se contornar esse problema, das quais vale
destacar as duas mais simples. A primeira é através do atributo Preserve, que marca
o conteúdo que não deve ser apagado, mesmo que não existam referências estáticas.
A segunda seria a criação de um arquivo que “finge” utilizar o conteúdo a ser mantido.
Esse bloco de código criado não precisa ser chamado em nenhum momento, apenas
precisa estar em uma classe a ser compilada para que a análise estática do Linker
considere que o conteúdo deve ser preservado. Essa opção se aplica em casos onde
não é possível utilizar o Preserve ou não é necessário preservar o assembly completo
(XAMARIN, 2017).
Depois de gerado o produto final basta seguir os procedimentos padrões da loja
onde o aplicativo será publicado. Para a distribuição na App Store, loja de aplicativos
da Apple, é exigida uma licença do Apple Developer Program, com custo de US$ 99
anuais. Para a distribuição de aplicativos iOS, além da licença citada, é necessário
submeter a aplicação para avaliação e aprovação da Apple antes de ir para a App
Store. Para agilizar o processo de aprovação, é necessário que o aplicativo esteja de
acordo com as diretrizes estabelecidas pela Apple, como as orientações de interface
35
gráfica e as orientações de revisão da App Store. Já para a publicação na loja de
aplicativos do Google, a Google Play Store, é cobrada uma taxa única de US$ 25.
Antes de serem publicados, os aplicativos passam por um processo de revisão para
assegurar que não violam as políticas estabelecidas pela loja (MEIER, 2015).
36
4 METODOLOGIA DO TRABALHO
Segundo Oliveira (1997), o método é uma forma de pensar para se chegar à
natureza de um determinado problema, quer seja para estudá-lo, quer seja para
explicá-lo, e pesquisar significa planejar cuidadosamente uma investigação de acordo
com as normas da Metodologia Científica, tanto em termos de forma como de
conteúdo. Pode-se destacar dois métodos que são amplamente utilizados em
pesquisas e trabalhos acadêmicos: o quantitativo e o qualitativo. Estes, apesar de não
serem completamente opostos, são essencialmente diferentes, principalmente pela
forma de abordagem do problema, sendo importante avaliar o objeto de estudo para
escolher o método mais adequado.
Portanto, considerando a natureza exploratória deste trabalho, foi realizada uma
pesquisa aprofundada a partir de uma abordagem qualitativa, para avaliar a
viabilidade da plataforma Xamarin para o desenvolvimento de aplicações
multiplataforma. Por serem muitos os fatores variantes que influenciam esse
processo, os quais serão tratados posteriormente, uma abordagem puramente
quantitativa seria complexa e ineficiente, se tratando do contexto deste único trabalho.
Inicialmente, apesar do conhecimento prévio adquirido, foram estudados os
processos de desenvolvimento de aplicações para os sistemas operacionais Android
e iOS individualmente, utilizando-se majoritariamente de suas respectivas
documentações, que se mostraram bastante abrangentes. Essa etapa foi necessária
para entender como o Xamarin unifica os dois processos, podendo assim realizar uma
avaliação mais eficiente do mesmo ao fim do trabalho.
O passo seguinte consistiu em estudar sobre as técnicas de desenvolvimento
multiplataforma, bem como as tecnologias mais utilizadas. Para isso, foram realizadas
análises de diferentes artigos e trabalhos acadêmicos, dentre os quais pode-se
destacar Charland; Leroux (2011), Corral; Janes; Remencius (2012), Budiu (2013), e
Bezerra; Schimiguel (2016). Entender as diferentes técnicas e ferramentas utilizadas
permitiu avaliar se aquelas utilizadas pelo Xamarin são realmente eficientes.
Depois dessas etapas, os últimos conteúdos pesquisados foram a plataforma
Xamarin e a tecnologia de geofencing, que constituem a parte principal deste estudo.
Devido ao fato de ser relativamente nova, a plataforma Xamarin ainda não possui uma
quantidade expressiva de material quando comparada aos outros assuntos
37
pesquisados, portanto a principal fonte bibliográfica utilizada foi a sua documentação,
e mesmo ela se encontra apenas parcialmente traduzida. Também foram utilizados os
estudos de Radi (2016) e Panigrahy (2015). Depois das pesquisas, o conhecimento
adquirido foi utilizado para a construção do capítulo abordando o Xamarin e o seu
funcionamento.
Por fim, para colocar em prática os conceitos e conhecimentos explorados no
trabalho, foi realizado um estudo de caso, que será tratado devidamente em um
capítulo próprio.
4.1 TECNOLOGIAS E CONCEITOS UTILIZADOS
Antes de prosseguir para o desenvolvimento do aplicativo serão abordadas
outras tecnologias e conceitos relevantes que foram utilizadas durante o processo e o
motivo pelo qual as mesmas foram escolhidas para o trabalho. Os tópicos a seguir
serão breves, tratando apenas de uma descrição simplificada e uma justificativa, visto
que não cabe a este trabalho avaliar ou explorar os mesmos com profundidade.
4.1.1 MVVM
O MVVM (Model-View-ViewModel) é um padrão criado por engenheiros da
Microsoft que ajuda a desenvolver aplicações com baixo acoplamento e fácil
manutenção. O padrão é separado em Model, onde são tratados os dados em si, as
ViewModels que moldam esses dados para exibição e as Views que exibirão esses
dados já moldados. O ideal é que cada View tenha a sua ViewModel, sendo assim a
UI não fará acesso direto aos dados. Na Figura 11 vemos como funciona este padrão.
38
Figura 11 - Modelo Model-View-ViewModel Fonte: Microsoft (2012)
Além de compreender as responsabilidades dos três componentes, também é
importante entender como os componentes interagem uns com os outros. Ao nível
mais alto, a visão "conhece" o modelo de exibição e o modelo de visão "conhece" o
modelo, mas o modelo desconhece o modelo de visão e o modelo de visão não tem
conhecimento da visão. O MVVM se presta naturalmente às plataformas de aplicativos
XAML, presente nas aplicações desenvolvidos com o Xamarin (MICROSOFT, 2012).
Ele é um padrão de projeto e é necessário também um framework para o implementar.
No mercado existem alguns pacotes já disponíveis para um projeto Xamarin como o
MvvmCross e o MvvmLight.
4.1.2 GeoFence e Mapas
Geofence, ou cerca eletrônica, é uma tecnologia utilizada para monitorar objetos,
como pessoas ou veículos, através de localização por GPS (RECLUS; DROUARD,
2009). As coordenadas geográficas do objeto monitorado são automática e
constantemente enviadas para um centro de controle através de redes móveis.
Simultaneamente, outro grupo de coordenadas geográficas é usado para delimitar
39
uma área geográfica real. O sistema então determina se o objeto em questão está
dentro ou fora dessa área, chamada geofence, e emite um alerta no momento em que
ele entra nela.
Para especificar o local a ser monitorado é preciso definir um ponto de interesse,
indicando sua latitude e longitude. Feito isso é preciso também ajustar a área do local,
adicionando um raio. Com latitude, longitude e raio define-se a geofence, criando uma
área circular, ao redor do local, como pode ser observado na Figura 12.
Figura 12 - Estruturação de uma Geofence Fonte: Synology (2014)
Esta tecnologia será usada ao criar uma área delimitada para o usuário do
aparelho e para o estabelecimento, sendo o primeiro móvel e o segundo fixo. Quando
as duas áreas entram em contato, o aparelho do usuário verificará possíveis
promoções existentes naquele perímetro e notificará o usuário.
Em primeiro momento, usaremos três pacotes para gerar um mapa e marcar
pontos nele para indicar os estabelecimento; são os pacotes Xam.Plugin.Geolocator
e o Xamarin.Forms.Maps, sendo o primeiro necessário instalar no seu projeto. Com
40
esses dois pacotes no projeto, temos acesso a função
CrossGeolocator.Current.GetPositionAsync() do Geolocator que nos retorna a latitude
e a longitude da posição atual do usuário e a classe Map, que quando instanciada é
usada para renderizar um mapa no XAML e definir os pontos do usuário e dos
estabelecimentos.
41
5 ESTUDO DE CASO
Para o seguinte estudo de caso foi utilizada uma situação hipotética baseada em
um cenário real da cidade de Campos dos Goytacazes. A proposta foi a criação de um
aplicativo, desenvolvido com a plataforma Xamarin e com alvo nos sistemas
operacionais Android e iOS. O processo de desenvolvimento serviu para avaliar a
criação de aplicativos multiplataforma nativos, o desempenho do Xamarin neste
processo e como o código compartilhado se comportou dentro da plataforma,
mostrando o quanto de código foi aproveitado para ambas as plataformas. Também
será avaliado o uso da tecnologia de mapas e geolocalização, funcionalidades
centrais para o aplicativo, em conjunto com o Xamarin.
O aplicativo consiste em reunir as promoções que estão acontecendo em
estabelecimentos comerciais na cidade, em tempo real, e localizá-los com o uso do
GPS e do geofence. Essa localização se dará partindo do local atual do usuário,
retornando para ele as promoções que estão em uma área ao seu redor e notificar o
usuário que estiver bem próximo do estabelecimento. Além destas tecnologias, o
aplicativo usou também um banco de dados simulado para acessar informações dos
estabelecimentos participantes e suas respectivas promoções.
O desenvolvimento do aplicativo baseou-se na alta demanda que a cidade
oferece. A rede lojista da cidade de Campos dos Goytacazes é grande e possui uma
quantidade considerável de consumidores. A ideia foi utilizar este fator em favor das
lojas físicas, aproveitando-se do fato de ser comum o cliente possuir um aparelho
sempre em mãos. Promoções são realizadas todos os momentos na internet
envolvendo lojas virtuais, e é fácil conseguir uma boa visibilidade. Porém, as lojas
físicas não tem esse mesmo acesso, e é essa lacuna que o aplicativo busca
preencher.
Com a ajuda da tecnologia de geofencing, o usuário que for cadastrado no
sistema receberia uma notificação contendo as promoções que estão dentro da
intercessão entre o raio do usuário e o raio das lojas, ou seja, o usuário poderá ver,
em tempo real, no dispositivo as promoções que estão acontecendo nas lojas
próximas a ele.
42
5.1 PROJETO ARQUITETURAL
Antes de abordar o desenvolvimento é necessário tratar sobre algumas etapas
e escolhas que precisaram ser feitas inicialmente. Primeiramente, um diagrama
simples foi desenhado para estruturar o funcionamento do aplicativo. Considerando
as funcionalidades básicas, como procurar as promoções no mapa, através de uma
lista com todas as promoções ou então pesquisando diretamente as lojas, foi
elaborado o diagrama da Figura 13, visando criar uma estrutura viável para o
funcionamento do aplicativo. A estrutura de classes do aplicativo é simples, pois a
parte principal do funcionamento está ligada ao uso da tecnologia de geolocalização,
que não necessita de uma estrutura de classes complexa para demonstrar a sua
utilização.
Figura 13 – Diagrama de Classes
Fonte: Próprio
43
A classe Promoção é responsável por armazenar um nome e uma breve
descrição das promoções, além de estar ligada à loja que a cadastrou. Estas
informações foram exibidas para o usuário quando ele localizar as lojas pelo mapa.
As lojas possuem, além de um nome e uma imagem, latitude e longitude, que serão
usadas para localizar a sua posição no mapa. Elas também possuem um tipo ligado
à casse LojasTipo, que servirá para filtrar as lojas por categoria.
Tendo a base do aplicativo em mente, passa-se para a próxima etapa, que
consiste em escolhas diretamente ligadas ao desenvolvimento. A primeira delas é a
plataforma, ou framework, utilizada para realizar todo o processo. Como já destacado
no decorrer do trabalho, existem inúmeras plataformas e frameworks para auxiliar no
desenvolvimento. Porém, por se tratar de uma aplicação que utiliza o sistema de
localização do aparelho e para apresentar uma interface mais natural, gerando assim
uma melhor experiência para os usuários dos diferentes sistemas operacionais, o
modo híbrido tradicional baseado majoritariamente em HTML e JavaScript foi evitado.
Com isso é necessário voltar a atenção para o desenvolvimento nativo, mas sem
deixar de pensar no aspecto multiplataforma.
Depois de escolhida a plataforma de desenvolvimento, avança-se então para o
tipo de projeto do próprio Xamarin que foi utilizado, com as duas opções sendo o
projeto de ativos compartilhados e a biblioteca de classes portátil, ambos já abordados
anteriormente. Para este projeto foi escolhida a utilização da biblioteca de classes
portátil. Os projetos compartilhados, apesar de funcionarem bem em aplicações
simples e protótipos, como é o caso aqui, acabam misturando muito o código entre as
plataformas, o que pode gerar sérios problemas quando se trata de manutenibilidade
e testabilidade, principalmente em projetos maiores e mais complexos. Porém, apesar
deste caso ser relativamente simples, a biblioteca de classes portátil foi escolhida
justamente pela possibilidade de trabalhos futuros que expandiriam a aplicação. Com
esse tipo de projeto é possível obter uma maior portabilidade, testes podem ser
implementados mais facilmente e o código é mais limpo e legível.
O sistema operacional utilizado foi o Windows 10 Pro 64 bits, versão 1709, e o
IDE utilizado durante o desenvolvimento foi o Visual Studio 2017, pois no presente
momento é o padrão quando se desenvolve utilizando o Windows. Dentro do projeto
foram utilizados alguns pacotes para auxiliar no desenvolvimento, como o
Xamarin.Forms, Xam.Plugin.Geolocator, Arc.Geofencing, etc. Esses pacotes são
44
utilizados através do NuGet e servem para agilizar certas partes do desenvolvimento,
como criação de UI, gerenciamento de geolocalização e uso de geofences.
5.2 EXECUÇÃO
Após terminada a etapa de planejamento foi realizado o desenvolvimento do
aplicativo. Os tópicos subsequentes abordarão como foi este processo e também o
resultado obtido. As telas obtidas serão mostradas, assim como alguns exemplos de
código para que possa ser percebido como ambas as aplicações seguem o visual
nativo de suas respectivas plataformas utilizando as mesmas views.
5.2.1 Desenvolvimento
O aplicativo foi criado utilizando os conceitos e tecnologias já esclarecidos no
decorrer deste trabalho. Vale destacar que o banco de dados utilizado não foi um
SGBD tradicional como se espera de uma aplicação real. Para evitar digressões com
relação ao objetivo principal foi utilizado um banco de dados falso simulado dentro do
próprio aplicativo. Com isso, os dados utilizados são tratados como se estivessem
vindo de um banco de dados, para manter a organização do código, mas, na verdade,
eles estão sendo buscados em coleções de objetos pré-concebidas.
Para iniciar o desenvolvimento foi criado um novo projeto no Visual Studio do
tipo Cross-Platform App. Ao criá-lo também é necessário especificar quais serão as
plataformas alvo, qual tecnologia será utilizada para a criação da UI e qual será a
estratégia de compartilhamento de código. Como apresentado anteriormente, foram
selecionados respectivamente o Android e o iOS, o Xamarin.Forms e a PCL. Depois
de criado o projeto já é possível iniciar o desenvolvimento.
45
Figura 14 – Criação de um novo projeto do Xamarin
Fonte: Próprio
Para utilizar os mapas na aplicação foi escolhido o próprio pacote de mapas do
Xamarin.Forms, o Xamarin.Forms.Maps. Sua instalação é feita através do gerenciador
de pacotes do NuGet. Este pacote utiliza os mapas nativos do próprio dispositivo, ou
seja, o Google Maps no Android e o Apple Maps no iOS. Para usá-lo no projeto é
preciso apenas criar um novo mapa e inicializá-lo individualmente em cada plataforma.
A Figura 18 apresenta o código necessário para criar um mapa. Já a inicialização é
feita através de um único comando, o Xamarin.FormsMaps.Init(), que é incluído na
classe de inicialização de cada projeto. No Android é a classe MainActivity e no iOS,
a classe AppDelegate.
Para a tecnologia de geofence foi o utilizado o pacote Arc.Geofencing, também
disponível através do gerenciador de pacotes do NuGet. Assim como o pacote de
mapas, para usá-lo no projeto basta abrir o gerenciador do NuGet, procurar pelo
pacote e instalá-lo, e isso também é válido para qualquer outro pacote. Também é
possível utilizar o console do NuGet para instalar pacotes através de linha de
comando. Para utilizar o Arc.Geofencing é preciso instalá-lo em todos os projetos.
Uma vez instalado, também é preciso incluir nos projetos de cada plataforma uma
46
permissão de acesso à localização do dispositivo. No Android isto é feito no arquivo
AndroidManifest.xml, já no iOS é feito no arquivo Info.plist. O Visual Studio permite
que estas permissões de localização sejam incluídas de forma visual, sem precisar
utilizar linhas de código.
Figura 15 – Gerenciador de pacotes do NuGet e o pacote Acr.Geofencing
Fonte: Próprio
Ao terminar a instalação de todos os plug-ins necessários passou-se para a
estruturação do projeto, onde foram criadas as pastas para utilização do MVVM.
Existem pacotes do NuGet que realizam este processo automaticamente, trazendo
também exemplos de uso, porém, neste trabalho, as pastas Models, Views e
ViewModels foram criadas manualmente a fim de evitar o uso exagerado de pacotes.
Também foram criadas mais duas pastas, Helpers e Services, que foram utilizadas
para classes que tratam dos serviços e pacotes de terceiros, como a API do Google
Maps e o Arc.Geofencing.
47
Figura 16 – Estrutura final do projeto
Fonte: Próprio
5.2.2 Telas do Aplicativo
O aplicativo é composto por uma tela principal dividida em três abas diferentes.
A primeira aba contém uma lista com todas as promoções. Nela será possível para o
usuário ver quais são as promoções que estão ao alcance através de uma lista com
uma breve descrição. A Figura 17 traz a comparação de ambas as telas nos sistemas
Android e iOS. Ao clicar em uma das promoções o usuário poderá ver informações
detalhadas sobre a mesma. Ele também poderá optar por localizar a loja que está
oferecendo a promoção através do mapa, que constitui a segunda aba da tela principal
do aplicativo. Essas abas fazendo chamadas para as telas são geradas por um único
código no projeto PCL, sem que precise ser escrito nada nos projetos específicos do
sistema operacional, como é mostrado na Figura 18.
48
Figura 17 – Telas de listagem de promoções no Android e iOS
Fonte: Próprio
Figura 18 – Código utilizado para criar as abas e gerar as telas.
Fonte: Próprio
49
A segunda aba do aplicativo consiste em um mapa obtido através da API do
Google Maps. Nela é possível localizar as lojas e visualizar as suas promoções
diretamente no mapa, através de pins que marcam a sua localização. Nela serão
utilizados os pacotes Geolocator e Geofencing. A Figura 19 mostra o uso do pacote
Geolocator, que é utilizado para obter a localização atual do usuário, assim podemos
resgatar sua latitude e longitude. Posteriormente é gerado um mapa com as posições
obtidas que será adicionado ao layout criado.
Figura 19 – Código para retornar a posição do usuário e criar o mapa
Fonte: Próprio
Foram resgatadas do banco de dados as empresas e, dentro de uma estrutura
de repetição, colocados os pontos no mapa para indicar a posição da empresa de
acordo com a sua latitude e longitude. Nessa mesma estrutura foi gerada uma
geofence para cada empresa, com um nome, latitude, longitude e o tamanho do raio,
que será usado para possíveis notificações. A Figura 20 apresenta o código utilizado
para isso e a Figura 21, a tela com o mapa gerado.
A função 'StartMonitoring' gera a geofence com a latitude e a longitude que foi
passado por parâmetro, que são as mesmas posições usadas para criar os pins.
Assim, é possível verificar se há algum usuário dentro dessa geofence, possibilitando
disparar notificações de promoção, fazendo com que um cliente em potencial se atraia
para dentro da loja.
50
Figura 20 – Código para criação dos pins e da geofence no mapa
Fonte: Próprio
Figura 21 – Tela com o mapa gerado
Fonte: Próprio
51
Por fim, a terceira aba traz uma lista com as lojas que estão oferecendo as
promoções, permitindo que o usuário pesquise a partir das lojas de sua preferência. A
Figura 22 traz a tela obtida. Ao clicar em uma promoção na primeira tela ou em uma
loja nas outras duas, uma nova tela é exibida, contendo os detalhes da promoção ou,
no caso das lojas, informações sobre a loja e as promoções que ela está oferecendo,
caso existam. Na tela de mapa também é possível selecionar um pin de uma loja e
traçar uma rota até ele utilizando o aplicativo de mapas nativo do dispositivo.
Figura 22 – Tela com a lista das lojas
Fonte: Próprio
52
6 CONCLUSÃO
No decorrer deste trabalho foram abordados as características e o
funcionamento do Xamarin, as especificidades, do Xamarin.Android e do
Xamarin.iOS, e como esse conjunto de ferramentas pode ser utilizado para o
desenvolvimento de aplicações multiplataforma. Também foram destacadas certas
tecnologias e métodos que auxiliaram direta e indiretamente no desenvolvimento. Os
conhecimentos tratados foram colocados em prática através de um estudo de caso,
que consistia em um aplicativo que também utiliza um componente primário dos
smartphones, o GPS.
A partir disto foi possível enumerar os pontos positivos e negativos observados
durante o processo. O conjunto da plataforma Xamarin proporciona um ambiente de
trabalho confortável para a equipe de desenvolvimento, principalmente se comparado
a um desenvolvimento de forma direta, realizando processos individuais para cada
plataforma. A linguagem utilizada também merece destaque, pois certos aspectos do
C# funcionam muito bem neste contexto, como a facilidade de implementação de
programação assíncrona.
No que diz respeito ao objetivo principal deste trabalho e da utilização do
Xamarin em projetos semelhantes, o mesmo é capaz de cumprir o que promete. O
estudo de caso apresentado, que utiliza a biblioteca de classes portátil, teve quase
todo o seu código desenvolvido compartilhado para ambos os projetos, Android e iOS.
Toda a interface do aplicativo foi desenvolvida uma única vez no projeto portátil e
funcionou de forma completamente nativa em ambos os sistemas operacionais.
Porém, por se tratar de uma tecnologia ainda um pouco recente, não é incomum
se deparar com erros inesperados tanto durante o desenvolvimento quanto durante a
execução. Muitas vezes esses erros podem ser complexos para resolver e podem
exigir um nível de conhecimento um pouco mais profundo, seja do próprio Xamarin,
seja das outras tecnologias utilizadas em conjunto. Apesar disso, ainda é uma
tecnologia que traz muito mais vantagens do que desvantagens quando o assunto é
o desenvolvimento de aplicações multiplataforma.
53
6.1 TRABALHOS FUTUROS
É esperado que, durante um processo de criação como este, novas ideias
venham a surgir, revelando espaços para possíveis melhorias. Algumas dessas
melhorias não puderam ser incluídas no contexto deste único trabalho, pois
demandariam conhecimentos que fugiriam do tema proposto inicialmente e mais
tempo para serem desenvolvidas. Porém essas ideias podem ser abordadas no futuro
para dar continuidade ao projeto.
Expandindo o protótipo utilizado no estudo de caso, seria possível atingir ainda
mais plataformas, como o Windows Phone e a Windows Store, para desktop, ambas
suportadas pelo Xamarin. Como o projeto foi desenvolvido de forma cuidadosa com a
biblioteca de classes portátil, torná-lo compatível com essas outras plataformas seria
uma forma de explorar ainda mais o potencial do Xamarin.
Também é possível implementar novas funcionalidades ao aplicativo, como um
sistema de gerenciamento de banco de dados real acessado através de uma API. Isso
permitirá utilizar elementos mais complexos como controle de acesso dos usuários,
seja das lojas ou das próprias pessoas, e publicar a aplicação para que ela possa ser
testada e avaliada em um cenário real.
54
7 REFERENCIAL BIBLIOGRÁFICO
ABED, Robbie. Hybrid vs Native Mobile Apps – The Answer is Clear. 2016. Disponível em: <https://ymedialabs.com/hybrid-vs-native-mobile-apps-the-answer-is-clear/>. Acesso em: 22 jul. 2017. ABLESON, Frank. Introdução ao Desenvolvimento do Android. 2009. Disponível em: <https://www.ibm.com/developerworks/br/library/os-android-devel/index.html>. Acesso em: 16 jul. 2017. ALLEN, Sarah; GRAUPERA, Vidal; LUNDRIGAN, Lee. Desenvolvimento Profissional Multiplataforma para Smartphones: iPhone, Android, Windows Mobile e BlackBerry. Alta Books, 2012. AMADEO, Ron. Google’s iron grip on Android: Controlling open Source by any means necessary. 2013. Disponível em: https://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/3/. Acesso em: 16 jul. 2017. ANDROID. Arquitetura da Plataforma. 2017. Disponível em: <https://developer.android.com/guide/platform/index.html>. Acesso em: 16 jul. 2017. ANDROID. O processo de criação de um aplicativo Android. 2017. Disponível em: <https://developer.android.com/studio/build/index.html>. Acesso em 16 jul. 2017. APP ANNIE. App Annie Market Forecast 2016-2021. Disponível em: <http://go.appannie.com/report-app-annie-market-forecast-2017>. Acesso em: 02 ago. 2017. APPLE. iOS Technology Overview. 2014. Disponível em: <https://developer.apple.com/library/content/documentation/Miscellaneous/Conceptual/iPhoneOSTechOverview/Introduction/Introduction.html>. Acesso em: 03 ago. 2017. BEZERRA, P. T.; SCHIMIGUEL, J. Desenvolvimento de aplicações mobile crossplatform utilizando phonegap. 2016. Disponível em: <http://www.guilhermemachado.com/academiaquebraregras/wp-content/uploads/2016/02/B%C3%94NUS-GUILHERME-MACHADO-PERSONA.pdf>. Acesso em: 26 ago. 2017.
55
BIZNESSAPPS. Who is Making Apps in 2017? – A Small Business Market Roundup. 2017. Disponível em: <https://www.biznessapps.com/blog/dominating-apps-2017/>. Acesso em: 16 dez. 2017. BUDIU, Raluca. Mobile: Native Apps, Web Apps and Hybrid Apps. 2013. Disponível em: <https://www.nngroup.com/articles/mobile-native-apps/>. Acesso em: 22 jul. 2017. CORRAL, Luis; JANES, Andrea; REMENCIUS, Tadas. Potential advantages and disadvantages of multiplatform development frameworks – A vision on mobile environments. International Workshop on Service Discovery and Composition in Ubiquitous and Pervasive Environments (SUPE). Elsevier Ltd., 2012. P. 1202-1207 FAYAD, Mohamed; SCHMIDT, Douglas C. Object-Oriented Application Frameworks. Communications of the ACM, Vol. 40, No. 10, p. 32-38, 1997. Disponível em: <https://paginas.fe.up.pt/~aaguiar/as/acm-out97-p32-fayad.pdf>. Acesso em: 23 jul. 2017 LAMBDA3. Xamarin. 2016. Disponível em: <http://www.lambda3.com.br/2016/07/podcast-6-xamarin/> Acesso em: 10 jul. 2017. MATOS, Beatriz R. D; SILVA, João G. de B. e. Estudo comparativo entre o desenvolvimento de aplicativos móveis utilizando plataformas nativas e multiplataforma. 2016. Disponível em: <https://fga.unb.br/articles/0001/5114/Beatriz_Joao_TCC_Aplicativos_M_veis.pdf>. Acesso em: 18 jul. 2017. MRC. Native Mobile Apps: The Wrong Choice for Business?. 2013. Disponível em: <https://www.mrc-productivity.com/research/whitepapers/NativeAppsWrongChoice.pdf>. Acesso em: 16 jul. 2017. NET MARKET SHARE. Operating System Market Share. 2018. Disponível em: <https://www.netmarketshare.com/operating-system-market-share.aspx>. Acesso em 20 fev. 2018. OLIVEIRA, Silvio Luiz de. Tratado de Metodologia Científica. São Paulo: Pioneira. 1997.
56
OPENHUB. Android Written Code. 2017. Disponível em: <https://www.openhub.net/p/android/analyses/latest/languages_summary>. Acesso em: 17 jul. 2017. PACKTPUB. Execução lado-a-lado do Mono CLR e da Dalvik VM. 2017. Disponível em: <https://www.packtpub.com/mapt/book/application_development/9781783559169/2/ch02lvl1sec13/mono-and-dalvik-side-by-side>. Acesso em: 10 ago. 2017. PANIGRAHY, Nilanchala. Xamarin Mobile Application Development for Android. Second Edition. 2015. 298 p. Mumbai: Packt Publishing Ltd, 2015. PREZOTTO, Ezequiel D.; BONIATI, Bruno B. Estudo de Frameworks Multiplataforma Para Desenvolvimento de Aplicações Mobile Híbridas. Anais do EATI – Encontro Anual de Tecnologia da Informação e Semana Acadêmica de Tecnologia da Informação, 2014. Ano 4 n.1. p. 72 – 79. Disponível em: <http://www.eati.info/eati/2014/assets/anais/artigo8.pdf>. Acesso em: 30 jul. 2017. RADI, Amer A. Evaluation of Xamarin Forms for MultiPlatform Mobile Application Development. 2016. Technical Library. Paper 249. Disponível em: <http://scholarworks.gvsu.edu/cistechlib/249>. Acesso em: 10 ago. 2017. RECLUS, Fabrice; DROUARD, Kristen. Geofencing for Fleet and Freight Management. Proceedings of the 9th International Conference on Intelligent Transport Systems Telecommunication, Lille, France, 353-356. 2009 STATISTA. Number of available applications in the Google Play Store from December 2009 to June 2017. 2017. Disponível em: <https://www.statista.com/statistics/266210/number-of-available-applications-in-the-google-play-store/> Acesso em: 16 jul. 2017. SYNOLOGY. Estruturação de uma Geofence. 2014. Disponível em: <https://blog.synology.com/wp-content/uploads/2014/12/blog_image-2.jpg>. Acesso em: 20 ago. 2017. TECHCRESENDO. Top 10 Cross Platform Mobile Development Tools. 2017. Disponível em: https://techcresendo.com/2017/02/17/top-10-cross-platform-mobile-development-tools-2017/>. Acesso em: 14 jul. 2017. TUBINO; QUINCOZES; KAZIENKO. Construindo Aplicativos Híbridos com Ionic Framework. 2015.
57
Disponível em: <http://intranet.ctism.ufsm.br/~kazienko/paper/ttsc.pdf#page=62>. Acesso em: 20 jul. 2017. WEINBERGER, David. The MVP process then and now. KM World, Oct 2014, Vol.23(9), p.1,21 XAMARIN. Estrutura de um projeto PCL. 2017. Disponível em:
<https://developer.xamarin.com/guides/cross-
platform/application_fundamentals/pcl/introduction_to_portable_class_libraries/>.
Acesso em: 14 ago. 2017.
XAMARIN. Estrutura de um projeto shared. 2017. Disponível em:
<https://developer.xamarin.com/guides/cross-
platform/application_fundamentals/shared_projects/>. Acesso em: 14 ago. 2017.
XAMARIN. Xamarin Guides. 2017. Disponível em: <https://developer.xamarin.com/pt-br/guides/>. Acesso em: 05 ago. 2017. XAMARIN.ANDROID. Xamarin.Android Guides. 2017. Disponível em: <https://developer.xamarin.com/guides/android/>. Acesso em: 12 ago. 2017. XAMARIN.FORMS. Xamarin.Forms Guides. 2017. Disponível em: <https://developer.xamarin.com/guides/xamarin-forms/>. Acesso em: 08 ago. 2017. XAMARIN.IOS. Xamarin.iOS Guides. 2017. Disponível em: <https://developer.xamarin.com/guides/ios/>. Acesso em: 14 agosto. 2017. XAMARIN.IOS. Estrutura de uma aplicação Xamarin.iOS. 2017. Disponível em: <https://developer.xamarin.com/guides/ios/under_the_hood/architecture/>. Acesso em: 14 ago. 2017.