Victor Chaves Casé

EM DIREÇÃO A UMA ABORDAGEM PARA O DESENVOLVIMENTO
DE APLICATIVOS MÓVEIS MULTIPLATAFORMA

Trabalho de Graduação

Universidade Federal de Pernambuco
posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao

RECIFE
FEV/2015

Universidade Federal de Pernambuco
Centro de Informática
Graduação em Engenharia da Computação

Victor Chaves Casé

EM DIREÇÃO A UMA ABORDAGEM PARA O DESENVOLVIMENTO
DE APLICATIVOS MÓVEIS MULTIPLATAFORMA

Trabalho apresentado ao Programa de Graduação em Engenharia da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial
para obtenção do grau de Bacharel em Engenharia da
Computação.

Orientador: Phd. Vinicius Cardoso Garcia
Co-Orientador: Msc. Lenildo José de Morais

RECIFE
FEV/2015

Eu dedico este trabalho de graduação à toda minha família,
amigos e professores que estiveram comigo nesta jornada.

Agradecimentos
Primeiramente, gostaria de agradecer à toda minha família pela base que me foi dada, e
por me mostrar a importância da educação durante todas as etapas da minha vida. A minha noiva,
Isabela, por ter me acompanhado de perto durante toda a minha graduação e principalmente
no processo de desenvolvimento deste trabalho, me apoiado nos momentos mais difíceis e
comemorando as alegrias das boas novas. Meus pais, Ricardo e Alessanndra, e meu irmão,
Ricardo, pela paciência e compreensão, sempre presentes na longa jornada que foi a graduação
em engenharia, e principalmente pelo constante apoio e exemplos que me serviram de guia nesta
vida.
Aos meus amigos, cujo apoio foi fundamental para o término deste trabalho e para minha
graduação. Fica aqui o meu muito obrigado a todos, especialmente para os colegas de graduação
e pelas madrugadas no CIn : Danilo Pena, Diógenes Santos, Diogo Almeida , Ricardo Mariz,
Pedro Neves e Victor Carriço.
Aos professores Vinicius Cardoso Garcia (orientador), com o qual tive a oportunidade
de trabalhar durante 2 anos como monitor-auxiliar, fica aqui meu obrigado pela confiança
depositada, sempre abrindo novas oportunidades e acreditando no meu potencial. Lenildo Morais
(co-orientador), obrigado pela paciência de acompanhar a evolução deste trabalho, dando valiosos
feedbacks para o término do mesmo. E ao professor Kiev Gama, pela disposição de fazer parte
da banca deste trabalho.
Não poderia deixar de agradecer aos amigos da família Ustore pela compreensão e
colaboração de todos, pelas dicas e produtivas discussões sobre o tema. Sou grato pelo convívio
com vocês, que me faz aprender cada vez mais.
Obrigado a todos!

The key question to keep asking is, Are you spending your time on the right
things? Because time is all you have.
—RANDY PAUSCH

Resumo
A expansão do mercado tecnológico desencadeado pela apresentação em 2007 do primeiro iPhone resultou em uma onda de grandes oportunidades. Dentre estas, deu origem ao que
hoje conhecemos como Apps. Diante da possibilidade de lucrar e distribuir estes aplicativos
diretamente para o cliente final, milhares de desenvolvedores voltaram suas atenções para o
desenvolvimento de aplicativos móveis. Segundo uma pesquisa encomendada pela Universidade
do Alabama, estima-se que até 2017 sejam realizados aproximadamente 268 bilhões de downloads, resultando em uma receita de $77 bilhões. Porém, assim como proporcionaram grandes
oportunidades, essa abertura de mercado trouxe novos obstáculos: a onda de novos dispositivos
pós-iPhone - com diferentes modelos, tamanhos distintos, hardwares diferenciados e sistema
operacionais concorrentes - tornou o processo de desenvolvimento de apps muito mais complexo
do que no início, em que só existiam poucos dispositivos.
Atualmente, Apple, Google e Microsoft detêm a maior parte do market-share dos sistemas
operacionais embarcados nos smartphones, iOS, Android e Windows Phone respectivamente.
Essas empresas concorrem entre si de modo que os seus desenvolvedores sejam beneficiados,
em uma tentativa de blindagem contra as outras plataformas, visto que um dos critérios de
aquisição dos dispositivos é a quantidade e qualidade de apps disponíveis. Por outro lado, essa
incompatibilidade entre as plataformas é tema de discussão, uma vez que ela gera um custo
maior de desenvolvimento para cada plataforma suportada. A fim de minimizar esse custo,
desenvolvedores começaram a pensar em uma abordagem multiplataforma em que, por exemplo,
um App codificado para o iOS, tivesse um baixo custo para ser adaptado outras plataformas.
Desde então, diversas abordagens estão sendo estudadas neste sentido. Após a visualização
dessas, será realizada um estudo para analisar qual abordagem será mais adequada para o
desenvolvimento de um aplicativo móvel multiplataforma a partir de um cenário especificado.
Palavras-chave: Desenvolvimento de aplicativos moveis, desenvolvimento multiplataforma,
Titanium framework

Abstract
The expansion of the technology market triggered by the presentation of the first iPhone
in 2007 resulted in a wave of great opportunities. Among these gave rise to what we now know
as Apps. Given the opportunity to publish and monetize applications directly to the end customer,
thousands of developers migrate their attention to the development of mobile applications.
According to a survey commissioned by the University of Alabama, it is estimated that 2017
will be realized approximately 268 billion downloads, resulting in revenues of $ 77 billion.
These facts, draw attention of the whole community of developers. However, great opportunities
come new obstacles: the wave of new post-iPhone devices with different models, different sizes,
different hardware and operating system competitors, became the apps development process
much more complex than at the beginning, where there were only a few devices.
Apple, Google and Microsoft, today, hold most of the market share of operating systems
embedded in smartphones, iOS, Android and Windows Phone, respectively. These companies
compete with each other, to bring benefits to its developers, in an attempt to shield the other
platforms, since the main reason for choices between a device and the other is the quantity and
quality of available apps. Furthermore, this incompatibility between platforms is the subject of
debate, since it generates a higher development cost. Independent developers and companies
need to pay various development teams for each supported platform, and to optimize the cost,
developers began to think of a multiplatform approach where, for example, a coded App for
iOS, had its development cost minimized in the work porting to other platforms. Since then,
several approach being studied in this regard. After visualization of such a study is performed to
examine which approach is most suitable for the development of a mobile platform application
from a specified scenario.
Keywords: Development of mobile applications, cross-platform development, Titanium framework

Lista de Figuras
2.1
2.2
2.3
2.4
2.5

Arquitetura do iOS . . . . . . . .
Estrutura de um aplicativo iOS . .
Arquitetura do Android . . . . . .
Estrutura de um aplicativo Android
Tabela de similiaridade . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

15
17
19
22
22

3.1
3.2
3.3
3.4
3.5
3.6

Visão Geral de um Web app . . . . . . . . . . . . . . . . . . . . . . . . .
Visão Geral de um App híbrido . . . . . . . . . . . . . . . . . . . . . . . .
Visão Geral de um App gerado . . . . . . . . . . . . . . . . . . . . . . . .
Visão Geral de um App interpretado . . . . . . . . . . . . . . . . . . . . .
Abordagem Cross-Compilados . . . . . . . . . . . . . . . . . . . . . . . .
Comparação entre as abordagens de desenvolvimento de aplicações móveis

.
.
.
.
.
.

.
.
.
.
.
.

25
26
27
28
29
37

4.1
4.2

Tela principal do AcheUPA para iOS e Android . . . . . . . . . . . . . . . . .
Estrutura de diretórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39
42

Lista de Acrônimos
API

Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SDK Software Development Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
IDE

Integrated Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

MVC Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
DSL

Domain Specified Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

UI

User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

JSON JavaScript Object Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Sumário
1

2

3

Introdução
1.1 Relevância do tema . . . . . . . . . .
1.2 Objetivos . . . . . . . . . . . . . . .
1.2.1 Objetivos específicos . . . . .
1.3 Metodologia . . . . . . . . . . . . . .
1.3.1 Definição de multiplataforma
1.4 Fora de escopo . . . . . . . . . . . .
1.5 Estrutura deste trabalho . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

Desenvolvimento de Aplicativos
2.1 Apps . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Desenvolvimento de Apps iOS . . . . . . . . . . . . .
2.2.1 Arquitetura do iOS . . . . . . . . . . . . . . .
2.2.1.1 Camada Cocoa Touch . . . . . . . .
2.2.1.2 Camada de Mídia . . . . . . . . . .
2.2.1.3 Core Services . . . . . . . . . . . .
2.2.1.4 Core OS . . . . . . . . . . . . . . .
2.2.2 Estrutura de um aplicativo iOS . . . . . . . . .
2.3 Desenvolvimento de Apps Android . . . . . . . . . . .
2.3.1 Arquitetura do Android . . . . . . . . . . . . .
2.3.1.1 Application Framework . . . . . . .
2.3.1.2 Libraries . . . . . . . . . . . . . . .
2.3.1.3 Android Runtime . . . . . . . . . .
2.3.2 Estrutura de um aplicativo Android . . . . . .
2.4 Um comparativo sobre os componentes das plataformas
2.5 Conclusões sobre o desenvolvimento de aplicativos . .
Introdução a abordagens multiplataforma
3.1 Motivação . . . . . . . . . . . . . . . . . . . . . . .
3.2 Web apps . . . . . . . . . . . . . . . . . . . . . . .
3.3 Apps Híbridos . . . . . . . . . . . . . . . . . . . . .
3.4 Apps Gerados . . . . . . . . . . . . . . . . . . . . .
3.5 Apps Interpretados . . . . . . . . . . . . . . . . . .
3.6 Apps Cross-Compilados . . . . . . . . . . . . . . .
3.7 Alguns Frameworks em suas determinadas categorias

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

11
11
12
12
12
13
13
13

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

14
14
14
15
15
16
16
17
17
18
18
19
21
21
21
22
23

.
.
.
.
.
.
.

24
24
24
25
26
27
28
29

10
.
.
.
.
.
.
.
.
.
.

29
30
30
30
30
31
31
32
36
37

.
.
.
.
.
.
.
.
.

38
38
38
38
40
42
43
45
45
46

Conclusão
5.1 Principais Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Novas ferramentas em potencial . . . . . . . . . . . . . . . . . . . . .
5.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47
47
48
48

3.8

3.9
4

5

3.7.1 jQuery Mobile (WebApps) . . . . . . . . . .
3.7.2 PhoneGap/Apache Cordova (Apps Híbridos)
3.7.3 Titanium Framework (Apps Interpretados) .
3.7.4 Applause (Apps Gerados) . . . . . . . . . .
3.7.5 Apportable (Apps Cross-Compilados) . . . .
A escolha de uma abordagem multiplataforma . . . .
3.8.1 Critérios para avaliação . . . . . . . . . . . .
3.8.2 Avaliação dos critérios por abordagem . . . .
3.8.3 A indicação de uma abordagem . . . . . . .
Conclusão . . . . . . . . . . . . . . . . . . . . . . .

