Você está na página 1de 90

SmartAndroid Mobile Enterprise Development

Joo Paulo Sousa Dias Costa Amaro

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

Jury
President: Supervisor: Co-Supervisor: Member: Prof. Doutor Antnio Manuel Ferreira Rito da Silva Prof. Doutor Jos Carlos Alves Pereira Monteiro Eng. Rben Joo dos Santos Paulino Ribeiro de Almeida 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
aventuras. Ha objectivos que se concluem estando sozinho, como se de uma Objectivos de vida sao outros que sao pautados pela presenc aprendizagem interna se tratassem. Ha a de pessoas que nos assim que olho para pr faria sentido. E sao oximas e que nos ajudam, sem as quais a aventura nao 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 zeram a diferenc a... A essas pessoas, a quem estou eternamente grato por terem passado na minha vida, dedico estas palavras. ao meu orientador, o Professor Jose Monteiro, Primeiro, gostaria de mostrar especial gratidao e ao Ruben Almeida da Tecmic. Sempre me acompanharam e sempre me guiaram da melhor e, acima de tudo, com experi teria forma com conselhos, ideias, compreensao encia. Sem eles, nao clara esta tese de Mestrado. Obrigado por acreditarem em sido poss vel concretizar de forma tao ` minha av mim. De seguida gostaria de demonstrar todo o carinho, afecto e apresso a o 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 voc es dedico por ser o resultado e o expoente maximo esta dissertac ao destes anos de trabalho. Havendo coisas que esquecemos facilmente e coisas que nos marcam para sempre, posso armar da minha ess que todo o esforc o que zeram nunca se dissociara encia. Fazem parte de mim, agora realidades apenas possiveis devido a ` e sempre. O que sou, o que consegui e o que quero atingir sao vossa exist encia. se ganha Ainda no campo da fam lia, nos ultimos 6 anos construi uma outra, aquela que nao essa outra fam quando nascemos mas a que se constroi por escolha pr opria. Os meus amigos sao 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. quero deixar passar a oportunidade de dedicar umas linhas a 2 dos membros dessa familia: Nao e as horas que passamos Luciano, nunca vou esquecer o companheirismo, a compreensao juntos ` conversa e a fazer os projectos do curso. Obrigado por teres tolerado com paci a encia os momentos longe, estaras menos bons deste Ribatejano com um pouco de Alentejo. Mesmo sabendo que estas es, por partilsempre perto, um grande abrac o; Pedro, obrigado por tolerares as minhas distrac o hares dos melhores e mais produtivos momentos de brain-storming da minha vida, pela capacidade das tabelas de dispersao... de ouvir e por teres ensinado ao teu caloiro favorito a magia por detras referi por ter muito para escrever e pouco espac A todos os outros, cujos nomes nao o para divagar, gostava de vos dizer, com toda a forc a e assertividade: Obrigado! Muito obrigado por existirem! agradavel Sem voc es nada disto seria tao e cheio de sentido. menos importantes foram o Carlos Simoes, Nao Filipe Martins, Henrique Rocha, Joao Ribeiro, Joel Fernandes, Maria Joao Pereira, Ricardo Leitao e especialMateus, Joao mente ao Pedro pela ajuda nos testes. Foram incansaveis. Obrigado, do fundo do corac ao.

Dias Amaro sempre vosso, Joao v

vi

Resumo
de smartphones e tablets, e com o aumento do suporte para aplicac es empreCom a proliferac ao o es m da maior importancia sariais de soluc o oveis, e ter um ambiente de desenvolvimento apropriado m de comunicac es enpara as necessidades de uma aplicac ao ovel empresarial tais como: gestao o tre dispositivos, camada de acesso a dados, mapeamento entre entidades relacionais e objetos da distribuic de aplicac es, updates e gestao de energia. Devido a ` falta de soluc es de aplicac ao, ao o o ao encontro de todas as funcionalidades mencionadas anteriormente, esta desenvolvimento que vao tese prop oe uma framework com foco nos requisitos e funcionalidades referidos atrav es de uma es ja existentes nas ferramentas de desenvolvimento Android. Esta forma integrada com as soluc o tamb framework consiste numa biblioteca de desenvolvimento para ajudar no processo. Sao em da framework, conclus es relaapresentados o modelo de avaliac ao oes nai, uma analise de soluc o proposta e ainda uma breve discussao dos ecossistemas de desenvolvimento cionadas com a que e m ovel atuais.

Palavras-chave: Android, Plataformas empresariais, Desenvolvimento M ovel, Arquitetura de Software, Ecossistemas M oveis vii

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 management. 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 framework and an analysis of related solutions to the development of mobile applications and about the current major mobile ecosystems.

Keywords:
Mobile Ecosystems

Android, Enterprise Platforms, Mobile Development, Software Architecture,

ix

Contents

Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

v vii ix

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Introduction 1.1 Background on Mobile Ecosystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Choosing a Mobile Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Hardware Prices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Development costs and Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Needed Skill Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 The Relevance of an Integrated Environment . . . . . . . . . . . . . . . . . . . . . . . . 1.4 The Enterprise Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Purpose and Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 4 4 5 6 6 8 8 9 10 11 12 12 14 16 17 19 20 21

1.6 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.7 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Related Work 2.1 Related Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Data Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Remote Communication API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Expressing the application Domain Model . . . . . . . . . . . . . . . . . . . . . . 2.1.4 DAL Data Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5 ORM Object Relational Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Native, Web-based and Hybrid Development . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Native Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

2.2.2 Web-based Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Hybrid Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 NDE Native Development Environments . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Android, Google Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 iOS, Apple Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 BlackBerry OS, RIM Research In Motion . . . . . . . . . . . . . . . . . . . . . 2.4 XDE Cross-Platform Development Environments . . . . . . . . . . . . . . . . . . . . 2.4.1 Rhodes, RhoMobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 PhoneGap, Adobe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Titanium Mobile, Appcelerator Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 System Architecture and Implementation 3.1 Requirements Specication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Architecture Specication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Functional Specication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Development Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Communication Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Persistency Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Framework Evaluation 4.1 Benchmarks Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Communication Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 DAL + ORM: Domain Management . . . . . . . . . . . . . . . . . . . . . . . . .

21 22 23 23 26 29 31 31 32 34 35 38 38 40 44 45 45 50 54 54 56 58 59 59 61 64 65 66 67 68 69 74

4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conclusions and Future Work A Major Cross-Platform Frameworks B Bluetooth Adapter UML C WiFi Adapter UML D Communication Manager UML E Communication Infrastructure UML F Application Development Results Bibliography

