Em Direção A Uma Abordagem para o Desenvolvimento de Aplicativos Móveis Multiplataforma

Victor Chaves Cas
EM DIREO A UMA ABORDAGEM PARA O DESENVOLVIMENTO

DE APLICATIVOS MVEIS MULTIPLATAFORMA
Trabalho de Graduao
Universidade Federal de Pernambuco

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

Centro de Informtica
Graduao em Engenharia da Computao
Victor Chaves Cas
EM DIREO A UMA ABORDAGEM PARA O DESENVOLVIMENTO

DE APLICATIVOS MVEIS MULTIPLATAFORMA
Trabalho apresentado ao Programa de Graduao em Engenharia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial
para obteno do grau de Bacharel em Engenharia da
Computao.
Orientador: Phd. Vinicius Cardoso Garcia

Co-Orientador: Msc. Lenildo Jos de Morais
RECIFE
FEV/2015
Eu dedico este trabalho de graduao toda minha famlia,

amigos e professores que estiveram comigo nesta jornada.
Agradecimentos
Primeiramente, gostaria de agradecer toda minha famlia pela base que me foi dada, e
por me mostrar a importncia da educao durante todas as etapas da minha vida. A minha noiva,
Isabela, por ter me acompanhado de perto durante toda a minha graduao e principalmente
no processo de desenvolvimento deste trabalho, me apoiado nos momentos mais difceis e
comemorando as alegrias das boas novas. Meus pais, Ricardo e Alessanndra, e meu irmo,
Ricardo, pela pacincia e compreenso, sempre presentes na longa jornada que foi a graduao
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 trmino deste trabalho e para minha
graduao. Fica aqui o meu muito obrigado a todos, especialmente para os colegas de graduao
e pelas madrugadas no CIn : Danilo Pena, Digenes Santos, Diogo Almeida , Ricardo Mariz,
Pedro Neves e Victor Carrio.
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 confiana
depositada, sempre abrindo novas oportunidades e acreditando no meu potencial. Lenildo Morais
(co-orientador), obrigado pela pacincia de acompanhar a evoluo deste trabalho, dando valiosos
feedbacks para o trmino do mesmo. E ao professor Kiev Gama, pela disposio de fazer parte
da banca deste trabalho.
No poderia deixar de agradecer aos amigos da famlia Ustore pela compreenso e
colaborao de todos, pelas dicas e produtivas discusses sobre o tema. Sou grato pelo convvio
com vocs, 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 expanso do mercado tecnolgico desencadeado pela apresentao 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 atenes para o
desenvolvimento de aplicativos mveis. Segundo uma pesquisa encomendada pela Universidade
do Alabama, estima-se que at 2017 sejam realizados aproximadamente 268 bilhes de downloads, resultando em uma receita de $77 bilhes. Porm, assim como proporcionaram grandes
oportunidades, essa abertura de mercado trouxe novos obstculos: a onda de novos dispositivos
ps-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 incio, em que s existiam poucos dispositivos.
Atualmente, Apple, Google e Microsoft detm 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 critrios de
aquisio dos dispositivos a quantidade e qualidade de apps disponveis. Por outro lado, essa
incompatibilidade entre as plataformas tema de discusso, uma vez que ela gera um custo
maior de desenvolvimento para cada plataforma suportada. A fim de minimizar esse custo,
desenvolvedores comearam 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 ento, diversas abordagens esto sendo estudadas neste sentido. Aps a visualizao
dessas, ser realizada um estudo para analisar qual abordagem ser mais adequada para o
desenvolvimento de um aplicativo mvel multiplataforma a partir de um cenrio 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
Viso Geral de um Web app . . . . . . . . . . . . . . . . . . . . . . . . .

Viso Geral de um App hbrido . . . . . . . . . . . . . . . . . . . . . . . .
Viso Geral de um App gerado . . . . . . . . . . . . . . . . . . . . . . . .
Viso Geral de um App interpretado . . . . . . . . . . . . . . . . . . . . .
Abordagem Cross-Compilados . . . . . . . . . . . . . . . . . . . . . . . .
Comparao entre as abordagens de desenvolvimento de aplicaes mveis
.
.
.
.
.
.
.
.
.
.
.
.
25
26
27
28
29
37
4.1
4.2
Tela principal do AcheUPA para iOS e Android . . . . . . . . . . . . . . . . .

Estrutura de diretrios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
42
Lista de Acrnimos
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
Sumrio
1
Introduo
1.1 Relevncia do tema . . . . . . . . . .
1.2 Objetivos . . . . . . . . . . . . . . .
1.2.1 Objetivos especficos . . . . .
1.3 Metodologia . . . . . . . . . . . . . .
1.3.1 Definio 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 Mdia . . . . . . . . . .
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 Concluses sobre o desenvolvimento de aplicativos . .
Introduo a abordagens multiplataforma
3.1 Motivao . . . . . . . . . . . . . . . . . . . . . . .
3.2 Web apps . . . . . . . . . . . . . . . . . . . . . . .
3.3 Apps Hbridos . . . . . . . . . . . . . . . . . . . . .
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
Concluso
5.1 Principais Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Novas ferramentas em potencial . . . . . . . . . . . . . . . . . . . . .
5.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
47
48
48
3.8
3.9
4
3.7.1 jQuery Mobile (WebApps) . . . . . . . . . .

3.7.2 PhoneGap/Apache Cordova (Apps Hbridos)
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 Critrios para avaliao . . . . . . . . . . . .
3.8.2 Avaliao dos critrios por abordagem . . . .
3.8.3 A indicao de uma abordagem . . . . . . .
Concluso . . . . . . . . . . . . . . . . . . . . . . .
Desenvolvimento de um estudo de caso

4.1 Introduo . . . . . . . . . . . . . . . . . . .
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 Geolocalizao . . . . . .
4.2.3.3 Chamadas a API especficas
4.3 Concluses sobre o estudo de caso . . . . . .
Referncias
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
11
1
Introduo
Genius is one percent inspiration, ninety-nine percent perspiration.
THOMAS A. EDISON
A revoluo dos dispositivos mveis iniciou-se em 2007, com a apresentao do ento

considerado primeiro smartphone, o iPhone, muito a frente de celulares existentes na poca, os
quais realizavam apenas tarefas bsicas. Atravs de um inovador modelo de negcio baseado
na distribuio direta de aplicativos ao usurio, o iPhone rapidamente obteve reconhecimento
pblico: com apenas uma semana de lanamento foram contabilizados mais de 10 milhes
de downloads desses aplicativos nessa plataforma (READWRITE, 2012). Um ano aps a
apresentao 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 aplicaes baseadas em Desktop concorriam para distribuir suas criaes em um modelo de
venda de licena, ou mesmo de taxa de servio 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 preo de seu aplicativo, ou mesmo disponibiliz-lo gratuitamente,
cedendo loja, porm, uma porcentagem da venda como taxa de servio.
1.1
Relevncia do tema
A fim de verificar o potencial econmico 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 bilhes de aplicativos
atravs das App Stores, gerando uma renda aproximada de 77 bilhes de dlares e afirmando a
prosperidade deste segmento (GARTNER, 2013).
Segundo IDC (2014), a App Store (Apple) e a Play Store (Google) detm mais de 90% do
market-share do mercado de Apps, fator o qual leva os desenvolvedores a voltarem suas atenes
para essas duas maiores plataformas. A corrida para publicar e lucrar com novos Apps diria,
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 especficos, por exemplo, para um desenvolvimento
nativo, aplicaes devem ser desenvolvidas separadamente: em Android normalmente so
programadas em Java, enquanto aplicaes para iOS usam a linguagem Objective-C.
Todavia, quando requisitado desenvolver um aplicativo que seja suportado em mltiplas
plataformas, uma aplicao elaborada para uma plataforma no ser compatvel com outra,
forando o desenvolvedor a reescrever a aplicao para cada um dos cenrios desejados, o que
aumenta o esforo e custo para o desenvolvedor e tempo para o aplicativo chegar ao usurio
final. A fim de solucionar essa adversidade, o desenvolvimento multiplataforma foi proposto,
abordagem na qual aplicativo escrito apenas uma vez e adaptado para suportar vrios 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, sero 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 especficos
Para alcanar o objetivo geral, foram designados objetivos especficos:
1.3
Investigar sobre o desenvolvimento de aplicativos mveis.
Pesquisar sobre a abordagem de desenvolvimento de apps mveis 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
Aps a definio dos objetivos, foi realizada uma reviso da literatura com a inteno
de sintetizar as abordagens nativas e de multiplataforma mais utilizadas pelo mercado e suas
tendncias (XANTHOPOULOS; XINOGALOS, 2013). Dentre os resultados da pesquisa se
destacaram as abordagens: Web apps, Apps hbridos, Apps interpretados, Apps gerados e Apps
cross-compilados.
1.4. FORA DE ESCOPO
1.3.1
13
Definio de multiplataforma
Diante dos dados explicitados pelo relatrio do (IDC, 2014), o termo multiplataforma
ser usado neste trabalho como referncia s plataformas iOS e Android.
1.4
1.5
Fora de escopo
A aprendizagem da utilizao de IDEs das tecnologias nativas.
A implementao de aplicativos mveis nativos
A avaliao de desempenho entre as abordagens multiplaformas
Estrutura deste trabalho