Desenvolvimento de um estudo de caso
4.1 Introdução . . . . . . . . . . . . . . . . . . .
4.2 Desenvolvimento do Aplicativo . . . . . . . .
4.2.1 Planejamento da UI . . . . . . . . . .
4.2.2 Implementando a UI . . . . . . . . .
4.2.3 Implementando as funcionalidades . .
4.2.3.1 Conectando a Webservices
4.2.3.2 Geolocalização . . . . . .
4.2.3.3 Chamadas a API específicas
4.3 Conclusões sobre o estudo de caso . . . . . .

Referências

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

49

11

1
Introdução
Genius is one percent inspiration, ninety-nine percent perspiration.
—THOMAS A. EDISON

A revolução dos dispositivos móveis iniciou-se em 2007, com a apresentação do então
considerado primeiro smartphone, o iPhone, muito a frente de celulares existentes na época, os
quais realizavam apenas tarefas básicas. Através de um inovador modelo de negócio baseado
na distribuição direta de aplicativos ao usuário, o iPhone rapidamente obteve reconhecimento
público: com apenas uma semana de lançamento foram contabilizados mais de 10 milhões
de downloads desses aplicativos nessa plataforma (READWRITE, 2012). Um ano após a
apresentação do iPhone, a loja de aplicativos da Apple - a App Store - já contava com 500 Apps.
As App Stores revolucionaram o mercado de software, pois enquanto os desenvolvedores
de aplicações baseadas em Desktop concorriam para distribuir suas criações em um modelo de
venda de licença, ou mesmo de taxa de serviço mensal, as lojas de aplicativos inovaram no sentido
de conectar diretamente o desenvolvedor com o cliente final. Dessa forma, o desenvolvedor
tinha a liberdade de colocar o preço de seu aplicativo, ou mesmo disponibilizá-lo gratuitamente,
cedendo à loja, porém, uma porcentagem da venda como taxa de serviço.

1.1

Relevância do tema

A fim de verificar o potencial econômico do mercado de aplicativos, a empresa de
consultoria Gartner, fez um estudo sobre o comportamento do mercado de apps. Essa pesquisa
indica uma expectativa de que até 2017 sejam transferidos mais de 268 bilhões de aplicativos
através das App Stores, gerando uma renda aproximada de 77 bilhões de dólares e afirmando a
prosperidade deste segmento (GARTNER, 2013).
Segundo IDC (2014), a App Store (Apple) e a Play Store (Google) detêm mais de 90% do
market-share do mercado de Apps, fator o qual leva os desenvolvedores a voltarem suas atenções
para essas duas maiores plataformas. A corrida para publicar e lucrar com novos Apps é diária,
e o tempo para a chegada do aplicativo à sua respectiva loja é um fator crucial para o sucesso

1.2. OBJETIVOS

12

do mesmo. Cada plataforma tem requisitos específicos, por exemplo, para um desenvolvimento
nativo, aplicações devem ser desenvolvidas separadamente: em Android normalmente são
programadas em Java, enquanto aplicações para iOS usam a linguagem Objective-C.
Todavia, quando é requisitado desenvolver um aplicativo que seja suportado em múltiplas
plataformas, uma aplicação elaborada para uma plataforma não será compatível com outra,
forçando o desenvolvedor a reescrever a aplicação para cada um dos cenários desejados, o que
aumenta o esforço e custo para o desenvolvedor e tempo para o aplicativo chegar ao usuário
final. A fim de solucionar essa adversidade, o desenvolvimento multiplataforma foi proposto,
abordagem na qual aplicativo é escrito apenas uma vez e adaptado para suportar vários sistemas
operacionais.

1.2

Objetivos

Este trabalho tem por objetivo principal apresentar as abordagens para o desenvolvimento
de aplicativos que devem suportar mais de uma plataforma. Por meio deste, serão expostas
as principais abordagens multiplataforma, suas vantagens e desvantagens, a fim de auxiliar na
escolha de uma destas, ao final será desenvolvido um estudo de caso para validar as vantagens
de adotar tal abordagem.

1.2.1

Objetivos específicos
Para alcançar o objetivo geral, foram designados objetivos específicos:

1.3 

Investigar sobre o desenvolvimento de aplicativos móveis. 

Pesquisar sobre a abordagem de desenvolvimento de apps móveis multiplataforma. 

Investigar quais as abordagens multiplataformas mais utilizadas. 

Discutir e avaliar as vantagens e desvantagens de cada abordagem. 

Desenvolver um estudo de caso utilizando uma abordagem multiplaforma.

Metodologia

Após a definição dos objetivos, foi realizada uma revisão da literatura com a intenção
de sintetizar as abordagens nativas e de multiplataforma mais utilizadas pelo mercado e suas
tendências (XANTHOPOULOS; XINOGALOS, 2013). Dentre os resultados da pesquisa se
destacaram as abordagens: Web apps, Apps híbridos, Apps interpretados, Apps gerados e Apps
cross-compilados.

1.4. FORA DE ESCOPO

1.3.1

13

Definição de multiplataforma

Diante dos dados explicitados pelo relatório do (IDC, 2014), o termo multiplataforma
será usado neste trabalho como referência às plataformas iOS e Android.

1.4

1.5

Fora de escopo 

A aprendizagem da utilização de IDEs das tecnologias nativas. 

A implementação de aplicativos móveis nativos 

A avaliação de desempenho entre as abordagens multiplaformas

Estrutura deste trabalho
Esta dissertação será organizada da seguinte forma:  

No Capítulo 2 é feita uma contextualização sobre o desenvolvimento de aplicativos
móveis.
No Capítulo 3 são levantadas as abordagens multiplataforma, bem como avaliadas
suas vantagens e desvantagens, a fim de indicar uma direção para a escolha de uma
dessas. 

No Capítulo 4 o estudo de caso é desenvolvido para validação deste trabalho. 

No Capítulo 5 são apresentadas as principais conclusões deste trabalho.

14

2
Desenvolvimento de Aplicativos
2.1

Apps

Os Apps são peças de softwares desenvolvidas para rodar em um sistema operacional
embarcado em dispositivos móveis. Tem como principal característica satisfazer de um modo
rápido e fácil a necessidade imediata de quem os utiliza. Por isso, o tempo de uso de um App
pode se resumir a apenas alguns toques ou gestos, alcançando o objetivo desejado e minimizando
o esforço do usuário.
Apesar de visualmente simples, Apps são softwares de extrema complexidade, uma
vez que, antes de qualquer escrita de código, o desenvolvedor deve considerar fatores como a
usabilidade do usuário e a interação homem-máquina. Essa última muito mais notável em uma
aplicação móvel do que em um sistema Desktop, por exemplo.
A especificidade de um aplicativo, focando a realização de uma tarefa singular, leva à
facilidade de interação do usuário com o mesmo. O objetivo é que esteja bem claro como utilizálo, minimizando a curva de aprendizado para usufruir do mesmo. Devido à essa característica, é
possível encontrar no mercado de Apps uma granularidade entre as categorias desses (STATISTA,
2015).

2.2

Desenvolvimento de Apps iOS

O iOS (APPLE, 2010) é o nome dado ao sistema operacional da família de dispositivos
Apple. Ele tem como objetivo fornecer uma série de facilidades e funcionalidades para que
os desenvolvedores aproveitem ao máximo o hardware embarcado destes dispositivos em seus
aplicativos, melhorando a experiência do usuários.
Para desenvolver um aplicativo iOS são necessários os seguintes requisitos mínimos: 

Um computador Mac rodando uma versão do OS X 10.9.4 ou superior. 

Xcode Integrated Development Environment (IDE) (mais atualizado). 

iOS Software Development Kit (SDK)

2.2. DESENVOLVIMENTO DE APPS IOS

15

Normalmente um aplicativo iOS é escrito na linguagem Objective-C ou, mais recentemente, na linguagem Swift, na qual é utilizada o Xcode para a escrita do código em si, modelagem
e construção da interface gráfica e auxílio na compilação e depuração do aplicativo.
Para entender o processo de desenvolvimento de aplicativos iOS é necessário um prévio
conhecimento da arquitetura do sistema operacional, a fim de conhecer os principais componentes
disponibilizados pelo iOS SDK.

2.2.1

Arquitetura do iOS

O esquema de arquitetura do iOS pode ser vista em quatro grandes camadas de abstração
(APPLE, 2010), como visto na Figura 2.1. Apesar dessas divisões em camadas, um App pode se
comunicar com qualquer uma das camadas diretamente, mas deve-se atentar que a utilização de
componentes das camadas mais inferiores exige uma maior complexidade do código.

Figura 2.1: Arquitetura do iOS1

2.2.1.1

Camada Cocoa Touch

A camada Cocoa Touch contém um conjunto de bibliotecas, chamado de Kits, que
definem padrões de projetos para a estrutura básica de uma aplicativo. Para uma lista completa
de todos os kits, verificar (APPLE, 2010).
UIKit Framework
Este framework provê os blocos básicos da estrutura necessária para a construção e
manutenção do App e seu ciclo de vida em execução. É encontrado neste kit, por exemplo,
o conjunto de arquiteturas gráficas que é utilizado na modelagem da interface visual,
além do controle de eventos de toque gerados pelo usuário através daquela. Ou até
1 https://cdn.tutsplus.com/mobile/uploads/legacy/Exploring-the-iOS-SDK/figure-01.png

2.2. DESENVOLVIMENTO DE APPS IOS

16

mesmo quesitos mais básicos, como o controle do loop principal do aplicativo durante sua
interação com o sistema.
Multitasking Framework
Este framework permite que, quando um aplicativo é finalizado, é colocado em um modo
congelado, residindo na memória, porém sem permissão para executar nenhuma ação.
Entretanto, em alguns casos, é necessário realizar alguma operação em segundo plano,
devendo informar a necessidade através de um arquivo de propriedades, para que o sistema
operacional possibilite o Multitasking (APPLE, 2010).
2.2.1.2

Camada de Mídia

Esta camada contém as principais bibliotecas de controle de multimídia, permitindo ao
desenvolvedor a escolha da utilização de uma variedade de componentes para a construção do
aplicativo. Como por exemplo, Core Graphics, Core Animation, Core Image, OpenGL, Metal,
entre outros.
2.2.1.3

Core Services

Esta camada contém frameworks fundamentais para o desenvolvimento de um aplicativo.
Destacam-se o Foundation Framework, que define os tipos básicos e o recente adicionado, e o
JavaScriptCore Framework, que permite o desenvolvimento de aplicativos nativos através da
linguagem JavaScript.
Foundation Framework
Este framework define uma camada de abstração para as classes escritas em ObjectiveC, facilitando o desenvolvimento do aplicativo. Por exemplo, provê uma super classe,
chamada de NSObject, que contém um conjunto de classes auxiliares para desalocação da
memória, suporte a strings no formato unicode, persistência de objetos, dicionários, entre
outros.
JavaScriptCore Framework Até a versão do iOS 7, o único modo de um aplicativo iOS
interagir com um código JavaScript seria através da subclasse UIWebView, que contém um
método para avaliar o código JavaScript: stringByEvaluatingJavaScriptFromString.
O problema é que o UIWebView detém o seu próprio ambiente de execução JavaScript,
em que é possível utilizar esse método para avaliar somente scripts escritos dentro de
documentos HTML, executados pelo UIWebView, limitando o acesso dos mesmos ao
ambiente completo.
Para remover essa restrição, foi proposto o JavaScriptCore framework. Basicamente, este
é uma composição de Application Programming Interface (API) escritas em Objective-C,
que dão acesso aos desenvolvedores a todo o ambiente de execução JavaScript a partir