xii

List of Tables

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

2 3

xiii

xiv

List of Figures

1.1 Graphic representation for the Market Share of all major platforms. . . . . . . . . . . 1.2 Global Smartphone Penetration. Manufacturer & Market Share [4]. . . . . . . . . . . 1.3 Strong Network Effects for Android and iOS [4]. . . . . . . . . . . . . . . . . . . . . . . 1.4 Weak Network Effects for Symbian, BlackBerry and Windows Phone [4]. . . . . . . . . 2.1 Simple schematic of sending/receiving serialized data through the network. . . . . . . 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). . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Generic communication protocol with several sub-protocol layers [17]. . . . . . . . . . 2.4 Table Data Gateway design pattern [23]. . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Row Data Gateway design pattern [23]. . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Active Record design pattern [23]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Data Mapper design pattern [23]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 Encapsulation of a RDBMS with an object-relational middleware. . . . . . . . . . . . . 2.9 Unit of Work design pattern [23]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.10 Identity Map design pattern [23]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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.12 Major components of the Android system architecture [30]. . . . . . . . . . . . . . . . . 2.13 The hierarchical layers of the iOS framework [36]. . . . . . . . . . . . . . . . . . . . . . 2.14 Sandbox for an iOS application. Source: http://developer.apple.com/. . . . . . . . . . . . . . . 2.15 The BlackBerry Operating System architecture [41]. . . . . . . . . . . . . . . . . . . . 2.16 The Rhodes MVC (Model-View-Controller) model [37]. . . . . . . . . . . . . . . . . . . . xv

2 5 7 7 12

15 15 18 18 18 18 19 20 20

22 25 28 28 30 33

2.17 Titanium Mobile architecture (when developing an Android application) [34]. . . . . . 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 framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 General overview of the communication architecture in a layered interaction model. . 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). . . . . . . . . 3.4 Persistency management architecture, highlighting the interactions between submodules and the decoupling between managers and DAL/ORM layers. . . . . . . . . . 3.5 The implemented inheritance model of the Physical Adapter Layer. . . . . . . . . . . . 3.6 The implemented inheritance model of the Communication Management Layer. . . . 3.7 The implemented inheritance model of the Communication Infrastructure Layer. . . . 3.8 An example of a simple domain model for a school application. . . . . . . . . . . . . . . 3.9 An ilustration of the domain generation procedure. From the example of Figure 3.8. . 4.1 The applications interface created for the evaluation tests. . . . . . . . . . . . . . . . . 4.2 Average LOCs (Android SDK VS SmarAndroid) for both applications. . . . . . . . . .

35

41 41

42

43 46 48 49 52 53 55 57 58 59 64

4.3 Survey answers to the metrics related to the SimpleMessenger application. . . . . . . 4.4 Survey answers to the metrics related to the SaveMyNotes application. . . . . . . . . A.1 List with all the major development platforms . . . . . . . . . . . . . . . . . . . . . . .

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 ow, as described before. For this to happen, employees must work with responsive and versatile devices, such as smartphones, tablets or PDAs 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 Worlds 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 ex1

Table 1.1: Major Mobile Operating Systems Market Share [3]. Mobile OS Symbian Android Blackberry iOS Windows Phone Other OS 2010 (%) 37.6 22.7 16.0 15.7 4.20 3.80 2011 (%) 19.2 38.5 13.4 19.4 5.60 3.90 2012 (%) 5.20 49.2 12.6 18.9 10.7 3.40 2015 (%) 0.10 48.8 11.1 17.2 19.5 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 dene, 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 developers 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, applications 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

by its wide user reach and openness. Microsoft is buying its way into the minds of developers by cosponsoring the porting of many popular apps to its Windows Phone platform. The next table demonstrates the effectiveness of Google, Apple and Microsoft in amassing ecosystems of publishing developers and the associated developer mindshare. Developer investment in Android, iOS, WP7 Platform Publishers4 Average apps/user5 4.1 4.1 3.6 3.6 Mindshare 6
(% of developers using the platform)

Android iOS (iPhone) iOS (iPad) Windows Phone 7

70,000 101,000 36,000 7,000

67% 59% N/A 36%

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

Software players put mobile operators on the defensive


users, which motivates developers to create more applications, which in turn attract more users
The barriers to entry ofplatforms modern smartphone bring a wide spectrum ofAssuming new playersfor into and so on.lower As such, these two generateplatforms huge nancial investments. simmobile ecosystem. can write an Economics app and engage smartphone anyone can bypass plicitythe the example given Anyone in the Developer report of 2012users. fromAnd VisionMobile [5], that a the mobile operator toll-booths.

typical application costs an estimated $10,000 to $50,000 per year to develop, then the approximate
Apple and Google combined control the represent user experience of nearly 400 million users through their iOS 500 thousand available iOS applications a diluted average investment of $15.000.000.000 and Android platforms. Both are strategically reducing the role of mobile operators to that of

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 apcentric strategies to profit from mobile. Start-ups such as Foursquare and Instagram have pioneered connectivity providers. Internet giants like Facebook and Amazon are using social-centric and retail-

plications, being that the total number of applications is frequently considered the main measure mobile-first services. Communication companies like Skype, WhatsApp and Viber put pressure on core of a platforms success, in a very simple way. telecom services, notably SMS and voice. The report referenced last paragraph also that 45% of the users reported using Mobile operators have in yet the to find a success formula forclaries dealing with the disruptions coming from an app store as their primary route to the market. It is possible to relate the sudden popularity software players. 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

Two time-to-market horses lead by the race the average 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
The last decade saw 20+ mobile operating system contenders, from handset makers (MotoMagx, UIQ,

that want to leverage the huge amount of users that are willing to pay for high-end applications, Palm 5/6, OpenMoko), software companies (Intrinsyc Soleus, Sasken Aria, SKY-MAP, TTPCom AJAR, even if the target of Access the two major mobile platforms iOS) is the domestic and Azingo Mobile, ALP, Openwave MIDAS, Mizi (Android Prizm) andand even operators (SavaJe) risesegment and
eventually die not having achieved not the professional/enterprise user. critical mass. However, today smartphone competition is a twohorse race: the smartphone market leadership is virtually divided Apple iOS anda Google Even though this approachOS may not be a scalable one and may between be tending towards technologiAndroid. The two leading platforms share three defining characteristics:

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 applica4 Xyologic, USA market, August 2011] tion business, there is a constant need for applications and development companies to continue to