Esta dissertao ser organizada da seguinte forma:
No Captulo 2 feita uma contextualizao sobre o desenvolvimento de aplicativos

mveis.
No Captulo 3 so levantadas as abordagens multiplataforma, bem como avaliadas
suas vantagens e desvantagens, a fim de indicar uma direo para a escolha de uma
dessas.
No Captulo 4 o estudo de caso desenvolvido para validao deste trabalho.
No Captulo 5 so apresentadas as principais concluses deste trabalho.
14
2
Desenvolvimento de Aplicativos
2.1
Apps
Os Apps so peas de softwares desenvolvidas para rodar em um sistema operacional

embarcado em dispositivos mveis. Tem como principal caracterstica satisfazer de um modo
rpido e fcil 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, alcanando o objetivo desejado e minimizando
o esforo do usurio.
Apesar de visualmente simples, Apps so softwares de extrema complexidade, uma
vez que, antes de qualquer escrita de cdigo, o desenvolvedor deve considerar fatores como a
usabilidade do usurio e a interao homem-mquina. Essa ltima muito mais notvel em uma
aplicao mvel do que em um sistema Desktop, por exemplo.
A especificidade de um aplicativo, focando a realizao de uma tarefa singular, leva
facilidade de interao do usurio com o mesmo. O objetivo que esteja bem claro como utilizlo, minimizando a curva de aprendizado para usufruir do mesmo. Devido essa caracterstica,
possvel 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 famlia de dispositivos

Apple. Ele tem como objetivo fornecer uma srie de facilidades e funcionalidades para que
os desenvolvedores aproveitem ao mximo o hardware embarcado destes dispositivos em seus
aplicativos, melhorando a experincia do usurios.
Para desenvolver um aplicativo iOS so necessrios os seguintes requisitos mnimos:
Um computador Mac rodando uma verso 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 cdigo em si, modelagem
e construo da interface grfica e auxlio na compilao e depurao do aplicativo.
Para entender o processo de desenvolvimento de aplicativos iOS necessrio um prvio
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 abstrao
(APPLE, 2010), como visto na Figura 2.1. Apesar dessas divises em camadas, um App pode se
comunicar com qualquer uma das camadas diretamente, mas deve-se atentar que a utilizao de
componentes das camadas mais inferiores exige uma maior complexidade do cdigo.
Figura 2.1: Arquitetura do iOS1
2.2.1.1
Camada Cocoa Touch
A camada Cocoa Touch contm um conjunto de bibliotecas, chamado de Kits, que

definem padres de projetos para a estrutura bsica de uma aplicativo. Para uma lista completa
de todos os kits, verificar (APPLE, 2010).
UIKit Framework
Este framework prov os blocos bsicos da estrutura necessria para a construo e
manuteno do App e seu ciclo de vida em execuo. encontrado neste kit, por exemplo,
o conjunto de arquiteturas grficas que utilizado na modelagem da interface visual,
alm do controle de eventos de toque gerados pelo usurio atravs daquela. Ou at
1 https://cdn.tutsplus.com/mobile/uploads/legacy/Exploring-the-iOS-SDK/figure-01.png
16
mesmo quesitos mais bsicos, como o controle do loop principal do aplicativo durante sua
interao com o sistema.
Multitasking Framework
Este framework permite que, quando um aplicativo finalizado, colocado em um modo
congelado, residindo na memria, porm sem permisso para executar nenhuma ao.
Entretanto, em alguns casos, necessrio realizar alguma operao em segundo plano,
devendo informar a necessidade atravs de um arquivo de propriedades, para que o sistema
operacional possibilite o Multitasking (APPLE, 2010).
2.2.1.2
Camada de Mdia
Esta camada contm as principais bibliotecas de controle de multimdia, permitindo ao

desenvolvedor a escolha da utilizao de uma variedade de componentes para a construo do
aplicativo. Como por exemplo, Core Graphics, Core Animation, Core Image, OpenGL, Metal,
entre outros.
2.2.1.3
Core Services
Esta camada contm frameworks fundamentais para o desenvolvimento de um aplicativo.

Destacam-se o Foundation Framework, que define os tipos bsicos e o recente adicionado, e o
JavaScriptCore Framework, que permite o desenvolvimento de aplicativos nativos atravs da
linguagem JavaScript.
Foundation Framework
Este framework define uma camada de abstrao para as classes escritas em ObjectiveC, facilitando o desenvolvimento do aplicativo. Por exemplo, prov uma super classe,
chamada de NSObject, que contm um conjunto de classes auxiliares para desalocao da
memria, suporte a strings no formato unicode, persistncia de objetos, dicionrios, entre
outros.
JavaScriptCore Framework At a verso do iOS 7, o nico modo de um aplicativo iOS
interagir com um cdigo JavaScript seria atravs da subclasse UIWebView, que contm um
mtodo para avaliar o cdigo JavaScript: stringByEvaluatingJavaScriptFromString.
O problema que o UIWebView detm o seu prprio ambiente de execuo JavaScript,
em que possvel utilizar esse mtodo para avaliar somente scripts escritos dentro de
documentos HTML, executados pelo UIWebView, limitando o acesso dos mesmos ao
ambiente completo.
Para remover essa restrio, foi proposto o JavaScriptCore framework. Basicamente, este
uma composio de Application Programming Interface (API) escritas em Objective-C,
que do acesso aos desenvolvedores a todo o ambiente de execuo JavaScript a partir
17
do Objective-C. Como por exemplo, verificao de sintaxe e execuo de scripts, acesso

s variveis, recebimento de funes de retorno, e principalmente o compartilhamento
de objetos presentes no Objective-C, tornando possvel uma real interao 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 nvel do UNIX, para quais as aplicaes no tm interao direta
por motivos de segurana. Porm, algumas outras esto disponveis publicamente, como por
exemplo, sockets BSD, POSIX threads e servios 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 interao 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 utilizao do padro de projeto Model-View-Controller (MVC), que permite

uma camada de segregao entre o cdigo lgico e a interface visual. Isso possibilita que, no
desenvolvimento do aplicativo, a lgica de negcio seja reutilizada, enquanto o cdigo de
interface visual seja adaptado para suportar diferentes dispositivos e resoluo distintas.
Para mais informaes 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 cdigo aberto da Google, baseado em