2.2. DESENVOLVIMENTO DE APPS IOS

17

do Objective-C. Como por exemplo, verificação de sintaxe e execução de scripts, acesso
às variáveis, recebimento de funções de retorno, e principalmente o compartilhamento
de objetos presentes no Objective-C, tornando possível uma real interação entre esses
ambientes.
2.2.1.4

Core OS

A camada Core OS é a camada mais inferior dentre as quatro camadas, encapsulando o
kernel e bibliotecas de baixo nível do UNIX, para quais as aplicações não têm interação direta
por motivos de segurança. Porém, algumas outras estão disponíveis publicamente, como por
exemplo, sockets BSD, POSIX threads e serviços de DNS (Domain Name Service).

2.2.2

Estrutura de um aplicativo iOS

Cada aplicativo iOS tem como alicerce principal um objeto chamado UIApplication, que
é uma subclasse do NSObject, e tem por objetivo permitir a interação entre os objetos do sistema
operacional ou mesmo com outros objetos do mesmo App. Pode-se examinar na Figura 2.2 a
maioria dos componentes mais comuns em um app baseado no iOS.

Figura 2.2: Estrutura de um aplicativo iOS2

2 http://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Art/core_objects_2x.p

2.3. DESENVOLVIMENTO DE APPS ANDROID

18

Percebe-se a utilização do padrão de projeto Model-View-Controller (MVC), que permite
uma camada de segregação entre o código lógico e a interface visual. Isso possibilita que, no
desenvolvimento do aplicativo, a lógica de negócio seja reutilizada, enquanto o código de
interface visual seja adaptado para suportar diferentes dispositivos e resolução distintas.
Para mais informações sobre o desenvolvimento de aplicativos iOS ver HILLEGASS
(2011) NUTTING et al. (2014) SERVICES (2010)

2.3

Desenvolvimento de Apps Android

Android é o nome dado ao sistema operacional de código aberto da Google, baseado em
uma versão modificada do kernel do Linux. Além da Google, todos os outros membros da Open
Handset Alliance (Open Handset Alliance, 2007), constituído por um consórcio de 80 empresas
de hardware/software/telecom, colaboram para o desenvolvimento dessa plataforma.
Para desenvolver um aplicativo Android são necessários os seguintes requisitos mínimos: 

Um computador Linux/Mac OS X 10.9.4 ou superior/Windows XP ou superior. 

Eclipse (mais atualizado). 

Android Development Tools (ADT).

Normalmente um aplicativo Android é escrito na linguagem Java, em que é utilizada a
IDE Eclipse, em conjunto com o ADT, para a escrita do código em si, modelagem e construção
da interface gráfica e auxílio na compilação e depuração do aplicativo.
Para entender o processo de desenvolvimento de aplicativos Android é necessário um
prévio conhecimento da arquitetura do sistema operacional, a fim de conhecer os principais
componentes disponibilizados pelo Android Development Tools.

2.3.1

Arquitetura do Android

O sistema operacional Android pode ser visto por uma composição de cinco componentes
principais, conforme a Figura 2.3.
Uma das principais características herdadas de um sistema baseado em Linux foi o
conceito de múltiplos usuários, em que o Android considera cada App como um usuário distinto.
Isso permite que cada App seja executado dentro de um processo diferente um do outro, criando
uma espécie de sandbox, ou seja, um ambiente seguro para que um App não acesse o espaço
de endereçamento alheio, ou até mesmo do próprio sistema operacional. Além disso, cada App
por padrão é executado com o mínimo de permissões necessárias e, caso seja necessário utilizar
APIs do sistema operacional, como SMS, Agenda, Bluetooth e etc, é necessário que o usuário
aceite explicitamente no momento da instalação do App.

2.3. DESENVOLVIMENTO DE APPS ANDROID

19

Figura 2.3: Arquitetura do Android3

2.3.1.1

Application Framework

Um App Android é constituído basicamente de blocos modulares (GOOGLE, 2015a).
A motivação para esta arquitetura é o poder de economia no desenvolvimento que se ganha ao
reutilizar funções que já são satisfeitas por um App terceiro. Estes blocos são chamados de
componentes essenciais, cada um com sua função específica. Em geral, existem quatro tipos
principais de componentes essenciais oferecidos por este framework.
Activity
Um activity é um componente essencial que provê uma tela que permite a interação
do usuário com objetivo de realizar alguma ação (GOOGLE, 2015a). Cada activity é
relacionada à uma janela, que normalmente preenche toda a tela do dispositivo móvel,
3 http://www.developer.com/imagesvr_ce/1638/CloudAndroid0_r1_c1.jpg

2.3. DESENVOLVIMENTO DE APPS ANDROID

20

podendo ser também um espécie de modal (janela sobreposta). Normalmente um App
Android é constituído de várias activities independentes, onde a principal é nomeada de
"main", e será a primeira a ser apresentada visualmente ao usuário.
Cada activity pode solicitar ou chamar outras, com o objetivo de realizar diferentes ações.
Cada vez que uma activity é iniciada, a anterior é parada, e armazenada em um registro da
pilha de contexto, chamada de "back stack". Além disso, ao receber uma ordem de parada,
a activity pausada deve liberar recursos, principalmente os de rede e banco de dados, por
exemplo.
A comunicação entre activities de Apps terceiros não é realizada diretamente entre os
aplicativos, sendo necessário criar uma intenção, que vai ser controlada pelo sistema
operacional. Assim, para um App interagir com o espaço reservado de um outro App,
é preciso criar um objeto contendo uma mensagem ao sistema operacional, o chamado
Intent, que irá criar uma ponte virtual entre os Apps em tempo de execução.
Um Intent pode executar uma ação de visualização ou modificação, como por exemplo, ao
escrever em um bloco de notas e solicitar ao App de e-mail para que o envie, é necessário
criar uma ponte enviando os dados da sua aplicação para o aplicativo de e-mail, contendo
os dados escritos no bloco de notas que se tem a intenção de imprimir.
Services
Um service é um componente essencial criado para rodar tarefas muito longas em segundo
plano (GOOGLE, 2015a). Diferente de uma Activity, o service não provê uma interface
gráfica, isto permite que o usuário modifique a pilha de contexto, por exemplo iniciando
outro App, e o service continue sendo executado em plano de fundo: executando uma operação de I/O (input/output), ou utilizando recursos de rede para realizar download/upload
de arquivos grandes.
Um service normalmente tem dois estados: "started e bound". O service "started"roda
independentemente da activity que o chamou, e é responsável por finalizar-se ao término
do trabalho. Já um service "bound"oferece um modo de comunicação intra processo (IPC),
no qual múltiplos componentes podem se comunicar com aquele para enviar ou requerer
requisições.
Content Providers
Um content provider é uma interface padrão de comunicação de dados compartilhados
entre processos (GOOGLE, 2015a). Este é responsável por controlar o acesso de terceiros
aos dados compartilhado de uma aplicação, caso seja permitido. Por padrão, o ciclo de
vida de um content provider é receber uma requisição de dados, executar a requisição e
retornar um resultado.
Broadcast Receivers

2.3. DESENVOLVIMENTO DE APPS ANDROID

21

Um broadcast receiver é um componente que controla o recebimento e envio de anúncios
globais do app para o sistema ou vice-versa (GOOGLE, 2015a), por exemplo, o aviso do
sistema operacional para um aplicativo cuja a bateria do dispositivo está baixa. Semelhantemente ao services, os broadcast receivers não têm uma interface gráfica própria, porém
pode se utilizar em alguns casos de uma área específica do sistema operacional, conhecida
como status bar, para criar uma notificação visível ao usuário.
2.3.1.2

Libraries

As Libraries são bibliotecas de uso compartilhado, normalmente escritas na linguagem
de programação C, para se obter um melhor desempenho. Dentre elas se destacam: OpenCore,
SQLite, OpenGL ES 2.0, WebKit e SSL.
2.3.1.3

Android Runtime

Dado que o ambiente de execução do Android deva suportar uma gama de dispositivos
heterogêneos com diferentes requisitos de hardwares, as aplicações necessitam ser encapsuladas
para atender os requisitos de desempenho e segurança sem depender do hardware embarcado.
Assim, cada aplicativo Android roda seu próprio processo, com sua própria instância da máquina
virtual Dalvik, ou mais recentemente ART (GOOGLE, 2015b).
A Dalvik foi desenvolvida para o Android permitindo que o dispositivo consiga suportar
o overhead, que é criado pelas instanciações de múltiplas máquinas virtuais eficientemente. Esta
VM executa classes compiladas pelo Java que são transformadas em um formato nativo desta,
o formato .dex, por uma ferramenta chamada dxtools, minimizando em até 50% o consumo
de memória em relação ao bytecode original (TECHTROPIA, 2013). Apesar de não estar
explicitado na figura 2.3, a máquina virtual Dalvik tem acesso direto ao kernel do Linux para
manipulação de funcionalidades como threads e controle da memória.

2.3.2

Estrutura de um aplicativo Android

Cada aplicativo Android tem como base uma classe chamada java.lang.Object. Esta
classe é a raiz de toda a hierarquia de classes primitivas e não primitivas, como por exemplo, os
componentes essenciais vistos acima. A maioria desses componentes mais comuns em um App
desenhado para Android pode ser observado na Figura 2.4.
Para mais informações sobre o desenvolvimento de aplicativos Android ver MEW (2011)
e ROGERS et al. (2009)

2.4. UM COMPARATIVO SOBRE OS COMPONENTES DAS PLATAFORMAS

22

Figura 2.4: Estrutura de um aplicativo Android4

2.4

Um comparativo sobre os componentes das plataformas

Conforme visto na Figura 2.2 e na Figura 2.4 existe diferença entre as arquiteturas de
cada plataforma. Entretanto pode-se perceber algumas equivalências entre os componentes do
ponto de vista estrutural de um App. Adiante algumas dessas podem ser vistas na Figura 2.5.

Figura 2.5: Tabela de similiaridade
4 https://vladnevzorov.files.wordpress.com/2011/05/classes4.png

2.5. CONCLUSÕES SOBRE O DESENVOLVIMENTO DE APLICATIVOS

23