Xyologic, USA market, August 2011] invest5their money on advertisement for this kind of applications [6]. Related to enterprise budgets
6 [VisionMobile Developer Economics 2011 report] of companies wanting to enter the mobile platform business is the cost for persuading developers

to work for a specic platform. For example, the price of $1 billion dollars spent over by Microsoft in marketing budgets for promoting Windows Phone during the rst year of launch with hands VisionMobile 2011 | www.visionmobile.com

12 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 specic 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 development 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 viable 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 stabilized in the smartphone segment. There are also feature devices (old cellphones with low-end operating systems, such as the Symbian or other vendor-specic OS) which represent the major part of the sold devices, with Nokia and Samsung being the main players in this segment (with an aggregate 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 smartphones 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 mobile 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 mobile 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 Googles alternative. In a very simple market analysis, one can relate the huge amount of Android device manufacturers with the devices 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

Compared to other mobile platforms, Android has greater price flexibility. Available Android devices sell for $100 to $750, with stops at all price points in between. As a result, Android competes with highpriced iPhones in post-paid markets, and with lower-cost Nokia and BlackBerry devices in pre-paid markets. Such pricing versatility has contributed to Androids rapid growth.

Figure 1.2: Global Smartphone Penetration. Manufacturer & Market Share [4].
VisionMobile 2011 | www.visionmobile.com

exibility, 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 lowercost Nokia and Samsung devices in pre-paid markets. Such pricing versatility has majorly contributed to Androids rapid growth.

17

1.2.2

Development costs and Licenses

Android is an open source stack for the development of mobile applications with the Apache Software License 2.01 and, as such, there is no fee associated with the creation of an enterprise business on top of Googles 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 benets of mobile applications in their core businesses.
1 http://www.apache.org/licenses/LICENSE-2.0.html

1.2.3

Needed Skill Set

To develop applications in the Android environment it is necessary to use the Java2 programming language which has an open source General Public License3 . For the iOS, a developer uses Objective-C4 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 additional 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 environment5 , Android also wins by having a free and also well supported development environment. It is critically important that a platform provides developers with efcient 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 reected in the health of their ecosystems. Moreover, developers need to master new tools every time they switch to a new platform. As mentioned before, Android has the benet of using a well-known general purpose programming language and environment.

1.3

The Relevance of an Integrated Environment

Although all the open source and proprietary development environments for the Android system offer a diverse and stable base for application developers based on the ADT6 they lack the support for enterprise systems. Such corporate solutions are usually based on complex and distributed applications, unlike the consumer ones, which are focused on the end-user, usually running within a closed environment dened 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, assuming 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 development platforms, iOS and Android offer the most feature-rich and exible API frameworks. The iOS
2 http://www.oracle.com/us/technologies/java/index.html 3 http://www.gnu.org/licenses/gpl-2.0.html 4 http://www.otierney.net/objective-c.html 5 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html 6 http://developer.android.com/sdk/installing.html

Mobile Platforms: The Clash of Ecosystems

When plotting Blackberry, Symbian and Windows Phone on a graph similar to the network effects graph for iOS and Android, we can see the mixed results of the efforts of the platform owners to establish pronounced network effects.

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

Consistency is key for the success of an application platform; applications must run on all implementations of the platform. For example, imagine if Microsoft Office only ran on Dell computers. A software platform, in contrast, needs flexibility rather than consistency, allowing it to fit the requirements of a wide range of product variants, and reach supply-side economies of scale. It is clear that Apples iOS is a clever implementation of a mobile application platform coming from a company with the right kind of experience and DNA. Strong network effects between users and app developers are inherent to iOS ecosystem design. These network effects have proven to be stronger than Nokias power over its supply chain and distribution channels, and have eventually led to the demise of Symbian. The unprecedented success of Apple iOS is a testament to the advantages of application platforms. All new platforms introduced after the original iPhone - including Android - attempt to copy Apples application platform recipe. Android comes from a company that has plenty of experience with advertising platforms that connect on-line users and advertisers. Its hardly a surprise that Android was designed as a free application platform that makes money by driving traffic to Googles on-line advertising services.

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 exible and more restrictive since it is locked to the costly for its phones, precluding any chance to kick-start a network effect.
Nokia has driven users away from Symbian by positioning Windows Phone as the unambiguous future VisionMobile 2011 | www.visionmobile.com

22

Apple environment, as explained in Section 1.2.2.

Microsoft, on the other hand, is clearly trying to jump-start the network effects of an application

The more integrated a platform for mobile development is, the more it users will positively feedback platform. They have incentivised developers to produce a large amount of apps, but so far
remained the early version of growing. the platform. the system unimpressed in order to with keep the ecosystem Considering that the major metric for plat-

form integration and attractiveness can and be dened with the then, number of native applications Application platforms are Microsofts bread butter. No wonder, that Windows Phone has all in an
the characteristics of an application platform, from high[4] consistency a strong focus calls on app ecosystem versus the number of device shipments in whatto VisionMobile Mobile Network developers. The jury is still out, however, on whether Microsoft can turn Windows Phone into a credible competitor to iOS and Android. For that to happen, Windows Phone must reach a significant market share: the critical mass at which strong network effects begin to take hold between users and application

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 exibility 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 ofcial announcement 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 Microsofts Windows Mobile platform (now discontinued) and RIMs 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 solutions that allow the deployment of the Android OS are much cheaper than other platforms, it is of the utmost importance to reduce the difculties 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 environments with the above mentioned tools and SmartAndroid represents a novel approach to the creation 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 technologies 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 development 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 dene 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 Android 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 objectoriented environment; The provisioning of the Android development environment with Aspect-Oriented Programming (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 Generation, (iv) Annotation Processing and (v) database abstraction without the need for cumbersome conguration routines by the developer.

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 specications for the architecture and functionality are presented. It is also presented the systems implementation strategies, including the several modules of the development library and the Eclipse plugin. Chapter 4 presents and analyzes the dened 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, specically, 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 rst one describes and compares the different possible approaches when developing mobile applications: Native, Hybrid and Web-based development. It is important to dene 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 throughout 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 environment 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 concepts 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 design, (ii) the OSI model and (iii) simple relational database operations. However, the needed concepts, which are based on those three knowledge areas, are described in a sufcient detailed way so that it is possible to understand the denitions 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...

serialization

011010 100110 011000

011010 100110 011000

serialization

Application

Application

Network
011010 100110 011000 011010 100110 011000

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 denition for data serialization, which is, in fact, the most commonly used denition: it is the process of converting a data structure into a sequence of binary data representation with a pre-dened conguration 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 rst 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 transmission 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/efciency 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 specication 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 denitions or web-service contracts 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 2 3 4 5 6 7 8 9 10 11

<?xml version="1.0" encoding="UTF-8"?> <contacts> <contact> <name>Jack Sparrow</name> <phone>123-532-5392</phone> <work>actor</work> </contact> <contact> ... </contact> </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 Programming Language Standard and denes a small set of formatting rules for the portable representation of structured data [11]. JSONs appeal comes from smaller HTTP messages and less complicated syntax, which can provide a signicant 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 benets, 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 2 3 4 5

{ "contacts": { "contact": { "name": "Jack Sparrow", "phone": "123-532-5392", "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 infrastructure. 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 internal 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 protocols 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, independently, 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. Besides 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 protocol 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 exemplies the OSI model with simple layer-to-layer interactions, that greatly benets and resembles an object-oriented system, where objects encapsulate their own behavior and 14

to-end delivery of data, subject to quality of service requirements (e.g., reliable connection-oriented or unreliable connection-less delivery). The distinction is relevant from the perspective that the lower layers are commonly implemented in the operating system and hardware while the upper layers are not.
(N)-service.request (N)-service.indication (N+1)-layer Application Upper Layers Presentation Session (N)-entity Transport Lower Layers Network Data Link Physical (N-1)-SDU (N-1)-entity (N-1)-protoco1 (N-1)-PDUs (N-1)-entity (N-1)-layer (N-1)-SAP (N-1)-SAP (N)-SDU (N)-protocol (N)-PDUs (N)-entity (N)-layer (N)-SAP (N)-SAP

Figure 2.2: Simple interaction structure for the OSI model [17]. In the left3side it is highlighted the FIGURE 1. Layered Peer-to-Peer Interaction Model 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 The OSI model is fundamentally a layered peer-to-peer model of interaction. The familiar layered Access points).

diagram is misleading since it only depicts a layered monolithic structure and omits the peer-topeer aspects of the model. The diagram on the right side of Figure 1 is a more accurate illustration interact with each other in order to orchestrate their unique components and methods to achieve a of the peer-to-peer structure. Interaction among layer entities occurs in two forms: direct and indimore complex output. In the left side of the gure it is represented the complete OSI model with the rect. Direct interaction occurs between vertically adjacent layer entities, related only by the existthree upper layers separated from the four lower ones. paradigm The primary function of the client-server lower layers isinterby a RPC mechanism. The usefulness of the RPC in supporting
3. Adapted in part from [Svobodova 1989].

lated

end-to-end delivery data, subject tothis quality of service (e.g: reliable data actionsto isprovide well known and is notof discussed. In section, the requirements requirements for the OSI upper service transmission TCP or connectionless transmissions UDP). The distinction between the layers are presented. upper and lower layers is relevant from the perspective that the lower layers are commonly imple5 in the a operating system and hardware while the upper layers are created in the application Figure mented 2 illustrates common multi-protocol architecture used to build distributed object-oriented domain. applications in Unix workstation environments.
Object-Oriented Application Infrastructure ISO/CCITT Upper Layer Protocols Transport Switch ISO/CCITT Lower Layer Protocols Internet Protocols

RPC Protocol

Various Subnetwork Technologies

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

FIGURE 2. Unix-Based Multi-Protocol Architecture

Based on the OSI concepts it is possible to2devise a part generic stack with explicit separation The transport switch layer depicted in Figure is not ofprotocol the standard OSI model. The concept between different kinds of transport sub-protocols and network layers (Figure 2.3). This stack of transport switching in OSI was rst introduced by [Rose 1986]. The switch addresses, in an ele-

gant manner, the pragmatic issue of simultaneously using many underlying transport services 15 arising from different transport/network protocol combinations. Different protocol combinations are required due to the varying characteristics of different subnetwork technologies. The primary

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 rst 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 simultaneously 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 requests (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 transportdependent upper layers, a single and consistent transport abstraction corresponding to the specic transport mechanism and respective implementation. This feature can be easily created using subtyping (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 benet from the implementation of good software engineering practices in terms of domain encapsulation. 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 application 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) Cachopos PhD thesis about rich domain models [19], (ii) Mannadiar et al. [20] where the authors studied the synthesis of mobile device applications from domain-specic models and, still, (iii) the work from Kramer et al. [21] where it is proposed a domain specic 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 benets associated with the translation between 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 inuence in late phases of the process, such as the quality assurance and maintenance phases. Besides this, the problem of domain modeling and management was only considered a uent 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 Cachopos work, he presents a way to dene the domain model and, at the same time, reduce the gap between the model denition language and the programming language, being that the DML (Domain Modeling Language) presented has several resemblances with the Java programming language 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-specic models for a given application, where the domain, eventual congurations, documentation, executables and performance models are dened in an integrated way with the help of DSLs (Domain Specic Languages). The purpose was that even non-programmers would be able to rene 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 dene the domain-specic 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-specic 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 benets 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 Patterns of Enterprise Application Architecture [23], discusses design patterns to solve many problems 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 development, 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 signicant 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.
194 S. Philippi / The Journal of Systems and Software 77 (2005) 193207

Object-Oriented Application System

Object Model & Application Logic

API

Object-Relational Middleware

SQL

Relational Database

OR-Mapping Definition

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


1 ing OR-middlewares to modications ofathe application source from code. an Anobject-oriented ap. However, generation capabiliTo access relational database application, there are three approaches proach to overcome these problems is the use of a dedties of software in this area usually only refers to: that can be enumerated as follows [25]: (i) to include SQL statements in the application code. This icated middleware, which decouples relational databases frombreaks object-oriented applications. Fig. 1 shows basic logic(a) The automatic import of object models from class abstraction layers and joins the the business code with the persistency management code. principle of this approach. During the run-time of an diagrams or implementation code into a mapping This can be object-relational cumbersome in complex systems but advantage of being a fast approach when application, the (OR) middleware is has thetool to support the manual mapping to relational congured with application denitions on how (ii) the table structures (forward engineering),in and/or developing very small specic applications or prototypes; encapsulation of SQL statements the object structures have to be mapped to a relational sche(b) the automatic import of existing relational tables domain classes, which is athe better approach the rst one, but although this ma. The SQLdata queries needed to access database are compared into with a mapping tool to support manual mapping then separates dynamically generated by the middleware, which to objectchanges structures engineering), and/or concerns, conforming with object-oriented principles, of(reverse the relational schema thus encapsulates the database from an application (c) the generation of static code to map objects to relastill leads The to modications of the source code; (iii) the of a The dedicated middleware point of view. main advantage of application this principle is tions at usage run-time. latter is only necessary for that that the database schema may be changed without the OR-middlewares, which do not dynamically can decouple relational databases from object-oriented logic altogether (Figure 2.8). This mid- generneed for application source code modications. For ate SQL at application run-time. dleware would be congured denitions and the domain model and would the application to work properly, with only application-specic the mapping specication to be adjusted. With in this category, Object Integrator produceneeds a thin layer of object-relational mapping between the tools database rows and thelike domain objects (Secant Technologies, 2001), EdgeXtend (Persistence However, even if an existing middleware is used for that are managed by the application. using if the schema changes, the decoupling of object-oriented applicationsBy from rela-this approach, Software, and 2002) and database Cocobase (Thought Inc., 2002), tional databases, mappings these dierent the development of object-relational only the mappings must between be changed in order for the persistency management to work. mappings is still a manual task. An approach for the automatic mapping structures need to be specied manually. In this context, forward engineering refers to the mapping of object of object models to relations is described in (Tesch structures to relations, while reverse engineering starts 19 and Volz, 1999). A drawback of the underlying concepts of this proposal is that only object models with structurfrom existing relational structures and maps them to object-oriented ones. The perspective taken throughout ally restricted inheritance hierarchies are covered. In this article is forward engineering. Due to the inherent contrast, the approach taken by TopLink (Object Peo-

Fig. 1. Encapsulation of a RDBMS with an object-relational middleware.

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 straightforward as the Identity Field and Foreign Key Mapping whose rational focus on the fact that all domain entity objects must have an identity eld 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), Identity Map (Figure 2.10) and Inheritance Mapper. The rst 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 distribute 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 hardware 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 specications, 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 hardware, with a designated programming language and this kind of applications. In the case of mobile devices, they make use of all the devices features [26, 27], such as mobile phone cameras or geolocation through GPS systems. Also they use resources more effective and efciently because they were designed for that specic 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 specic development process with different programming languages, features and running hardware with different architectures. Knowing that companies want their applications 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 because, 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 compatible applications in all mobile operating systems, there was still an adaptation problem with these web-based applications [27]. They cannot access the devices hardware because they run on a webbrowser and, because of software security policies, they cannot access the devices le 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 applications, 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 de22

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 devices hardware, and web technologies to render the interface and logic of the applications, developers can create an abstraction layer to the devices heterogeneity [29]. This also allows companies to obtain all the benets 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 benet 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 devices 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 rstly presented in 2007 by Andy Rubin, director for mobile platforms at Google, as the rst 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 developers 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 ve version releases each year, standing out from the competition (iOS) which evolves at a more measured pace. 23

Positioning According to Gartners survey, resumed in the Table 1.1 (on page 2), Android will have a market 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 Googles). The initial versions of Android targeted 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 initiatives 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 makers. 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 inuenced by string support from top US carrier Verizon Wireless, as well as the wide proliferation 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 specic hardware; Native Runtime libraries with graphics rendering, database, security and other components to support the Android framework; Android Runtime, containing both the Dalvik Virtual Machine to run the applications and the frameworks core libraries; Application Framework, written in Java, containing functionalities to be used by the applications.

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 applications resources or interfering with the operating systems normal behaviour. This sandbox enforces xed-solution policies for the execution of mobile applications 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 ofcial Android Market into the devices unless they satisfy Googles Compatibility Denition Document, with no charges associated with the process. For the creation of Android applications, Google released the Android Development Tools1 , which consists of a program and a plugin for the Eclipse IDE2 , extending its capabilities for setting up Android projects, creating user interfaces for the applications, debugging code with integration of the Android SDK and generating Android executable les for applications distribution. Included in the SDK is a mobile device emulator with the Android system installed, compatible with Windows, Mac
1 http://developer.android.com/guide/developing/tools/adt.html 2 http://www.eclipse.org/

25

OS and Linux distributions, that lets the developer test the applications, from a users 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 applications les can only be accessed by the applications user ID. Regarding the execution cycle of the applications, the system uses the principle of the least privilege which forces the developer to dene 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 aws in the applications 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 systems 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 Apples mobile devices was rstly released on the iPhone in June 2007 and, in its early stages, was closed to third-party applications. Only in March 2008 the development 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 Darwin3 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 prots selling iPhone, iPad and iPod devices at a premium price. The unprecedented success of the products helped Apple become the Worlds 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.
3 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 operators 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 denes the applications infrastructure and support for multitasking, touchbased input, data protection, notications 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 devices graphics, audio, and video technologies; Core Services is the layer that contains interfaces for access to the le system, the sockets 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 Xcode4 IDE to manage 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 environment and the iOS Developer Library which has the documentation created by Apple regarding the creation of iOS applications [37, 38].
4 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 Googles Android platform, the iOS developer programs, encompassing ofcial forum support, distribution with the ofcial 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 doesnt 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 applicationlevel permissions (like the Android permissions which must be dened in each application in compile 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 les and resources [38], as shown in Figure 2.14. One other restriction regarding third-party applications is that those applications cant 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 rst BlackBerry device, with more modern communication technologies, such as GPRS (General Packet Radio Service), and also support for Java applications, and its rst adopters were businessmen, whose work was starting to be increasingly dependent on e-mail and remote communications [37, 39]. Positioning BlackBerry devices were the rst 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 companys 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 congure the employees 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 platforms 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 rst two are dened as Oracle standards for Java ME applications: (i) CLDC which stands for Connected Limited Device Conguration, represents a specication targeted at devices 29

with limited resources and capabilities, including streamlined versions of Java ME libraries; (ii) MIDP stands for Mobile Information Device Prole 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 specication and BlackBerry is one of those devices; (iii) when developing applications for RIMs operating system, the developer may also use BlackBerrys specic APIs, breaking the compatibility standards of MIDlets but acessing the BlackBerry devices full features; Java Virtual Machine isolates the applications from the closed operating system and gives the base for BlackBerrys APIs and also for the Java ME specications; BlackBerry Operating System supports the drivers for specic 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 plugin 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 different 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 compatibility. 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 specic 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 RIMs ofcial website, C/C++ applications and HTML5 web applications. This is an expressive response to the decreasing of BlackBerrys 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 developers and administrators can attach to applications so that they can not access specic 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 difculty 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 different 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 nonmobile, 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 devices platform specic 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 difcult 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 devices hardware. Moreover, to allow 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 applications, 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 Nitobi. 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 Adobes 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 PhoneGaps 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 Netix, 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 specic distribution channels. The other aspect is a downside of this framework, and derives from the inability to create cross-platform datadriven applications, such as enterprise applications, since it can not access the devices 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 specic 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 rst half of 2012. Appcelerator also acquired Cocoash in February 2012, with the aim of integrating a host of cloud based platform services, including storage, push notications, 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. Appcelerators 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 devices. Appcelerator claims a developer client base of 250,000 mobile developers, and with the Aptana 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 analysed 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 dened as follows: all the application resources (HTML, CSS and Javascript les) are kept inside the B1 block which represents the directory where the project les 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 devices 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 le (relations L3 and L4). The nal 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 fteen 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 different 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 possi35

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 application, like the MVC pattern described in the Rhodes framework, and others, instead of a dened 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 efciency and full support of the devices features. On the other hand, it is impractical to develop a native application across every active device. The key benet of XDEs is the possibility to create 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 features when a new version of a given mobile OS is released, eventually slowing the adoption rate of security xes. 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 applications 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 community, 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 interact 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 simplies the development process. While small applications may not benet from this additional layer, enterprise-level ones can greatly have their development processes streamlined 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 simplications 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 readability 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 generates 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 encapsulation to the point where testing without a database is quite difcult. For this, it is sometimes considered an anti-pattern. Nonetheless, it simplies 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, Sections 3.1 through 3.3 present the specications for the solution, including requirements, architectural and functional specications. In Section 3.4, the development library is presented, including the framework issues and design strategies actually implemented

3.1

Requirements Specication

In order to design the entire system, some requirements were needed to be taken into account. By doing so, it helps to further dene the frmaeworks scope. The criteria to ascertain some of them as being useful to this framework was related to the absence of tools that could actually fulll 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 unication 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 nd or create all the tools needed to support the mobile application 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 devices 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 modules 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 difcult 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 specication languages for modelling the applications 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 difcult 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 companys network, it can be hard to update an application to its latest version and this can pose security threats or efciency 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 ofce for update. One way of circumventing this situation is with the usage of ofcial distribution channels for the specic 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 interfaces 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 ination 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 Specication

In order to satisfy each requirement presented before, the proposed architecture was designed to be highly modular and congurable. 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 architecture. One can analyze the presented gure as an increment in the Android libraries available to the applications.

Enterprise Applications
SmartAndroid Framework
Communication API Serialization DAL ORM Update Management ()

Energy Management

Android Runtime Libraries


Android OS
Figure 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 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, allowing 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 physical 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 congures all the aspects related to message exchange procedures between two endpoints within a given technology and, nally, (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 congurations related to communication 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 granular 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

Configuration API

Communication Infrastructure

WiFi Communication Manager

WiFi Stack Wifi Comm Manager Wifi Adapter

Bluetooth Stack Bluetooth Comm Manager Bluetooth Adapter

WiFi Adapter

Android WiFi Libraries Android Libraries

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 gure, 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 gure 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, congurations 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 gure it is also possible to denote a Conguration API that is connected to each of the sub layers of the stacks. This API acts as a central repository for the framework congurations and can be reused throughout the SmartAndroid modules. Each layer is locked to a specic set of congurations, so it is not possible to miscongure a layer with other layers congurations. In this specic case, it is possible to see the interaction between the upper Infrastructure layer and the lower one, since the Communication Stack manages the congurations for all of them. Associated with the communication infrastructure is the serialization mechanisms of the SmartAndroid framework. It is possible to associate a message serializer with a communication manager. It can be changed by conguration and is associated with every message that is sent/received by that specic manager. This architecture allows for further creation of specic 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 Custom ORM Custom DAL

Android OS
Runtime Libraries

Object Relational Mapping Data Access Layer

SQLite Database

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

Another module of the SmartAndroid environment, that greatly benets from a layered architecture, is the data persistency module, depicted in Figure 3.4. This module holds the DAL and ORM layers as shown in the gure. The DAL sublayer is responsible to the database access procedures, 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 lowlevel 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 instance, in the gure 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 Specication

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 benet 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 communication. 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 conguration 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 congurations. Every functional block that needs to store, retrieve and change congurations can do so by using a Conguration Holder that can be locked to a specic kind of conguration 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 congurations, 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 le (.apk le) and update the application based on that remote le. 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 functionalities: (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 conguration 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 incorporate functionalities such as device discovery, pairing and Bluetooth prole handling; The creation of a communication layer that acts as a hub for delivery and reception of mes44

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 communication 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) congured 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 dene 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 diagrams 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 Specication, 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>

<interface>

Bluetooth API

WiFi API

<interface>

Physical Adapter
Configuration Holder
<BluetoothConfig>
(AOP)

Configuration Holder
<WiFiConfig>
(AOP)

Bluetooth Adapter

WiFi Adapter

<bind> BluetoothConfig

<interface>

<bind> WiFiConfig

Configurable<ConfigType>

Figure 3.5: The implemented inheritance model of the Physical Adapter Layer. The main implementation points, for the adapters logic in this layer, are the BluetoothAdapter and the WifiAdapter classes shown with a bolder outline in the gure. 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 dene yet another Wi 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 gure, both adapters implement the API dened 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 conguration parameters, each specic adapter is required to implement yet another interface to standardize each technologys 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 asynchronous 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 gure, 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 t 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 adapters attributes and force that adapter to implement the same interface. By doing this, the architecture stays true to its modular nature and isolates the conguration 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 Googles 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 otherwise. 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 framework, 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 dene 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 object 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 technologys features is different. This heterogeinity can be unied 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 messagerelated mechanisms. The architecture of this layer can be observed in Figure 3.6
<abstract>

ConnectionEstablishedCallback <ConnectionEndpoint, ConnectionHandler>


<abstract>

Connection Handler
<interface>

<abstract>

Connection Endpoint

ConnectionReceivedCallback <ConnectionHandler>

<interface>

<abstract>

Configurable<ConfigType>

Communication Manager <A, B, C, D>


<bind> WiFiConfig

<abstract>

Callback Handler

(AOP)

<bind> A:WifiConnectionEndpoint B:WifiConnectionHandler C:WifiConnectionReceivedCallback D:WifiConnectionEstablishedCallback

Configuration Holder
<WifiConfig>

WiFi Communication Manager

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

The rst point of analysis in this gure is the WifiCommunicationManager class, which holds conguration 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 denition. 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 specic 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 conguration 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 gure the relations and bounds between the CommunicationManager and the generic types. The rst 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 specic serialization and message delimiting strategies with high48

level procedures and, with the method sendMessage(Message), it sends a message in a nonblocking 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 congurations, which allows them to serialize themselves and be handled by every callback in a transparent way, provided that the messages obey the dened contract. The callbacks that are dened in the structure of the CommunicationManager class also have their structures locked to specic endpoints and connection handlers so that it is not possible to dene a manager for Bluetooth, for instance, with callbacks for the WiFi technol ogy.

<interface>

Communication Stack

Bluetooth Communication Stack


1 1

Communication Infrastructure

WiFi Communication Stack


1 1

Bluetooth Communication Manager Bluetooth Adapter

<interface>

WiFi Communication Manager WiFi Adapter

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 managers 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 technology being used by the application at a given time is inferred by the class types and the specic 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 Appendices B to E.

3.4.2

Persistency Management

To manage the application persistent storage in the local database, the SmartAndroid offers a feature that encapsulates a DAL and ORM layers to create an integrated domain management scenario. With it, it is possible to dene 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, discussed 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 analyzed 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 efciency 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 nal 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 frameworks case were derived from those in ORMLite. They can be assigned to the domain objects attributes as standard Java annotations and are listed as follows: CanBeNull: Whether the eld can be assigned to null or have no value. Default is true. ColumnName: When a domain entity eld 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 eld will be used instead. 50

DataType: The DataType associated with the eld. If not set then the Java class of the eld 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 eld cannot be automatically determined. Type handling is inherited from the ORMLite library. DefaultEnumValue: If the eld 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 denitions. DefaultValue: The default value of a generic eld when creating the table. Default is none. ID: Used to identify this eld as the ID of the domain eld. Default is FIELD ID and the object dened by this eld 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 dened with the name of the database sequence to generate this eld. Only one eld can be marked as the table ID. Indexable: This will tell the database to create an index with the name of this eld. 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 specied elds. Reference: Identies the eld as corresponding to another class that is also stored in the database. The eld must not be a primitive type and the other class must have an id eld (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 eld set. This behavior is called lazy loading. StringLength: Integer width of the eld. Default is zero which means to take the data-type and database-specic 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 denition of the domain model which, in the SmartAndroid framework, is dened by the denition of a class with the annotation @DomainModel, so that the system knows where to look for the domains root. This annotation can be congured to change the database name or version if needed. Similarly, a domain entity can have its corresponding table name changed by annotating the entity denition with @DomainEntity. In Figure 3.8 a simple domain denition is exemplied. 51

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

@DomainModel(value = ist.db, version = 3) class JustAnApplicationDomain { class Student { @ID(IdType.AUTO_GENERATED) int studentID; @Unique String name; @Reference List<Subject> subjects; } @DomainEntity(tableName = ClassSubject) class Subject { @ID(IdType.AUTO_GENERATED) int subjectID; String name; @StringLength(200) String description; @Reference Teacher teacher; } class Teacher { @ID(IdType.AUTO_GENERATED) long teacherID; @Reference @ColumnName(classesTaught) List<Subject> subjects; @Reference List<Student> students;

}
}

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 specied 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 dened 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 denition, parse it and (ii) generate the appropriate DAL layer, instantiating the local database, changing it if it must and, nally, (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 Definition
Business Logic

Domain Entities: Student Subject Teacher

Java Preprocessor

1 2 3
010101010 010101010 101110101 010101010 101110101 000100101 101110101 000100101 000100101

3 artifacts

Domain Objects: StudentBase.java SubjectBase.java TeacherBase.java

Data Access Layer

6 artifacts

Proxy Objects: Student.java Subject.java Teacher.java

Android OS
SQLite Database

Runtime Libraries

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 denition 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 frameworks benchmark. 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 specic results for the two major tested areas of the framework will follow and, nally, 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 nal 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 ve 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 bachelors 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 rst process consisted in the development 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 users 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 primitives 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 question areas: the rst is about general questions about the developer including the knowledge about 55

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

4.2

Evaluation

The focus of the proposed frameworks 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 specic 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 dened rules and should be used by software engineers to provide deeper insights about the softwares 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 x an error in an operational program. Will be measure by the surveys response; 4. Extensibility: to test whether the application can be easily extended to add new features and will be measured by the surveys 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

In order to determine which lines of code would matter to the statistics, they were ltered according to the following characteristics: (i) Android-specic 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, regardless 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 identied 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 introduced 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

Average LOC aggregated by Testers Group

180

Lines of Code (LOC)

160 140 120 100 80 60 40 20 0

1 Android

2 SmartAndroid

3 Android

4 SmartAndroid

SimpleMessenger App

SaveMyNotes App

Juniors

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 persistency 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 element). Some developers sugested some improvements in the frameworks 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 summarized 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 Googles framework as being mainly bad rated.

SimpleMessenger - Android
Usability Very Good Good 11% 33% Portability 22% 33% Extensibility 11% 22% Maintainability 11% 33% Test Easiness 0% 44%

Bad
Very Bad

56%
0%

44%
0%

56%
11%

56%
0%

33%
11%

SimpleMessenger - SmartAndroid
Usability Portability Extensibility Maintainability Test Easiness

Very Good
Good Bad Very Bad

22%
56% 11% 0%

11%
78% 0% 0%

33%
56% 0% 0%

56%
33% 0% 0%

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 module 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 denition 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 difcult 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 Figure 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 difculty 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 elements were not present in the juniors 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
Usability Very Good Good Bad Very Bad 0% 0% 44% 22% Portability 0% 11% 44% 11% Extensibility 0% 11% 56% 0% Maintainability 0% 11% 56% 0% Test Easiness 11% 22% 33% 0%

SaveMyNotes - SmartAndroid
Usability Very Good Good 56% 33% Portability 56% 22% Extensibility 33% 22% Maintainability 22% 56% Test Easiness 22% 11%

Bad
Very Bad

0%
0%

0%
0%

11%
0%

0%
0%

33%
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 difculty 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 surveys 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 conrmed the necessity of having more highly semantic frameworks in order to streamline the application 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, allowing high-level abstraction to be easy to use and accessible; One cumbersome task, identied 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 support 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 Googles 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 nd 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 applications with Android: (i) it will integrate in the development environment all the needed functionalities identied 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 Android 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 applications 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 interesting to offer an integration of the SmartAndroid core libraries in the Eclipse IDE. This would fairly reduce the amount of conguration 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 congure 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 benet 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 applications 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 t into a 32bit integer, forcing the developer to use reection mechanisms 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 difcult 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 problem is ofter referred as the Android permission-creep problem [49]. A feature that would automatically 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 benet 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 specic 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 ne-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 difcult task to the developer. Related to the architecture and the ways through which the application uses the system features, there is a lot of room for improvements in the WiFi management solution proposed. The Android SDK wi modules are tightly coupled with the system services that originate them and they can be simplied to offer a simpler API to the application. Some work was done in the area but further renements 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 identied bugs, mainly in the broadcast events of the platform, were ofcially 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 possible comparison with similar features in the Android SDK, mainly the central update manager and the conguration 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

Tool Vendor Shoot-out

A
Tool Type Web code wrapper Runtime Framework Runtime IDE, Runtime Authoring HTML5, CSS, JS ActionScript Lua, Corona API HTML, CSS, JavaScript WYSIWYG, Forms, Lua HTML, CSS, JS C++ with Marmalade APIs C++. HTML5 HTML, Ruby, Rhodes APIs Templates, WYSIWYG HTML, CSS, JS, BiscuitML Visual design, LiveCode language C++ with Qt APIs, QML, HTML JavaScript Output Hybrid web apps swf Flash player files Native Native (primarily), Hybrid and Web apps (beta)

This chapter presents detailed profiles for 15 major vendors of cross platform tools. We begin by listing the key characteristics of each vendor, the platforms they target and the developer sentiments towards each tool, based on our developer survey. CROSS-PLATFORM VENDORS REVIEWED

Major Cross-Platform Frameworks

Company Adobe (Nitobi, 2011) Adobe Ansca Mobile Appcelerator

Product PhoneGap Flash Platform Corona Titanium

Founded 2008 1982 2008 2007

Seregon IBM Ideaworks 3D, Ltd. MoSync Motorola (RhoMobile) Netbiscuits

DragonRad Worklight Marmalade

2001 2006 (Worklight) 1998

Runtime Enterprise app platform Source code translator (compiler) IDE, Runtime Runtime Framework Platform services IDE Runtime Framework, Runtime

Native, Hybrid, Web Native

MoSync Rhodes BiscuitsML

2004 2008 2000

Native Native Web apps, Hybrid

RunRev

LiveCode

1997

Native

Qt Development Frameworks (Nokia/Digia) Sencha

Qt

Trolltech 1994 Nokia acq. 2008 2007

Native, Hybrid

Touch

Unity Technologies Xamarin

Unity

2004

Framework, Webcode wrapper (v2.0) Games engine

Hybrid, Web apps

MonoTouch Mono for Android

2011

Runtime, OS abstraction

C#, JavaScript, Boo, creative tools C#, .NET libraries

Native

Native

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

source: VisionMobile research

B
Bluetooth Adapter UML

65

C
WiFi Adapter UML

66

D
Communication Manager UML

67

E
Communication Infrastructure UML

68

SimpleMessenger - Developer LOCs

120

100

80

60

Lines of Code (LOC)

40

Application Development Results

69
D 80 43 46,25% 46,55% 16,22% 40,32% 40,48% 31 31 37 50 37 42,19% 58 37 62 84 64 E F G H I J 96 47 51,04%

20

Android LOCs

90

85

79

SmartAndroid LOCs

48

37

57

% Gain

46,67%

56,47%

27,85%

Android LOCs

SmartAndroid LOCs

SaveMyNotes - Developer LOCs

300

250

200

150

100

Lines of Code (LOC)

70
B 71 11 84,51% 96,95% 93,85% 5 52 15 4 95,58% 113 238 250 97 C D E F G 53 17 67,92%

50

H 123 21 82,93%

I 131 4 78,15%

J 130 8 94,00%

Android LOCs

243

SmartAndroid LOCs

% Gain

96,71%

95,88%

Android LOCs

SmartAndroid LOCs

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):115, December 2009. [2] iPass Aliance. Mobile Workforce Report September. Technical report, iPass Alliance, 2012. [3] C. Milanesi and R. Cozza. System, 2008 - 2015. Mobile Communication Devices by Open Operating Extended Abstract at

Technical report, Gartner, 2011.

http://www.gartner.com/it/page.jsp?id=1622614. [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 182185, Washington, DC, USA, 2011. IEEE Computer Society. [11] Douglas Crockford. RFC 4627 - The application/json Media Type for JavaScript Object Notation (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 denition, recommendations 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:330351, 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 INFOCOM98, pages 765773, 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):159173, March 1986. M. P. Cachopo. Development of Rich Domain Models with Atomic Actions. PhD thesis, [19] Joao Instituto Superior T ecnico - Universidade T ecnica de Lisboa, July 2007. [20] Raphael Mannadiar and Hans Vangheluwe. Modular synthesis of mobile device applications from domain-specic models. In Proceedings of the 7th International Workshop on Model-Based Methodologies for Pervasive and Embedded Software, MOMPES 10, pages 2128, New York, NY, USA, 2010. ACM. [21] Dean Kramer, Tony Clark, and Samia Oussena. Mobdsl: A domain specic language for multiple mobile platform deployment. In NESEA, pages 17. IEEE, 2010. [22] Faheem Sohail, Farooq Zubairi, Nabeel Sabir, and Nazir Ahmad Zafar. Designing veriable and reusable data access layer using formal methods and design patterns. Computer Modeling and Simulation, International Conference on, 0:167172, 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 452465, New York, NY, USA, 1987. ACM. [25] Stephan Philippi. Model driven generation and testing of object-relational mappings. J. Syst. Softw., 77(2):193207, 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 397400, New York, NY, USA, 2010. ACM. [27] Andre Charland and Brian LeRoux. Mobile application development: Web vs native. ACM Queue, 9:20:2020: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. Proceedings 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 V2141 V2143, August 2010. [37] Sarah Allen, Vidal Graupera, and Lee Lundrigan. Pro Smartphone Cross-Platform Development: iPhone, Blackberry, Windows Mobile and Android Development and Distribution. Apress, 2010. [38] Erica Sadun. The iOS 5 Developers 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: Beginners Guide. Packt Publishing, 2011. [44] Tim Kindberg and Armando Fox. System software for ubiquitous computing. IEEE Pervasive Computing, 1:7081, 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 Wesley, 2003. [48] Joseph P. Cavano and James A. McCall. A framework for the measurement of software quality. SIGSOFT Softw. Eng. Notes, 3:133139, January 1978. [49] Toimothy Vidas, Nicolas Christin, and Lorrie Faith. Curbing android permission creep. Technical 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 international conference on Hardware/software codesign and system synthesis, CODES/ISSS 10, pages 105114, New York, NY, USA, 2010. ACM.

74

Você também pode gostar