uma verso modificada do kernel do Linux. Alm da Google, todos os outros membros da Open
Handset Alliance (Open Handset Alliance, 2007), constitudo por um consrcio de 80 empresas
de hardware/software/telecom, colaboram para o desenvolvimento dessa plataforma.
Para desenvolver um aplicativo Android so necessrios os seguintes requisitos mnimos:
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 cdigo em si, modelagem e construo
da interface grfica e auxlio na compilao e depurao do aplicativo.
Para entender o processo de desenvolvimento de aplicativos Android necessrio um
prvio 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 composio de cinco componentes
principais, conforme a Figura 2.3.
Uma das principais caractersticas herdadas de um sistema baseado em Linux foi o
conceito de mltiplos usurios, em que o Android considera cada App como um usurio distinto.
Isso permite que cada App seja executado dentro de um processo diferente um do outro, criando
uma espcie de sandbox, ou seja, um ambiente seguro para que um App no acesse o espao
de endereamento alheio, ou at mesmo do prprio sistema operacional. Alm disso, cada App
por padro executado com o mnimo de permisses necessrias e, caso seja necessrio utilizar
APIs do sistema operacional, como SMS, Agenda, Bluetooth e etc, necessrio que o usurio
aceite explicitamente no momento da instalao do App.
19
Figura 2.3: Arquitetura do Android3
2.3.1.1
Application Framework
Um App Android constitudo basicamente de blocos modulares (GOOGLE, 2015a).

A motivao para esta arquitetura o poder de economia no desenvolvimento que se ganha ao
reutilizar funes que j so satisfeitas por um App terceiro. Estes blocos so chamados de
componentes essenciais, cada um com sua funo especfica. 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 interao
do usurio com objetivo de realizar alguma ao (GOOGLE, 2015a). Cada activity
relacionada uma janela, que normalmente preenche toda a tela do dispositivo mvel,
3 http://www.developer.com/imagesvr_ce/1638/CloudAndroid0_r1_c1.jpg
20
podendo ser tambm um espcie de modal (janela sobreposta). Normalmente um App

Android constitudo de vrias activities independentes, onde a principal nomeada de
"main", e ser a primeira a ser apresentada visualmente ao usurio.
Cada activity pode solicitar ou chamar outras, com o objetivo de realizar diferentes aes.
Cada vez que uma activity iniciada, a anterior parada, e armazenada em um registro da
pilha de contexto, chamada de "back stack". Alm disso, ao receber uma ordem de parada,
a activity pausada deve liberar recursos, principalmente os de rede e banco de dados, por
exemplo.
A comunicao entre activities de Apps terceiros no realizada diretamente entre os
aplicativos, sendo necessrio criar uma inteno, que vai ser controlada pelo sistema
operacional. Assim, para um App interagir com o espao 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 execuo.
Um Intent pode executar uma ao de visualizao ou modificao, como por exemplo, ao
escrever em um bloco de notas e solicitar ao App de e-mail para que o envie, necessrio
criar uma ponte enviando os dados da sua aplicao para o aplicativo de e-mail, contendo
os dados escritos no bloco de notas que se tem a inteno 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 no prov uma interface
grfica, isto permite que o usurio modifique a pilha de contexto, por exemplo iniciando
outro App, e o service continue sendo executado em plano de fundo: executando uma operao 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 responsvel por finalizar-se ao trmino
do trabalho. J um service "bound"oferece um modo de comunicao intra processo (IPC),
no qual mltiplos componentes podem se comunicar com aquele para enviar ou requerer
requisies.
Content Providers
Um content provider uma interface padro de comunicao de dados compartilhados
entre processos (GOOGLE, 2015a). Este responsvel por controlar o acesso de terceiros
aos dados compartilhado de uma aplicao, caso seja permitido. Por padro, o ciclo de
vida de um content provider receber uma requisio de dados, executar a requisio e
retornar um resultado.
Broadcast Receivers
21
Um broadcast receiver um componente que controla o recebimento e envio de anncios

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 no tm uma interface grfica prpria, porm
pode se utilizar em alguns casos de uma rea especfica do sistema operacional, conhecida
como status bar, para criar uma notificao visvel ao usurio.
2.3.1.2
Libraries
As Libraries so bibliotecas de uso compartilhado, normalmente escritas na linguagem

de programao 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 execuo do Android deva suportar uma gama de dispositivos
heterogneos com diferentes requisitos de hardwares, as aplicaes necessitam ser encapsuladas
para atender os requisitos de desempenho e segurana sem depender do hardware embarcado.
Assim, cada aplicativo Android roda seu prprio processo, com sua prpria instncia da mquina
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 instanciaes de mltiplas mquinas virtuais eficientemente. Esta
VM executa classes compiladas pelo Java que so transformadas em um formato nativo desta,
o formato .dex, por uma ferramenta chamada dxtools, minimizando em at 50% o consumo
de memria em relao ao bytecode original (TECHTROPIA, 2013). Apesar de no estar
explicitado na figura 2.3, a mquina virtual Dalvik tem acesso direto ao kernel do Linux para
manipulao de funcionalidades como threads e controle da memria.
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 no 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 informaes 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 diferena entre as arquiteturas de
cada plataforma. Entretanto pode-se perceber algumas equivalncias 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. CONCLUSES SOBRE O DESENVOLVIMENTO DE APLICATIVOS
23
Em relao a interface grfica, temos que os Activities so os componentes visuais mais

bsico no Android, assim como os UIViewControllers so os componentes visuais mais bsicos
no iOS.
O iOS utiliza-se do padro de projeto Delegate, implementado no Application Delegate.
Esse padro 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 trmino. Esse mesmo conceito pode ser encontrado no Android atravs
dos Event Listeners.
Como visto anteriormente, o Android utiliza-se dos Services para rodar longas tarefas em
segundo plano. J no iOS, existe uma restrio para se criar esses tipos de tarefas por motivos
de economia de bateria. Entretanto o conceito mais prximo seria a utilizao de uma tcnica
implementada no servidor chamada Push Notification, na qual um App, ao invs de realizar
vrias requisies 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, especficos do Android, no foi encontrado nenhum componente explcito presente no iOS para se realizar a comparao.
2.5
Concluses sobre o desenvolvimento de aplicativos
Como visto nas sees anteriores, pode-se perceber que cada plataforma requer uma
linguagem de programao especfica, diferentes requisitos e ambientes de desenvolvimento e
distintos modelos de programao, baseado em seus kits de desenvolvimento especficos (SDK).
Por exemplo, desenvolver aplicativos para Android requer um prvio conhecimento de Java,
enquanto desenvolver para iOS requer domnio sobre Objective-C/Swift.
O problema ocorre quando um aplicativo precisa ser pensado para suportar ambas
as plataformas, exigindo a restrio de se manter duas verses do mesmo produto, porm
implementadas em suas tecnologias nativas, e como pode-se perceber baseado nas sees acima,
totalmente independentes e incompatveis.
A fragmentao, termo utilizado para descrever as diferentes verses de sistema operacional, e distintas resolues de tela entre os dispositivo mveis, tornou-se um dos maiores
obstculos no ecossistema mobile, sendo um dos fatores mais significantes e custoso para o
desenvolvimento e manuteno de um aplicativo pensado em multiplataformas (FLING, 2009).
Pelo alto custo adicionado ao desenvolvimento e manuteno a cada nova plataforma
suportada, foi pensada uma abordagem onde fosse possvel reusar parte do esforo utilizado em
uma plataforma, no desenvolvimento de outras, a fim de reduzir o custo associado.
24
3
Introduo a abordagens multiplataforma
3.1
Motivao
Conforme visto no Captulo 2, possvel ter uma ideia sobre os componentes cada
sistema operacional, suas caractersticas e diferenas. O custo de desenvolvimento de um App
pensado para suportar ambas as plataformas requer manter dois repositrios de cdigo 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 invivel em termos financeiros.
Sabe-se que o Android tem um mercado mais abrangente, entretanto o iOS a plataforma
mais rentvel (The Guardian, 2013). Visando contemplar os benefcios de cada plataforma e
evitar a criao de dois ou mais bancos de cdigo independentes, os desenvolvedores comearam a pensar em abordagens extensveis maioria das plataformas (XANTHOPOULOS;
XINOGALOS, 2013).
3.2
Web apps
A primeira abordagem foi utilizar o navegador de internet (browser) como base de