Em relação a interface gráfica, temos que os Activities são os componentes visuais mais
básico no Android, assim como os UIViewControllers são os componentes visuais mais básicos
no iOS.
O iOS utiliza-se do padrão de projeto Delegate, implementado no Application Delegate.
Esse padrão permite que o trabalho associado a um objeto possa ser transferido para um outro
objeto, chamado de delegador, esse último irá realizar o trabalho associado liberando o primeiro
a realizar outras tarefas. Ao final do trabalho, o delegador enviará uma mensagem para o objeto
original informando o seu término. Esse mesmo conceito pode ser encontrado no Android através
dos Event Listeners.
Como visto anteriormente, o Android utiliza-se dos Services para rodar longas tarefas em
segundo plano. Já no iOS, existe uma restrição para se criar esses tipos de tarefas por motivos
de economia de bateria. Entretanto o conceito mais próximo seria a utilização de uma técnica
implementada no servidor chamada Push Notification, na qual um App, ao invés de realizar
várias requisições ao servidor para verificar se um determinado evento aconteceu, o mesmo
ficará escutando o servidor e somente receberá uma mensagem quando o determinado evento
acontecer.
Para os conceitos de Intent e BroadcastReveicer, específicos do Android, não foi encontrado nenhum componente explícito presente no iOS para se realizar a comparação.

2.5

Conclusões sobre o desenvolvimento de aplicativos

Como visto nas seções anteriores, pode-se perceber que cada plataforma requer uma
linguagem de programação específica, diferentes requisitos e ambientes de desenvolvimento e
distintos modelos de programação, baseado em seus kits de desenvolvimento específicos (SDK).
Por exemplo, desenvolver aplicativos para Android requer um prévio conhecimento de Java,
enquanto desenvolver para iOS requer domínio sobre Objective-C/Swift.
O problema ocorre quando um aplicativo precisa ser pensado para suportar ambas
as plataformas, exigindo a restrição de se manter duas versões do mesmo produto, porém
implementadas em suas tecnologias nativas, e como pode-se perceber baseado nas seções acima,
totalmente independentes e incompatíveis.
A fragmentação, termo utilizado para descrever as diferentes versões de sistema operacional, e distintas resoluções de tela entre os dispositivo móveis, tornou-se um dos maiores
obstáculos no ecossistema mobile, sendo um dos fatores mais significantes e custoso para o
desenvolvimento e manutenção de um aplicativo pensado em multiplataformas (FLING, 2009).
Pelo alto custo adicionado ao desenvolvimento e manutenção a cada nova plataforma
suportada, foi pensada uma abordagem onde fosse possível reusar parte do esforço utilizado em
uma plataforma, no desenvolvimento de outras, a fim de reduzir o custo associado.

24

3
Introdução a abordagens multiplataforma
3.1

Motivação

Conforme visto no Capítulo 2, é possível ter uma ideia sobre os componentes cada
sistema operacional, suas características e diferenças. O custo de desenvolvimento de um App
pensado para suportar ambas as plataformas requer manter dois repositórios de código em
paralelo, mantidos por uma ou mais equipes de desenvolvimento, o que em algumas fases de um
projeto, seja individual ou corporativo, pode se tornar inviável em termos financeiros.
Sabe-se que o Android tem um mercado mais abrangente, entretanto o iOS é a plataforma
mais rentável (The Guardian, 2013). Visando contemplar os benefícios de cada plataforma e
evitar a criação de dois ou mais bancos de código independentes, os desenvolvedores começaram a pensar em abordagens extensíveis à maioria das plataformas (XANTHOPOULOS;
XINOGALOS, 2013).

3.2

Web apps

A primeira abordagem foi utilizar o navegador de internet (browser) como base de
abstração para o sistema operacional, como visto na Figura 3.1, uma vez que o browser já estava
presente em ambas plataformas. Os Web apps são sites responsivos, ou seja, que adaptam seu
conteúdo para serem visualizados em diferentes formatos de tela ou orientação, desenvolvidos
utilizando HTML5 e rodam sobre o browser do dispositivo, o aplicativo não é instalado. Os Web
apps aparentam ter a interface visual de um App nativo.
Pelo fato destas tecnologias relacionadas ao desenvolvimento de sites já serem bastante
utilizadas e maduras e devido à grande quantidade de desenvolvedores na área, o custo de
desenvolvimento de um Web app comparado ao App nativo é muito menor. Além disso, por
ser acessado através de um browser, os Web Apps não são distribuídos pelas App Stores, não
passando pelo processo de revisão e chegando ao cliente rapidamente.
Logo, verifica-se que a principal vantagem de um Web app é o rápido desenvolvimento
multiplataforma aliado ao baixo custo. Outra vantagem é a facilidade da manutenção de um Web

3.3. APPS HÍBRIDOS

25

App, ou seja, adicionar novas funcionalidades, por exemplo, pois assim como sistemas Web,
basta modificar o código do site no servidor, não sendo necessária nenhuma atualização no lado
do cliente.
Em compensação a desvantagem dos Web apps é a impossibilidade de usufruir da
distribuição e das ações de marketing providos pelas lojas de aplicativos, visto que os mesmos
são acessados através de uma URL (HEITKöTTER; HANSCHKE; MAJCHRZAK, 2013). Além
disso, seu desempenho é comprometido pela renderização que é realizada através de um browser,
e pela qualidade da infraestrutura de rede, pois a cada nova página solicitada, é realizada uma
nova requisição ao servidor externo (backend) como visto na Figura 3.1, onde em casos extremos
pode-se ter um Web app indisponível.
Diante disso, a utilização desta abordagem é apenas recomendada para aplicações simples,
e que não necessitem de recursos nativos de cada plataforma.

Figura 3.1: Visão Geral de um Web app1

3.3

Apps Híbridos

Para contornar as desvantagens dos Web Apps, foi pensada em uma abordagem híbrida,
na qual tenta-se combinar as vantagens de um Web App e a de um App nativo. Os Apps
híbridos, assim como os Web Apps, são desenvolvidos utilizando tecnologias web como HTML5.
Entretanto sua diferença está no fato de ser encapsulado por browser transparente ao usuário,
chamado de UIWebView (iOS) e WebView ( Android ).
O funcionamento de um App híbrido, baseia-se na utilização do engine Webkit presente
nesses browsers nativos como visto na Seção 2.2.1.3, que tem como responsabilidade renderizar
o HTML5 escrito para a aplicação. Pelo fato de ambas as plataformas, conter esse engine de
renderização, obtém-se o mesmo comportamento esperado.
1 http://cross-platform.mobi/images/cpmd_serversideweb.png

3.4. APPS GERADOS

26

Os Apps híbridos, por serem encapsulados em um componente nativo, vide Figura
3.2, são visualizados pelo sistema operacional como aplicações nativas, possibilitando serem
distribuídos pelas lojas de aplicativos presentes nas plataformas.
Além disso, os aplicativos híbridos se utilizam de funcionalidades presentes no HTML5,
como por exemplo, web storage W3C (2013a) e geolocation W3C (2013b), para serem executados sem a dependência imediata de uma infraestrutura de rede, e possibilitar chamadas as APIs
nativas de Geolocalização, respectivamente. Isso minimiza as restrições em relação aos Web
Apps, ao mesmo tempo que mantém o desenvolvimento rápido e a baixo custo.
A desvantagem dos Apps híbridos é percebida pelo fator desempenho, pois assim como
os Web Apps, estes são renderizados como uma página web, através do browser. Além disso,
o App é restringido ao contexto da WebView, limitando o acesso a funcionalidades presentes
no SDK, vistas nas Figuras 2.1 e 2.3. Ademais, limites técnicos presentes na especificação do
HTML5, por exemplo, o limite de 5MB para o web storage, podem tornar excludente a escolha
desta abordagem.

Figura 3.2: Visão Geral de um App híbrido2

3.4

Apps Gerados

Os Apps gerados (XANTHOPOULOS; XINOGALOS, 2013), são desenvolvidos a
partir de uma descrição em alto nível, normalmente utilizando-se de uma Domain Specified
Language (DSL) (DEURSEN; KLINT; VISSER, 2000), na qual várias regras de negócios são
estruturadas, por exemplo utilizando UML, gerando um modelo, que servirá de base para a
gerador de códigos nativo de cada plataforma, como visto na Figura 3.3.
2 http://cross-platform.mobi/images/cpmd_hybridapps.png

3.5. APPS INTERPRETADOS

27

Esta abordagem, permite que os Apps tenham o mesmo desempenho de um App nativo,
pois após ter o modelo interpretado pelo gerador de códigos, o mesmo criará vários códigos
nativos escrito para as plataformas descriminadas. Assim, torna-se possível escrever códigos em
alto nível, que fazem uso de todo o potencial do SDK destas plataformas, previsto na DSL.
Entretanto, a desvantagem da utilização da abordagem dos Apps Gerados está na necessidade do aprendizado de uma linguagem específica do domínio, e caso venha a ser necessário
utilizar alguma funcionalidade não descrita na DSL ou acompanhar as atualizações dos SDKs,
o código nativo e o gerador de códigos devem ser alterado para suportar esses requisitos. Isso
causa um overhead para o desenvolvedor, visto que será necessário escrever para cada uma
dessas plataformas suportada.

Figura 3.3: Visão Geral de um App gerado3

3.5

Apps Interpretados

Os Apps interpretados são uma evolução natural dos Apps híbridos, conseguindo unir
as vantagens do rápido desenvolvimento, utilizando JavaScript, e o desempenho nativo provido
pelos Apps Gerados. Em parte, essa evolução foi possibilitada pela adição de interpretadores
JavaScript, como o JavaScriptCore Framework visto na seção 2.2.1.3, aos sistemas operacionais,
onde antes estavam presentes apenas no escopo de componentes de WebViews.
Assim, esta abordagem tem como principal característica a utilização de uma camada
intermediária, uma ponte, que será responsável pela comunicação entre o código interpretado
pelo interpretador JavaScript e o ambiente de execução do código nativo de cada plataforma,
conforme visto na Figura 3.4.
3 http://cross-platform.mobi/images/cpmd_generatedapps.png

3.6. APPS CROSS-COMPILADOS

28

A principal vantagem desse tipo de abordagem é o desempenho do App muito próximo
ao nativo, somente diferindo pela existência de um overhead gerado pela figura de uma ponte.
Além disso, como o interpretador JavaScript agora pertence ao sistema operacional e não a um
componente de WebView, faz com que seja permitido ao App o acesso a todas as camadas do
sistema operacional 2.1 2.3, diferentemente dos Apps Híbridos.
Todavia, a desvantagem vem do fato de ser necessário implementar uma camada intermediária para comunicação com os interpretadores JavaScript presente nas plataforma suportadas.
Entretanto, adiante será mostrado que essa desvantagem é minimizada pela utilização de ferramentas que já provêm uma interface de programação (API) normalizada para a comunicação
com os interpretadores destas plataformas.

Figura 3.4: Visão Geral de um App interpretado4

3.6

Apps Cross-Compilados

Diferente das abordagens citadas acima, os Apps cross-compilados são escritos e desenvolvidos a partir da escolha de uma das tecnologias nativas Java ou Objective-C. A estratégia de
suportar múltipla plataformas vem da utilização de um compilador cruzado, que será utilizado
para traduzir o código escrito em uma destas, em linguagem de máquina (bytecode), suportando
assim as diferentes plataformas que compartilhem da mesma arquitetura de hardware (SHEN;
HSU; YANG, 2014).
Pode-se dividir a construção desses Apps em duas etapas de desenvolvimento: implementação do código backend, que é responsável pela lógica do aplicativo, e implementação do
código frontend, que é responsável pela interface visual.
4 http://cross-platform.mobi/images/cpmd_interpreted.png

