SmartAndroid – Mobile Enterprise Development

João Paulo Sousa Dias Costa Amaro

Dissertation submitted to obtain the Master Degree in Information Systems and Computer Engineering

Jury

President:	Prof. Doutor António Manuel Ferreira Rito da Silva
Supervisor:	Prof. Doutor José Carlos Alves Pereira Monteiro
Co-Supervisor:	Eng. Rúben João dos Santos Paulino Ribeiro de Almeida
Member:	Prof. Doutor Alberto Manuel Ramos da Cunha

November 2012

ii

“Enthusiasm is one of the most powerful engines of success. When you do a thing, do it with all your might. Put your whole soul into it. Stamp it with your own personality. Be active, be energetic, be enthusiastic and faithful, and you will accomplish your objective.” — Ralph Waldo Emerson

iii

iv

Agradecimentos

Objectivos de vida sao˜ aventuras. Ha´ objectivos que se concluem estando sozinho, como se de uma

aprendizagem interna se tratassem. Ha´ outros que sao˜

faria sentido. E assim que olho para

os ultimos´ 6 anos da minha vida, como uma aventura. Uma aventura que ocorreu no IST e que nao˜

aconteceu sem a presenc¸a de grandes amigos e pessoas que fizeram a diferenc¸a

pautados pela presenc¸a de pessoas que nos

sao˜ proximas´

´

e que nos ajudam, sem as quais a aventura nao˜

A essas pessoas,

a	quem estou eternamente grato por terem passado na minha vida, dedico estas palavras.
	Primeiro, gostaria de mostrar especial gratidao˜ ao meu orientador, o Professor Jose´ Monteiro,
e	ao Ruben´ Almeida da Tecmic. Sempre me acompanharam e sempre me guiaram da melhor

forma com conselhos, ideias, compreensao˜ e, acima de tudo, com experiencia.ˆ Sem eles, nao˜ teria

sido poss´ıvel concretizar de forma tao˜ clara esta tese de Mestrado. Obrigado por acreditarem em

mim. De seguida gostaria de demonstrar todo o carinho, afecto e apresso a` minha avo´ Isilda Sousa

que tanto suportou para que conseguisse chegar onde estou hoje. A ela devo muito do que sou e sem

ela, e sem os meus pais Ana e Fernando Amaro, nada disto teria sido poss´ıvel. A vocesˆ dedico

esta dissertac¸ao˜ por ser o resultado e o expoente maximo´ destes anos de trabalho.

Havendo coisas que esquecemos facilmente e coisas que nos marcam para sempre, posso afirmar

que todo o esforc¸o que fizeram nunca se dissociara´ da minha essencia.ˆ Fazem parte de mim, agora

e sempre. O que sou, o que consegui e o que quero atingir sao˜ realidades apenas possiveis devido a`

vossa existencia.ˆ

Ainda no campo da fam´ılia, nos ultimos´ 6 anos construi uma outra, aquela que nao˜ se ganha

quando nascemos mas a que se constroi por escolha propria.´ Os meus amigos sao˜ essa outra fam´ılia.

Mudaram a minha forma de pensar, de ver a vida e construiram a minha personalidade ao longo

dos anos. Aprendi com eles nestes ultimos´ 6 anos mais do que nos primeiros 18 da minha vida.

Nao˜ quero deixar passar a oportunidade de dedicar umas linhas a 2 dos membros dessa familia:

Luciano, nunca vou esquecer o companheirismo, a compreensao˜ e as horas que passamos´ juntos

a` conversa e a fazer os projectos do curso. Obrigado por teres tolerado com pacienciaˆ os momentos

menos bons deste Ribatejano com um pouco de Alentejo. Mesmo sabendo que estas´ longe, estaras´

sempre perto, um grande abrac¸o; Pedro, obrigado por tolerares as minhas distrac¸oes,˜ por partil-

hares dos melhores e mais produtivos momentos de brain-storming da minha vida, pela capacidade

de ouvir e por teres ensinado ao teu caloiro favorito a magia por detras´

A todos os outros, cujos nomes nao˜ referi por ter muito para escrever e pouco espac¸o para divagar,

gostava de vos dizer, com toda a forc¸a e assertividade: Obrigado! Muito obrigado por existirem!

Sem vocesˆ nada disto seria tao˜ agradavel´ e cheio de sentido.

Nao˜ menos importantes foram o Carlos Simoes,˜ Filipe Martins, Henrique Rocha, Joao˜

Mateus, Joao˜ Ribeiro, Joel Fernandes, Maria Joao˜ Pereira, Ricardo Leitao˜ e especial-

mente ao Pedro pela ajuda nos testes. Foram incansaveis.´ Obrigado, do fundo do corac¸ao.˜

das tabelas de dispersao

˜

sempre vosso, Joao˜

Dias Amaro

v

vi

Resumo

Com a proliferac¸ao˜ de smartphones e tablets, e com o aumento do suporte para aplicac¸oes˜ empre- sariais de soluc¸oes˜ moveis,´ e´ da maior importanciaˆ ter um ambiente de desenvolvimento apropriado para as necessidades de uma aplicac¸ao˜ movel´ empresarial tais como: gestao˜ de comunicac¸oes˜ en- tre dispositivos, camada de acesso a dados, mapeamento entre entidades relacionais e objetos da aplicac¸ao,˜ distribuic¸ao˜ de aplicac¸oes,˜ updates e gestao˜ de energia. Devido a` falta de soluc¸oes˜ de desenvolvimento que vao˜ ao encontro de todas as funcionalidades mencionadas anteriormente, esta tese propoe˜ uma framework com foco nos requisitos e funcionalidades referidos atraves´ de uma forma integrada com as soluc¸oes˜ ja´ existentes nas ferramentas de desenvolvimento Android. Esta framework consiste numa biblioteca de desenvolvimento para ajudar no processo. Sao˜ tambem´ apresentados o modelo de avaliac¸ao˜ da framework, conclusoes˜ finai, uma analise´ de soluc¸oes˜ rela- cionadas com a que e´ proposta e ainda uma breve discussao˜ dos ecossistemas de desenvolvimento movel´ atuais.

Palavras-chave: Android, Plataformas empresariais, Desenvolvimento Movel,´ tura de Software, Ecossistemas Moveis´

vii

Arquite-

viii

Abstract

With the proliferation of smartphones and tablets, and with the increased support of enterprise businesses in mobile computing solutions, it is of the utmost importance to have a development environment suitable for the needs of a corporate mobile application such as device communication management, data access layer, object relational mapping, application distribution or energy man- agement. Due to the lack of a development solution that meets all the aforementioned needs, this thesis proposes a framework to address those requirements and integrate with the already existing Android development tools. This framework consists of a development library module to help the deployment process. It will also be presented the evaluation model and conclusions for the frame- work and an analysis of related solutions to the development of mobile applications and about the current major mobile ecosystems.

Keywords: Android, Enterprise Platforms, Mobile Development, Software Architecture, Mobile Ecosystems

ix

x

Contents

Agradecimentos						.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	v
Resumo	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	vii
. List of Tables Abstract . .					.	.	.	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	. .	ix xiii
List of Figures					.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	xvi
Nomenclature					.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	1
1 Introduction																																																		1
1.1 Background on Mobile Ecosystems																				.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	2
1.2 Choosing a Mobile Environment																			.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	4
1.2.1 Hardware Prices																					.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	4
1.2.2 Development costs and Licenses																							.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	5
1.2.3 Needed Skill Set																					.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	6
1.3 The Relevance of an Integrated Environment																																																		6
1.4 The Enterprise Context																				.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	8
1.5 Purpose and Goals											.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	8
1.6 Contributions								.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	9
1.7 Document Structure												.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	10
2 Related Work																																																		11
2.1 Related Concepts										.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	12
2.1.1 Data Serialization																				.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	12
2.1.2 Remote Communication API .																					.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	14
2.1.3 Expressing the application Domain Model																																																		16
2.1.4 DAL – Data Access Layer																			.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	17
2.1.5 ORM – Object Relational Mapping																								.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	19
2.2 Native, Web-based and Hybrid Development																										.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	20
2.2.1		Native Development														.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	21
																							xi

2.2.2 Web-based Development													.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	21
2.2.3 Hybrid Development											.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	22
2.3 NDE – Native Development Environments																				.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	23
2.3.1 Android, Google Inc.											.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	23
2.3.2 iOS, Apple															.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	26
2.3.3 BlackBerry OS, RIM – Research In Motion																								.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	29
2.4 XDE – Cross-Platform Development Environments																									.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	31
2.4.1 Rhodes, RhoMobile										.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	31
2.4.2 PhoneGap, Adobe									.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	32
2.4.3 Titanium Mobile, Appcelerator																																													34
2.5 Discussion	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	35
3 System Architecture and Implementation																																													38
3.1 Requirements Specification											.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	38
3.2 Architecture Specification										.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	40
3.3 Functional Specification									.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	44
3.4 Development Library							.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	45
3.4.1 Communication Management																.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	45
3.4.2 Persistency Management															.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	50
4 Framework Evaluation																																													54
4.1 Benchmarks Overview								.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	54
4.2 Evaluation	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	56
4.2.1 Communication Management																.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	58
4.2.2 DAL + ORM: Domain Management																				.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	59
4.3 Discussion	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	59
5 Conclusions and Future Work																																													61
A Major Cross-Platform Frameworks																																													64
B Bluetooth Adapter UML																																													65
C WiFi Adapter UML																																													66
D Communication Manager UML																																													67
E Communication Infrastructure UML																																													68
F Application Development Results																																													69
Bibliography																																													74

xii

List of Tables

1.1 Major Mobile Operating Systems – Market Share [3].					.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	2
1.2 Simple Measure of Platform Effectiveness [4].	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	3

xiii

xiv

List of Figures