abstrao para o sistema operacional, como visto na Figura 3.1, uma vez que o browser j estava
presente em ambas plataformas. Os Web apps so sites responsivos, ou seja, que adaptam seu
contedo para serem visualizados em diferentes formatos de tela ou orientao, desenvolvidos
utilizando HTML5 e rodam sobre o browser do dispositivo, o aplicativo no 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. Alm disso, por
ser acessado atravs de um browser, os Web Apps no so distribudos pelas App Stores, no
passando pelo processo de reviso e chegando ao cliente rapidamente.
Logo, verifica-se que a principal vantagem de um Web app o rpido desenvolvimento
multiplataforma aliado ao baixo custo. Outra vantagem a facilidade da manuteno de um Web
3.3. APPS HBRIDOS
25
App, ou seja, adicionar novas funcionalidades, por exemplo, pois assim como sistemas Web,
basta modificar o cdigo do site no servidor, no sendo necessria nenhuma atualizao no lado
do cliente.
Em compensao a desvantagem dos Web apps a impossibilidade de usufruir da
distribuio e das aes de marketing providos pelas lojas de aplicativos, visto que os mesmos
so acessados atravs de uma URL (HEITKTTER; HANSCHKE; MAJCHRZAK, 2013). Alm
disso, seu desempenho comprometido pela renderizao que realizada atravs de um browser,
e pela qualidade da infraestrutura de rede, pois a cada nova pgina solicitada, realizada uma
nova requisio ao servidor externo (backend) como visto na Figura 3.1, onde em casos extremos
pode-se ter um Web app indisponvel.
Diante disso, a utilizao desta abordagem apenas recomendada para aplicaes simples,
e que no necessitem de recursos nativos de cada plataforma.
Figura 3.1: Viso Geral de um Web app1
3.3
Apps Hbridos
Para contornar as desvantagens dos Web Apps, foi pensada em uma abordagem hbrida,
na qual tenta-se combinar as vantagens de um Web App e a de um App nativo. Os Apps
hbridos, assim como os Web Apps, so desenvolvidos utilizando tecnologias web como HTML5.
Entretanto sua diferena est no fato de ser encapsulado por browser transparente ao usurio,
chamado de UIWebView (iOS) e WebView ( Android ).
O funcionamento de um App hbrido, baseia-se na utilizao do engine Webkit presente
nesses browsers nativos como visto na Seo 2.2.1.3, que tem como responsabilidade renderizar
o HTML5 escrito para a aplicao. Pelo fato de ambas as plataformas, conter esse engine de
renderizao, obtm-se o mesmo comportamento esperado.
1 http://cross-platform.mobi/images/cpmd_serversideweb.png
3.4. APPS GERADOS
26
Os Apps hbridos, por serem encapsulados em um componente nativo, vide Figura

3.2, so visualizados pelo sistema operacional como aplicaes nativas, possibilitando serem
distribudos pelas lojas de aplicativos presentes nas plataformas.
Alm disso, os aplicativos hbridos se utilizam de funcionalidades presentes no HTML5,
como por exemplo, web storage W3C (2013a) e geolocation W3C (2013b), para serem executados sem a dependncia imediata de uma infraestrutura de rede, e possibilitar chamadas as APIs
nativas de Geolocalizao, respectivamente. Isso minimiza as restries em relao aos Web
Apps, ao mesmo tempo que mantm o desenvolvimento rpido e a baixo custo.
A desvantagem dos Apps hbridos percebida pelo fator desempenho, pois assim como
os Web Apps, estes so renderizados como uma pgina web, atravs do browser. Alm 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 tcnicos presentes na especificao do
HTML5, por exemplo, o limite de 5MB para o web storage, podem tornar excludente a escolha
desta abordagem.
Figura 3.2: Viso Geral de um App hbrido2
3.4
Apps Gerados
Os Apps gerados (XANTHOPOULOS; XINOGALOS, 2013), so desenvolvidos a

partir de uma descrio em alto nvel, normalmente utilizando-se de uma Domain Specified
Language (DSL) (DEURSEN; KLINT; VISSER, 2000), na qual vrias regras de negcios so
estruturadas, por exemplo utilizando UML, gerando um modelo, que servir de base para a
gerador de cdigos 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 aps ter o modelo interpretado pelo gerador de cdigos, o mesmo criar vrios cdigos
nativos escrito para as plataformas descriminadas. Assim, torna-se possvel escrever cdigos em
alto nvel, que fazem uso de todo o potencial do SDK destas plataformas, previsto na DSL.
Entretanto, a desvantagem da utilizao da abordagem dos Apps Gerados est na necessidade do aprendizado de uma linguagem especfica do domnio, e caso venha a ser necessrio
utilizar alguma funcionalidade no descrita na DSL ou acompanhar as atualizaes dos SDKs,
o cdigo nativo e o gerador de cdigos devem ser alterado para suportar esses requisitos. Isso
causa um overhead para o desenvolvedor, visto que ser necessrio escrever para cada uma
dessas plataformas suportada.
Figura 3.3: Viso Geral de um App gerado3
3.5
Apps Interpretados
Os Apps interpretados so uma evoluo natural dos Apps hbridos, conseguindo unir
as vantagens do rpido desenvolvimento, utilizando JavaScript, e o desempenho nativo provido
pelos Apps Gerados. Em parte, essa evoluo foi possibilitada pela adio de interpretadores
JavaScript, como o JavaScriptCore Framework visto na seo 2.2.1.3, aos sistemas operacionais,
onde antes estavam presentes apenas no escopo de componentes de WebViews.
Assim, esta abordagem tem como principal caracterstica a utilizao de uma camada
intermediria, uma ponte, que ser responsvel pela comunicao entre o cdigo interpretado
pelo interpretador JavaScript e o ambiente de execuo do cdigo 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 prximo

ao nativo, somente diferindo pela existncia de um overhead gerado pela figura de uma ponte.
Alm disso, como o interpretador JavaScript agora pertence ao sistema operacional e no 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 Hbridos.
Todavia, a desvantagem vem do fato de ser necessrio implementar uma camada intermediria para comunicao com os interpretadores JavaScript presente nas plataforma suportadas.
Entretanto, adiante ser mostrado que essa desvantagem minimizada pela utilizao de ferramentas que j provm uma interface de programao (API) normalizada para a comunicao
com os interpretadores destas plataformas.
Figura 3.4: Viso Geral de um App interpretado4
3.6
Apps Cross-Compilados
Diferente das abordagens citadas acima, os Apps cross-compilados so escritos e desenvolvidos a partir da escolha de uma das tecnologias nativas Java ou Objective-C. A estratgia de
suportar mltipla plataformas vem da utilizao de um compilador cruzado, que ser utilizado
para traduzir o cdigo escrito em uma destas, em linguagem de mquina (bytecode), suportando
assim as diferentes plataformas que compartilhem da mesma arquitetura de hardware (SHEN;
HSU; YANG, 2014).
Pode-se dividir a construo desses Apps em duas etapas de desenvolvimento: implementao do cdigo backend, que responsvel pela lgica do aplicativo, e implementao do
cdigo frontend, que responsvel pela interface visual.
4 http://cross-platform.mobi/images/cpmd_interpreted.png
3.7. ALGUNS FRAMEWORKS EM SUAS DETERMINADAS CATEGORIAS
29
O cdigo backend ento compilados atravs compilador cruzado multiplataforma,

oferecendo um desempenho excelente em cada uma das plataformas, pois o cdigo traduzido
para bytecodes, no exigindo o overhead de um interpretador JavaScript em tempo de execuo
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 restrio dos Apps Gerados, em que preciso utilizar
apenas bibliotecas j suportadas pelo compilador cruzado, limitando sua utilizao. Alm disso,
boa parte do cdigo frontend, que corresponde a interface visual do aplicativo, precisa ser
desenvolvido em suas plataformas especficas.
Figura 3.5: Abordagem Cross-Compilados5
3.7
Alguns Frameworks em suas determinadas categorias
Diversas ferramentas e frameworks esto disponveis para cada tipo de abordagem

anteriormente citada, algumas com licena comercial e outras de cdigo aberto. Alguns desses
se tornaram relevantes para o cenrio do mercado atual e merecem destaque nesta seo.
A utilizao 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 criao de sites

responsivos, ou seja, aqueles que se adaptam ao tamanho e orientao da tela, seus componentes
grficos 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 esto acostumados com