3.7. ALGUNS FRAMEWORKS EM SUAS DETERMINADAS CATEGORIAS

29

O código backend então é compilados através compilador cruzado multiplataforma,
oferecendo um desempenho excelente em cada uma das plataformas, pois o código é traduzido
para bytecodes, não exigindo o overhead de um interpretador JavaScript em tempo de execução
como nos Apps Interpretados. Assim, como visto na Figura 3.5, o App cross-compilado é visto
como um App nativo pelo sistema operacional.
Sua desvantagem assemelha-se à restrição dos Apps Gerados, em que é preciso utilizar
apenas bibliotecas já suportadas pelo compilador cruzado, limitando sua utilização. Além disso,
boa parte do código frontend, que corresponde a interface visual do aplicativo, precisa ser
desenvolvido em suas plataformas específicas.

Figura 3.5: Abordagem Cross-Compilados5

3.7

Alguns Frameworks em suas determinadas categorias

Diversas ferramentas e frameworks estão disponíveis para cada tipo de abordagem
anteriormente citada, algumas com licença comercial e outras de código aberto. Alguns desses
se tornaram relevantes para o cenário do mercado atual e merecem destaque nesta seção.
A utilização desses frameworks é motivada pela possibilidade de minimizar as desvantagens citadas dessas abordagens, acelerando o desenvolvimento de aplicativos multiplataforma.

3.7.1

jQuery Mobile (WebApps)

jQuery Mobile (JQUERY, 2015) é um framework que possibilita a criação de sites
responsivos, ou seja, aqueles que se adaptam ao tamanho e orientação da tela, seus componentes
gráficos simulam a interface nativa das plataformas.
5 http://cross-platform.mobi/images/cpmd_native.png

3.7. ALGUNS FRAMEWORKS EM SUAS DETERMINADAS CATEGORIAS

30

Este framework é recomendado para os desenvolvedores que já estão acostumados com
as tecnologias web, visto que basicamente transforma um site web já existente para um formato
amigável aos dispositivos móveis. Utilizando-se de tecnologias como CSS3 e HTML5, permite
que uma equipe web inicie o desenvolvimento de um App de forma rápida e econômica.

3.7.2

PhoneGap/Apache Cordova (Apps Híbridos)

O PhoneGap, cujo atual nome chama-se Apache Cordova (CORDOVA, 2014), é uma
ferramenta de desenvolvimento multiplataforma híbrida, de código aberto e licenciada sob
Apache 2.0. O Apache Cordova funciona basicamente encapsulando uma aplicação web.
O Apache Cordova minimiza as desvantagens citadas na Seção 3.3, pois implementa
alguns componentes presentes no SDK dos sistemas operacionais, permitindo o desenvolvimento
de aplicações mais complexas.

3.7.3

Titanium Framework (Apps Interpretados)

O Titanium Framework é um framework de código aberto que implementa uma API
normalizada, escrita nativamente para cada plataformas específica, facilitando a comunicação
com os interpretadores JavaScript presentes internamente em cada dessas. Isso permite a
execução de código JavaScript nativamente nestas plataformas.
O Titanium minimiza a desvantagem, vista na abordagem interpretada, pois sua lista de
APIs suportadas é atualizada constantemente, contemplando mais de 90% das funcionalidades
presentes nos SDKs nativos (Appcelerator Inc., 2015). Além disso, o Titanium permite o
desenvolvimento de módulos nativos que estendem as APIs já suportadas oficialmente.

3.7.4

Applause (Apps Gerados)

Applause (APPLAUSE, 2015) é um conjunto de ferramentas para o desenvolvimento
de aplicações multiplataforma. Diferente das abordagens citadas, o desenvolvimento através do
Applause é baseado em uma linguagem de domínio específico que descreve o comportamento
das aplicações. Ao descrever a aplicação, utiliza-se um conjunto de geradores pré-definidos para
criar as aplicações nativas. O Applause está em desenvolvimento e dá suporte ao iOS, Android.

3.7.5

Apportable (Apps Cross-Compilados)

Apportable (APPORTABLE, 2015) utiliza-se de um compilador multiplataforma de
uso geral, como o clang (CLANG, 2015), para compilar o código escrito em Objetive-C para
o bytecode da arquitetura desejada. Ao realizar esta operação, não é necessário que nenhum
interpretador JavaScript ou máquina virtual existam, assim como é necessário pelos Apps
interpretados, e também evita o uso de DSL, como no caso dos Apps Gerados. Porém, é preciso
ter conhecimento completo de uma linguagem específica como Objetive-C.

3.8. A ESCOLHA DE UMA ABORDAGEM MULTIPLATAFORMA

3.8

31

A escolha de uma abordagem multiplataforma

Diante da necessidade de se desenvolver um aplicativo multiplataforma, pode-se recorrer
a utilização de uma das abordagens vistas na seção anterior. Como visto, existe uma heterogeneidade entre as vantagens e desvantagens dessas abordagens, podendo tornar difícil a escolha de
uma destas. Entretanto, é importante perceber que não existe concorrência entre as abordagens,
visto que a escolha da utilização de uma destas é resultado de uma soma de variáveis de contexto. A seguir serão abordados fatores de decisão baseados em HEITKöTTER; HANSCHKE;
MAJCHRZAK (2013) e XANTHOPOULOS; XINOGALOS (2013) para construção posterior
de uma tabela comparativa entre as abordagens para o desenvolvimento de um aplicativo móvel
multiplataforma.

3.8.1

Critérios para avaliação     

Desempenho: Referente a responsividade do aplicativo durante a interação com o
usuário. É um fator significativo para a qualidade final do aplicativo. Porém deve-se
atentar que o fator desempenho pode ser comprometido através de fatores externos,
independentes da abordagem escolhida, como por exemplo, qualidade do código,
infraestrutura de rede e requisitos de hardware. Por esse motivo subjetivo, a análise
de porcentagem de memória consumida e tempo de processamento (profiling) de um
App está fora de escopo deste trabalho.
Custo: Referente ao custo financeiro necessário para desenvolver um aplicativo
multiplataforma. Foi utilizado como parâmetro o salário anual médio de um desenvolvedor WEB(HTML,JavaScript) (R$27.600) e desenvolvedor iOS (R$31.250) e
Android (R$37.250) (CATCHO, 2015).
Acesso a API nativa: Referente a quantidade de funcionalidades nativas disponíveis
para a utilização do desenvolvedor presentes no SDK de cada plataforma, por exemplo:
GPS, BTE, NFC, Acelerômetro, Câmera, Rede e Armazenamento. Foi utilizado
como parâmetro a quantidade de APIs disponíveis pela abordagem em questão.
Facilidade de manutenção: Referente a facilidade de manter o código do aplicativo,
como adicionar novas funcionalidades e corrigir erros. A manutenção está relacionada
a quantidade de ambientes de desenvolvimento. Foi utilizado como parâmetro de
referencia a quantidade de linhas de código (LOC) e a tecnologia utilizada.
Velocidade de desenvolvimento: Referente ao tempo total para desenvolver o aplicativo em todas as plataformas desejadas, não levando em conta o tempo de revisão
do aplicativo nas App Stores.

3.8. A ESCOLHA DE UMA ABORDAGEM MULTIPLATAFORMA 

3.8.2

32

Suporte da comunidade: Referente ao apoio do grupo de desenvolvedores e material
disponível, como documentação, tutoriais e aulas fornecidas por usuários ativos.
Além disso, foi utilizado como parâmetro a quantidade de questões encontradas pelas
tags específicas em um dos maiores site de perguntas e repostas técnicas, o Stack
Overflow (STACKOVERFLOW, 2015).

Avaliação dos critérios por abordagem

Para analisar os critérios citados na subseção anterior, foi-se necessário utilizar as
ferramentas que implementam cada uma das abordagem demonstradas vistas na Seção 3.7.
Para a avaliação dessas abordagens, foi proposto neste trabalho, um conceito para cada um dos
critérios acima, são eles: Baixo, Médio ou Alto. A seguir será apresentado os argumentos para a
avaliação dos conceito. 

Abordagem Nativa
1. Desempenho (Conceito: Alto) - Os aplicativos nativos apresentam uma
excelente responsividade ao usuário, visto que são Apps desenvolvidos utilizando os
kits de desenvolvimento disponibilizados nativamente por cada sistema operacional.
2. Custo (Conceito: Alto) - Para se desenvolver um aplicativo que suporte a
várias plataformas, cada aplicativo deve ser desenvolvido separadamente, podendo
requerer duas ou mais equipes de profissionais qualificados para cada plataforma.
Acesso a API nativa (Conceito: Alto) - Por serem desenvolvidos utilizando as
ferramentas próprias de cada sistema operacional, estes podem ter acesso a totalidade
de APIs disponíveis no SDK, além de total controle dos recursos de hardware
disponível no dispositivo.
Facilidade de Manutenção (Conceito: Baixo) - A cada plataforma suportada
é preciso manter um repositório de código, aumentando assim o número de linhas de
código a cada plataforma adicionada.
Velocidade de desenvolvimento (Conceito : Baixo) - É preciso iniciar o desenvolvimento para cada uma das plataformas paralelamente (em caso de duas ou mais
equipes), ou seja, não é aproveitado o código de um aplicação em uma outra, por
consequência pode gerar um atraso entre o lançamento do aplicativo nas diferentes
plataformas.
Suporte da comunidade (Conceito: Alto) Foram contabilizados aproximadamente 311.842 e 635.787 questões utilizando as tags "ios"e "android"respectivamente.
O que mostra uma comunidade bastante ativa, oferecendo muito suporte ao usuário
iniciante e durante o desenvolvimento. 

Web Apps utilizando jQuery Mobile.

3.8. A ESCOLHA DE UMA ABORDAGEM MULTIPLATAFORMA

33

Desempenho (Conceito: Baixo) - O desempenho de um Web App em relação ao
nativo é considerado relativamente baixo, pois o mesmo requer ser executado dentro
de um browser gerando um overhead significativo, consequentemente reduzindo a
sensação de responsividade do App, pois a sensibilidade ao toque é limitada e os
efeitos de transição se assemelham a uma site e não a um App nativo.
Custo (Conceito: Baixo) - O custo é considerado relativamente baixo pois
apenas uma equipe de profissionais qualificados em WEB é necessário para o desenvolvimento deste App para várias plataformas.
Acesso a API nativa (Conceito: Baixo) - Pela limitação do browser, os Web
Apps não tem acesso direto as API nativas do sistema operacional. Sendo qualificado
como baixo.
Facilidade de Manutenção (Conceito: Alto) - Além de ter apenas um repositório de código para ambas plataformas, diminuindo as linhas de código do projeto.
o Web App não é instalado no dispositivo do usuário, tornado o processo de adição
de funcionalidades e remoções de bugs transparentes ao usuário.
Velocidade de desenvolvimento (Conceito: Alto) - A velocidade de desenvolvimento é muito rápida visto que os as tecnologias utilizadas, como HTML5, são
bastantes difundidas e utilizadas pelos desenvolvedores. Ao término no desenvolvimento o App funcionará para várias plataformas ao mesmo tempo.
Suporte da comunidade (Conceito: Alto) - Foram contabilizados aproximadamente 39.399 e 69.941 questões utilizando as tags "jquery mobile"e "html5". O que
mostra uma comunidade relativamente ativa, oferecendo muito suporte ao usuário
iniciante e durante o desenvolvimento. 