1.1	Graphic representation for the Market Share of all major platforms.																					.	.	.	.	.	.	.	.	.	.	2
1.2	Global Smartphone Penetration. Manufacturer & Market Share [4].																					.	.	.	.	.	.	.	.	.	.	5
1.3	Strong Network Effects for Android and iOS [4].									.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	7
1.4	Weak Network Effects for Symbian, BlackBerry and Windows Phone																															7
2.1	Simple schematic of sending/receiving serialized data through the																															12
2.2	Simple interaction structure for the OSI model [17]. In the left side it is highlighted the separation between upper and lower layers of the model. In the right side it is possible to see the layer-to-layer interaction and the exchange of PDUs (Protocol Data Units) between SAPs (Service Access																															15
2.3	Generic communication protocol with several sub-protocol layers [17].																						.	.	.	.	.	.	.	.	.	15
2.4	“Table Data Gateway” design pattern [23].						.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	18
2.5	“Row Data Gateway” design pattern [23].					.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	18
2.6	“Active Record” design pattern		.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	18
2.7	“Data Mapper” design pattern		.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	18
2.8	Encapsulation of a RDBMS with an object-relational																															19
2.9	“Unit of Work” design pattern [23].	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	20
2.10	“Identity Map” design pattern		.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	20
2.11	The history and life spans of the 22 major Mobile Operating Systems. The lifespan is
	bounded by the dates of public announcements of start and end of development efforts by the platform owner. It does not include times when products are still in the market
	or the platform is still supported [28].			.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	22
2.12	Major components of the Android system architecture																															25
2.13	The hierarchical layers of the iOS framework																															28
2.14	Sandbox for an iOS application. Source: http://developer.apple.com/.																	.	.	.	.	.	.	.	.	.	.	.	.	.	.	28
2.15	The BlackBerry Operating System architecture [41].												.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	30
2.16	The Rhodes MVC (Model-View-Controller) model																															33

xv

2.17

Titanium Mobile architecture (when developing an Android application)

35

3.1	General overview of the integration between enterprise applications, the Android Runtime Libraries (depicted in more detail in Section 2.3.1) and the SmartAndroid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .																																							.	41
3.2	General overview of the communication architecture in a layered interaction																																								41
3.3	Example of the interaction between the communication architecture layers and the Android runtime libraries (depicted in more detail within Section																																								42
3.4	Persistency management architecture, highlighting the interactions between sub- modules and the decoupling between managers and DAL/ORM																																								43
3.5	The implemented inheritance model of the Physical Adapter																																								46
3.6	The implemented inheritance model of the Communication Management																																								48
3.7	The implemented inheritance model of the Communication Infrastructure																																								49
3.8	An example of a simple domain model for a school																																								52
3.9	An ilustration of the domain generation procedure. From the example of Figure																																								53
4.1	The applications’ interface created for the evaluation																																								55
4.2	Average LOCs (Android SDK VS SmarAndroid) for both																																								57
4.3	Survey answers to the metrics related to the SimpleMessenger																																								58
4.4	Survey answers to the metrics related to the SaveMyNotes																																								59
A.1 List with all the major development platforms																		.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	.	64

xvi

1

Introduction

Since a very long time, enterprises and their businesses found the need to adapt to new technologies and more modern methods to continue to grow and prosper. This urge to adapt is crucial for stable business growth and allows for the creation of new market value in an ever-changing economy. This fact is relevant, not only in enterprises that are changing their management policies to ad-hoc teams and more distributed forms of leadership, but also in start-ups or companies with more strict and hierarchical architectures.

For enterprises to have this kind of proactive environment, they must provide their employees with dynamic tools to let them interact with this new kind of organizational flow, as described be- fore. For this to happen, employees must work with responsive and versatile devices, such as smart- phones, tablets or PDA’s that will provide new sources of knowledge to their companies. This kind of knowledge may stay in a central repository or may even be spread among all the mobile devices, representing what was described as tacit knowledge by Cosquer and Ohayon-Dekel in 2009 [1].

Because this tacit knowledge is so important nowadays, enterprises are willing to transform their employees into a mobile workforce. Supporting this fact is iPass Alliance which studies the penetration of mobile devices in the enterprise environments since 2010. In their most recent study “Mobile Workforce Report” from November 2011 [2], which is based on information obtained from more than 2300 responses at over 1100 enterprises worldwide, it is clear that 95% of mobile workers now have smartphones, up from 85% in 2010. Also tablet ownership has grown to 44% of mobile employees, up from 33% in the second quarter of this year.

This study also concludes that, from all the mobile device users, 58% of all the smartphones are issued by the company, and among the companies that give the devices to their employees, 44% of the devices are chosen from a list of corporate supported smartphones. Finally, iPass also states that, from all the queried smartphone types, Android and iPhone powered devices are leading the smartphone enterprise usage.

Also surveying this mobile workforce, although in a more general and global way, is Gartner, one of the World’s leading IT research and advisory company, that predicts in a survey to the consumer segment of mobile devices from April 2011 (whose results are displayed in Table 1.1 and Figure 1.1), that the Android OS will have 49.2% of market share by the end of 2012, accompanied by an ex-

1

Table 1.1: Major Mobile Operating Systems – Market Share [3].

Mobile OS	2010 (%)	2011 (%)	2012 (%)	2015 (%)
Symbian	37.6	19.2	5.20	0.10
Android	22.7	38.5	49.2	48.8
Blackberry	16.0	13.4	12.6	11.1
iOS	15.7	19.4	18.9	17.2
Windows Phone	4.20	5.60	10.7	19.5
Other OS	3.80	3.90	3.40	3.30

Figure 1.1: Graphic representation for the Market Share of all major platforms.

pressive reduction in the market share of Symbian and the stabilization of other major platforms,

such as the iOS [3].

1.1 Background on Mobile Ecosystems

The evolution of the market share of all the mobile operating systems, depicted in Figure 1.1, is

also accompanied by a, not so linear to define, growth rate of devices sold across the World. In the

second quarter of 2011, smartphone penetration surpassed 29% of all sold communication devices

globally. However, smartphone shipment penetration varies widely from nearly 65% in the USA

and over 50% in Europe to 19% in Asia, 17% in Latin America and 18% in Africa/Middle East [2, 4].

Android and iOS, being the two most adopted mobile platforms, exemplify successful application

infrastructures that were designed from the beginning to connect two disjointed markets: users and

application developers. From the end-user perspective, each application adds value to the platform

and from a developer’s perspective, the platform gains value with each and every new user.

With simple measures, it is possible to conclude that when the number of developers, applica-

tions and users on a platform reaches critical mass, the platform begins to grow exponentially. This

is because of positive feedback loops between users and application developers: applications attract

2

Developer investment in Android, iOS, WP7

Platform

Publishers 4

Average

Mindshare 6

apps/user 5

(% of developers using the

platform)

Android

70,000

4.1

67%

iOS (iPhone)

101,000

4.1

59%

iOS (iPad)

36,000

3.6

N/A

Windows Phone 7

7,000

3.6

36%

Table 1.2: Simple Measure of Platform Effectiveness [4].

users, which motivates developers to create more applications, which in turn attract more users and so on. As such, these two platforms generate huge financial investments. Assuming for sim- plicity the example given in the Developer Economics report of 2012 from VisionMobile [5], that a typical application costs an estimated $10,000 to $50,000 per year to develop, then the approximate 500 thousand available iOS applications represent a diluted average investment of $15.000.000.000 only in this platform worldwide. Since the developers drive the adoption of an application platform over another, one can state that a platform is only as successful as the developers who build its ap- plications, being that the total number of applications is frequently considered the main measure of a platform’s success, in a very simple way.

The report referenced in the last paragraph also clarifies that 45% of the users reported using an app store as their primary route to the market. It is possible to relate the sudden popularity of this monolithic approach for application distribution to the reach it offers. Another important motivation reported in the survey from VisionMobile suggests that app stores have also reduced the average time-to-market by two thirds: from 68 days across traditional channels (private owned websites and download centers) to 22 days via an app store. These numbers appeal to companies that want to leverage the huge amount of users that are willing to pay for high-end applications, even if the target of the two major mobile platforms (Android and iOS) is the domestic segment and not the professional/enterprise user.

Even though this approach may not be a scalable one and may be tending towards a technologi- cal bubble similar to the “.com bubble”, as stated by Jim Edwards (senior editor in Business Insider Magazine) in August 2012, in order to maintain the positive feedback around the mobile applica- tion business, there is a constant need for applications and development companies to continue to invest their money on advertisement for this kind of applications [6]. Related to enterprise budgets of companies wanting to enter the mobile platform business is the cost for persuading developers to work for a specific platform. For example, the price of $1 billion dollars spent over by Microsoft in marketing budgets for promoting Windows Phone during the first year of launch with “hands- on” campaigns, or even the estimated acquisition cost of over $2,300 dollars for an iOS developer in the case of Apple [5] reveals the effort put in establishing a good ecosystem for those mobile environments.

3

The heterogeneity of this development ecosystem is balanced in several vectors that comprise, among other factors: (i) independent software vendors, (ii) hobbyist developers, (iii) entrepreneurs, (iv) in-house developers, (v) B2C companies and (vi) B2B companies. To balance this ecosystem towards a specific edge of the competition, platforms compete for developer mind-share using a diverse set of motivators (Table 1.2). These include monetization, user reach, quality of develop- ment tools, technology characteristics and also the, many times under-looked, cool factor. In case of Apple, it has turned iOS into “a must have” niche platform; Android is quickly becoming a vi- able alternative, both in the user and enterprise segment, for developers by its wide user reach and “openness”; Microsoft is buying its way into the minds of developers by sponsoring the porting of many popular applications to the Windows Phone platform and by creating joint-ventures with hardware manufactures, such as Nokia. In Figure 1.2 it is also possible to infer that the world market for mobile handsets is not yet sta- bilized in the smartphone segment. There are also “feature devices” (old cellphones with low-end operating systems, such as the Symbian or other vendor-specific OS) which represent the major part of the sold devices, with Nokia and Samsung being the main players in this segment (with an ag- gregate of 34% of market share). On the smartphone area of the graphic it is possible to see a much more evident fragmentation of the market which leads to the same behavior in smartphone’s OS fragmentation, manifesting an hectic behavior in what the market penetration share is concerned.

1.2 Choosing a Mobile Environment

Since corporate businesses are beginning to be more and more sustained by smart devices and mo- bile technology, there are several factors to analyze before choosing one development environment over another. Some major deciding factors, when a company wants to support its business on mo- bile devices, are listed below and it is possible to note important differences between the two bigger market players, Android from Google and iOS from Apple.

1.2.1 Hardware Prices

There are major differences when looking at prices for both Android and iOS devices which are, on average, much more expensive than Google’s alternative. In a very simple market analysis, one can relate the huge amount of Android device manufacturers with the device’s price reduction (a total of 23 manufacturers worldwide registered in the Open Handset Alliance by December 2011 [7], excluding the hardware vendors not registered with Google) in contrast with the only iOS device manufacturer, Apple. There are other reasons for this contrast but the rationale for choosing Android, instead of iOS, is not linear in what prices are concerned, due to different market variables and approaches. Companies often prefer low-priced devices over high-end and over-priced ones, which puts Android devices in the front line and, when compared to other mobile platforms, Android has greater price

4

Figure 1.2: Global Smartphone Penetration. Manufacturer & Market Share [4].

flexibility, having device prices from $100 to $750, with stops at all price points in between.

As a result, Android competes with high-priced iPhones in post-paid markets and with lower- cost Nokia and Samsung devices in pre-paid markets. Such pricing versatility has majorly con- tributed to Android’s rapid growth.

1.2.2 Development costs and Licenses

Android is an open source stack for the development of mobile applications with the Apache Soft- ware License 2.0 ¹ and, as such, there is no fee associated with the creation of an enterprise business on top of Google’s mobile operating system (considering the development of native applications with the Android SDK). On the other side, Apple offers a paid solution for iOS which costs, at least, $99 per year. Although Apple offers much more documentation and support, much of it is also paid and since the Android environment is getting bigger and more stable over the years it is also becoming a potential and appealing choice for companies that wish to use the benefits of mobile applications in their core businesses.

¹ http://www.apache.org/licenses/LICENSE-2.0.html

5

1.2.3

Needed Skill Set

To develop applications in the Android environment it is necessary to use the Java ² program- ming language which has an open source General Public License ³ . For the iOS, a developer uses Objective-C ⁴ in order to implement mobile applications and is restricted to the Apple environment. Since software development skills are hard to acquire and maintain, those skills represent an ad- ditional cost for companies who want to have Objective-C developers in their teams and also due to the very small usage of this programming language outside the Apple environment ⁵ , Android also wins by having a free and also well supported development environment. It is critically important that a platform provides developers with efficient tools for all stages of application development, from writing code, to publishing and distribution. Different platforms have varying degrees of success in this area, and their success is reflected in the health of their ecosystems. Moreover, developers need to master new tools every time they switch to a new plat- form. As mentioned before, Android has the benefit of using a well-known general purpose pro- gramming language and environment.

1.3 The Relevance of an Integrated Environment

Although all the open source and proprietary development environments for the Android system of- fer a diverse and stable base for application developers – based on the ADT ⁶ – they lack the support for enterprise systems. Such corporate solutions are usually based on complex and distributed ap- plications, unlike the consumer ones, which are focused on the end-user, usually running within a closed environment defined only by the smart device (and, maybe, by a cloud-based service managed or attached only to a given user). The easier it is to begin developing for a given platform, the more developers will start creating applications and systems based on that platform. Apple excelled in lowering entry barriers with the iOS SDK, making it easy to install and integrate with the rest of the Apple environment, as- suming the cost of having Mac OS and Mac hardware and the cost of having a team of Objective-C developers is not a problem in the enterprise ecosystem. Android and Windows Phone also offer competitive development tools, but they typically require more complex experience and system integration skills which translates into more learning effort and investment for companies that want to start building their businesses in these platforms [4]. Rich APIs save developers and, consequently, companies lots of time and funds. The less code developers have to write, the less code they have to debug and maintain and less money is wasted by their employees in the overall budget for mobile application development. Among mobile develop- ment platforms, iOS and Android offer the most feature-rich and flexible API frameworks. The iOS

² http://www.oracle.com/us/technologies/java/index.html

³ http://www.gnu.org/licenses/gpl-2.0.html

⁴ http://www.otierney.net/objective-c.html

⁵ http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

⁶ http://developer.android.com/sdk/installing.html

6

Figure 1.3: Strong Network Effects for Android and iOS [4].

Figure 1.4: Weak Network Effects for Symbian, BlackBerry and Windows Phone [4].

application framework is derived from the proven Mac OS API, and excels in UI-related areas [5]. Compared to Android, however, it is less flexible and more restrictive since it is locked to the costly Apple environment, as explained in Section 1.2.2.

The more integrated a platform for mobile development is, the more it will positively feedback the system in order to keep the ecosystem growing. Considering that the major metric for plat- form integration and attractiveness can be defined with the number of native applications in an ecosystem versus the number of device shipments [4] in what VisionMobile calls “Mobile Network

7

Effect”, it is possible to see that both Android and iOS have strong network effects (Figure 1.3) while other platforms such as Symbian and BlackBerry, or even Windows Phone, can not seem to start a positive feedback system (Figure 1.4). This means that the growing of Android and iOS device shipments is accompanied with the increase of native applications in the markets, with no explicit signs of a decrease in the network effect rate.

1.4 The Enterprise Context

There are different alternatives for the development of Android applications, described in detail in Chapter 2, and the great built-in features of the Android SDK provide immense flexibility and opportunity to develop mobile applications. However, its target was never the enterprise world, but rather the closed mobile environments in the consumer segment (as stated in the official an- nouncement of the Open Handset Alliance and the Android system by Google, in May 2007 [8]). At the time Android appeared, Symbian-based systems were dominating the smartphone usage, while Microsoft’s Windows Mobile platform (now discontinued) and RIM’s BlackBerry were growing and establishing – at that time – a stable position in the corporate environment.

Since the Android operating system is growing rapidly on the market and the hardware solu- tions that allow the deployment of the Android OS are much cheaper than other platforms, it is of the utmost importance to reduce the difficulties of developing corporate mobile applications using this platform.

1.5 Purpose and Goals

The solution to be developed in this project has the goal of addressing several unresolved issues and create a development environment suitable for the development of corporate mobile applications based on the Android system. For an application to correctly support enterprise business processes it must be developed with an integrated environment that facilitates the usage of distinct and diverse tools to manage all the heterogeneity that is inherent to mobile computing.

The motivation behind this project is the fact that there are no mobile development environ- ments with the above mentioned tools and SmartAndroid represents a novel approach to the cre- ation of mobile corporate solutions in an integrated way.

Taking into account the analysis done during the course of this work, this document presents an integrated solution to minimize the overhead of creating Android applications for corporate environments, avoiding the integration of different libraries to the development process and thus, reducing the hindrance of managing different tools for the creation of an integrated enterprise solution.

8

1.6

Contributions

This thesis is focused on a group of additions to the Android SDK in order to provide enterprise level developers with an integrated environment to create mobile applications for the Android ecosystem. With this in mind, the main contributions of this thesis can be listed as follows:

• A brief survey of all the major mobile ecosystems and some related work in the area of mobile application development;

• Discussion and analysis of some of the Android SDK design issues;

• A new communication API with a more integrated and modular design, when compared with the Android SDK. This helps managing different types of communication strategies and tech- nologies in a more easy and adjustable way. This also provides a standard and uniform way of interacting with the system capabilities. Hiding what is considered to slow down the develop- ment process and creating new abstraction concepts to change the way the developer creates applications that operate in heterogeneous environments;

• The introduction of an “Application Domain” to the Android development process. This greatly eases the development of applications that deal with data persistency by adding an extra layer of functionality that isolates database access code and business logic code. All this is done without the need of extra languages or scripts to define the domain model. This Data Access Layer (DAL) is constructed in development time, to permit the developer to add new functionality and domain services above the domain layer;

• The capability for Object Relational Mapping (ORM) in the local SQLite database of the An- droid system through the implementation of an additional layer with the Active Record design pattern. This allows the developer to access the persisted data without leaving the object- oriented environment;

• The provisioning of the Android development environment with Aspect-Oriented Program- ming (AOP) primitives to allow the development of applications in a more high level fashion;

• An approach to the application update management process that allows an application to check online for a given update or feature and install it on the system, in an integrated way with the rest of the SmartAndroid primitives;

• An Eclipse plugin to integrate (i) the SmartAndroid API, (ii) AOP features, (iii) Domain Gen- eration, (iv) Annotation Processing and (v) database abstraction without the need for cumber- some configuration routines by the developer.

9

1.7

Document Structure

The remainder of this document is organized as follows:

Chapter 2 describes the related work associated with already existing software frameworks for mobile application development, covering two major areas: native and cross-platform development. Also in this chapter, it is presented a brief discussion for the state of the art related with this thesis. In Chapter 3, the system requirements and specifications for the architecture and functionality are presented. It is also presented the system’s implementation strategies, including the several modules of the development library and the Eclipse plugin. Chapter 4 presents and analyzes the defined benchmarks for the SmartAndroid development library. Within Chapter 5 some proposals and directions for future work will be discussed, for the area of mobile application frameworks and, specifically, for the SmartAndroid environment. This chapter also provides an overview of the major challenges and problems that occurred during the work done for the project. Finally, it also presents some concluding remarks for the work completed in this thesis.

10

2

Related Work

This chapter surveys relevant contributions to the area of mobile application development. To better analyze those contributions, the chapter is divided into four sections.

The first one describes and compares the different possible approaches when developing mobile applications: Native, Hybrid and Web-based development. It is important to define the mentioned mobile development strategies, since every analyzed platform, presented in the following sections, are based on one of those approaches.

The second section holds a brief enumeration and study of some relevant concepts used through- out the rest of the document. These concepts are useful to better understand the modules of the SmartAndroid framework.

The third section examines the native mobile development environments (NDE) for three of the most used mobile operating systems and the fourth section covers three major cross-platform development environments (XDE) from many different vendors and companies.

Some of them are open-source, others are paid options, but all these platforms offer an envi- ronment to develop applications to mobile operating systems with only one (XDE) or more (NDE) development cycles. When discussing both environments, the comparison will be normalized into several points of interest:

1. General Data: Statistic facts and information about the platform;

2. Positioning: Analyses the main target of the platform;

3. Adoption: Covers how the platform is being used by the applications;

4. Technological Foundations: Checks which technologies are used by the platform;

5. Development: Covers how applications are developed under the platform;

The last section of this chapter presents some comments and an overall analysis of all the con- cepts and systems in a general and global point of view.

11

2.1

Related Concepts

Examples presented in this section assume some degree of familiarity with (i) object-oriented de- sign, (ii) the OSI model and (iii) simple relational database operations. However, the needed con- cepts, which are based on those three knowledge areas, are described in a sufficient detailed way so that it is possible to understand the definitions and constructs related to the SmartAndroid environment.

2.1.1 Data Serialization

There are several situations where data serialization can be, or must be, used. Just to name a few examples, one may need need to use serialization techniques when dealing with relational or object oriented databases or when sending/receiving data across the network. Although this thesis relates to both mentioned cases, we only deal directly with data serialization in the latter scenario.

sending messages

Application

A

011010

011010

100110

100110

011000

011000

serialization

Network

011010

011010

100110

100110

011000

011000

serialization

Application

B

receiving messages

Figure 2.1: Simple schematic of sending/receiving serialized data through the network.

Robert Greene, responsible for the open source operations of Versant, vendor of object-oriented database systems, proposes a simple definition for data serialization, which is, in fact, the most commonly used definition: it is the process of converting a data structure into a sequence of binary data representation with a pre-defined configuration so that it can be stored or transmitted in a network [9]. A typical scenario of sending/receiving messages with serialization is depicted in Figure 2.1.

Since serialization occurs on both sides of the communication process, both applications need to run the same serialization procedures in order to deconstruct and reconstruct the data. There are two main representations of serialized data, the first of which is XML (eXtensible Markup Language) and the other JSON (JavaScript Object Notation).

12

As two different approaches to data serialization formats, they are used in different situations. While developing a way to serialize data locally in a device can lead the developer to relax the choices related to the format in which to save the application objects, when dealing with data trans- mission across the network, the problem of data size and the time taken by the transaction to occur may force the developer to choose, among all formats, the one with the best size/efficiency ratio. Thus, some of the main considerations to take in mind when choosing XML or JSON are described below.

XML and JSON: Simple Comparison

In the XML textual represented format (example in Listing 2.1), all data is stored in one tag closed strictly with indexing labels. The specification of XML ensure, by forcing this kind of data structure, good defense against data corruption, since when a node has a broken starting or ending tag, the serialization process can report and error.

The strongly-structured syntax also allows for complex object definitions or web-service con- tracts to be created and exchanged without end-to-end misinterpretations. However, this fact is also one of its main drawbacks. When dealing with XML objects, the application must parse it as a DOM object (Document Object Model) which leads to high latency due to the bloated, dense and redundant structure, and this can slow web applications that require speed both in the client and server side [10].

Listing 2.1: Example of an XML document

1	<?xml version="1.0"	encoding="UTF-8"?>
2	<contacts>
3	<contact>
4	<name>Jack Sparrow</name>
5	<phone>123-532-5392</phone>
6	<work>actor</work>
7	</contact>
8	<contact>
9
10	</contact>
11	</contacts>

On the other side, the IETF describes JSON in its RFC4627 as a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Program- ming Language Standard and defines a small set of formatting rules for the portable representation of structured data [11].

JSON’s appeal comes from smaller HTTP messages and less complicated syntax, which can pro- vide a significant performance advantage over XML. As a result, JSON is popular for rich Internet applications, essentially AJAX applications, and mobile applications that need to communicate with minimum overhead.

13

JSON has several major benefits, as described in the OpenEdge documentation [12], with an example in Listing 2.2, which are:

1. Self-describing syntax: can be interpreted by applications as a string;

2. Textual Representation: easy to debug and transfer as a byte array between applications;

3. Compact: An average JSON string is about two thirds of the size of the same data in XML;

Listing 2.2: Example of a JSON document

1	{	"contacts":	{
2		"contact":	{
3		"name":	"Jack Sparrow",
4		"phone":	"123-532-5392",
5		"work":	"actor"	}	}	}

2.1.2 Remote Communication API

When developing an abstraction for remote communication in applications that use the Berkeley socket system (POSIX sockets), that abstraction must use the concepts behind the OSI model in- frastructure. A layered protocol architecture, such as the OSI model [13], has useful implications for object-oriented applications. Layers are commonly interpreted as independent entities with in- ternal state that delegate actions upon the lower layers and act as a service provider to the upper layers. Much work has been done in the area of high-level and general purpose communication proto- cols that rely upon the lower OSI levels and primitives, such as sockets, timers and byte buffers, to construct modular protocol instances that could be deployed, virtually, in any object-oriented system. Some of this research was done by Falcone [14] and Holzmann [15] that proposed, in- dependently, extensible sub-systems in which communication protocols could be downloaded from protocol servers. Relying on such object-oriented protocols can have an impact on performance as well as improve expressiveness and modularity of the protocol itself, when compared with low-level examples. Be- sides all the study in these kind of abstraction layers, there are few researches that focus and examine the performance gain (or penalty) associated with the object orientation of this protocols. A study that points in this direction was done by Calvert et al. [16], where the authors found and analyzed that constructing such protocols can lead to a lower performance when compared with low-level socket programming. Nonetheless, choosing the architecture of the communication proto- col is an important design factor to keep up with when developing corporate applications that can scale to a rather complex system that must be maintained and eventually extended in the future. Figure 2.2 exemplifies the OSI model with simple layer-to-layer interactions, that greatly ben- efits and resembles an object-oriented system, where objects encapsulate their own behavior and

14

Upper

Layers

Lower

Layers

Application

Presentation

Session

Transport

Network

Data Link

Physical

(N)-service.request

(N)-service.indication

(N+1)-layer

(N)-SAP

(N)-SAP

(N)-SDU

(N)-protocol

(N)-layer

(N)-entity

(N)-entity

(N)-PDUs

(N-1)-SAP

(N-1)-SAP

(N-1)-SDU

(N-1)-protoco1

(N-1)-entity

(N-1)-layer

(N-1)-entity

(N-1)-PDUs

Figure 2.2: Simple interaction structure for the OSI model [17]. In the left side it is highlighted the separation between upper and lower layers of the model. In the right side it is possible to see the layer-to-layer interaction and the exchange of PDUs (Protocol Data Units) between SAPs (Service Access points).

interact with each other in order to orchestrate their unique components and methods to achieve a

more complex output. In the left side of the figure it is represented the complete OSI model with the

three upper layers separated from the four lower ones. The primary function of the lower layers is

to provide end-to-end delivery of data, subject to quality of service requirements (e.g: reliable data

service transmission – TCP – or connectionless transmissions – UDP). The distinction between the

upper and lower layers is relevant from the perspective that the lower layers are commonly imple-

mented in the operating system and hardware while the upper layers are created in the application

domain.

Object-Oriented

Application Infrastructure

ISO/CCITT

Upper Layer Protocols

RPC

Protocol

Transport Switch

ISO/CCITT

Internet

Lower Layer

Protocols

Protocols

Various

Subnetwork Technologies

Figure 2.3: Generic communication protocol with several sub-protocol layers [17].

Based on the OSI concepts it is possible to devise a generic protocol stack with explicit separation

between different kinds of transport sub-protocols and network layers (Figure 2.3). This stack

15

can be accessed through an object-oriented API in order to maintain the modularization and code expressiveness requirement.

One of the most interesting layer of this generic protocol stack, proposed by Tomlinson et al. in 1992, depicts a Transport Layer Switch that is not part of the standard OSI model. The concept behind this extra layer was first introduced by Rose et al. in the year of 1986 where they describe it as “a protocol entity that addresses, in an elegant manner, the pragmatic issue of simultane- ously using many underlying transport services arising from different transport/network protocol combinations” [18].

Different protocol combinations may be required due to the varying characteristics of different network technologies and the primary function of the switch layer is to map transport service re- quests (represented as SDUs in Figure 2.2) made by an upper layer, such as the OSI session service, into some instance of an OSI transport service. Thus, the switch must present, to the transport- dependent upper layers, a single and consistent transport abstraction corresponding to the specific transport mechanism and respective implementation. This feature can be easily created using sub- typing (inheritance) in an object-oriented framework.

2.1.3 Expressing the application Domain Model

When creating extensive applications, whether mobile or not, the development process can greatly benefit from the implementation of good software engineering practices in terms of domain encap- sulation. An application domain is, simply put, the collection of all the objects that represent a real World entity. The application also deals with those entities and builds its business logic around them.

By doing this, and if the model makes sense from the point of view of a user that is familiar with the domain, and if it can serve as a basis for implementing the systems, it is said that the applica- tion is related with a “Model-driven approach”. This model allows the isolation of the application sections of the application that deal with data persistency and domain services from the business logic of the application, thus reducing validation and debugging efforts.

The state of the art relating to model-driven development and domain management is vast, however the main contributions and references that were considered in this document came from (i) Cachopo’s PhD thesis about rich domain models [19], (ii) Mannadiar et al. [20] where the au- thors studied the synthesis of mobile device applications from domain-specific models and, still, (iii) the work from Kramer et al. [21] where it is proposed a domain specific environment for mobile applications.

Although, in some applications, the domain model may only exist theoretically in sketches to aid the development process, the cited works point several benefits associated with the translation be- tween those sketches and the application code, in some way. But regardless of the way of converting the model from sketch to code, it should have a constant presence in all the development process. Starting in the requirements assessment and going through the analysis and design phases and,

16

as such, this has influence in late phases of the process, such as the quality assurance and mainte- nance phases. Besides this, the problem of domain modeling and management was only considered

a fluent research topic in the eighties [19] and, from that point on, it is now common to argue the development process with the help of UML class diagrams that correspond to the domain model of the application.

In Cachopo’s work, he presents a way to define the domain model and, at the same time, reduce the gap between the model definition language and the programming language, being that the DML (Domain Modeling Language) presented has several resemblances with the Java programming lan- guage and, more generally, with object-oriented design to express relationships between domain objects.

Other concept for domain modeling can be integrated in a more broaden environment which is the creation of domain-specific models for a given application, where the domain, eventual configu- rations, documentation, executables and performance models are defined in an integrated way with the help of DSLs (Domain Specific Languages). The purpose was that even non-programmers would be able to refine the model and play an active role in the development process. This approach was taken by Mannadiar et al.

Similar to this work, is the assumption that a graphical interface to define the domain-specific model is the most correct approach to the problem and that tool would then generate a formal XML model with the domain contract. This contract would be parsed and domain-specific code would be generated and processed. This is the view of Kramer, Clark and Oussena, back in 2010.

2.1.4 DAL – Data Access Layer

When an application has a clear separation between the business logic and the ways through which

it accesses persisted data it is said that that application has a DAL (Data Access Layer) which is

isolated from the rest of the code. As argued before, code isolation brings great benefits in terms of feature modularization and code maintainability and, similar to the application domain issue, the data access methods with which the application uses the underlying database or persistency manager are a subject of academic study. This is due to the fact that also this layer of application development can be formalized in a generic way so that the guiding principles of the obtained solutions can be reused.

This re-usability can be achieved, again, with design patterns. In the work of Sohail et al. [22], the authors propose the use of two design patterns to establish a reusable DAL infrastructure:

(i) the Data Access Object and the (ii) Transfer Object Assembler. Both hide the database access complexity and offer the application means to persist the data objects in a generic way, although both have distinct implications in the software design and can present further issues depending on the kind of application being developed. If there is the need to change database handlers or even support multiple databases at the same time, it is easy to swap the handlers and keep the rest of the code intact.

17

Figure 2.4: “Table Data Gateway” design pattern [23].

Figure 2.5: “Row Data Gateway” design pattern [23].

Figure 2.6: “Active Record” design pattern [23].

Figure 2.7: “Data Mapper” design pattern [23].

Although these simple design patterns can solve the problem of data access layers, there are other literature elements on this topic, but with an enterprise overview. Fowler, in his book “Pat- terns of Enterprise Application Architecture” [23], discusses design patterns to solve many prob- lems that can rise when dealing with enterprise-level applications. Some of those problems are

18

the domain management and data access layers. For solving the latter problem, he references four design patterns: (i) Table Data Gateway, with an object that acts as a gateway to a database table. One instance handles all the rows in the table (Figure 2.4); (ii) Row Data Gateway, with an object that acts as a Gateway to a single record in a data source. There is one instance per row (Figure 2.5); (iii) Active Record, with an object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data (Figure 2.6) and (iv) Data Mapper, with a layer of Mappers that moves data between objects and a database while keeping them independent of each other and the mapper itself (Figure 2.7).

2.1.5 ORM – Object Relational Mapping

Given the popularity of relational data storage, and the ubiquitous use of object-oriented devel- opment, it is more common to store data objects in RDBMS (Relational Database Management Systems) than in OODBMS (Object-Oriented Database Management Systems). Due to the usage of this two paradigms, the interplay of objects and relations is not trivial, as there is a significant distance between the object-oriented and relational worlds. This distance is described by Smith and Zdonik as “object-relational impedance mismatch” [24] and its been a subject of academic research since 1987.

Object-Oriented Application System

Object Model &

Application Logic

API

Object-Relational

SQL

Relational

Middleware

Database

OR-Mapping Definition

Figure 2.8: Encapsulation of a RDBMS with an object-relational middleware.

To access a relational database from an object-oriented application, there are three approaches that can be enumerated as follows [25]: (i) to include SQL statements in the application code. This breaks abstraction layers and joins the business logic code with the persistency management code. This can be cumbersome in complex systems but has the advantage of being a fast approach when developing very small applications or prototypes; (ii) the encapsulation of SQL statements in the domain data classes, which is a better approach compared with the first one, but although this separates concerns, conforming with object-oriented principles, changes of the relational schema still leads to modifications of the application source code; (iii) the usage of a dedicated “middleware” that can decouple relational databases from object-oriented logic altogether (Figure 2.8). This mid- dleware would be configured with application-specific definitions and the domain model and would produce a thin layer of object-relational mapping between the database rows and the domain objects that are managed by the application. By using this approach, and if the database schema changes, only the mappings must be changed in order for the persistency management to work.

19

Fowler [23], also studied and references several design patterns that aid in the creation of such object-relational middleware layers. Some of the referenced patterns are as simple and straight- forward as the “Identity Field” and “Foreign Key Mapping” whose rational focus on the fact that all domain entity objects must have an identity field equal to the primary key of the corresponding database table and, the latter, that there must be a conversion between referenced foreign entities and their respective database tables.

Figure 2.9: “Unit of Work” design pattern [23].

Figure 2.10: “Identity Map” design pattern [23].

Other relevant design patterns for an ORM layer include the “Unit of Work” (Figure 2.9), “Iden- tity Map” (Figure 2.10) and “Inheritance Mapper”. The first helps maintaining a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems; the second ensures that each object gets loaded only once by keeping them in a map using it when referring to them; the last one handles type hierarchies when persisting extensions of domain entities. This keeps the relations intact when converting back the entities to domain objects regardless of the database structure that represents the inheritance relations.

2.2 Native, Web-based and Hybrid Development

Until mobile computing and smart devices became ubiquitous, native application development was the main strategy for creating applications for all major operating systems (Windows, Mac OS and Linux-based). Due to the fact that developers knew their target users and those operating systems

20

offered a stable base for development, this was a consistent strategy for companies wanting to dis- tribute their applications in more than one system. Applications would be rendered on monitors with fairly enough display area and resolution; they would also run on limited and known hard- ware infrastructures or use virtual machines for heterogeneity abstraction (like the Java Virtual Machine), so the developer would not have the need to worry about these specifications, in most situations.

Over the years, and since the environments where the applications run became more and more heterogeneous, not only in terms of communication or running devices but also in the way the applications are created, other strategies were created to deal with all this complexity.

2.2.1 Native Development

When an application is developed natively it will run only in a target operating system and hard- ware, with a designated programming language and this kind of applications. In the case of mobile devices, they make use of all the device’s features [26, 27], such as mobile phone cameras or geolo- cation through GPS systems. Also they use resources more effective and efficiently because they were designed for that specific device and they can use the distribution channels targeted for that device.

2.2.2 Web-based Development

Due to the fact that mobile devices have become ubiquitous, application development changed in such a way that it is not feasible to create native applications for every mobile operating system anymore. Nowadays, there are a total of fourteen mobile platforms, as seen on Figure 2.11 [28], and each of them has a specific development process with different programming languages, features and running hardware with different architectures. Knowing that companies want their applica- tions and businesses to reach as many users as possible, the cost associated to the maintenance of a development team with the necessary skill set for creating applications in all platforms represents a big weight to software companies. They are not willing to waste resources in the management of every single update and development cycle, and thus another approach for application development gained focus. That approach makes use of web technologies, namely HTML with Javascript and CSS, and it is referred to as web-based development [27].

This approach reduces the overhead of implementing an application for every mobile OS be- cause, since one of the goals of mobile devices was to allow the users to be connected at every moment on the go, all of them have a web-browser with Javascript rendering capabilities. This greatly reduced the skill set and technologies needed to create an application for all the mobile operating systems.

21

Figure 2.11: The history and life spans of the 22 major Mobile Operating Systems. The lifespan is bounded by the dates of public announcements of start and end of development efforts by the platform owner. It does not include times when products are still in the market or the platform is still supported [28].

2.2.3 Hybrid Development

Although the introduction of the web-based approach has streamlined the development of compat-

ible applications in all mobile operating systems, there was still an adaptation problem with these

web-based applications [27]. They cannot access the device’s hardware because they run on a web-

browser and, because of software security policies, they cannot access the device’s file system too. As

such, these applications are limited and may not be suitable to fully support corporate businesses.

To increase the effectiveness of web-based approaches, for the development of mobile applica-

tions, another development strategy was devised that allows an application to be supported on web

technologies and still access the device hardware. This new approach is referred to as Hybrid de-

22

velopment and consists in embedding HTML, Javascript and CSS code in a native application. By using this native application, that functions as a proxy to access the device’s hardware, and web technologies to render the interface and logic of the applications, developers can create an abstrac- tion layer to the devices’ heterogeneity [29]. This also allows companies to obtain all the benefits of native applications while ensuring the longevity associated with well-established web technologies. There is, nonetheless, a problem associated with applications based on hybrid development.

These applications are based on frameworks that use the device native development capabilities and present an abstraction to the developer. If a mobile device and operating system are upgraded and start presenting new APIs or features to the applications, these hybrid frameworks may take a lot of time to integrate these new assets, or may never integrate them at all, and the applications developed in this fashion, that may benefit from the use of the new features, will never be updated because of the abstraction layer that stays between the application and the mobile operating system native development tools. Because of this, corporate businesses that happen to be supported by this kind of approach will always have a delay in terms of receiving platform updates that are readily available to applications developed with the native approach.

2.3 NDE – Native Development Environments

Every mobile operating system has its own development environment. Those environments are native to each mobile OS and present a framework for developers to create applications that use the device’s full potential. Next, are presented the native development environments for the three mobile operating systems with more market share, according to Gartner [3].

2.3.1 Android, Google Inc.

This mobile platform was firstly presented in 2007 by Andy Rubin, director for mobile platforms at Google, as the first truly open and comprehensive platform for mobile devices [8]. It includes an operating system, user-interface and applications, without the proprietary obstacles that have hindered mobile innovation. It was the acquisition of Android Inc. that provided Google with the code for this mobile operating system. In the developer’s perspective, it is a software stack for mobile devices that includes an operating system, middleware and key applications. The Android SDK provides the tools and APIs necessary to develop applications on the Android platform using the Java programming language.

Google has tight control over the platform development, including roadmap planning and code commit decisions. Only Google employees are allowed to commit code to the main software branch and newer versions of the OS are only shared with a small number of handset vendors. The pace of Android development sets a new standard in the telecom industry, with four to five version releases each year, standing out from the competition (iOS) which evolves at a more measured pace.

23

Positioning

According to Gartner’s survey, resumed in the Table 1.1 (on page 2), Android will have a mar- ket share of 49.2% by the end of 2012, being the most used mobile operating system worldwide, being positioned by Google as an open Internet platform, allowing unrestricted mobile access to Internet cloud services (including privileged access to Google’s). The initial versions of Android tar- geted smartphones, including high-end, mid-range and low-end devices. Android began expanding rapidly into tablets, TVs and set-top boxes in early 2011 [4]. The open source nature of this system has enabled numerous vendors to work on parallel ini- tiatives independently from Google. These initiatives have aimed to adapt Android for use in car entertainment systems, DECT handsets, video conferencing terminals, embedded devices and other consumer electronic products. Due to these facts, Android devices manufacturing escalated, scaling across a range of, mostly ARM-based, application processors, including low-end 528MHz processors to ARM Cortex 1.2GHz dual core processors at the high-end. All the sales from these devices do not bring revenue to Google. Android is monetized indirectly through search-driven ads served to Android devices.

Adoption

Google has successfully created a broad and diverse ecosystem of Android handset and tablet mak- ers. In May 2011, Google announced at the Google IO conference there were 310 Android device models from all the registered manufacturers in the Open Handset Alliance, in 112 countries [4]. Android found its initial success in the North American market. Its high rate of adoption there was influenced by string support from top US carrier Verizon Wireless, as well as the wide prolifer- ation of Internet services and broad deployment of 3G data services. After the initial debut in the USA, it gained popularity in Western Europe mostly, and is growing in Asia and Latin America.

Technological Foundations

The system architecture [30] of the latest major Android version, from October 2011, is summarized in the list bellow and can be visualized with more detail in Figure 2.12.

• Linux Kernel 2.6 to function as an hardware abstraction layer, containing device drivers to interact with specific hardware;

• Native Runtime libraries with graphics rendering, database, security and other compo- nents to support the Android framework;

• Android Runtime, containing both the Dalvik Virtual Machine to run the applications and the framework’s core libraries;

• Application Framework, written in Java, containing functionalities to be used by the ap- plications.

24

Figure 2.12: Major components of the Android system architecture [30].

Development

Android applications run in a sandbox environment, each one of them with a non-shareable process running an instance of the virtual machine, which prevents the application from accessing other application’s resources or interfering with the operating system’s normal behaviour. This sand- box enforces fixed-solution policies for the execution of mobile application’s code and represents a security measure to give the applications a more stable running environment [31].

The custom Linux kernel of the Android system is licensed with the GNU General Public License 2.0 and the remaining of the platform is released under the Apache License 2.0, and even though the platform is open source, manufacturers can not use the Android trademark or integrate the official Android Market into the devices unless they satisfy Google’s Compatibility Definition Document, with no charges associated with the process.

For the creation of Android applications, Google released the Android Development Tools ¹ , which consists of a program and a plugin for the Eclipse IDE ² , extending its capabilities for setting up An- droid projects, creating user interfaces for the applications, debugging code with integration of the Android SDK and generating Android executable files for application’s distribution. Included in the SDK is a mobile device emulator with the Android system installed, compatible with Windows, Mac

¹ http://developer.android.com/guide/developing/tools/adt.html

² http://www.eclipse.org/

25

OS and Linux distributions, that lets the developer test the applications, from a user’s perspective, without a physical device.

When the application is deployed, and since the Android system runs in a Linux environment,

it is assigned a unique Linux user ID to the application and permissions are created so that the

application’s files can only be accessed by the application’s user ID. Regarding the execution cycle of the applications, the system uses the principle of the “least privilege” which forces the developer to define in compile time the kinds of privileges an application needs from the system to run properly. This principle limits the damage that results from an error, bad application design or even security flaws in the application’s code. This was described and detailed, by Saltzer and Schroeder [32], as the best approach if a question arises related to the bad usage of a privilege, since the number of programs or procedures that must be checked is minimized.

Although there are limitations that applications need to comply with, in the Android system all applications reside in the same level [33, 34], even the core system applications, as seen in the top level of the diagram from Figure 2.12. This means that a developer can override a system application, such as the application responsible for tuning the system’s settings, as long as the new application maintains the same interface for the events that would be delivered to the replaced one.

2.3.2 iOS, Apple Inc.

The operating system for Apple’s mobile devices was firstly released on the iPhone in June 2007 and, in its early stages, was closed to third-party applications. Only in March 2008 the develop- ment kit for the iOS was released, namely the iPhone OS SDK, as it was called at the time. This mobile operating system is a branch of Mac OS, which is based in the Darwin ³ foundation, an open source operating system released by Apple in 2000, and is therefore a Unix-like operating system. However, it has a proprietary license as an integrated system.

Apple makes most of its revenues and profits selling iPhone, iPad and iPod devices at a premium price. The unprecedented success of the products helped Apple become the World’s second-richest public company, behind only Exxon Mobil [4].

Positioning

Gartner states that by the end of 2012, iOS will have a total of 18.9% of worldwide market share, down from 19.4% in 2011 [3], and although its market position is stabilizing it is also based on

a solid hardware platform, with limited device choices and all controlled by Apple as the only

manufacturer and current iOS versions target high-end mobile devices, with string emphasis on

multimedia and gamming.

³ http://darwinbuild.macosforge.org/

26

Adoption

Since iOS devices are only produced by Apple, the adoption scenario can only be analyzed in the operators and carriers that sell iOS devices. In this area, AT&T had an exclusivity agreement with Apple in the USA, and was the only USA mobile operator to offer the device. In February 2011, Apple introduced iPhone 4 versions supporting CDMA networks and, as such, Verizon entered the operator’s market share competition. In European countries, regulators prevented such exclusivity agreements and the iPhone was offered by multiple operators. These operators offered, associated with iOS products, long-term subscriptions and premium data plans that increase the average revenue per user, taking a hit on device costs.

Technological Foundations

Like other operating systems, iOS mediates the interactions of applications with the underlying operating system and its architecture [35, 36, 37], represented in graphical form in Figure 2.13, is summarized as follows:

• Cocoa Touch defines the application’s infrastructure and support for multitasking, touch- based input, data protection, notifications and other high-level system services. This layer functions as a wrapper to the lower level system layers, presenting an Objective-C interface for the system hardware and software services;

• Media Layer contains Objective-C and C libraries for applications to make use of the device’s graphics, audio, and video technologies;

• Core Services is the layer that contains interfaces for access to the file system, the socket’s API, SQLite database management, task management, address book framework and other system-related functions;

• Core OS contains the low-level features that the other operating system technologies are built upon. It presents interfaces for image processing, acceleration processes, external accessory management, security API and other memory-related interfaces.

Development

Concerning the development environment for iOS applications, Apple offers native tools to aid in the creation process. System interfaces are delivered in packages called “frameworks” which are linked, as a normal code library, in the application. The SDK includes the Xcode ⁴ IDE to man- age and create applications, a debugging and runtime analysis tool called “Instruments”, an iOS simulator which is an emulator-like application used to test the applications in their native envi- ronment and the iOS Developer Library which has the documentation created by Apple regarding the creation of iOS applications [37, 38].

⁴ http://developer.apple.com/tools/xcode

27

Figure 2.13: The hierarchical layers of the iOS framework [36].

Although Apple offers a much more complete development environment, compared to Google’s Android platform, the iOS developer programs, encompassing official forum support, distribution with the official application store, and access to the newer versions of the SDK, are paid solutions, not counting with the University program which is free up to 200 students and it doesn’t have any application distribution option. The Developer Program costs $99 per year and only the Enterprise Program, costing $299 per year, has an “in-house” distribution option [38].

Figure 2.14: Sandbox for an iOS application. Source: http://developer.apple.com/.

When deploying to iOS, an application will run in a “sandbox”, just like the Android system, although with a different approach in terms of system limitations. There is no notion of application- level permissions (like the Android permissions which must be defined in each application in com- pile time), and the sandbox created for these applications restricts those applications to a set of folders in which they are allowed to store and manage its files and resources [38], as shown in Fig- ure 2.14. One other restriction regarding third-party applications is that those applications can’t replace system applications like the browser or the contacts management application, this being one other difference when comparing iOS and the Android system.

28

2.3.3

BlackBerry OS, RIM – Research In Motion

RIM was founded in 1984 and, in the 90s, when e-mail usage was becoming mainstream, the founders of Research In Motion decided to create an Internet enabled device for users to check and send e-mail messages. Later, in 1999, RIM released the first BlackBerry device, with more modern communication technologies, such as GPRS (General Packet Radio Service), and also sup- port for Java applications, and its first adopters were businessmen, whose work was starting to be increasingly dependent on e-mail and remote communications [37, 39].

Positioning

BlackBerry devices were the first fully featured smartphones to be introduced in the enterprise environment, with relatively great expression. And although BlackBerry is becoming less present on the market, Gartner predicts, for this operating system, a share of 12.6% by the end of 2012 [3]. From the company’s revenue 73% comes from hardware and 24% from services and software [4].

Adoption

This system is only used by RIM devices and is not licensed to other manufacturers. The majority of BlackBerry sales come from the North American market with traditionally string support from Verizon Wireless. Unique to this mobile platform is its enterprise support. Through the BlackBerry Enterprise Server, deployed and controlled by the company, it is possible to configure the employee’s devices so that IT policies can be enforced in a more transparent way. This kind of integrated corporate features helped this mobile operating system to stand as the preferred platform for enterprise users, despite the price of some of the newer devices [4].

Technological Foundations

This operating system is a proprietary and closed source solution and is developed in Java ME (Java Micro Edition). The virtual machine runs the operating system and it is impossible for developers to install or run other applications than those natively developed with Java ME [40], which is a different approach when compared to the Android system which allows the installation of C/C++ applications that run on top of the Linux operating system. When creating applications, developers are presented with a platform’s architecture with four layers (Figure 2.15) described as follows:

• Application Layer is where the applications are installed and represents the user space where he interacts with his data;

• Libraries Layer There are three kinds of libraries which can be accessed by applications and the first two are defined as Oracle standards for Java ME applications: (i) CLDC which stands for Connected Limited Device Configuration, represents a specification targeted at devices

29

with limited resources and capabilities, including streamlined versions of Java ME libraries; (ii) MIDP stands for Mobile Information Device Profile and builds on top of CLDC libraries and is targeted for more powerful embedded devices, such as smartphones. These applications have access to more libraries of the Java ME and applications adhering to this standard are called MIDlets. It is possible to run MIDlets in every device which implements the MIDP specification and BlackBerry is one of those devices; (iii) when developing applications for RIM’s operating system, the developer may also use BlackBerry’s specific APIs, breaking the compatibility standards of MIDlets but acessing the BlackBerry device’s full features;

• Java Virtual Machine isolates the applications from the closed operating system and gives the base for BlackBerry’s APIs and also for the Java ME specifications;

• BlackBerry Operating System supports the drivers for specific BlackBerry devices and is closed to the applications. They can not access it with native libraries or other low-level APIs.

Figure 2.15: The BlackBerry Operating System architecture [41].

Development

To develop applications for the BlackBerry OS, developers have two choices over the development environment: (i) the BlackBerry JDE (Java Development Environment) and (ii) the BlackBerry plu- gin for Eclipse. There are no differences in the applications created with these two approaches but the versions of the development environment must be selected carefully since BlackBerry supports backward-compatibility through emulation in a restricted environment and in some OS versions, applications will not behave correctly if developed in an older JDE. This characteristic is also dif- ferent from other solutions already analysed, such as the Android OS, that allows every application developed for an older version of the system to run without limitations due to full backward compat- ibility. If there is the need, while creating the application, to load the applications onto a BlackBerry device, it is necessary to use the Blackberry Desktop Manager, a Windows software, to connect the device to the development environment [39]. This fact limits support for the full development cycle

30

to the Windows platform. A similar approach when compared to the iOS development, as previously discussed.

There are other limitations in the development environment for the BlackBerry OS, such as the blocking of some specific APIs, such as the persistent storage, cryptography and the embeddable web browser, or even the automatic start feature if the developer does not associate a pair of code signing keys, that cost $20 each, with the JDE [37, 39].

Since the release of BlackBerry Tablet OS, in April 2011, RIM started to support cross-compiled Android applications, which behave normally and run with all the functionality – according to RIM’s official website, C/C++ applications and HTML5 web applications. This is an expressive response to the decreasing of BlackBerry’s market value over the years and the increasing of tablet devices on the market. With the introduction of web development in the BlackBerry environment it is now possible, since BlackBerry 7.0, to create applications compatible with both the smartphone and tablet operating systems from RIM.

As with the other analysed operating systems, BlackBerry also has security policies that devel- opers and administrators can attach to applications so that they can not access specific features or capabilities of the device [41]. These application control policies are segmented into three areas: (i) Connectivity and Communication, (ii) Third-party APIs with default access, such as Bluetooth API and Phone API, and (iii) Third-party APIs without default access, such as Events API and Browser API.

2.4 XDE – Cross-Platform Development Environments

The escalation in the number of devices and mobile platforms was also accompanied by the increase in the number of cross-platform development environments for those devices [26], due to the diffi- culty associated with creating applications for every mobile platform. This subsection will present three frameworks for the development of hybrid applications (described in Section 2.2) across dif- ferent mobile operating systems.

2.4.1 Rhodes, RhoMobile

Founded in 2008, RhoMobile provides Rhodes, a development and deployment tool for creating enterprise applications for all major smartphone platforms. RhoMobile was venture-capital backed by VSpring Capital and Alta Ventures. The company was acquired by Motorola Solutions (the non- mobile, enterprise and government oriented division not acquired by Google in July 2011), who have continued developing and supporting the products [42]. Since Rhodes generates native applications with an hybrid approach, application executables generated with this framework can be deployed to any device with that device’s platform specific distribution tools [37].

31

Positioning

RhoMobile targets enterprise developers producing enterprise and B2B applications. On that basis, it is closely competing with web technology based solutions – such as Appcelerator. Ruby bytecode and the Virtual Machine should offer superior performance to hybrid applications rendered using the native browser. Rhodes covers all major smartphone platforms - iOS, Android, BlackBerry, Symbian and Windows Phone 7 - and offers a well-rounded suite of tools to integrate, deploy and manage enterprise systems. Rhodes requires knowledge of the Ruby language, although this comes with an easy learning curve that should appeal to web developers.

Adoption

RhoMobile reports that there have been over 100.000 unique downloads of Rhodes and hundreds of Rhodes-based applications on the Apple App Store. However it is difficult to assess the true user base of Rhodes given that the framework is open source and, under the permissive MIT license, allow liberal code re-use [42].

Technological Foundations

As an hybrid development platform, it offers means to create applications in HTML, CSS and Javascript but also with the Ruby programming language if the developer wants to integrate the applications with server-side features of RhoMobile or use the device’s hardware. Moreover, to al- low the integration with all platforms mentioned above, the tools for application development with Rhodes are available for Windows, Mac and Linux and is primarily targeted at enterprise applica- tions, lacking support for interactive-intensive applications such as games.

Development

Rhodes follows the MVC (Model-View-Controller) model, which is represented in Figure 2.16, to mediate the interactions between the controller and the view layer and also create data mappings in the model layer through an ORM tool present in Rhodes, named Rhom. This structure is therefore transposed to the native application and Rhodes and support multi-threading in the framework level, which means an application can not create threads. Rhodes generates three threads, one for managing the user interface, other for executing Ruby code (interacting with device features) and the last is for synchronizing data when needed [37].

2.4.2 PhoneGap, Adobe

PhoneGap, one of the most popular cross-platform development tools, has been maintained by Ni- tobi. The project was born at an iPhoneDevCamp event in 2008 as a way to use web development skills to deliver native apps. In 2009, PhoneGap won the Web 2.0 Expo LaunchPad competition, and the code was released under a permissive open source (MIT) license [42]. Following Adobe’s acquisition of Nitobi in October 2011, the project was renamed to Apache Cordova, and the code

32

Figure 2.16: The Rhodes MVC (Model-View-Controller) model [37].

contributed to the Apache Software Foundation. Partners and major contributors to the project include IBM, Sony Ericsson, Symbian, Palm, RIM and Sencha.

Positioning

PhoneGap’s spread across app categories is fairly standard, with enterprise apps dominating, and slightly elevated numbers of media apps (20% against an average of 13%) [42].

Adoption

By November 2011, Nitobi claimed 600,000 plus downloads of PhoneGap, and thousands of apps created with the SDK. Standouts include Netflix, LinkedIn and the Ars Technica Reader for iPad. Since pioneering the hybrid web app paradigm, PhoneGap has become a core component of many crossplatform tools, including AppMobi, BKRender, Feedhenry, The Unify Project and Worklight. However, alternative hybrid wrappers are beginning to appear, including those used by Sencha 2.0 and Antenna Mobility Studio. PhoneGap has been integrated with popular emulators, debuggers, game libraries, UI libraries (notably Sencha), persistence and testing libraries [42].

Technological Foundations

There are two major different aspects in PhoneGap not present in other frameworks. A positive aspect is that it is possible to convert an already existing web application to a native format with this XDE, only if the application follows PhoneGap limitations in terms of device usage. Doing this, a developer can insert the application in the platforms specific distribution channels. The other aspect is a downside of this framework, and derives from the inability to create cross-platform data- driven applications, such as enterprise applications, since it can not access the device’s data storage features in some of the native platforms it supports, for instance in the BlackBerry. Also another major goal of PhoneGap is the adherence to the W3C (World Wide Web Consortium) standards, namely the Device API and the HTML5 features even if they are still in development [43].

Development

PhoneGap does not force a specific structure in the applications developed with the framework, like the MVC pattern used in Rhodes applications, and exposes the device features, for every supported

33

device, with a Javascript API. The app payload comprises web code, the native wrapper plus an API bridge between the web code and the native platform.

2.4.3 Titanium Mobile, Appcelerator Inc.

Founded in 2006, Appcelerator is based in Mountain View, California. The core product, Titanium, provides an OS abstraction runtime and IDE, and was released in 2008 for PC, Mac and Linux. In 2009, Android and iOS were added. Appcelerator has taken an industry consolidation role through three recent acquisitions. It acquired Aptana in January 2011, gaining an Eclipse-based IDE with 1.6 million users. Particlecode was acquired in October 2011, in order to extend target platforms to the gaming and mobile web realms; web support is due out in the first half of 2012. Appcelerator also acquired Cocoafish in February 2012, with the aim of integrating a host of cloud based platform services, including storage, push notifications, messaging, user management and social integration connectors [42].

Positioning

Appcelerator is designed primarily for information-rich, interactive applications, rather than heavy graphic games. Our survey found that nearly twice as many Appcelerator developers target media, entertainment and education applications, on average. Appcelerator’s Titanium is currently geared towards web developers that create applications primarily for iPhone (97%) and Android (92%), followed by iPad (85%) and Android tablets (60%).

Adoption

Appcelerator reports that 35,000 applications have been published and deployed on 40 million de- vices. Appcelerator claims a developer client base of 250,000 mobile developers, and with the Ap- tana acquisition, an additional 1.6 million web developers. Appcelerator reports that 35,000 apps have been published and deployed on 40 million devices. Appcelerator claims a developer client base of 250,000 mobile developers, and with the Aptana acquisition, an additional 1.6 million web developers.

Technological Foundations

Although this platform supports less mobile operating systems, when compared to the other anal- ysed XDEs, it can cross-compile applications not only for mobile devices but also for Windows, Mac OS and Linux distributions. The Android and iOS APIs offered by Titanium are the most complete of the three XDE solutions analysed and, like PhoneGap, does not force a structure in the developed solutions while containing the most complete set of secondary features to aid the development of cross-platform applications, with free and paid options.

34

Figure 2.17: Titanium Mobile architecture (when developing an Android application) [34].

The high level architecture of Titanium is displayed on Figure 2.17. The most important aspects of the architecture are defined as follows: all the application resources (HTML, CSS and Javascript files) are kept inside the B1 block which represents the directory where the project files are stored; the B2 block represents the Titanium Developer IDE which is used to manage the project with the Appcelerator features (relation L1). This block holds native javascript (to access the device’s capabilities) that will be later accessed by the Javascript code in the application (relation L2); when the project is ready to deploy, the Titanium IDE compiles and builds the .apk file (relations L3 and L4). The final block B3 represents the Android device (the same applies for iOS devices) and the application uses the Webkit browser engine to render the application (relations L5, L6 and L7) [34].

2.5

Discussion

Besides the previously outlined solutions for the development of mobile applications, there are a lot more frameworks that were left out of this analysis due to reduced market share [3] or loss of relevance in the enterprise [2, 4]. Alongside the three analysed NDEs, there are also other fifteen native platforms, currently supported in the time frame from 2011 to 2012 (Figure 2.11), and also other twelve XDEs summarized and listed in the Appendix A. Beyond the capacity to create mobile applications, all these development environments use dif- ferent approaches. The NDEs differ mainly in the openness of the platform, ranging from total open source solutions like the Android OS to closed platforms such as the iOS, where there is no possi-

35

bility of customizing the operating system or adding new functionalities. The XDEs use the hybrid strategy for application development and, for the most part, they use HTML, CSS and Javascript as the development base. Some of the cross-platform environments enforce a structure in the appli- cation, like the MVC pattern described in the Rhodes framework, and others, instead of a defined application structure, offer a wide set of supported features that allow the developer to use more device capabilities (or less, depending on the platform).

Reviewing the previously analysed solutions, the major advantages of NDEs are application ef- ficiency and full support of the device’s features. On the other hand, it is impractical to develop a native application across every active device. The key benefit of XDEs is the possibility to cre- ate a mobile application with only one development cycle, that works on every supported device, but the main disadvantage of these frameworks is the slow pace with which they support new fea- tures when a new version of a given mobile OS is released, eventually slowing the adoption rate of security fixes.

The only characteristic that all these solutions share is the lack of an integrated set of features to support enterprise businesses, like those described in Section 1.5. There is also no integrated solution, even in the native environments, for customizing the operating system in which the appli- cations will be deployed.

Related to the concepts described in the Section 2.1, in what the serialization approaches are concerned, it is possible the observe the accelerated adoption of the JSON standard in the web com- munity, despite of XML being more semantically expressive. This is due to the simplicity, versatility and “economic” approach to data serialization and representation of JSON.

When dealing with communication protocols for high level frameworks, such as those that in- teract with protocol messages and complex relations between peers, it is more feasible to deal with message endpoints separated by abstraction layers. This approach helps the modularization of code logic and the debug process. Although these high-level communication frameworks are similar to the OSI model, they represent a performance penalty related to the overhead of layer internal states.

Expressing the application domain model in an abstracted and separated way from the rest of the code also simplifies the development process. While small applications may not benefit from this additional layer, enterprise-level ones can greatly have their development processes stream- lined and the semantic of the code increased when using a systematic approach to their domain models. The use of such domain models can lead, in a more direct way, to other simplifications such those related to the data access methods and the mapping of objects into relational entities, to be persisted in a database. These two other layers, DAL and ORM, greatly improve code readabil- ity and maintainability while abstracting the code from the cumbersome task of converting from domain objects to relational entities.

Combining a consistent domain model with a strong Data Access Layer and a solid mapping between code artifacts and database entities is a scenario greatly undervalued by the frameworks whose target is the creation of mobile applications, even for those who claim to build applications

36

with enterprise-level tools. The use of design patterns greatly eases the design of such abstraction layers. One example of such patterns in the data manipulation layer is the Active Record that gen- erates a lot of controversy among researchers and developers. This is due to the fact that in OOP the concept of encapsulation is often at odds with the concept of separation of concerns. Generally speaking, patterns that favor separation of concerns are more suitable to isolated unit tests while patterns that favor encapsulation have easier to use APIs. Active Record heavily favors encapsu- lation to the point where testing without a database is quite difficult. For this, it is sometimes considered an “anti-pattern”. Nonetheless, it simplifies code when compared with the Data Mapper pattern that uses a proxy class solely responsible for the basic CRUD operations (Create, Refresh, Update, Delete) while the data class itself is responsible for maintaining the business logic.

37

3

System Architecture and Implementation

This chapter discusses the developed framework for the SmartAndroid environment. Firstly, Sec- tions 3.1 through 3.3 present the specifications for the solution, including requirements, architec- tural and functional specifications. In Section 3.4, the development library is presented, including the framework issues and design strategies actually implemented

3.1 Requirements Specification

In order to design the entire system, some requirements were needed to be taken into account. By doing so, it helps to further define the frmaework’s scope. The criteria to ascertain some of them as being useful to this framework was related to the absence of tools that could actually fulfill those requirements in an integrated fashion. However, the rationale behind such criteria changed over the execution of this work. This is due to several factors, the most important being: (i) several Android API levels were released during the development process and (ii) more deep research was done proving that some of the initial requirements could be implemented by integrating one or more features already present in the standard Android SDK. Although the integration of those features could lead to some interesting work and unification effort, it was left out of the scope for the proposed approach.

When presented with the challenge of creating a corporate mobile application with the Android platform, a development team must find or create all the tools needed to support the mobile appli- cation and this represents an hindrance that slows the development cycle and forces the developers to waste time managing separate library versions and also other tools related to the process.

The following requirements were considered when creating the application. Those that were left for future work are referenced and a brief discussion, about the reasons for such decision, is done shortly after.

38

Device Heterogeneity Management

Since the middle of the last decade, mobile devices became more and more ubiquitous and the number of hardware vendors increased exponentially, resulting in a huge amount of smart devices. Those devices can be very different from each other, with different computational power, different interfaces and different approaches to I/O and peripheral interaction. Even when reducing the number of devices to those who run the Android operating system, the heterogeneity of all the de- vices represents a serious problem when creating a mobile application to be available in all those devices. Fortunately for Android developers, the latest version of the operating system, Android 4.0, released in October 2011 [33], minimizes this problem by allowing the developer to reuse mod- ules from a smartphone application into a tablet application and vice-versa in a transparent way, without changing the code base. This fairly reduces the heterogeneity created by the proliferation of devices and since the Android system is now provided with features to help reduce this problem, this goal is not in the scope of this thesis.

Communication Management

Mobile devices interact with a variety of different environments and systems. Applications that run on that device may need to communicate with such systems and they are presented with different methods to do so. This interaction and spontaneous inter-operation have major implications in software infrastructures, as described by Kindberg and Fox [44]. There are environments where Wi-Fi or 3G connection is available, but there are other situations where the device must interact with its environment by using Bluetooth or NFC (Near Field Communication). The management of all these communication methods or contracts can pose a difficult task to the developer. As such, a well supported IDE for these applications must deal with this heterogeneity and expose tools that can help the developer to manage and integrate all these communication diversity, as needed, into the application.

Data Access Layer and Object Relational Mapping

When creating a corporate application, the domain of that application can be as simple as a set of entities mapping the business process interactions or a complex system of relations between remote entities. All those entities and relations must be stored in a persistent database, being that the majority of these tasks are done with relational or object oriented databases. Dealing with low-level database access in such complex application domains can be a time-consuming task and, as such, there is a need to use a more high level tool like a DAL (Data Access Layer) framework to simplify the access to the data and the management of the relations between the entities. Furthermore, the use of high-level specification languages for modelling the application’s domain is encouraged by software engineering good practices in order to (i) reduce the number of errors, (ii) simplify the code and (iii) to use abstraction layers between the application domain and the application business logic [45]. Despite all the aforementioned assumptions and facts, there are no development

39

environments for mobile applications with an integrated solution for this problem. A developer must rely on external DAL and ORM (Object Relational Mapping) frameworks to achieve the goal of domain abstraction and persistent data access, for instance, to automatically create the SQL scripts responsible for handling database manipulation and to convert the results into object usable by the application in a more high level fashion.

Application Distribution

Managing updates to mobile applications can be a difficult task when that application is installed in dozens or hundreds of mobile devices. This is a complete different scenario from a situation where the application to be updated is installed in static workstations connected to the enterprise network in a stable environment. In a mobile context though, where devices can be isolated from the company’s network, it can be hard to update an application to its latest version and this can pose security threats or efficiency problems to the device. A complete IDE for mobile applications should have the means to let the developer manage the update process of those devices in an agile and transparent way, without forcing the mobile users to hand over the devices to a central office for update. One way of circumventing this situation is with the usage of official distribution channels for the specific mobile OS, the native application markets described and analyzed in Section 1.1, but those markets often add additional overhead in terms of applications signing and registration, and that can be something to avoid by a company that wants to manage its mobile applications distribution process.

Dynamic Interface Generation

When creating an application to support a corporate business, it is common for that application to have multiple interfaces where the different business processes are mapped. Those interfaces usually require the presence of forms for user input and each form is different, even in the same application, for instance, in different departments or in the presence of different types of users. Nowadays there is a lot of work in the area of dynamic form building to generate dynamic inter- faces with the use of descriptive and mark-up languages such as XML to ease the development of such applications. Since the layout (XML) and logic (Java code) of an Android application is well separated one from another, there are several techniques available to help create such interfaces. One of those techniques, and one of the most used, is called XML inflation of the application layout and the injection of interface dependencies dynamically [46]. This allows for controlled changes in the interface through code logic and since there are available solutions for the problem, this too was left out of the scope of this project.

3.2 Architecture Specification

In order to satisfy each requirement presented before, the proposed architecture was designed to be highly modular and configurable. This proved to be helpful when the implementation or design

40

of some module changed over the development process and will also allow for further functionality

increment in an easy way. Figure 3.1 provides an overview for the modules of the SmartAndroid ar-

chitecture. One can analyze the presented figure as an increment in the Android libraries available

to the applications.

Enterprise Applications

Communication API

Serialization

SmartAndroid Framework

DAL

ORM

Energy

Management

Management Update

^(…)

Android Runtime Libraries

Android OS

Figure 3.1: General overview of the integration between enterprise applications, the Android Run- time Libraries (depicted in more detail in Section 2.3.1) and the SmartAndroid framework.

One important aspect to note is the two connections between the applications layer and both the

Android runtime libraries and the SmartAndroid framework. The decision for not completely hiding

the Android SDK from the applications is based on the assumption that not all the features from

the SDK are abstracted or “replaced” by the framework. Tools like interface design, media codecs,

location providers or even graphics processing (just to name a few), may still be incorporated in the

applications. Completely hiding these features would mean a full rewriting of the Android SDK and

that is not the goal of this thesis. By exposing both the Android and SmartAndroid features, the

developer can compose, extend or even restructure one of the modules without the need to create

facade abstractions to hide the underlying features, and this leads to a more open architecture

feasible to further increments.

Communication Infrastructure Layer

Communication Manager Layer

Physical Adapter Layer

Figure 3.2: General overview of the communication architecture in a layered interaction model.

Each of the shown modules of the framework was implemented with extensibility in mind, al-

lowing for other features to be integrated in the system. One of the SmartAndroid modules is the

Communication Management API that follows the architecture shown in Figure 3.2.

41

The model is comprised of three layers, (i) the Physical Adapter Layer which deals with the phys-

ical aspects of a given communication technology, such as the power state of the physical adapter or

the connection establishment nuances that are unique to each technology; (ii) the Communication

Manager Layer which is built upon the features of the lower layer and configures all the aspects re-

lated to message exchange procedures between two endpoints within a given technology and, finally,

(iii) the Communication Infrastructure Layer. The top layer hides the complexity and heterogeneity

of the lower layers and acts as a unique point of contact for the application, managing everything

related to the communication issues for several technologies with the primitives supplied by the

other layers. Since this layer aggregates the other two, it can change configurations related to com-

munication or physical features in behalf of the application, hence the direct connection between

the top and the lower layers.

All the described layers can be used independently from one another or integrated in more gran-

ular architectures if so is the necessity of the system being developed. In order to better understand

the concept and the design of this module, Figure 3.3 highlights several of its inner components and

all the relations that exist between them.

Application

WiFi Communication Stack

Communication Infrastructure

WiFi

Communication

Manager

WiFi

Bluetooth

Stack

Stack

Wifi

Bluetooth

Comm

Comm

Manager

Manager

WiFi Adapter

Wifi

Bluetooth

Adapter

Adapter

Android WiFi Libraries

Android Libraries

Configuration API

Figure 3.3: Example of the interaction between the communication architecture layers and the Android runtime libraries (depicted in more detail within Section 2.3.1).

From the figure, it is possible to note the narrow relation between groups of Physical Adapters

and Communication Managers. For a given technology, the distinct aggregation of a physical

adapter and a communication manager creates a Communication Stack. In the figure there are

two examples of those stacks, for WiFi and Bluetooth. The Communication Manager shown holds

those two stacks in order to offer the application an high-level API that allows for the management

of different communication technologies, configurations and message exchange endpoints. Since it

has control of both stacks it can also offer features such as network fail-over detection or the notion

about communication priorities.

42

In the figure it is also possible to denote a Configuration API that is connected to each of the

sub layers of the stacks. This API acts as a central repository for the framework configurations

and can be reused throughout the SmartAndroid modules. Each layer is “locked” to a specific set

of configurations, so it is not possible to misconfigure a layer with other layer’s configurations. In

this specific case, it is possible to see the interaction between the upper Infrastructure layer and

the lower one, since the Communication Stack manages the configurations for all of them.

Associated with the communication infrastructure is the serialization mechanisms of the Smar-

tAndroid framework. It is possible to associate a message serializer with a communication manager.

It can be changed by configuration and is associated with every message that is sent/received by

that specific manager. This architecture allows for further creation of specific serialization protocol

codecs to allow for different business logic to be stacked above the communication infrastructure.

Application

Interface Layer

Business Logic Layer

Persistency Manager Layer

SmartAndroid PM

Custom PM

Object Relational

Custom ORM

Android OS

Mapping

Data Access

Custom DAL

Runtime Libraries

Layer

SQLite

Database

Figure 3.4: Persistency management architecture, highlighting the interactions between submod- ules and the decoupling between managers and DAL/ORM layers.

Another module of the SmartAndroid environment, that greatly benefits from a layered archi-

tecture, is the data persistency module, depicted in Figure 3.4. This module holds the DAL and

ORM layers as shown in the figure. The DAL sublayer is responsible to the database access proce-

dures, while the ORM layer is responsible to abstract the complexity of relational mapping between

business objects and database entities. Thus, SmartAndroid applications are isolated from the low-

level database access. One advantage of this decoupling is that different approaches can be used in

the application data persistency strategy without changing the logic of accessing that data. For in-

stance, in the figure it is possible to observe two Persistency Managers (PM) under the Persistency

Manager Layer. They may hold different database “drivers” while maintaining the way in which

the domain objects are retrieved, being that database a local one (SQLite or other) or even a remote

database with different persistency approaches (RDBMS or OOBDMS).

43

3.3

Functional Specification

Several features were designed to be implemented on top of the presented architecture. The major of these features, which was an initial assumption that derived from the heterogeneous nature of mobile applications, be them enterprise or standard versions, was the asynchronous behavior of the framework to develop. On such heterogeneous environments, events occur without a predicted model and, as such, enterprise mobile applications must be prepared on how to deal with them. Android already supports asynchronous behaviors in the runtime libraries and that behavior was passed into the framework so that the new features would benefit and inherit from the native Android event-driven and asynchronous model. The SmartAndroid feature that mostly adheres to the notion of asynchronism is the Communication Infrastructure which deals with remote commu- nication. This kind of behavior is offered to the applications by callbacks that are invoked when a given event occurs. The functional blocks presented in Section 3.2 that deal with asynchronism interact with a Callback Handler that stores callbacks and triggers them when the registered events occur. Another feature that was designed for the SmartAndroid system was the configuration API. An example of such a feature was already illustrated in Figures 3.3 and 3.4 and it is, basically, a central repository for system configurations. Every functional block that needs to store, retrieve and change configurations can do so by using a Configuration Holder that can be locked to a specific kind of configuration parameters. This is of the utmost importance since the extensibility and modularity of the SmartAndroid framework may lead to a mismatch between the types of generic behaviors and their configurations, and this must be avoided. The update management feature of the framework was created with the capability of checking online for a given URL, download the contents and an Android application file (.apk file) and update the application based on that remote file. This gives the application an atomic procedure that composes several Android features into an easy to use way of checking for remote updates. The implementation details of the presented features will be given in the next section along with the interaction between the callbacks and the functional modules. One of the major features of the SmartAndroid environment is the communication management. The next list summarizes the aspects implemented in this module:

• Exposure of a single physical adapter layer which manages and deals with two kinds of func- tionalities: (i) Hardware device states and changes to those states; (ii) Management of the lower level features associated with a given technology. As an example, it is possible to relate the network association and configuration features of a WiFi adapter as being part of this layer. Such features are not present in the Bluetooth adapters due to the collapsed stack of this technology that discarded the notion of structured networks, but it is necessary to incor- porate functionalities such as device discovery, pairing and Bluetooth profile handling;

• The creation of a communication layer that acts as a hub for delivery and reception of mes-

44

sages across a large number of physical technologies. This layer is capable of dealing with different kinds of messages with a single API and it introduces the notion of endpoints. A com- munication endpoint enclosures all the information needed to establish a message exchange with a remote application. As an example, to establish a WiFi connection both an IP address and an application port are needed, while in a Bluetooth connection only a MAC address is needed along with a service ID to identify a single application within a given device;

• The capacity to deal with sets of communication technologies and expose a highly semantic API that can allow an application to establish points of communication based on (i) config- ured priorities, (ii) technology metrics to force the choice of a communication technology over another and (iii) detect aggregated internal changes or fail-over events between technologies.

The features of the Persistency Management layer can be listed as follows:

• To hide direct access to the local Android SQLite database, creating an abstraction between the business logic and database access procedures;

• Allow such an abstraction to be extensible and modular so that other types of persistency strategies can be implemented in the framework, without a development penalty such as massive code refactoring;

• Offer a CRUD layer to the application;

• Offer a semantic way to define a single domain model for the application;

• Create, in an automatic fashion, the ORM layer associated with the domain model.

3.4 Development Library

This section presents the implementation strategies for each of the components of the SmartAndroid framework, including design decisions, used Android SDK libraries and features as well as dia- grams to help understand the concepts explained. The core libraries of the framework were developed with the Java programming language and the API level 10 of the Android SDK, which corresponds to the Android OS 2.3.3. The Java Runtime Environment 1.6 (JRE6) is used throughout the development cycle since it is the version supported by the Android Development Tools 20 (ADT20). Since Google only supports the Eclipse IDE as the main development environment for the creation of Android applications, it was also used in the creation of the framework, in its version 3.7 (Ganimede).

3.4.1 Communication Management

In Figure 3.2, presented in the Architecture Specification, it is possible to observe the general interactions between the layers of the communication management module. The Physical Adapter

45

Layer (the lowest layer, closer to the Android runtime libraries) can be described in terms of a simple class diagram such as the one depicted in Figure 3.5.

< abstract >

Callback Handler

<interface>

Bluetooth API

<interface>

WiFi API

<interface>

Physical Adapter

Configuration Holder

< BluetoothConfig >

(AOP)

Configuration Holder

< WiFiConfig >

1

<bind>

WiFiConfig

(AOP)

1

<bind>

BluetoothConfig

Bluetooth Adapter

WiFi Adapter

<interface>

Configurable<ConfigType>

Figure 3.5: The implemented inheritance model of the Physical Adapter Layer.

The main implementation points, for the adapter’s logic in this layer, are the BluetoothAdapter and the WifiAdapter classes shown with a bolder outline in the figure. In order to maintain the architecture extensible, as discussed before, these classes implement a set of interfaces and extend abstract classes so that the core of the framework can be as modular as possible. It is feasible to define yet another Wifi or Bluetooth adapter class by changing concrete implementations of these inheritances. This is possible since the procedures in the framework only deal with generic APIs and abstractions, leaving the concrete implementations for the developer. However, and in order to prove the functionality and relevance of the framework, the two depicted central classes were implemented as a proof of concept for all the inheritance model. As it is possible to understand from the figure, both adapters implement the API defined by the PhysicalAdapter interface. This interface describes the common behavior expected for all the concrete adapter implementations. Since each technology has its unique features, behaviors and configuration parameters, each specific adapter is required to implement yet another interface to standardize each technology’s API. This can be seen in the implementation relationship between the adapters and the BluetoothAPI and WifiAPI interfaces. The inheritance, by the adapters, from the abstract CallbackHandler class models the asyn- chronous behavior described earlier in this chapter. Each technology has its set of events that are delivered as soon as an occurrence is detected. Since the logic associated with each event runs in a parallel execution line, the adapters must know how to handle callbacks that are invoked to deal

46

with such asynchronism. The abstract class holds an implemented approach to deal with all types of callbacks; the only issue is that each implementation has the responsibility of knowing which kinds of callbacks it wants to deal with.

In the lower section of the figure, it is possible to see a triple relation between the adapters, the Configurable interface and an implementation of that interface – ConfigurationHolder. This is due to the necessity of overcoming the Java single inheritance limitation which forces each class to only inherit only one other class. Multiple levels of inheritance would overcome this issue but would not fit the architecture properly since it would not respect abstraction barriers and the object-oriented guideline of single-purposed classes, where each class or interface must only deal with a single context. With this in mind, the only option would be use the Composite design pattern to insert an implementation of such an interface (the Configurable interface) to the adapter’s attributes and force that adapter to implement the same interface. By doing this, the architecture stays true to its modular nature and isolates the configuration procedures to that single object. With further notions of Aspect-Oriented Programming (AOP) it is possible to delegate the exposed API of the CofigurationHolder attribute to the Configurable interface of the adapter, emulating multiple inheritance of other object-oriented languages such as C++.

The chosen model for the physical layer also helps to mitigate the heterogeneity with which the Android SDK deals with adapter technology instantiation. For instance, in Google’s SDK, and in order to obtain the object responsible to handle all the Bluetooth interaction (also a class called BluetoothAdapter) one must call the method BluetoothAdapter.getDefaultAdapter(). The static method returns an object if the Bluetooth technology is available in the device or null other- wise. While this may seem a straightforward approach, there are ways to express the instantiation without referring to static logic. One of those options, the one used by the SmartAndroid frame- work, is the return of a semantic exception to warn the application of the eventual unavailability of the Bluetooth technology, whithout forcing the develop to check for a null value. This acts as a highly semantic API, that adheres to standard good practices and one which is more familiar to object-oriented programmers.

Comparing the Bluetooth example with the WiFi instantiation, it is possible to observe that, even within the same SDK, the lower level technologies are instantiated with different methods for no explicit reason. To instantiate the object responsible to deal with the WiFi interaction, the developer must use the Context object, available in every Activity and View that define the core of the application. When in possession of the context it is necessary to call the method getSystemService(Context.WIFI SERVICE) and cast the result to a WifiManager object. The core object that deals with WiFi technology is considered a system service, while the Bluetooth ob- ject is not, and in this case, the method returns an exception if the WiFi adapter is not available in the device. For each technology, the ways through which the developer deals with that technology’s features is different. This heterogeinity can be unified and integrated and one way of doing so is proposed in the communication manager of the SmartAndroid framework.

The next level in the hierarchy of the communication manager is the Communication Manager

47

Layer, it is based on the correct behavior of the lower layer and is responsible for managing message- related mechanisms. The architecture of this layer can be observed in Figure 3.6

<

abstract >

ConnectionEstablishedCallback

<ConnectionEndpoint, ConnectionHandler>

<

abstract >

Connection

Handler

<

abstract >

<interface>

ConnectionReceivedCallback

Connection

<ConnectionHandler>

Endpoint

<

abstract >

<interface>

<

abstract >

Configurable < ConfigType >

Communication Manager

<A, B, C, D>

Callback Handler

< bind>

WiFiConfig

1

(AOP)

< bind>

A: WifiConnectionEndpoint

B:WifiConnectionHandler

C: WifiConnectionReceivedCallback

D: WifiConnectionEstablishedCallback

WiFi Communication Manager

Configuration Holder

< WifiConfig >

Figure 3.6: The implemented inheritance model of the Communication Management Layer.

The first point of analysis in this figure is the WifiCommunicationManager class, which holds configuration values with the same strategy discussed previously, where the manager implements the Configurable interface and delegates the procedures inside the interface methods to an inner object with the same API. This time, in order for the application to be able to send and receive messages, the manager inherits the CommunicationManager abstract class, that is binded with four generic types in its definition. These generic types are associated with the structure of the enclosing class and can be used to lock the behavior of the class to the usage of those specific classes. By doing this, it is possible to create, for instance, a WiFi communication manager that only accepts not only WiFi callbacks but also other types of objects related to the WiFi features. With this design option, as well as with the composition of Configurable objects inside configuration holders, it is possible to assert the correct types for object dependencies in development time, so that the developer does not have to deal with runtime exceptions due to misused class types.

The callback management procedures, for this manager, are inherited from the super class and it is also possible to see in the figure the relations and bounds between the CommunicationManager and the generic types. The first generic type to introduce is the ConnectionEndpoint and, as discussed in the last section, intends to represent a single communication point. In the case of WiFi, it consists of an IP address and a port number. The ConnectionHandler acts as an abstraction to a network socket. It handles specific serialization and message delimiting strategies with high-

48

level procedures and, with the method sendMessage(Message), it sends a message in a non- blocking manner as well as with the message reception method startReceivingMessages(), which creates a background worker thread to handle the reception of messages and returns to the application when such a messages is received, with the help of an appropriate callback. The Message entity is just an interface, to which the SmartAndroid offers two implementations to prove the concept of message generalization: the StringMessage and the JsonMessage. The messages are created through features of the manager and, as such, inherit its configurations, which allows them to serialize themselves and be handled by every callback in a transparent way, provided that the messages obey the defined contract. The callbacks that are defined in the structure of the CommunicationManager class also have their structures locked to specific endpoints and connection handlers so that it is not possible to define a manager for Bluetooth, for instance, with callbacks for the WiFi technol ogy.

<interface>

Communication Stack

1

Communication

Infrastructure

1

Bluetooth Communication Stack

1

Bluetooth

Communication

Manager

Bluetooth

Adapter

1

WiFi Communication Stack

1

1

WiFi

Communication

Manager

WiFi

Adapter

<interface>

Infrastructure

Figure 3.7: The implemented inheritance model of the Communication Infrastructure Layer.

Finally, the top layer of the communication management module has the organization depicted in Figure 3.7. The framework contains a proposed implementation for the Communication Infrastructure class, which implements both the Infrastructure and CommunicationStack interfaces. It can be created with any number of technologies to manage and it orchestrates the behavior of the lower layers through what is called a Stack. These stacks, as explained before, hold both the man- agers and the adapters for a given technology and the overall structure of the inheritance model for this layer is quite simple when compared with the other two. This is due to the complexity that is hidden, or dealt with, in the lower layers, allowing for this one to be more simple and with a more straightforward API. It offers two main methods, the connectWith(Connection Endpoint, ConnectionEstablishedCallback) and, the one that relates to a server behavior:

startReceivingConnectionsAt(ServerDescription, ConnectionReceivedCallback).

49

Both methods detect the generic typing associated with the instances they receive as arguments. They can handle as much class types as technologies they can manage. The communication tech- nology being used by the application at a given time is inferred by the class types and the specific procedures are started if possible. This layer also caches connections so that they can be reused without any extra instantiation. The detailed API of all the SmartAndroid classes and interfaces can be found in the Appen- dices B to E.

3.4.2 Persistency Management

To manage the application persistent storage in the local database, the SmartAndroid offers a fea- ture that encapsulates a DAL and ORM layers to create an integrated domain management sce- nario. With it, it is possible to define the business objects as part of the application domain and the framework creates the “boilerplate” code automatically to associate those objects to the database entities. This feature is tightly coupled with the Eclipse functionalities, such as the Java 6 preprocessor handling, which is triggered each time the IDE detects a change in the code base. This is a useful functionality if one thinks that the domain is something that can change over time, even in the same development cycle. This setup allows for automatic domain regeneration and is a similar feature when compared to the automatic parsing of the code when a change occurs. There are some possible approaches when dealing with domain abstraction, DAL and ORM, dis- cussed in Chapter 2, but some of the functionalities implemented in the SmartAndroid in which this thesis’ framework is based on is already built within some external libraries. One of the ana- lyzed solutions was the Hibernate library, the other was the ORMLite library. Although Hibernate presents a more complete solution and customization options, ORMLite was designed with effi- ciency and modularity in mind. Besides this, it was expanded to support the SQLite database from the Android OS, since its appearance. Due to this fact, it was the chosen library from which several features were extracted. The main feature, which is based on the ORMLite library, is the possibility to easily create a DAL layer. It is based on the Data Mapper design pattern, which is not what was planned for the SmartAndroid framework to begin with, but it is possible to overcome this issue in the final stages of the DAL generation. It is typically possible, in DAL frameworks, to map some characteristics to the data to be stored, and those features in the framework’s case were derived from those in ORMLite. They can be assigned to the domain object’s attributes as standard Java annotations and are listed as follows:

• CanBeNull: Whether the field can be assigned to null or have no value. Default is true.

• ColumnName: When a domain entity field is marked with this annotation the attribute will be used as the name of the column to be stored in the database. If this annotation is not present the name of the field will be used instead.

50

• DataType: The DataType associated with the field. If not set then the Java class of the field is used to match with the appropriate DataType. This should only be set if the developer is overriding the default database type or if the field cannot be automatically determined. Type handling is inherited from the ORMLite library.

• DefaultEnumValue: If the field is an Enumeration and the database has a value that is not one of the names in it, then this name will be used instead. It must match one of the enumeration names. This is mainly useful when the developer is worried about backwards compatibility with older database rows or future compatibility if it is necessary to roll back to older data definitions.

• DefaultValue: The default value of a generic field when creating the table. Default is none.

• ID: Used to identify this field as the ID of the domain field. Default is FIELD ID and the object defined by this field will be used. If AUTO GENERATED is used, then the data type can only be Integer or Long and the database will auto-generate them. If AUTO GENERATED BY SEQUENCE is used, then the attribute “generatedIdSequenceName” must be defined with the name of the database sequence to generate this field. Only one field can be marked as the table ID.

• Indexable: This will tell the database to create an index with the name of this field.

• IndexElement: Accepts a string as argument and every attribute in a given domain entity with the same value will be added to an composed index with all the specified fields.

• Reference: Identifies the field as corresponding to another class that is also stored in the database. The field must not be a primitive type and the other class must have an id field (either id, generatedId, or generatedIdSequence) which will be stored in this table. When an object is returned from a query call, any foreign objects will just have the id field set. This behavior is called “lazy loading”.

• StringLength: Integer width of the field. Default is zero which means to take the data-type and database-specific defaults. For strings, that means 255 characters.

• Unique: Sets the attribute as unique in every row in the entity table.

• UniqueCombo: Set this to be true (default false) to have the database ensure that all of the columns marked with this as true will together be unique.

• Volatile: Annotation used to tell the DAL processor that this attributed is not to be persisted.

All these annotations can be used in the definition of the domain model which, in the SmartAn- droid framework, is defined by the definition of a class with the annotation @DomainModel, so that the system knows where to look for the domain’s root. This annotation can be configured to change the database name or version if needed. Similarly, a domain entity can have its corresponding table name changed by annotating the entity definition with @DomainEntity. In Figure 3.8 a simple domain definition is exemplified.

51

1	@DomainModel(value = “ist.db”, version = 3)
2	class JustAnApplicationDomain
3	{
4	class Student
5	{
6		@ID(IdType.AUTO_GENERATED)
7		int studentID;
8
9		@Unique
10		String name;
11
12		@Reference
13		List<Subject> subjects;
14	}
15
16	@DomainEntity(tableName = “ClassSubject”)
17	class Subject
18	{ @ID(IdType.AUTO_GENERATED)
19
20		int subjectID;
21
22		String name;
23
24		@StringLength(200)
25		String description;
26
27		@Reference
28		Teacher teacher;
29	}
30
31	class Teacher
32	{ @ID(IdType.AUTO_GENERATED)
33
34		long teacherID;
35
36		@Reference
37		@ColumnName(“classesTaught”)
38		List<Subject> subjects;
39
40		@Reference
41		List<Student> students;
42	}

43 }

Figure 3.8: An example of a simple domain model for a school application.

In the code listing, it is possible to understand how a domain is specified in the framework. Every annotation type listed before can be added to the domain entities’ attributes to model the logic and constraints associated with the database tables. Each of the defined domain entities will be mapped into an application object so that it is possible to create and deal with the business logic using those objects. This operation sums up the execution of the ORM layer by creating two objects for each domain entity. The whole operation is summarized in Figure 3.9, where it is possible to note that the preprocessor has 3 different roles in the process: (i) receive the domain definition, parse it and (ii) generate the appropriate DAL layer, instantiating the local database, changing it if it must and, finally, (iii) creating the domain objects to be used by the application. These objects have the necessary internal procedures to know how to CRUD (Create, Refresh, Update, Delete) themselves and access the DAL layer in behalf of the application. two types of objects are created:

(i) the domain proxy objects and the (ii) domain objects.

The preprocessor, in the second phase, is responsible for generating all the connections between the ORMLite library and the SmartAndroid framework, resulting in an integrated procedure which

52

Application Artifacts

Domain Entities:

Java Preprocessor

Student

Subject

1

Domain

Teacher

Definition

3 artifacts

2

Business Logic

3

Domain Objects:

StudentBase.java

Data Access

SubjectBase.java

Layer

TeacherBase.java

6 artifacts

Proxy Objects:

Student.java

Android OS

Subject.java

Teacher.java

SQLite

Database

Runtime Libraries

010101010

010101010

101110101

010101010

101110101 000100101

101110101 000100101

000100101

Figure 3.9: An ilustration of the domain generation procedure. From the example of Figure 3.8.

is completely transparent to the developer. The only aspect that the developer must account for is related to extra logic that may be added to the domain objects. This extra logic may be needed in situations where unitary operations are relevant to the development process. As an example, one could create a method, based on those in the DAL layer, to retrive all teachers that teach more than one subject. If this kind of addition is useful, the development of such extra logic must be done in the domain objects, the second type of objects described in the last paragraph. The proxy objects only support the main DAL operations and the framework must be sure that their structure is stable and unchanged, unless by a domain changing event, where both the domain definition and domain objects are changed. Since the proxy objects are inherited by the domain objects, they will have the save CRUD behavior and can be used to manage the domain.

53

4

Framework Evaluation

This chapter presents the evaluation method and the results obtained from the framework’s bench- mark. First, the evaluation procedure will be described, followed by the evaluation parameters that will be retrieved from such tests and the metrics that were gathered in a conducted survey. The specific results for the two major tested areas of the framework will follow and, finally, a brief overview and conclusion of the evaluation procedure will be presented.

4.1 Benchmarks Overview

The evaluation of the SmartAndroid framework was divided into two main phases: (i) an application development cycle and (ii) a final survey of the participants. In order to measure what would be the impact in the development process from developers with Android experience and those that are still learning the basis of software development, the group was divided into two subgroups: the senior and the junior group, both with five elements each.

The criteria for selecting the members for each group was based on (i) the perceived software development skills, (ii) the experience in enterprise application development and (iii) the familiarity with the Android system and development environment, such that, after the selection, the juniors’ group were mainly formed by elements that were still completing the bachelor’s degree, with little or no experience in Android development and, the seniors’ group was formed by elements with enterprise experience or which were familiar with Android development.

Both the evaluation processes were measured equally for both development groups, in order to create the same base of comparison for both of them, and the first process consisted in the develop- ment of two applications:

SimpleMessenger

• Objective: to develop an application (Figure 4.1) that would behave as a chat client with a single remote peer and would also wait for remote connections. As soon as a connection was received, or established by the user’s initiative, the application would be locked to that

54

connection only. From that moment on, both peers could send messages to each other until one of them would exit the application;

• Test Purposes: to test the creation of a client/server behavior, remote communication primi- tives and the ability to handle application asynchronism.

SaveMyNotes

• Objective: to develop a note-taking application (Figure 4.1) that would persist all the notes, each of them with an associated type tag, in the local Android database. It would be possible to create new notes, change or delete existing notes and when the application started it should be able to load all the notes in the database;

• Test Purposes: to test the creation and handling of databases as well as the concepts of ORM when dealing with domain objects that are persisted in the local database and the main features of DAL when making CRUD operations to the objects.

SimpleMessage

SaveMyNotes

Figure 4.1: The applications’ interface created for the evaluation tests.

All the developers were required to create two copies of the presented applications in a time span of one month. One version was to be developed only with the Android SDK and the other with the SmartAndroid framework. The purpose of such duplication resides in the possibility to evaluate some metrics related to the developed software when comparing both the Android SDK and the SmartAndroid framework. The relevant metrics are outlined in the next section. In the end of the development procedure, a survey was provided to all the test elements so that some other relative and indirect metrics could be measured. The supplied survey consisted on six ques- tion areas: the first is about general questions about the developer including the knowledge about

55

the Android system and general programming skills; areas from two to five have the objective of inferring data for the perceived software metrics by the developers; the sixth area asks about some opinions specifically about the SmartAndroid system.

4.2

Evaluation

The focus of the proposed framework’s evaluation was to compare the standard environment for Android applications development with the SmartAndroid environment in order to discuss whether this thesis has provided better solutions for enterprise mobile applications. When evaluating a software program or library it is possible to infer some measurements based on non-functional requirements. Those requirements specify benchmarks that can be used to judge the operation or “quality” of a system, rather than specific behaviors, which is an analysis to be done in the functional requirements area [47]. Although technical metrics for software libraries and frameworks are not absolute, McCall et al. [48] argues that those metrics provide a systematic way to assess quality, based on a set of clearly defined rules and should be used by software engineers to provide deeper insights about the software’s structural quality. As such, and since a deep analysis of software quality measurement is not in the scope of this thesis, only some metrics, also proposed by McCall et al., will be analysed and they are summarized as follows:

1. Correctness: will be assessed by the creation of fully functional applications to act as a proof of concept for the SmartAndroid features, so it will be ascertained by the development of applications with the framework;

2. Usability: will be measured in Lines of Code (LOC), since this metric infers if the framework is easy to use and the effort required to learn, operate, prepare input, and interpret the output of a developed program;

3. Maintainability: represents the effort required to locate and fix an error in an operational program. Will be measure by the survey’s response;

4. Extensibility: to test whether the application can be easily extended to add new features and will be measured by the survey’s responses;

5. Portability: will check the ability for an application to enforce and favor a modular approach that eases the possibility of exporting some of those modules to other applications;

6. Testability: that checks if it is easy to test the application with perceived metrics in the survey.

The developed applications were used to retrieve some usability metrics. Those metrics were calculated based on the lines of code (LOC) used to create each individual feature. The retrieved numbers can be observed, for each developer, in the Appendix F.

56

Lines of Code (LOC)

In order to determine which lines of code would matter to the statistics, they were filtered ac- cording to the following characteristics: (i) Android-specific LOCs were ignored as well as (ii) lines related to method and variable/attribute declarations, (iii) import lines and (iv) lines with only block statements or parenthesis. This was done in order to introduce some level of mitigation for code heterogeneity which is always present since every developer has its own programming strategies and approaches. While some developers prefer to create a line of code for each variable, regard- less of being novice or expert, there are developers who prefer to use method in-lining, anonymous classes or multiple variable declaration, just no name a few examples. With this in mind, only the LOCs that were identified as being part of an application feature were counted. The aggregated average results for the lines of code with both platforms (Android SDK and SmartAndroid) are presented in Figure 4.2 where it is possible to denote that the framework in- troduced favorable gains, in terms of usability, for both types of applications. In the SaveMyNotes application (persistency and database management) the usability gain is much more expressive, having an approximated value of 90% less lines.

200

180

160

140

120

100

80

60

40

20

0

Android 1

SmartAndroid 2

SimpleMessenger App

Juniors

Android 3

SmartAndroid 4

SaveMyNotes App

Seniors

Figure 4.2: Average LOCs (Android SDK VS SmarAndroid) for both applications.

It is also possible to observe the LOC metric but with focus on both test groups. In the graphic, it is possible to note that, even if the difference in LOCs for both test groups is roughly the same in almost every test case, in the SaveMyNotes application, the seniors used much more code lines than the juniors. This may be due to usage of more advanced programming skills which lead to more generic code and more abstraction layers which, in turn, lead to more lines of code. The “Correctness” metric evaluation of the framework focused on the communication and persis- tency modules, in what the proposed features are concerned. It was tested through the successful implementation of all the 40 applications by all the testers (four applications for each group ele- ment). Some developers sugested some improvements in the framework’s API, however all of them

57

completed the applications and proved the functional requirements of this thesis.

4.2.1 Communication Management

The survey answers related with the SimpleMessenger, in both development modes, are summa- rized in Table 4.3. The darker the cell background, the more answers were concentrated on that scale range. One important factor to note is the absence of answers referring to a “very bad” metric behavior in the SmartAndroid framework, while the Android SDK lead the developers to evaluate the Google’s framework as being mainly “bad” rated.

SimpleMessenger - Android

56%

Very Good

Good

Bad

Very Bad

0%

0%

11%

Usability

Portability

Extensibility

Maintainability

Test Easiness

11%	22%	11%	11%	0%
33%

33%

44%

22%	33%	44%
56%	56%	33%

0%

11%

SimpleMessenger - SmartAndroid

Usability

Portability

Extensibility

Maintainability

Very Good	22%	11%	33%	56%
Good	56%	78%	56%	33%
Bad	11%	0%	0%	0%

Very Bad

0%

0%

0%

0%

Test Easiness

33%

33%

22%

0%

Figure 4.3: Survey answers to the metrics related to the SimpleMessenger application.

The metric which generated the greater consensus among the developers was the portability. This maybe due to the highly modularity imprinted in the development of the communication mod- ule that allows for easy isolation of code artifacts. The developed applications were also useful to infer some metrics about the “Usability” of the SmartAndroid framework, when compared to its counterpart, the Android SDK. With the proposed definition for usability, one can relate that if a framework produces more lines of code, to do exactly the same procedure, then it will also be more difficult and cumbersome to debug an application done with that framework, at least when compared to another framework that, for the same functionality, uses a more succinct syntax or less lines of code. For the SimpleMessenger application (communication functionalities) and the graphic in Fig- ure 4.2, which represents the measured usability, again the perceived usability retrieved from the survey, comes that the developers used 44.76% less code. The seniors used again in this application, and on average, more lines of code to do the same feature. However, that difference is less evident in the same application when using the SmartAndroid framework, closing the gap between juniors and seniors in what the framework usability is concerned. Another relevant conclusion refers to the easiness with which the developers created the client

58

and server parts of the application. In the Android version, 78% agreed that the client was more straightforward while the same percentage of developers perceived both server and client as having the same difficulty with the SmartAndroid version.

4.2.2 DAL + ORM: Domain Management

In Figure 4.2 it is also possible to observe the LOC metric but with focus on both test groups. In the SaveMyNotes application, the seniors used much more code lines than the juniors. This was due to the fact that their applications were prepared to handle possible extensions, with more high level constructs such as database access abstractions and simple custom ORM behaviors. These el- ements were not present in the junior’s applications. In fact, the survey answered by the developers (Figure 4.4), revealed that 44% consider the usability of the Android SDK “bad” and 22% considered it “very bad”, in terms of database access.

SaveMyNotes - Android

Very Good

Good

Bad

Very Bad

Usability

Portability

Extensibility

Maintainability

Test Easiness

0%	0%	0%	0%	11%
0%	11%	11%	11%	22%
44%	44%	56%	56%	33%

22%

11%

0%

0%

0%

SaveMyNotes - SmartAndroid

Usability

Portability

Very Good	56%	56%
Good	33%	22%

Bad	0%	0%
Very Bad	0%	0%

Extensibility

Maintainability

Test Easiness

33%	22%	22%
22%	56%	11%

11%	0%	33%
0%	0%	0%

Figure 4.4: Survey answers to the metrics related to the SaveMyNotes application.

The persistency management capabilities of the SmartAndroid framework greatly improved the number of code lines in the developed applications. This was perceived by all group elements since the measured (lines of code) and the perceived usability increased. The LOC percentage gain was approximately 90% and the perceived usability for the Android system does not include any ratings with value “very Good”. On the contrary 56% of the developers rated the SmartAndroid usability, in this case, with that level.

4.3

Discussion

Although the number of volunteers might be considered small, the difficulty and time consumption associated with learning, creating and testing the applications cannot be neglected. While the

59

majority of junior developers needed to learn both frameworks (Android and SmartAndroid), the seniors also had to learn the SmartAndroid system. Some actions could be taken to increase the relevance of the executed tests, such as giving more time to the developers to create the applications or increasing the number of developers in each group, diluting eventual statistical quirks that might have occurred when assessing the survey’s results and counting the lines of code. However some consistent conclusions were retrieved from the executed tests. They can be summarized in the following items:

• Every developer that was exposed to the development cycle with the SmartAndroid confirmed the necessity of having more highly semantic frameworks in order to streamline the applica- tion development process;

• They also relate the existence of such frameworks with the necessity of dealing with less code, which means less problems when creating applications;

• The major contribution to the development process was the Persistency Management module, which lead to the greatest usability gain in every development group;

• The SmartAndroid framework can reduce the gap between junior and senior developers, al- lowing high-level abstraction to be easy to use and accessible;

• One cumbersome task, identified by the developers, was the management of asynchronous tasks. Since the application must not block the user in any given functionality waiting for remote response, the developer must handle this asynchronism properly. However this may be considered as a side-task to the application and the SmartAndroid allows the developer not to worry about how the asynchronous behavior acts inside the Android system.

60

5

Conclusions and Future Work

Pushed by the ever-growing dynamism of the market, enterprises are migrating or starting to sup- port their businesses on top of mobile technologies. Those technologies are becoming more cheap, powerful and ubiquitous than ever and the number of mobile operating systems do not show signs of shrinking. Independently of the diffusion and variety of choices generated by the great number of mobile operating systems, Android stands as the most used mobile platform in the consumer segment and is gaining more and more adepts in the enterprise environment. This platform also has the greater number of hardware vendors and the better cost/advantage relationship among all the other mobile platforms, turning Android into a serious and stable competitor for the construction of a mobile business. Due to the popularity and the open source features of Google’s mobile operating system, the number of development environments for this platform has also escalated but, after all the research done in the area of integrated development environments for native, web-based and hybrid mobile applications, it is possible to conclude that none of them has professional and enterprise tools for developing corporate mobile applications. Even the development tools supported by Google lack the support for this features. One reason for this may be related to the fact that Android has its main focus on the consumer segment and, because of that, a company willing to support its business with Android may find many obstacles to establish an integrated and professional environment for mobile application development with all the needed tools, not only to aid in the development of mobile applications, but also to manage the integration of those applications into the devices as well as the customization of the operating system to match the needs of the company or the business. The SmartAndroid framework integrates several solutions to help creating enterprise-level ap- plications with Android: (i) it will integrate in the development environment all the needed func- tionalities identified in the requirements in order to support corporate mobile applications. All this without the need for the developer to manage external libraries, and (ii) the framework will also allow the creation of a custom Android system image with the required applications and will also aid in the customization of the OS by removing or adding functionality. The preformed evaluation proved the effectiveness of the proposed approaches, with usability gains ranging from 45% to 90%.

61

The proposed solution represents a novel approach to deploy mobile solutions based on the An- droid system and will integrate with the already supported tools from Google. This allows the developer to use the well-established code base for the Android operating system while giving the choice to use the developed corporate tools.

Since the presented work has several implications in the development process of enterprise ap- plications using the Android mobile system, it also has several potential points of improvement and future work. Some of those points are related to the scope of the thesis which were relatively small when compared to all the discussed enterprise application necessities throughout the document.

In order to offer a completely integrated corporate development environment, it would be in- teresting to offer an integration of the SmartAndroid core libraries in the Eclipse IDE. This would fairly reduce the amount of configuration work by that should be done by the developer. Another important aspect related to the enterprise integration of the system is a possible way to configure the Android system within the same development environment. For instance, the customization of the Android system, removal of applications and disabling of system components with Eclipse tools. Further research and development in this area would greatly benefit the increase the speed with which the business applications would be created.

Since there are several differences in every new version of the Android OS, those differences must be abstracted from the enterprise applications. For standard Android applications, Google states that all the SDK versions are retro-compatible, meaning that, for instance, an application targeted for Android 2.3.3 would run transparently within an Android 4.1.0. In enterprise applica- tions this may not be a stable assumption, due to the advanced object-oriented features that may be needed in order to map a real World problem into an application. This kind of problems occurred during the development of this thesis, because the Android libraries were created and targeted for the Android API Level 10, and were related to classpath inspection. This kind of feature is available to standard Java programs and was blocked by Google since Android 3.0.1. The domain generation tactics, that used automatic class inspection to infer which class represented the domain model could not be used anymore because of this design decision. One other challenge was related to the support of IPv6 addresses that prevented applications to correctly handle this kind of addresses since the Android APIs only exposed integer values as IP addresses. Since an IPv6 has an address space of 128bits it would not fit into a 32bit integer, forcing the developer to use reflection mecha- nisms to lookup the correct IP value until Android version 2.3.7. These were just examples of how the heterogeneity in the lower-level features of the Android OS could lead to difficult approaches in what enterprise applications are concerned.

There are several literature referencing the permission restrictions of Android applications, where developers need to explicitly indicate which permissions their applications have. This prob- lem is ofter referred as the Android permission-creep problem [49]. A feature that would auto- matically calculate the needed permissions of the application would also ease the development of enterprise applications that may need a big set of those permissions in order to run in the system.

The aspect of energy management is of the utmost importance to mobile devices since they run

62

on batteries that are relatively small. This should greatly benefit not the application development but the processes related to application tunning. Android does not offer native support for the applications to query the battery status related to specific application threads or processes. A stable implementation of an energy framework such as the PowerTutor described in a technical report from Lei Yang, from Google [50] would allow the applications to offer fine-grained reports about their energy consumptions. Since this feature can only be achieved with deep introspection of the native and linux components, it can pose a difficult task to the developer. Related to the architecture and the ways through which the application uses the system fea- tures, there is a lot of room for improvements in the WiFi management solution proposed. The Android SDK wifi modules are tightly coupled with the system services that originate them and they can be simplified to offer a simpler API to the application. Some work was done in the area but further refinements would be relevant in the enterprise context. Also related to the proposed architecture, is the level of where the modules were created. They were built above the core libraries of the Android OS but further study is necessary in order to understand if those features preform better in the native level of the Android APIs (in the operating system level) with the NDK (Native Development Kit). Another challenge that need to be taken into account is related to some bugs present in the Android platform that may prevent advanced features to work well across several OS versions. This proved to be a challenge since many of the identified bugs, mainly in the broadcast events of the platform, were officially reported but not solved, forcing the SmartAndroid framework to provide a solution to them. When testing the framework, several modules were left out of the evaluation procedures since a lot of time would be required by the developers to understand them and because there was no possi- ble comparison with similar features in the Android SDK, mainly the central update manager and the configuration features. It would be interesting to compare different approaches when dealing with these functionalities and conduct the tests with more developers, with different backgrounds and experience levels, in order to better ascertain the validness of the framework.

63

A

Major Cross-Platform Frameworks

Company

Product

Founded

Tool Type

Authoring

Output

Adobe

PhoneGap

2008

Web code

HTML5, CSS, JS

Hybrid web apps

(Nitobi, 2011)

wrapper

Adobe

Flash

1982

Runtime

ActionScript

Platform

Framework

swf Flash player

files

Ansca Mobile

Corona

2008

Runtime

Lua, Corona API

Native

Appcelerator

Titanium

2007

IDE, Runtime

HTML, CSS,

JavaScript

Native (primarily),

Hybrid and Web

apps (beta)

Seregon

DragonRad

2001

Runtime

WYSIWYG,

Forms, Lua

IBM

Worklight

2006

Enterprise app

HTML, CSS, JS

Native, Hybrid,

(Worklight)

platform

Web

Ideaworks

Marmalade

1998

Source code

C++ with

Native

3D, Ltd.

translator

Marmalade APIs

(compiler)

MoSync

MoSync

2004

IDE, Runtime

C++. HTML5

Native

Motorola

Rhodes

2008

Runtime

HTML, Ruby,

Native

(RhoMobile)

Rhodes APIs

Netbiscuits

BiscuitsML

2000

Framework

Templates,

WYSIWYG

HTML, CSS, JS,

BiscuitML

Web apps, Hybrid

Platform services

RunRev

LiveCode

1997

IDE

Visual design,

Native

Runtime

LiveCode

language

Qt

Qt

Trolltech

Framework,

Native, Hybrid

Development

1994 Nokia

Runtime

Frameworks

acq. 2008

C++ with Qt

APIs, QML,

HTML

(Nokia/Digia)

Sencha

Touch

2007

Framework,

JavaScript

Hybrid, Web apps

Webcode

wrapper (v2.0)

Unity

Unity

2004

Games engine

C#, JavaScript,

Native

Technologies

Boo, creative

tools

Xamarin

MonoTouch

2011

Runtime, OS

C#, .NET

Native

Mono for

abstraction

libraries

Android

Figure A.1: List with all the major development platforms

64

B

Bluetooth Adapter UML

65

C

WiFi Adapter UML

66

D

Communication Manager UML

67

E

Communication Infrastructure UML

68

SmartAndroid LOCs

SimpleMessenger - Developer LOCs

Android LOCs

120
100

20

80

60
40

F

Application Development Results

(LOC)CodeofLines

69

_27,85%

₅₇

₇₉

C

₃₇

₈₅

B

₉₀

A

0

_56,47%

_46,67%

₄₈

SmartAndroid LOCs

Android LOCs

% Gain

SmartAndroid LOCs

SaveMyNotes - Developer LOCs

Android LOCs

300

150
100

250
200

50

(LOC)CodeofLines

70

_84,51%

₁₁₃

C

₅

₇₁

₁₁

B

₂₄₃

A

0

_95,88%

_96,71%

₈

SmartAndroid LOCs

Android LOCs

% Gain

Bibliography

[1] Franc¸ois J. N. Cosquer and Annie Ohayon-Dekel. Mobility and Enterprise 2.0. International Journal of Interdisciplinary Telecommunications and Networking, 1(4):1–15, December 2009.

[2] iPass Aliance. Mobile Workforce Report – September. Technical report, iPass Alliance, 2012.

[3] C.

Milanesi

and

R.

Cozza.

Mobile

Communication

Devices

System,

http://www.gartner.com/it/page.jsp?id=1622614.

report,

2008

-

2015.

Technical

Gartner,

2011.

by

Open

Operating

at

Extended

Abstract

[4] M. Vakulenko, S. Schuermans, A. Constantinou, and M. Kapetanakis. Clash of Ecosystems. Technical report, VisionMobile, 2012.

[5] George Voulgaris. Developer economics 2012. Technical report, VisonMobile, 2012.

[6] Jim Edwards. Here is the evidence that mobile advertising is in a bubble. Technical report, Business Insider, August 2012. accessed in 25 September 2012.

[7] Open Handset Alliance. Device Manufacturers, September 2011. Accessed 13 December 2011.

[8] Andrew Hoog. Android Forensics. Elsevier Inc., 2011.

[9] Robert Greene. Objects, databases and the myth of serialization. Technical report, Versant,

2011.

[10] Guanhua Wang. Improving data transmission in web applications via the translation between xml and json. In Proceedings of the 2011 Third International Conference on Communications and Mobile Computing, CMC ’11, pages 182–185, Washington, DC, USA, 2011. IEEE Com- puter Society.

[11] Douglas Crockford. RFC 4627 - The application/json Media Type for JavaScript Object Nota- tion (JSON). Technical report, IETF - Internet Engineering Task Force, 2008.

[12] John Bates. Openedge development: Working with json. Technical report, Progress Software Corporation, 2009.

71

[13] ISO. Open systems interconnection (osi) model and notation, service definition, recommenda- tions x.200-x.219. Technical report, The International Telegraph and Telephone Consultative Committee, 1989.

[14] Joseph R. Falcone. A programmable interface language for heterogeneous distributed systems. ACM Transactions on Computer Systems, 5:330–351, 1987.

[15] Gerard J. Holzmann and Gerard J. Holzmann. Standardized protocol interfaces. Software - Practice and Experience, 23, 1993.

[16] Bobby Krupczak, Kenneth L. Calvert, and Mostafa Ammar. Implementing protocols in java:

The price of portability. In In IEEE INFOCOM’98, pages 765–773, 1998.

[17] R. Greg Lavender, Chris J. Tomlinson, and Dennis G. Kafura. Implementing communication protocols using object-oriented techniques. Technical report, 1992.

[18] Marshall T. Rose and Dwighat E. Cass. Osi transport services on top of the tcp. Comput. Netw. ISDN Syst., 12(3):159–173, March 1986.

[19] Jo ao˜

M. P. Cachopo. Development of Rich Domain Models with Atomic Actions . PhD thesis,

Instituto Superior Tecnico´

- Universidade Tecnica´

de Lisboa, July 2007.

[20] Raphael Mannadiar and Hans Vangheluwe. Modular synthesis of mobile device applications from domain-specific models. In Proceedings of the 7th International Workshop on Model-Based Methodologies for Pervasive and Embedded Software, MOMPES ’10, pages 21–28, New York, NY, USA, 2010. ACM.

[21] Dean Kramer, Tony Clark, and Samia Oussena. Mobdsl: A domain specific language for mul- tiple mobile platform deployment. In NESEA, pages 1–7. IEEE, 2010.

[22] Faheem Sohail, Farooq Zubairi, Nabeel Sabir, and Nazir Ahmad Zafar. Designing verifiable and reusable data access layer using formal methods and design patterns. Computer Modeling and Simulation, International Conference on, 0:167–172, 2009.

[23] Martin Fowler. Patterns of Enterprise Application Architecture. Addison-Wesley Professional,

2002.

[24] Karen E. Smith and Stanley B. Zdonik. Intermedia: A case study of the differences between relational and object-oriented database systems. In Conference proceedings on Object-oriented programming systems, languages and applications, OOPSLA ’87, pages 452–465, New York, NY, USA, 1987. ACM.

[25] Stephan Philippi. Model driven generation and testing of object-relational mappings. J. Syst. Softw., 77(2):193–207, August 2005.

72

[26] Anthony I. Wasserman. Software engineering issues for mobile application development. In Proceedings of the FSE/SDP workshop on Future of software engineering research, FoSER ’10, pages 397–400, New York, NY, USA, 2010. ACM.

[27] Andre Charland and Brian LeRoux. Mobile application development: Web vs native. ACM Queue, 9:20:20–20:28, April 2011.

[28] Horace Dediu. The Proliferation of Mobile Platforms, September 2011. accessed 21 December

2011.

[29] Sam Alexander.

Building hybrid mobile applications with PhoneGap and IBM WebSphere

Portlet Factory. IBM, 2011.

[30] Lucas Jordan and Pieter Greyling. Practical Android Projects. Apress, 2011.

[31] G. Radhamani and G.S.V. Radha Krishna Rao. Web Services Security and e-business. Idea Group Publishing, 2007.

[32] J.H. Saltzer and M.D. Schroeder. The protection of information in computer systems. Proceed- ings of the IEEE, 63(9):1278 – 1308, September 1975.

[33] Marziah Karch. Android Tablets Made Simple. Apress, 2011.

[34] Sayed Hashimi, Satya Komatineni, and Dave MacLean. Pro Android 2. Apress, 2010.

[35] James Brannan and Blake Ward. iOS SDK Programming. McGraw Hill, 2011.

[36] Hee-Yeon Cho, Choon-Sung Nam, and Dong-Ryeol Shin.

A compariosn of open and closed

mobile platforms. In Electronics and Information Engineering (ICEIE), 2010 International

Conference, volume 2, pages V2–141 –V2–143, August 2010.

[37] Sarah Allen, Vidal Graupera, and Lee Lundrigan.

Pro Smartphone Cross-Platform Devel-

opment: iPhone, Blackberry, Windows Mobile and Android Development and Distribution.

Apress, 2010.

[38] Erica Sadun. The iOS 5 Developer’s Cookbook. Addison Wesley Professional, 2011.

[39] Glenn Bachmann. Hacking BlackBerry. Wiley Publishing, Inc., 2007.

[40] Anthony Rizk. Beginning BlackBerry Development. Apress, 2009.

[41] John M. Wargo. BlackBerry Development Fundamentals. Pearson Education, Inc., 2009.

[42] S. Jones, C. Voskoglou, M. Vakulenko, V. Measom, A. Constantinou, and M. Kapetanakis. Cross Platform Developer Tools. Technical report, VisionMobile, 2012.

[43] Andrew Lunny. PhoneGap: Beginner’s Guide. Packt Publishing, 2011.

[44] Tim Kindberg and Armando Fox. System software for ubiquitous computing. IEEE Pervasive Computing, 1:70–81, January 2002.

73

[45] Eric Evans. Domain-driven design: Tackling Complexity in the Heart of Software. Addison Wesley Professional, 2004.

[46] Frank Ableson. Build dynamic user interfaces with Android and XML. IBM - Developer Works,

2010.

[47] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice. Addison Wes- ley, 2003.

[48] Joseph P. Cavano and James A. McCall. A framework for the measurement of software quality. SIGSOFT Softw. Eng. Notes, 3:133–139, January 1978.

[49] Toimothy Vidas, Nicolas Christin, and Lorrie Faith. Curbing android permission creep. Tech- nical report, Carnegie Mellon INI/CyLab, 2011.

[50] Lide Zhang, Birjodh Tiwana, Zhiyun Qian, Zhaoguang Wang, Robert P. Dick, Zhuoqing Morley Mao, and Lei Yang. Accurate online power estimation and automatic battery behavior based power model generation for smartphones. In Proceedings of the eighth IEEE/ACM/IFIP inter- national conference on Hardware/software codesign and system synthesis, CODES/ISSS ’10, pages 105–114, New York, NY, USA, 2010. ACM.

74