as tecnologias web, visto que basicamente transforma um site web j existente para um formato
amigvel aos dispositivos mveis. Utilizando-se de tecnologias como CSS3 e HTML5, permite
que uma equipe web inicie o desenvolvimento de um App de forma rpida e econmica.
3.7.2
PhoneGap/Apache Cordova (Apps Hbridos)
O PhoneGap, cujo atual nome chama-se Apache Cordova (CORDOVA, 2014), uma
ferramenta de desenvolvimento multiplataforma hbrida, de cdigo aberto e licenciada sob
Apache 2.0. O Apache Cordova funciona basicamente encapsulando uma aplicao web.
O Apache Cordova minimiza as desvantagens citadas na Seo 3.3, pois implementa
alguns componentes presentes no SDK dos sistemas operacionais, permitindo o desenvolvimento
de aplicaes mais complexas.
3.7.3
Titanium Framework (Apps Interpretados)
O Titanium Framework um framework de cdigo aberto que implementa uma API

normalizada, escrita nativamente para cada plataformas especfica, facilitando a comunicao
com os interpretadores JavaScript presentes internamente em cada dessas. Isso permite a
execuo de cdigo 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). Alm disso, o Titanium permite o
desenvolvimento de mdulos 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 aplicaes multiplataforma. Diferente das abordagens citadas, o desenvolvimento atravs do
Applause baseado em uma linguagem de domnio especfico que descreve o comportamento
das aplicaes. Ao descrever a aplicao, utiliza-se um conjunto de geradores pr-definidos para
criar as aplicaes 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 cdigo escrito em Objetive-C para
o bytecode da arquitetura desejada. Ao realizar esta operao, no necessrio que nenhum
interpretador JavaScript ou mquina virtual existam, assim como necessrio pelos Apps
interpretados, e tambm evita o uso de DSL, como no caso dos Apps Gerados. Porm, preciso
ter conhecimento completo de uma linguagem especfica 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 utilizao de uma das abordagens vistas na seo anterior. Como visto, existe uma heterogeneidade entre as vantagens e desvantagens dessas abordagens, podendo tornar difcil a escolha de
uma destas. Entretanto, importante perceber que no existe concorrncia entre as abordagens,
visto que a escolha da utilizao de uma destas resultado de uma soma de variveis de contexto. A seguir sero abordados fatores de deciso baseados em HEITKTTER; HANSCHKE;
MAJCHRZAK (2013) e XANTHOPOULOS; XINOGALOS (2013) para construo posterior
de uma tabela comparativa entre as abordagens para o desenvolvimento de um aplicativo mvel
multiplataforma.
3.8.1
Critrios para avaliao

Desempenho: Referente a responsividade do aplicativo durante a interao com o

usurio. um fator significativo para a qualidade final do aplicativo. Porm deve-se
atentar que o fator desempenho pode ser comprometido atravs de fatores externos,
independentes da abordagem escolhida, como por exemplo, qualidade do cdigo,
infraestrutura de rede e requisitos de hardware. Por esse motivo subjetivo, a anlise
de porcentagem de memria consumida e tempo de processamento (profiling) de um
App est fora de escopo deste trabalho.
Custo: Referente ao custo financeiro necessrio para desenvolver um aplicativo
multiplataforma. Foi utilizado como parmetro o salrio anual mdio 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 disponveis
para a utilizao do desenvolvedor presentes no SDK de cada plataforma, por exemplo:
GPS, BTE, NFC, Acelermetro, Cmera, Rede e Armazenamento. Foi utilizado
como parmetro a quantidade de APIs disponveis pela abordagem em questo.
Facilidade de manuteno: Referente a facilidade de manter o cdigo do aplicativo,
como adicionar novas funcionalidades e corrigir erros. A manuteno est relacionada
a quantidade de ambientes de desenvolvimento. Foi utilizado como parmetro de
referencia a quantidade de linhas de cdigo (LOC) e a tecnologia utilizada.
Velocidade de desenvolvimento: Referente ao tempo total para desenvolver o aplicativo em todas as plataformas desejadas, no levando em conta o tempo de reviso
do aplicativo nas App Stores.

3.8.2
32
Suporte da comunidade: Referente ao apoio do grupo de desenvolvedores e material

disponvel, como documentao, tutoriais e aulas fornecidas por usurios ativos.
Alm disso, foi utilizado como parmetro a quantidade de questes encontradas pelas
tags especficas em um dos maiores site de perguntas e repostas tcnicas, o Stack
Overflow (STACKOVERFLOW, 2015).
Avaliao dos critrios por abordagem
Para analisar os critrios citados na subseo anterior, foi-se necessrio utilizar as

ferramentas que implementam cada uma das abordagem demonstradas vistas na Seo 3.7.
Para a avaliao dessas abordagens, foi proposto neste trabalho, um conceito para cada um dos
critrios acima, so eles: Baixo, Mdio ou Alto. A seguir ser apresentado os argumentos para a
avaliao dos conceito.
Abordagem Nativa
1. Desempenho (Conceito: Alto) - Os aplicativos nativos apresentam uma
excelente responsividade ao usurio, visto que so 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
vrias 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 prprias de cada sistema operacional, estes podem ter acesso a totalidade
de APIs disponveis no SDK, alm de total controle dos recursos de hardware
disponvel no dispositivo.
Facilidade de Manuteno (Conceito: Baixo) - A cada plataforma suportada
preciso manter um repositrio de cdigo, aumentando assim o nmero de linhas de
cdigo 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, no aproveitado o cdigo de um aplicao em uma outra, por
consequncia pode gerar um atraso entre o lanamento do aplicativo nas diferentes
plataformas.
Suporte da comunidade (Conceito: Alto) Foram contabilizados aproximadamente 311.842 e 635.787 questes utilizando as tags "ios"e "android"respectivamente.
O que mostra uma comunidade bastante ativa, oferecendo muito suporte ao usurio
iniciante e durante o desenvolvimento.
Web Apps utilizando jQuery Mobile.
33
Desempenho (Conceito: Baixo) - O desempenho de um Web App em relao ao

nativo considerado relativamente baixo, pois o mesmo requer ser executado dentro
de um browser gerando um overhead significativo, consequentemente reduzindo a
sensao de responsividade do App, pois a sensibilidade ao toque limitada e os
efeitos de transio se assemelham a uma site e no a um App nativo.
Custo (Conceito: Baixo) - O custo considerado relativamente baixo pois
apenas uma equipe de profissionais qualificados em WEB necessrio para o desenvolvimento deste App para vrias plataformas.
Acesso a API nativa (Conceito: Baixo) - Pela limitao do browser, os Web
Apps no tem acesso direto as API nativas do sistema operacional. Sendo qualificado
como baixo.
Facilidade de Manuteno (Conceito: Alto) - Alm de ter apenas um repositrio de cdigo para ambas plataformas, diminuindo as linhas de cdigo do projeto.
o Web App no instalado no dispositivo do usurio, tornado o processo de adio
de funcionalidades e remoes de bugs transparentes ao usurio.
Velocidade de desenvolvimento (Conceito: Alto) - A velocidade de desenvolvimento muito rpida visto que os as tecnologias utilizadas, como HTML5, so
bastantes difundidas e utilizadas pelos desenvolvedores. Ao trmino no desenvolvimento o App funcionar para vrias plataformas ao mesmo tempo.
Suporte da comunidade (Conceito: Alto) - Foram contabilizados aproximadamente 39.399 e 69.941 questes utilizando as tags "jquery mobile"e "html5". O que
mostra uma comunidade relativamente ativa, oferecendo muito suporte ao usurio
iniciante e durante o desenvolvimento.
Hbridos utilizando Apache Cordova.