Híbridos utilizando Apache Cordova.
Desempenho (Conceito: Baixo) - Apresentam um desempenho melhor do que
os Web Apps, visto que não dependem da infraestrutura de rede e são executados sob
um browser nativo com menor overhead, porém não apresentam um desempenho
similar ao nativos, pois continuam sendo executados dentro de contexto não acessível
diretamente pelo sistema operacional, o que limita a sensibilidade aos toques e por
consequência a responsividade do App.
Custo (Conceito: Baixo) - Por utilizar as mesmas tecnologias utilizadas para o
desenvolvimento dos Web Apps, o conceito foi mantido o mesmo.
Acesso a API nativa (Conceito : Médio) - Os Apps híbridos por estarem
contidos dentre de um componente nativo presente nas plataformas, podem utilizar
aproximadamente 10 APIs nativas do sistema operacional, mais do que os Web Apps,
porém menor do que o nativo.

3.8. A ESCOLHA DE UMA ABORDAGEM MULTIPLATAFORMA

34

Facilidade de Manutenção (Conceito: Alto) - Por utilizar as mesmas tecnologias utilizadas para o desenvolvimento dos Web Apps, e um único repositório de
código, o conceito foi mantido o mesmo.
Velocidade de desenvolvimento (Conceito: Alto) - Por utilizar as mesmas
tecnologias utilizadas para o desenvolvimento dos Web Apps, o conceito foi mantido
o mesmo.
Suporte da comunidade (Conceito: Alto) Foram contabilizados aproximadamente 40.801, 32.104 e 69.941 questões utilizando as tags "phonegap"e "cordova"e
"html5". O que mostra uma comunidade relativamente ativa, oferecendo muito
suporte ao usuário iniciante e durante o desenvolvimento. 

Gerados utilizando Applause.
Desempenho (Conceito: Alto) - Apresentam uma excelente responsividade
similar a abordagem nativo. Portanto o conceito adotado será o mesmo da abordagem
nativa.
Custo (Conceito: Médio) - Por precisar apenas de uma equipe para desenvolver
uma aplicação dentre as várias necessitadas na abordagem nativa. Foi considerado o
custo de desenvolvimento similar a de apenas uma aplicação nativa. Porém o custo
relacionado a esse desenvolvimento é maior do que os Web Apps ou Híbridos pelo
fato da tecnologia utilizada.
Acesso a API nativa (Conceito: Médio) - Apesar de serem Apps nativos em
tempo de execução e acessar todas as APIs presente no SDK de cada plataforma,
é necessário que as APIs sejam definidas previamente na DSL, caso contrário não
poderão ser usadas em tempo de desenvolvimento, o que caracteriza o conceito
médio.
Facilidade de Manutenção (Conceito : Médio) - Apesar de ter somente um
repositório de código para várias plataformas, os Apps Gerados são muito específicos
em seu domínio, e caso haja a necessidade de uma nova funcionalidade futura não
prevista na DSL, existe um overhead de implementação nativa dessa funcionalidade
para cada uma das plataformas suportadas.
Velocidade de desenvolvimento (Conceito: Médio) - É relativamente mais
lenta do que a abordagem híbrida e mais rápida do que os Apps nativos, qualificando
em médio. Além disso a velocidade pode ser influenciada negativamente caso haja a
necessidade de expansão do domínio do contexto do App.
Suporte da comunidade (Conceito: Baixo) - Não foi encontrada nenhuma
resultado para a tag "applause". O que mostra uma comunidade ainda pequena ou
inativa.

3.8. A ESCOLHA DE UMA ABORDAGEM MULTIPLATAFORMA 

35

Interpretados utilizando Titanium Framework.
Desempenho (Conceito: Médio) - Apresentam um desempenho superior aos
WebApps e Híbridos, pois não são executados dentro de um browser. Entretando
devido ao overhead gerado pelo interpretador JavaScript em tempo de execução, tem
um desempenho relativamente menor do que o nativo.
Custo (Conceito: Baixo) - O desenvolvimento é menos custoso do que os Apps
nativos, Gerados e Cross compilados, e similar aos WebApps e Híbridos, pelo fato
de ser preciso apenas de uma equipe para suportar várias plataformas e da utilização
de tecnologias web, como JavaScript.
Acesso a API nativa (Conceito: Alto) - Essa abordagem tem potencial acesso
a totalidade de funcionalidades nativas, mesmo que APIs não estejam implementadas
originalmente na ferramenta, pode-se estender a mesma criando módulos nativos para
realizar a interface com essas APIs ainda em desenvolvimento. Segundo Appcelerator
Inc. (2015) o Titanium cobre 90% das funcionalidades nativas.
Facilidade de Manuntençao (Conceito: Alto) - Por utilizar as mesmas tecnologias utilizadas para o desenvolvimento dos Web Apps e Híbridos, e um único
repositório de código, o conceito foi mantido o mesmo.
Velocidade de desenvolvimento (Conceito: Alto) - Por utilizar as mesmas
tecnologias utilizadas para o desenvolvimento dos Web Apps, o conceito foi mantido
o mesmo.
Suporte da comunidade (Conceito: Médio) - Foram contabilizados aproximadamente 12.090 questões utilizando as tags "titanium". O que mostra uma comunidade menor que os Híbridos e Web Apps, porém maior do que a dos gerados e Cross
compilados, caracterizando o conceito médio. 

Cross-Compilados utilizando o Apportable.
Desempenho (Conceito: Alto) - Apresentam uma excelente responsividade
similar a abordagem nativo. Portanto o conceito adotado será o mesmo da abordagem
nativa.
Custo (Conceito: Médio) - Por precisar apenas de uma equipe para desenvolver
uma aplicação dentre as várias necessitadas na abordagem nativa. Foi considerado o
custo de desenvolvimento similar a de apenas uma aplicação nativa. Porém o custo
relacionado a esse desenvolvimento é maior do que os Web Apps ou Híbridos pelo
fato da tecnologia utilizada.
Acesso a API nativa (Conceito:Alto) - Essa abordagem tem potencial acesso
a totalidade de funcionalidades nativas. Porém deve-se atentar aos que algumas

3.8. A ESCOLHA DE UMA ABORDAGEM MULTIPLATAFORMA

36

APIs nativas não conseguem ser compiladas para o Android devido a restrições da
arquitetura.
Facilidade de Manuntençao (Conceito: Médio) - Para realizar a manutenção
deve se atentar que o código backend é o mesmo, assim mais rápido que os nativos,
porém se a nova funcionalidade requerer alterações na interface gráfica é preciso
implementar cada interface gráfica em cada plataforma, gerando um aumento na
linhas de código.
Velocidade de desenvolvimento (Conceito: Médio) - Os Apps Cross compilados são construídos utilizando somente uma tecnologia e portado através de um
compilador cruzado, porém o código de interface gráfica é implementado nativamente,
o que reduz a velocidade de desenvolvimento em relação aos Apps Interpretados e
Gerados, por exemplo.
Suporte da comunidade (Conceito: Baixo) Foram contabilizados aproximadamente 446 questões utilizando as tags "apportable". O que mostra uma comunidade
ainda pequena ou inativa.

3.8.3

A indicação de uma abordagem

Com o objetivo de auxiliar o leitor sobre qual abordagem mais vantajosa, propôs-se neste
trabalho questionamentos que devem ser respondidos utilizando os conceitos de Alto,Médio ou
Baixo de acordo com o cenário do Aplicativo a ser desenvolvido. Considerando como parâmetro
as respostas suscitadas, é possível fazer uma comparação com a tabela que sumariza as avaliações
dos conceitos explanados na subseção anterior, esta tabela pode ser vista na Figura 3.6.      

Qual nível de desempenho é requerido para executar a aplicação? Leve em consideração, por exemplo, se seu aplicativo requer a necessidade de realizar processamento
de imagens em três dimensões (3D) ou processar matrizes complexas.
Qual seu nível de restrição ao custo total para o desenvolvimento do App. Leve em
consideração a quantidade de profissionais envolvidos e licença de software.
Qual seu nível de urgência para desenvolver o aplicativo e entregá-lo ao mesmo
tempo em ambas as plataformas?
Após a entrega do aplicativo, qual nível de intensidade de manutenções como por
exemplo, acrescentar funcionalidades ao App?
Qual nível de integração com o sistema operacional seu App precisará ter? Leve
conta acesso à funcionalidade de hardware como Câmera, Bluetooth, NFC, GPS.
Qual seu nível de dependência de suporte da comunidade? Leve em consideração seu
domínio e conhecimento sobre a ferramenta e as tecnologias que irão ser utilizadas.

3.9. CONCLUSÃO

37

Figura 3.6: Comparação entre as abordagens de desenvolvimento de aplicações móveis

3.9

Conclusão

Pode-se verificar que não há uma solução ótima que atenda a todos os casos, para cada
abordagem destacada vê-se vantagens e desvantagens para cada tipo de cenário, ou seja, a
escolha de uma abordagem é dependente de uma série de critérios contextuais. Através dos
questionamentos propostos neste trabalho e da verificação das respostas na matriz de critérios
vista na Figura 3.6, é possível indicar uma direção para a escolha de uma abordagem mais
vantajosa.
Pode-se citar alguns exemplos como o cenário de um App baseado em dados - catálogos,
comunicação, finanças, armazenamento - no qual não é necessário utilizar todos os recursos de
desempenho do dispositivo, aliado a necessidade de um rápido desenvolvimento em ambas as
plataformas, porém com uma restrição de custo. Logo a abordagem interpretada é a mais indicada.
Para outro cenário, no qual há a necessidade de se desenvolver um jogo 3D, por exemplo, o
alto desempenho é uma restrição crucial, logo se deve pagar o custo associado, através de uma
abordagem nativa ou cross-compilada. Para aplicações simples ou mesmo temporárias, que
devem ser desenvolvidas a um baixo custo, pode-se optar por uma abordagem híbrida ou mesmo
o desenvolvimento de um Web app.
No capítulo seguinte, será visto um estudo de caso demonstrando o desenvolvimento
de um App utilizando uma abordagem multiplataforma. O estudo de caso foi demandado sob
os critérios de restrição máxima de custo, necessidade de APIs nativas como: GPS, Rede e
Celular, e rápida entrada em ambas as App Stores. Como esse não demandou grandes recursos
de desempenho, e baseado-se nos critérios vistos a abordagem indicada foi a interpretada.

38

4
Desenvolvimento de um estudo de caso
4.1

Introdução

Será demonstrado como estudo de caso deste trabalho o desenvolvimento de um App
multiplataforma. A construção do mesmo foi realizada utilizando a abordagem interpretada,
através da ferramenta Titanium Framework e seu framework MVC Alloy (Appcelerator Inc.,
2015).
O presente estudo de caso é o aplicativo chamado AcheUPA. O objetivo do AcheUPA é
permitir que se encontre a Unidade de Pronto Atendimento (UPA) mais próxima da localização
atual do usuário, utilizando-se para isso de informações geográficas que são providas pelo GPS
do dispositivo móvel.
Para demonstrar a utilização de recursos nativos, o App faz uso das APIs de rede e
geolocalização de cada sistema operacional para interagir com os serviços de resolução de
latitudes do Google WebServices (GOOGLE, 2015c) e principalmente com a API do Google
Maps (GOOGLE, 2015c).
O App AcheUPA foi desenvolvido para uma demanda de um cliente real e se encontra
disponível nas lojas da AppStore e da Play Store, validando que a abordagem utilizada está
madura para o mercado.

4.2

Desenvolvimento do Aplicativo

O processo de desenvolvimento de um App pode ser visto em três grandes etapas:
design e planejamento da User Interface (UI), implementação da UI e implementação das
funcionalidades.

4.2.1

Planejamento da UI

Um dos momentos mais importantes no desenvolvimento de um App multiplataforma é
pensar em como satisfazer a experiencia do usuário em cada uma das plataformas suportadas.

4.2. DESENVOLVIMENTO DO APLICATIVO

39

Por isso, durante a fase de planejamento, é necessário decidir se o App será construído sob uma
interface visual agnóstica, ou utilizará somente componentes nativos de cada plataforma.
A abordagem agnóstica segue o mesmo padrão para cada sistema operacional. Ou
seja, é possível criar uma interface totalmente independente do sistema operacional. Contudo,
deve-se atentar que usuário espera um comportamento parecido com o sistema nativo o qual está
habituado a usar, o que não deve ser obstáculo para inovar no modo de interação criando uma
identidade única ao App.
No planejamento do AcheUPA, foi preferido uma abordagem agnóstica, a fim de demostrar a flexibilidade do framework Titanium. Visto que, por exemplo, o Android tem um
componente nativo chamado barra de ação (ActionBar), esse componente é utilizado normalmente como guia de localização contextual do usuário, além de prover botões para expandir menu
lateral e de ações, como compartilhamento. Porém, ambos componentes não são encontrados
nativamente no iOS, sendo necessário construir esses componentes. Pode-se ter uma visão da
tela principal do AcheUPA na Figura 4.1

(a) iOS

(b) Android

Figura 4.1: Tela principal do AcheUPA para iOS e Android

4.2. DESENVOLVIMENTO DO APLICATIVO

4.2.2

40

Implementando a UI

A interface gráfica no Titanium é basicamente composta por uma dupla de arquivos: um
arquivo XML, onde os componentes são inseridos; e um arquivo TSS, onde se determina as
propriedades gráficas. No AcheUPA, temos basicamente uma Window ou Activity (no Android),
onde será inserido um Mapa, um menu lateral e o botão principal terá como ação buscar a UPA
mais próxima ao usuário.
Como pode ser visto no trecho de Código 4.1, primeiramente foram definidos os componentes necessários para o App, porém deve-se atentar que, sempre que se utilizar o framework
Alloy, é necessário explicitar na primeira linha do arquivo XML a marcação <Alloy>.
A unidade básica de um App é constituída por uma Window. Uma Window tem como
correspondente um UIWindow no iOS e uma Activity no Android. O Alloy permite definir alguns
atributos na hora da construção do mesmo, no trecho mostrado, foi determinado na primeira
View, ao atributo id o nome "mainView". Alguns desses atributos são especiais, como o platform,
que define que este componente em questão só deverá ser compilado na plataforma especificada.
Ao final, é possível perceber a requisição de um widget, que é um componente construído
e distribuído por desenvolvedores terceiros, visando a aumentar a velocidade de criação de um
App. Funciona como uma peça de encaixe, onde é possível inseri-lo no App em desenvolvimento
sem maiores dificuldades.
Código 4.1: Trecho de código da View principal
<Alloy>
<Window>
<View id="mainView">
<View id="mapview" ns="Alloy.Globals.Map" onClick="report"/>
<View id="topBar" layout="vertical">
<View id="firstLine"/>
<ImageView id="title"/>
</View>
<View id="secondLine" layout="horizontal">
<TextField id="searchBar"/>
<ImageView id="search" onClick="doSearch"/>
</View>
</View>
<Button platform="ios" onClick="swipeMenu" id="menuPicker"/>
<View id="center" layout="vertical">
<Label id="topword" top="3%">UPA mais proxima:</Label>
<Widget id="acheUpa" src="nl.fokkezb.button" onClick="getLocation"/>
</View>
</Window>
</Alloy>

4.2. DESENVOLVIMENTO DO APLICATIVO

41

Já no trecho do TSS, visto em 4.2 , pode-se verificar uma boa prática de estratégia de
multiplataforma. Como o Alloy é pré-processado antes da compilação do aplicativo, é possível
utilizar macros, para possibilitar a compilação em uma plataforma específica utilizando a sintaxe
[plataform=*]. A ideia é mostrar que, com o mesmo controlador, pode-se criar diferentes interface gráficas para cada plataforma, sem nenhuma mudança estrutural de código.