Desempenho (Conceito: Baixo) - Apresentam um desempenho melhor do que
os Web Apps, visto que no dependem da infraestrutura de rede e so executados sob
um browser nativo com menor overhead, porm no apresentam um desempenho
similar ao nativos, pois continuam sendo executados dentro de contexto no acessvel
diretamente pelo sistema operacional, o que limita a sensibilidade aos toques e por
consequncia 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 : Mdio) - Os Apps hbridos 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,
porm menor do que o nativo.
34
Facilidade de Manuteno (Conceito: Alto) - Por utilizar as mesmas tecnologias utilizadas para o desenvolvimento dos Web Apps, e um nico repositrio de
cdigo, 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 questes utilizando as tags "phonegap"e "cordova"e
"html5". O que mostra uma comunidade relativamente ativa, oferecendo muito
suporte ao usurio 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: Mdio) - Por precisar apenas de uma equipe para desenvolver
uma aplicao dentre as vrias necessitadas na abordagem nativa. Foi considerado o
custo de desenvolvimento similar a de apenas uma aplicao nativa. Porm o custo
relacionado a esse desenvolvimento maior do que os Web Apps ou Hbridos pelo
fato da tecnologia utilizada.
Acesso a API nativa (Conceito: Mdio) - Apesar de serem Apps nativos em
tempo de execuo e acessar todas as APIs presente no SDK de cada plataforma,
necessrio que as APIs sejam definidas previamente na DSL, caso contrrio no
podero ser usadas em tempo de desenvolvimento, o que caracteriza o conceito
mdio.
Facilidade de Manuteno (Conceito : Mdio) - Apesar de ter somente um
repositrio de cdigo para vrias plataformas, os Apps Gerados so muito especficos
em seu domnio, e caso haja a necessidade de uma nova funcionalidade futura no
prevista na DSL, existe um overhead de implementao nativa dessa funcionalidade
para cada uma das plataformas suportadas.
Velocidade de desenvolvimento (Conceito: Mdio) - relativamente mais
lenta do que a abordagem hbrida e mais rpida do que os Apps nativos, qualificando
em mdio. Alm disso a velocidade pode ser influenciada negativamente caso haja a
necessidade de expanso do domnio do contexto do App.
Suporte da comunidade (Conceito: Baixo) - No foi encontrada nenhuma
resultado para a tag "applause". O que mostra uma comunidade ainda pequena ou
inativa.

35
Interpretados utilizando Titanium Framework.

Desempenho (Conceito: Mdio) - Apresentam um desempenho superior aos
WebApps e Hbridos, pois no so executados dentro de um browser. Entretando
devido ao overhead gerado pelo interpretador JavaScript em tempo de execuo, 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 Hbridos, pelo fato
de ser preciso apenas de uma equipe para suportar vrias plataformas e da utilizao
de tecnologias web, como JavaScript.
Acesso a API nativa (Conceito: Alto) - Essa abordagem tem potencial acesso
a totalidade de funcionalidades nativas, mesmo que APIs no estejam implementadas
originalmente na ferramenta, pode-se estender a mesma criando mdulos nativos para
realizar a interface com essas APIs ainda em desenvolvimento. Segundo Appcelerator
Inc. (2015) o Titanium cobre 90% das funcionalidades nativas.
Facilidade de Manuntenao (Conceito: Alto) - Por utilizar as mesmas tecnologias utilizadas para o desenvolvimento dos Web Apps e Hbridos, e um nico
repositrio de cdigo, 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: Mdio) - Foram contabilizados aproximadamente 12.090 questes utilizando as tags "titanium". O que mostra uma comunidade menor que os Hbridos e Web Apps, porm maior do que a dos gerados e Cross
compilados, caracterizando o conceito mdio.
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: Mdio) - Por precisar apenas de uma equipe para desenvolver
uma aplicao dentre as vrias necessitadas na abordagem nativa. Foi considerado o
custo de desenvolvimento similar a de apenas uma aplicao nativa. Porm o custo
relacionado a esse desenvolvimento maior do que os Web Apps ou Hbridos pelo
fato da tecnologia utilizada.
Acesso a API nativa (Conceito:Alto) - Essa abordagem tem potencial acesso
a totalidade de funcionalidades nativas. Porm deve-se atentar aos que algumas
36
APIs nativas no conseguem ser compiladas para o Android devido a restries da

arquitetura.
Facilidade de Manuntenao (Conceito: Mdio) - Para realizar a manuteno
deve se atentar que o cdigo backend o mesmo, assim mais rpido que os nativos,
porm se a nova funcionalidade requerer alteraes na interface grfica preciso
implementar cada interface grfica em cada plataforma, gerando um aumento na
linhas de cdigo.
Velocidade de desenvolvimento (Conceito: Mdio) - Os Apps Cross compilados so construdos utilizando somente uma tecnologia e portado atravs de um
compilador cruzado, porm o cdigo de interface grfica implementado nativamente,
o que reduz a velocidade de desenvolvimento em relao aos Apps Interpretados e
Gerados, por exemplo.
Suporte da comunidade (Conceito: Baixo) Foram contabilizados aproximadamente 446 questes utilizando as tags "apportable". O que mostra uma comunidade
ainda pequena ou inativa.
3.8.3
A indicao de uma abordagem
Com o objetivo de auxiliar o leitor sobre qual abordagem mais vantajosa, props-se neste
trabalho questionamentos que devem ser respondidos utilizando os conceitos de Alto,Mdio ou
Baixo de acordo com o cenrio do Aplicativo a ser desenvolvido. Considerando como parmetro
as respostas suscitadas, possvel fazer uma comparao com a tabela que sumariza as avaliaes
dos conceitos explanados na subseo anterior, esta tabela pode ser vista na Figura 3.6.
Qual nvel de desempenho requerido para executar a aplicao? Leve em considerao, por exemplo, se seu aplicativo requer a necessidade de realizar processamento
de imagens em trs dimenses (3D) ou processar matrizes complexas.
Qual seu nvel de restrio ao custo total para o desenvolvimento do App. Leve em
considerao a quantidade de profissionais envolvidos e licena de software.
Qual seu nvel de urgncia para desenvolver o aplicativo e entreg-lo ao mesmo
tempo em ambas as plataformas?
Aps a entrega do aplicativo, qual nvel de intensidade de manutenes como por
exemplo, acrescentar funcionalidades ao App?
Qual nvel de integrao com o sistema operacional seu App precisar ter? Leve
conta acesso funcionalidade de hardware como Cmera, Bluetooth, NFC, GPS.
Qual seu nvel de dependncia de suporte da comunidade? Leve em considerao seu
domnio e conhecimento sobre a ferramenta e as tecnologias que iro ser utilizadas.
3.9. CONCLUSO
37
Figura 3.6: Comparao entre as abordagens de desenvolvimento de aplicaes mveis
3.9
Concluso
Pode-se verificar que no h uma soluo tima que atenda a todos os casos, para cada
abordagem destacada v-se vantagens e desvantagens para cada tipo de cenrio, ou seja, a
escolha de uma abordagem dependente de uma srie de critrios contextuais. Atravs dos
questionamentos propostos neste trabalho e da verificao das respostas na matriz de critrios
vista na Figura 3.6, possvel indicar uma direo para a escolha de uma abordagem mais
vantajosa.
Pode-se citar alguns exemplos como o cenrio de um App baseado em dados - catlogos,
comunicao, finanas, armazenamento - no qual no necessrio utilizar todos os recursos de
desempenho do dispositivo, aliado a necessidade de um rpido desenvolvimento em ambas as
plataformas, porm com uma restrio de custo. Logo a abordagem interpretada a mais indicada.
Para outro cenrio, no qual h a necessidade de se desenvolver um jogo 3D, por exemplo, o
alto desempenho uma restrio crucial, logo se deve pagar o custo associado, atravs de uma
abordagem nativa ou cross-compilada. Para aplicaes simples ou mesmo temporrias, que
devem ser desenvolvidas a um baixo custo, pode-se optar por uma abordagem hbrida ou mesmo
o desenvolvimento de um Web app.
No captulo 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 critrios de restrio mxima de custo, necessidade de APIs nativas como: GPS, Rede e
Celular, e rpida entrada em ambas as App Stores. Como esse no demandou grandes recursos
de desempenho, e baseado-se nos critrios vistos a abordagem indicada foi a interpretada.
38
4
Desenvolvimento de um estudo de caso
4.1
Introduo
Ser demonstrado como estudo de caso deste trabalho o desenvolvimento de um App