Código 4.2: Trecho de código do TSS
"#acheUpa[platform=android]":{
top:’2%’,
height:’30dp’,
backgroundColor: ’#e6594a’,
backgroundSelectedColor: ’#e6594a’,
title:’Clique aqui’,
}
"#acheUpa[platform=ios]":{
top:’2%’,
height:’30dp’,
backgroundColor: ’#e6594a’,
backgroundSelectedColor: ’#e6594a’,
activeStyle: {
backgroundColor: ’#e6594a’,
color: ’#e6594a’
},
font: {fontWeight:’bold’, fontSize:’14sp’},
title:’Clique aqui’,

Por fim, durante a implementação, pode ser necessário utilizar arquivos estáticos como:
imagens, áudios, entre outros. Ao usar o framework Alloy é possível organizar esses arquivos,
utilizando uma organização de diretório: arquivos que serão compartilhados entre todas as
plataformas devem ficar na pasta raiz do diretório, enquanto que os arquivos específicos devem
residir dentro das suas determinadas pastas como mostrado na Figura 4.2

4.2. DESENVOLVIMENTO DO APLICATIVO

42

Figura 4.2: Estrutura de diretórios

4.2.3

Implementando as funcionalidades

Após o planejamento e implementação da interface gráfica, é preciso implementar o
funcionamento do App. Como visto no Capítulo ??, os controladores implementam a lógica de
negócio do App, e são responsáveis pela renderização de cada View, por isso, para cada arquivo
View XML, existe um controlador correspondente JavaScript. Onde, através do operador especial
"$", é possível referenciar um componente presente no XML através do controlador.
No controlador visto no trecho de Código 4.3, foi definida uma variável thisWin que
armazena a instância da Window. Salienta-se a utilização do operador $ para capturar o elemento
através do atributo id. Igualmente, nota-se que como o elemento Window, presente na View, não
tem o atributo id declarado explicitamente, portanto o Titanium automaticamente o configura
com o nome do arquivo, neste caso index.xml.
A segunda linha define a criação de um novo controlador denominado mapview, e tem
sua respectiva View requerida pelo método getView. Ao final, é setado um escutador de eventos
ao componente referenciado pela variável thisWin, através do método addEventListener, prática
muito comum em JavaScript. Esse escutador espera assincronamente pela ocorrência do evento
especificado, executando a função de callback na presença do mesmo.

4.2. DESENVOLVIMENTO DO APLICATIVO

43

Código 4.3: Trecho de código do Controller principal
var thisWin = $.index;
var main = Alloy.createController(’mapview’).getView();
var menu = Alloy.createController(’menu’).getView();
$.drawermenu.init({
menuview : menu,
mainview : main,
duration : 200,
parent : thisWin
});
thisWin.addEventListener(’open’, function(e) {
var actionBarHelper = require(’com.alcoapps.actionbarhelper’)(
thisWin);
actionBarHelper.setTitle(’Ache UPA’);
actionBarHelper.setUpAction(function(e) {
$.drawermenu.showhidemenu();
});
});
$.index.open();

4.2.3.1

Conectando a Webservices

Muitas vezes um App necessita realizar tarefas mais longas e computacionalmente
pesadas. No caso do AcheUPA, é necessário, através das informações de longitude e latitude,
providas pelo GPS, realizar um cálculo para determinar as UPAs mais próximas na região
procurada.
Isso seria bastante custoso para um smartphone comum, além de consumir bastante
a potência da bateria. Por isso, para realizar este tipo de processamento são utilizados os
webservices . Para não ser necessário elaborar algo já desenvolvido, foi adotado neste trabalho
os webservices do Google Maps (GOOGLE, 2015c) para resolução de nome e para determinar
as posições das UPAS mais próximas.
Para melhor organização do código, foi criado um controlador apenas para armazenar as
APIs utilizadas. No trecho de Código 4.4, pode-se verificar a implementação deste. Note que ao
utilizar o exports, o objeto api torna-se público para quaisquer controlador que o necessite.

4.2. DESENVOLVIMENTO DO APLICATIVO

44

Código 4.4: Arquivo api.js
exports.api = {
searchAPI: "https://maps.googleapis.com/maps/api/place/search/json?
location=",
directionsAPI : "http://maps.google.com/maps?t=m&saddr=",
geoDecodeAPI: "http://maps.googleapis.com/maps/api/geocode/json?
address=",
secretKey: "XXXXXXXXXXXX",
};

A fim de realizar as requisições a essas APIs, o Titanium utiliza-se dos componentes
nativos de rede presente em cada sistema operacional. Pode-se chamar o método createHTTPClient através da API normalizada do Titanium, criando uma função totalmente multiplataforma.
Assim, com a invocação do método Titanium.Network.createHTTPClient, cria-se um objeto
HTTPClient preparado para fazer uma requisição HTTP ao webservice desejado.
O trecho código lógico mostrado em 4.5 reflete a utilização do HttpClient, comportandose equivalentemente em cada plataforma, apesar das implementações nativas serem diferentes.
Quando a resposta do webservice é retornada, normalmente recebida no formato JavaScript
Object Notation (JSON), é possível realizar a função de callback, determinada no caso pelo
evento onload.
Código 4.5: Requisição HTTP utilizando HttpClient
function findsUpas(origin){
var latitude_longitude = origin.latitude+origin.longitude;
var url = api.searchAPI+latitude_longitude+"&radius=15000"
var client = Ti.Network.createHTTPClient({
onload : function(evt) {
var json = JSON.parse(this.responseText);
var results = json[’results’];
results.forEach(function(place){
var upaMarker = Alloy.Globals.Map.createAnnotation({
latitude:place.geometry.location.lat,
longitude:place.geometry.location.lng,
title:place.name,
});
$.mapview.addAnnotation(upaMarker);
}
}});
client.open("GET", url);
client.send();
}

4.2. DESENVOLVIMENTO DO APLICATIVO
4.2.3.2

45

Geolocalização

A localização do usuário é determinada utilizando a API do Titanium:
Ti.Geolocation.getCurrentPosition. Essa API é configurada para receber, de tempos em tempos,
a posição em latitude e longitude do dispositivo. Esse intervalo pode ser ajustado para um alto
grau de precisão ou para uma melhor economia de bateria. Sua utilização está demonstrada no
trecho de Código 4.6
Código 4.6: Obtenção da Geolocalização utilizando GPS do dispositivo
function getLocation(){
Ti.Geolocation.getCurrentPosition(function(e){
if(e.code == 0){
if(OS_IOS && e == null){
return;
}
$.mapview.region = {latitude:e.coords.latitude, longitude:e.coords.
longitude};
}else{
return;
}
});
}

4.2.3.3

Chamadas a API específicas

Para demonstrar a utilização de API’s específicas de cada sistema operacional, serão
utilizadas como exemplos a API de ligações telefônicas. Como visto anteriormente, no TSS foi
utilizado um macro para explicitar uma plataforma especifica, no caso do controlador, pode-se utilizar outra macro, em conjunto com uma operação condicional, por exemplo, if(OS_ANDROID)
ou if(OS_IOS).
Ao realizar esse tipo de operação, é criado mesma base de código: uma ramificação
de código específico para cada plataforma. Idealmente, deve ser minimizado o tamanho desta
ramificação, criando funções que abstraiam as diferenças entre plataformas.
No trecho de código mostrado em 4.7, a aplicação para Android trata a funcionalidade
como um Intent, previamente explicado em 2.3, esse é enviado para o sistema operacional na
espera da resposta a intenção. Já no iOS essa funcionalidade é exposta como um protocolo,
onde cada App ao ser instalado pode registrar uma rota, como por exemplo o acheUpa:code ou
whatsapp:code e no caso do telefone, que também é tratado como uma aplicação, tel://numero.

4.3. CONCLUSÕES SOBRE O ESTUDO DE CASO

46

Código 4.7: Ramificação do código onde a API do Titanium não é normalizada
function emergencyCall(){
var dialog = Ti.UI.createAlertDialog({
cancel: 1,
buttonNames: [’Ligar’, ’Agora nao’,],
message: "Deseja ligar para o SAMU?",
});
dialog.addEventListener(’click’, function(e){
if(OS_ANDROID){
var intent = Ti.Android.createIntent({
action : Ti.Android.ACTION_CALL,
data : ’tel:192’,
});
Ti.Android.currentActivity.startActivity(intent);
}else if(OS_IOS){
Ti.Platform.openURL(’tel:192’);
}
}
});
dialog.show();
};

4.3

Conclusões sobre o estudo de caso

Como pôde-se perceber, a manutenção de um App multiplataforma desenvolvido utilizando o framework Titanium é mais produtivo do que a manutenção de dois aplicativos nativos
distintos. Essa facilidade é provida pela maior parte do código ser compartilhada, com pequenos
ramos referentes a funcionalidades específicas dos sistema operacional. Deve-se atentar à para a
criação do mínimo de ramificações possíveis, como por exemplo, uma solução mais custosa à
primeira vista pode ser uma mais econômica a longo prazo.
Um bom domínio da interface gráfica de cada uma das plataformas desejadas permite
que o App tenha uma boa avaliação na revisão técnica e tenha destaque nas App Store. Além
disso, conhecer as diferentes implementações do interpretador JavaScript pertencente ao sistema
operacional é uma ótima maneira de otimizar o desempenho do código lógico.

47

5
Conclusão
5.1

Principais Conclusões

A rápida evolução das tecnologias de sistema embarcado permitiram que diversos nichos
de dispositivos eletrônicos - dentre eles smartphones e tablets- se estabelecessem no mercado.
Cada uma destes dispositivos tem presente um sistema operacional, com suas características
específicas e peculiares. Ótimo para os consumidores que se beneficiam da concorrência
do mercado para satisfazer suas necessidades tecnológicas. Alguns chegam a defender sua
plataforma como uma unidade.
As lojas de aplicativos demonstraram um potencial imenso para um novo tipo de mercado
focado diretamente no cliente, onde empresas tiveram que repensar seus negócios para se adaptar
a este novo conceito. Milhares de desenvolvedores voltaram suas atenções atraídos pelo grande
valor de mercado gerados por essas lojas. Entretanto, devido à incompatibilidade entre as
arquiteturas destes sistemas operacionais, cada plataforma apresenta seus kits de desenvolvimento.
Logo, o desenvolvimento de aplicativos pensados para suportar as diversas plataformas tornouse bastante custoso, daí foram pensadas abordagens que permitissem o desenvolvimento de
aplicativos multiplataforma.
Web apps, Apps Híbridos, Gerados, Cross-compilados e Apps Interpretados são algumas
das abordagens utilizadas pelo desenvolvimento multiplataforma numa tentativa de contornar os
obstáculos do desenvolvimento nativo. Estas abordagens apresentam vantagens e desvantagens
em relação uma a outra e em relação ao desenvolvimento nativo.
Web apps são sites webs responsivos que se adaptam a diferentes tamanho e orientações de telas e são a opção mais econômica, enquanto os Apps Híbridos são apenas Web
apps encapsulados com um componente nativo, restringindo o escopo do mesmo a poucas
funcionalidades.
Os Apps Interpretados apresentaram um bom desempenho e facilidade de entendimento,
porém podem depender de ferramentas para minimizar suas desvantagens. Por fim, os Apps
cross-compilados e gerados exigem o conhecimento de linguagens mais específicas, como uma
DSL para o caso dos gerados ou, para o caso dos cross-compilados, o conhecimento de um

5.2. TRABALHOS FUTUROS

48

ambiente nativo e a utilização de compilador cruzado.
Como estudo de caso deste trabalho foi desenvolvido o App AcheUPA, utilizando-se de
APIs de geolocalização, rede e acesso a funcionalidades específicas de cada plataforma, como
ligações telefônicas, validando o funcionamento da abordagem interpretada e do framework
Titanium.
Até o término deste trabalho, o Titanium encontrava-se na versão 3.5.0.GA suportando o
desenvolvimento de aplicação multiplataforma para iOS, Android, BlackBerry e em Developer
Preview para o Windows Phone (Appcelerator Inc., 2015).

5.1.1

Novas ferramentas em potencial

Novas abordagens e ferramentas estão sendo criadas para minimizar o custo de desenvolvimento de Apps multiplataforma. Recentemente, o Facebook noticiou que o App Facebook
Groups (FACEBOOK, 2015), foi desenvolvido utilizando-se uma ferramenta muito parecida
com o Titanium. Essa ferramenta se tornou de código aberto recentemente e está sendo chamada
de ReactJS (FACEBOOK, 2015).
O Google também demonstrou sua solução de desenvolvimento multiplataforma, utilizando um compilador cruzado, chamado J2OBJC (GOOGLE, 2015d), que traduz o código nativo
escrito em Java para o Objective-C, porém ainda com algumas restrições de funcionalidades.
A Microsoft também mostrou-se interessada no desenvolvimento multiplataforma e, no inicio
do ano, tornou aberto o código-fonte da biblioteca WinJS (MICROSOFT, 2014), que permite a
criação de Apps utilizando a linguagem JavaScript.

5.2

Trabalhos futuros
Algumas possibilidades para novos trabalhos a partir deste: 

Realizar uma análise de desempenho das abordagens estudadas. 

Implementar um decisor para auxiliar na escolha da abordagem mais vantajosa. 

Realizar um novo estudo de caso utilizando outro cenário para validar outras abordagens.

49

Referências
Appcelerator Inc. Titanium Mobile Application Development. 2015.
APPLAUSE. APPlause. 2015.
APPLE. iOS Technology Overview. Media, [S.l.], p.69, 2010.
APPLE. JavaScriptCore Framework Reference. Media, [S.l.], p.111, 2013.
APPORTABLE. Apportable - Objective-C for Android. 2015.
CATCHO. Guia de Profissões e Salários | Catho. 2015.
CLANG. C Language Family Frontend for LLVM. 2015.
CORDOVA. Apache Cordova. 2014.
DEACON, J.; SYSTEMS, C. Model View Controller Architecture. , [S.l.], n.Mvc, p.1–6, 2009.
DEURSEN, A. V.; KLINT, P.; VISSER, J. Domain-specific languages: an annotated
bibliography. ACM Sigplan Notices, [S.l.], v.35, p.26–36, 2000.
ENTREPREUNER. By 2017, the App Market Will Be a $77 Billion Industry (Infographic).
2014.
FACEBOOK. A JavaScript library for building user interfaces | React. 2015.
FLING, B. Mobile Design and Development: practical concepts and techniques for
creating mobile sites and web apps. [S.l.: s.n.], 2009. 336p.
FOWLER, M. Mocks Aren’t Stubs. 2007.
GARTNER. Gartner Says Mobile App Stores Will See Annual Downloads Reach 102
Billion in 2013. 2013.
GOOGLE. Chrome V8 — Google Developers. 2014.
GOOGLE. Application Fundamentals | Android Developers. 2015.
GOOGLE. ART and Dalvik | Android Developers. 2015.
GOOGLE. Serviços da Web da API do Google Maps - Serviços da Web da API do Google
Maps. 2015.
GOOGLE. J2ObjC. 2015.
HEITKöTTER, H.; HANSCHKE, S.; MAJCHRZAK, T. a. Evaluating cross-platform
development approaches for mobile applications. Lecture Notes in Business Information
Processing, [S.l.], v.140 LNBIP, p.120–138, 2013.
HILLEGASS, A. Objective-C Programming. [S.l.: s.n.], 2011.
IDC. IDC: smartphone os market share 2014, 2013, 2012, and 2011. 2014.

REFERÊNCIAS

50

INTERNATIONAL, E. ECMAScript Language Specification. World Wide Web Internet And
Web Information Systems, [S.l.], n.December, p.188, 1999.
JQUERY. jQuery Mobile. 2015.
MEW, K. M. Android 3.0 Application Development Cookbook. [S.l.: s.n.], 2011. 1–272p.
MICROSOFT. WinJS – Windows app development. 2014.
NUTTING, J. et al. Exploring the iOS SDK. , [S.l.], 2014.
Open Handset Alliance. Open Handset Alliance. 2007.
READWRITE. History of Mobile App Stores - ReadWrite. 2012.
ROGERS, R. et al. Android Application Development: programming with the google sdk.
[S.l.: s.n.], 2009. 336p.
SERVICES, W. iPhone Programming. [S.l.: s.n.], 2010.
SHEN, B.-y.; HSU, W.-c.; YANG, W. U. U. A Retargetable Static Binary Translator for the
ARM Architecture. , [S.l.], v.11, n.2, p.1–25, 2014.
STACKOVERFLOW. Stack Overflow. 2015.
STATISTA. Apple: most popular app store categories 2015. 2015. 1p.
TECHTROPIA. An Overview of the Android Architecture. 2013.
The Guardian. Android overtakes iOS for app downloads, but Apple’s platform still more
lucrative for developers | Technology | The Guardian. 2013.
W3C. Web Storage. 2013.
W3C. Geolocation API Specification. 2013.
XANTHOPOULOS, S.; XINOGALOS, S. A Comparative Analysis of Cross-platform
Development Approaches for Mobile Applications. Proceedings of the 6th Balkan
Conference in Informatics, [S.l.], p.213–220, 2013.