multiplataforma. A construo do mesmo foi realizada utilizando a abordagem interpretada,
atravs 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 prxima da localizao
atual do usurio, utilizando-se para isso de informaes geogrficas que so providas pelo GPS
do dispositivo mvel.
Para demonstrar a utilizao de recursos nativos, o App faz uso das APIs de rede e
geolocalizao de cada sistema operacional para interagir com os servios de resoluo 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
disponvel 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 trs grandes etapas:

design e planejamento da User Interface (UI), implementao da UI e implementao 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 usurio em cada uma das plataformas suportadas.
4.2. DESENVOLVIMENTO DO APLICATIVO
39
Por isso, durante a fase de planejamento, necessrio decidir se o App ser construdo sob uma
interface visual agnstica, ou utilizar somente componentes nativos de cada plataforma.
A abordagem agnstica segue o mesmo padro para cada sistema operacional. Ou
seja, possvel criar uma interface totalmente independente do sistema operacional. Contudo,
deve-se atentar que usurio espera um comportamento parecido com o sistema nativo o qual est
habituado a usar, o que no deve ser obstculo para inovar no modo de interao criando uma
identidade nica ao App.
No planejamento do AcheUPA, foi preferido uma abordagem agnstica, a fim de demostrar a flexibilidade do framework Titanium. Visto que, por exemplo, o Android tem um
componente nativo chamado barra de ao (ActionBar), esse componente utilizado normalmente como guia de localizao contextual do usurio, alm de prover botes para expandir menu
lateral e de aes, como compartilhamento. Porm, ambos componentes no so encontrados
nativamente no iOS, sendo necessrio construir esses componentes. Pode-se ter uma viso 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.2
40
Implementando a UI
A interface grfica no Titanium basicamente composta por uma dupla de arquivos: um

arquivo XML, onde os componentes so inseridos; e um arquivo TSS, onde se determina as
propriedades grficas. No AcheUPA, temos basicamente uma Window ou Activity (no Android),
onde ser inserido um Mapa, um menu lateral e o boto principal ter como ao buscar a UPA
mais prxima ao usurio.
Como pode ser visto no trecho de Cdigo 4.1, primeiramente foram definidos os componentes necessrios para o App, porm deve-se atentar que, sempre que se utilizar o framework
Alloy, necessrio explicitar na primeira linha do arquivo XML a marcao <Alloy>.
A unidade bsica de um App constituda 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 construo do mesmo, no trecho mostrado, foi determinado na primeira
View, ao atributo id o nome "mainView". Alguns desses atributos so especiais, como o platform,
que define que este componente em questo s dever ser compilado na plataforma especificada.
Ao final, possvel perceber a requisio de um widget, que um componente construdo
e distribudo por desenvolvedores terceiros, visando a aumentar a velocidade de criao de um
App. Funciona como uma pea de encaixe, onde possvel inseri-lo no App em desenvolvimento
sem maiores dificuldades.
Cdigo 4.1: Trecho de cdigo 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>
41
J no trecho do TSS, visto em 4.2 , pode-se verificar uma boa prtica de estratgia de
multiplataforma. Como o Alloy pr-processado antes da compilao do aplicativo, possvel
utilizar macros, para possibilitar a compilao em uma plataforma especfica utilizando a sintaxe
[plataform=*]. A ideia mostrar que, com o mesmo controlador, pode-se criar diferentes interface grficas para cada plataforma, sem nenhuma mudana estrutural de cdigo.
Cdigo 4.2: Trecho de cdigo do TSS

"#acheUpa[platform=android]":{
top:2%,
height:30dp,
backgroundColor: #e6594a,
backgroundSelectedColor: #e6594a,
title:Clique aqui,
}
"#acheUpa[platform=ios]":{
top:2%,
height:30dp,
backgroundSelectedColor: #e6594a,
activeStyle: {
color: #e6594a
},
font: {fontWeight:bold, fontSize:14sp},
title:Clique aqui,
Por fim, durante a implementao, pode ser necessrio utilizar arquivos estticos como:
imagens, udios, entre outros. Ao usar o framework Alloy possvel organizar esses arquivos,
utilizando uma organizao de diretrio: arquivos que sero compartilhados entre todas as
plataformas devem ficar na pasta raiz do diretrio, enquanto que os arquivos especficos devem
residir dentro das suas determinadas pastas como mostrado na Figura 4.2
42
Figura 4.2: Estrutura de diretrios
4.2.3
Implementando as funcionalidades
Aps o planejamento e implementao da interface grfica, preciso implementar o

funcionamento do App. Como visto no Captulo ??, os controladores implementam a lgica de
negcio do App, e so responsveis pela renderizao de cada View, por isso, para cada arquivo
View XML, existe um controlador correspondente JavaScript. Onde, atravs do operador especial
"$", possvel referenciar um componente presente no XML atravs do controlador.
No controlador visto no trecho de Cdigo 4.3, foi definida uma varivel thisWin que
armazena a instncia da Window. Salienta-se a utilizao do operador $ para capturar o elemento
atravs do atributo id. Igualmente, nota-se que como o elemento Window, presente na View, no
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 criao de um novo controlador denominado mapview, e tem
sua respectiva View requerida pelo mtodo getView. Ao final, setado um escutador de eventos
ao componente referenciado pela varivel thisWin, atravs do mtodo addEventListener, prtica
muito comum em JavaScript. Esse escutador espera assincronamente pela ocorrncia do evento
especificado, executando a funo de callback na presena do mesmo.
43
Cdigo 4.3: Trecho de cdigo 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, necessrio, atravs das informaes de longitude e latitude,
providas pelo GPS, realizar um clculo para determinar as UPAs mais prximas na regio
procurada.
Isso seria bastante custoso para um smartphone comum, alm de consumir bastante
a potncia da bateria. Por isso, para realizar este tipo de processamento so utilizados os
webservices . Para no ser necessrio elaborar algo j desenvolvido, foi adotado neste trabalho
os webservices do Google Maps (GOOGLE, 2015c) para resoluo de nome e para determinar
as posies das UPAS mais prximas.
Para melhor organizao do cdigo, foi criado um controlador apenas para armazenar as
APIs utilizadas. No trecho de Cdigo 4.4, pode-se verificar a implementao deste. Note que ao
utilizar o exports, o objeto api torna-se pblico para quaisquer controlador que o necessite.
44
Cdigo 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 requisies a essas APIs, o Titanium utiliza-se dos componentes

nativos de rede presente em cada sistema operacional. Pode-se chamar o mtodo createHTTPClient atravs da API normalizada do Titanium, criando uma funo totalmente multiplataforma.
Assim, com a invocao do mtodo Titanium.Network.createHTTPClient, cria-se um objeto
HTTPClient preparado para fazer uma requisio HTTP ao webservice desejado.
O trecho cdigo lgico mostrado em 4.5 reflete a utilizao do HttpClient, comportandose equivalentemente em cada plataforma, apesar das implementaes nativas serem diferentes.
Quando a resposta do webservice retornada, normalmente recebida no formato JavaScript
Object Notation (JSON), possvel realizar a funo de callback, determinada no caso pelo
evento onload.
Cdigo 4.5: Requisio 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.3.2
45
Geolocalizao
A localizao do usurio determinada utilizando a API do Titanium:

Ti.Geolocation.getCurrentPosition. Essa API configurada para receber, de tempos em tempos,
a posio em latitude e longitude do dispositivo. Esse intervalo pode ser ajustado para um alto
grau de preciso ou para uma melhor economia de bateria. Sua utilizao est demonstrada no
trecho de Cdigo 4.6
Cdigo 4.6: Obteno da Geolocalizao 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 especficas
Para demonstrar a utilizao de APIs especficas de cada sistema operacional, sero

utilizadas como exemplos a API de ligaes telefnicas. 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 operao condicional, por exemplo, if(OS_ANDROID)
ou if(OS_IOS).
Ao realizar esse tipo de operao, criado mesma base de cdigo: uma ramificao
de cdigo especfico para cada plataforma. Idealmente, deve ser minimizado o tamanho desta
ramificao, criando funes que abstraiam as diferenas entre plataformas.
No trecho de cdigo mostrado em 4.7, a aplicao para Android trata a funcionalidade
como um Intent, previamente explicado em 2.3, esse enviado para o sistema operacional na
espera da resposta a inteno. 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 tambm tratado como uma aplicao, tel://numero.
4.3. CONCLUSES SOBRE O ESTUDO DE CASO
46
Cdigo 4.7: Ramificao do cdigo onde a API do Titanium no 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
Concluses sobre o estudo de caso
Como pde-se perceber, a manuteno de um App multiplataforma desenvolvido utilizando o framework Titanium mais produtivo do que a manuteno de dois aplicativos nativos
distintos. Essa facilidade provida pela maior parte do cdigo ser compartilhada, com pequenos
ramos referentes a funcionalidades especficas dos sistema operacional. Deve-se atentar para a
criao do mnimo de ramificaes possveis, como por exemplo, uma soluo mais custosa
primeira vista pode ser uma mais econmica a longo prazo.
Um bom domnio da interface grfica de cada uma das plataformas desejadas permite
que o App tenha uma boa avaliao na reviso tcnica e tenha destaque nas App Store. Alm
disso, conhecer as diferentes implementaes do interpretador JavaScript pertencente ao sistema
operacional uma tima maneira de otimizar o desempenho do cdigo lgico.
47
5
Concluso
5.1
Principais Concluses
A rpida evoluo das tecnologias de sistema embarcado permitiram que diversos nichos
de dispositivos eletrnicos - dentre eles smartphones e tablets- se estabelecessem no mercado.
Cada uma destes dispositivos tem presente um sistema operacional, com suas caractersticas
especficas e peculiares. timo para os consumidores que se beneficiam da concorrncia
do mercado para satisfazer suas necessidades tecnolgicas. 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 negcios para se adaptar
a este novo conceito. Milhares de desenvolvedores voltaram suas atenes atrados 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 Hbridos, Gerados, Cross-compilados e Apps Interpretados so algumas
das abordagens utilizadas pelo desenvolvimento multiplataforma numa tentativa de contornar os
obstculos do desenvolvimento nativo. Estas abordagens apresentam vantagens e desvantagens
em relao uma a outra e em relao ao desenvolvimento nativo.
Web apps so sites webs responsivos que se adaptam a diferentes tamanho e orientaes de telas e so a opo mais econmica, enquanto os Apps Hbridos so 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,
porm podem depender de ferramentas para minimizar suas desvantagens. Por fim, os Apps
cross-compilados e gerados exigem o conhecimento de linguagens mais especficas, 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 utilizao de compilador cruzado.

Como estudo de caso deste trabalho foi desenvolvido o App AcheUPA, utilizando-se de
APIs de geolocalizao, rede e acesso a funcionalidades especficas de cada plataforma, como
ligaes telefnicas, validando o funcionamento da abordagem interpretada e do framework
Titanium.
At o trmino deste trabalho, o Titanium encontrava-se na verso 3.5.0.GA suportando o
desenvolvimento de aplicao 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 esto 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 cdigo aberto recentemente e est sendo chamada
de ReactJS (FACEBOOK, 2015).
O Google tambm demonstrou sua soluo de desenvolvimento multiplataforma, utilizando um compilador cruzado, chamado J2OBJC (GOOGLE, 2015d), que traduz o cdigo nativo
escrito em Java para o Objective-C, porm ainda com algumas restries de funcionalidades.
A Microsoft tambm mostrou-se interessada no desenvolvimento multiplataforma e, no inicio
do ano, tornou aberto o cdigo-fonte da biblioteca WinJS (MICROSOFT, 2014), que permite a
criao de Apps utilizando a linguagem JavaScript.
5.2
Trabalhos futuros
Algumas possibilidades para novos trabalhos a partir deste:
Realizar uma anlise de desempenho das abordagens estudadas.
Implementar um decisor para auxiliar na escolha da abordagem mais vantajosa.
Realizar um novo estudo de caso utilizando outro cenrio para validar outras abordagens.
49
Referncias
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 Profisses e Salrios | 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.16, 2009.
DEURSEN, A. V.; KLINT, P.; VISSER, J. Domain-specific languages: an annotated
bibliography. ACM Sigplan Notices, [S.l.], v.35, p.2636, 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 Arent 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. Servios da Web da API do Google Maps - Servios da Web da API do Google
Maps. 2015.
GOOGLE. J2ObjC. 2015.
HEITKTTER, 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.120138, 2013.
HILLEGASS, A. Objective-C Programming. [S.l.: s.n.], 2011.
IDC. IDC: smartphone os market share 2014, 2013, 2012, and 2011. 2014.
REFERNCIAS
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. 1272p.
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.125, 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 Apples 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.213220, 2013.

Em Direção A Uma Abordagem para o Desenvolvimento de Aplicativos Móveis Multiplataforma

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Em Direção A Uma Abordagem para o Desenvolvimento de Aplicativos Móveis Multiplataforma

Hochgeladen von

Copyright:

Verfügbare Formate

Victor Chaves Cas

EM DIREO A UMA ABORDAGEM PARA O DESENVOLVIMENTO

Universidade Federal de Pernambuco

Universidade Federal de Pernambuco

Victor Chaves Cas

EM DIREO A UMA ABORDAGEM PARA O DESENVOLVIMENTO

Orientador: Phd. Vinicius Cardoso Garcia

Eu dedico este trabalho de graduao toda minha famlia,

Viso Geral de um Web app . . . . . . . . . . . . . . . . . . . . . . . . .

Tela principal do AcheUPA para iOS e Android . . . . . . . . . . . . . . . . .

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

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

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

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

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

3.7.1 jQuery Mobile (WebApps) . . . . . . . . . .

Desenvolvimento de um estudo de caso

A revoluo dos dispositivos mveis iniciou-se em 2007, com a apresentao do ento

A fim de verificar o potencial econmico do mercado de aplicativos, a empresa de

Investigar sobre o desenvolvimento de aplicativos mveis.

Pesquisar sobre a abordagem de desenvolvimento de apps mveis 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.

1.4. FORA DE ESCOPO

A aprendizagem da utilizao de IDEs das tecnologias nativas.

A implementao de aplicativos mveis nativos

A avaliao de desempenho entre as abordagens multiplaformas

Estrutura deste trabalho

No Captulo 2 feita uma contextualizao sobre o desenvolvimento de aplicativos

No Captulo 4 o estudo de caso desenvolvido para validao deste trabalho.

No Captulo 5 so apresentadas as principais concluses deste trabalho.

Os Apps so peas de softwares desenvolvidas para rodar em um sistema operacional

Desenvolvimento de Apps iOS

O iOS (APPLE, 2010) o nome dado ao sistema operacional da famlia de dispositivos

Um computador Mac rodando uma verso 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

Figura 2.1: Arquitetura do iOS1

Camada Cocoa Touch

A camada Cocoa Touch contm um conjunto de bibliotecas, chamado de Kits, que

2.2. DESENVOLVIMENTO DE APPS IOS

Esta camada contm as principais bibliotecas de controle de multimdia, permitindo ao

Esta camada contm frameworks fundamentais para o desenvolvimento de um aplicativo.

2.2. DESENVOLVIMENTO DE APPS IOS

do Objective-C. Como por exemplo, verificao de sintaxe e execuo de scripts, acesso

A camada Core OS a camada mais inferior dentre as quatro camadas, encapsulando o

Estrutura de um aplicativo iOS

Figura 2.2: Estrutura de um aplicativo iOS2

2.3. DESENVOLVIMENTO DE APPS ANDROID

Percebe-se a utilizao do padro de projeto Model-View-Controller (MVC), que permite

Desenvolvimento de Apps Android

Android o nome dado ao sistema operacional de cdigo aberto da Google, baseado em

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

2.3. DESENVOLVIMENTO DE APPS ANDROID

Figura 2.3: Arquitetura do Android3

Um App Android constitudo basicamente de blocos modulares (GOOGLE, 2015a).

2.3. DESENVOLVIMENTO DE APPS ANDROID

podendo ser tambm um espcie de modal (janela sobreposta). Normalmente um App