You are on page 1of 60

UNIVERSITATEA BABE-BOLYAI CLUJ-NAPOCA FACULTATEA DE MATEMATIC I INFORMATIC SPECIALIZAREA INFORMATICA - ENGLEZ

LUCRARE DE DIPLOM

Aplicaia CODER (Control Device Remotely)

Conductor tiinific Lect. Dr. Dan Mircea Suciu Absolvent Raul Rene Lepa Grunfeld

2012

BABE-BOLYAI UNIVERSITY CLUJ-NAPOCA FACULTY OF MATHEMATICS AND COMPUTER SCIENCE SPECIALIZATION COMPUTER SCIENCE - ENGLISH

DIPLOMA THESIS

CODER (Control Device Remotely) application

Supervisor Lect. Dr. Dan Mircea Suciu Author Raul Rene Lepa Grunfeld

2012

Abstract

This study discusses mobile application development and in particular the possibilities given by cloud to device communication. As mobile devices have become indispensable in the modern day-to-day life, mobile computing has advanced rapidly in the last years, providing new and interesting functionalities and also having the advantage of portability. Once the new possibilities given by mobile computing emerged, there appeared the need of making them communicate with other devices, home computers, or servers, which all together form the Internet cloud. Thus, Cloud computing started to play an important role in mobile device application development, allowing data synchronization and remote control over the Internet.

Keywords: mobile device, mobile development, mobile operating system, cloud computing, remote device control This work is the result of my own activity. I have neither given nor received unauthorized assistance on this work.

Table of contents
1. Introduction .................................................................................................................................. 1 2. Mobile Application Development ................................................................................................ 2 2.1 Mobile devices ....................................................................................................................... 2 2.2 Mobile Operating Systems ..................................................................................................... 4 2.2.1 A brief history of execution environments ...................................................................... 4 2.2.2 Mobile OS market shares ................................................................................................ 5 2.3.3 Customer loyalty by operating system ............................................................................ 7 2.3 Mobile application development process ............................................................................... 8 2.3.1 Overview ......................................................................................................................... 8 2.3.2 History and development of mobile applications ............................................................ 8 2.3.3 The next generation of mobile applications .................................................................... 9 2.3.4 Native and portable code in mobile application development ...................................... 11 3. Mobile cloud computing ............................................................................................................ 15 3.1 Cloud computing .................................................................................................................. 15 3.1.1 Generalities.................................................................................................................... 15 3.1.2 Cloud computing models .............................................................................................. 16 3.2 Mobile cloud computing ...................................................................................................... 18 3.2.1 Generalities.................................................................................................................... 18 3.2.2 Mobile cloud services .................................................................................................... 20 3.2.3 Device synchronization with mobile cloud services ..................................................... 21 3.3 Cloud to device messaging ................................................................................................... 22 3.3.1 Mobile Cloud Middleware ............................................................................................ 22

3.3.2 An overview of Android Cloud to Device Messaging Framework............................... 24 3.3.3 Android C2DM architecture and lifecycle ................................................................... 25 4. CODER Application Design ...................................................................................................... 28 4.1 Introduction to CODER ....................................................................................................... 28 4.2 CODER Design Model......................................................................................................... 29 4.2.1 Application Architecture ............................................................................................... 29 4.2.2 Package structure........................................................................................................... 29 4.2.3 Database structure ......................................................................................................... 30 4.3 CODER Analysis Model ...................................................................................................... 31 4.3.1 Use case diagrams an corresponding use cases ............................................................. 31 4.3.2 Sequence diagram ......................................................................................................... 33 4.3.3 Class diagram for the third-party application server ..................................................... 34 4.3.4 Class diagram for the receiving devices Android application ..................................... 37 5. CODER User Manual ................................................................................................................. 39 5.1 Application overview ........................................................................................................... 39 5.2 CODER instruction receiver application (Android) ............................................................. 40 5.2.1 Overview and requirements .......................................................................................... 40 5.2.2 Usage ............................................................................................................................. 41 5.3 CODER main controller (Web) ............................................................................................ 42 5.3.1 Overview and requirements .......................................................................................... 42 5.3.2 Usage ............................................................................................................................. 42 5.4 CODER alternative controller (Android) ............................................................................. 48 5.4.1 Requirements ................................................................................................................. 48 5.4.2 Usage ............................................................................................................................. 48

5.5 Similar existing applications ................................................................................................ 50 5.6 Future application improvements ......................................................................................... 51 6. Conclusions ................................................................................................................................ 52 Bibliography ................................................................................................................................... 53

1. Introduction

The concept of mobile applications has become very central in the last years, and has a great impact on our lives. Mobile computing has advanced rapidly, due to peoples needs of virtual communication and access to information from anywhere and at any moment. Together with cloud computing, they represent a promising solution for the near future, at least. The way that people use mobile devices know has changed a lot, compared to just a few ago. Internet access is now taken for granted and mobile applications have evolved in order to fulfill this need. The general purpose of this thesis is to investigate mobile application development, especially the mobile cloud computing aspect of it and to provide an application example for this field. In particular, the papers second chapter, Mobile Application Development, presents historical information related to mobile computing and execution environments, statistical information regarding mobile operating systems and aspects of mobile development in general. The third chapter, Mobile Cloud Computing, is focused on cloud computing and mobile cloud computing in particular. It also analyzes cloud to device synchronization and messaging solutions and introduces Googles Android Cloud to Device Messaging Framework (or C2DM). The fourth chapter, CODER Application Design, introduces CODER, an application that makes use of the above-mentioned C2DM, and has the purpose of presenting its design and architecture and providing an analysis model for it. The fifth chapter, CODER User Manual, is intended to offer functional specifications for the CODER application, followed by the last chapter that consists of the thesis conclusions.

2. Mobile Application Development

2.1 Mobile devices

A mobile device (also known as a hand-held device, hand-held computer or simply hand-held) is a small, hand-held computing device, typically having a display screen with touch input and/or a miniature keyboard and weighing less than 2 pounds (0.91 kg). Apple, HTC, LG, Motorola, Research in Motion (RIM), and Samsung are just a few examples of the many manufacturers that produce these types of devices . A hand-held computing device has an operating system (OS), and can run various types of application software, known as apps. Most hand held devices can also be equipped with Wi-Fi, Bluetooth and GPS capabilities that can allow connections to the Internet and other Bluetooth capable devices such as an automobile or a microphone headset. A camera or media player feature for video or music files can also be typically found on these devices along with a stable battery power source such as a lithium battery. Early pocket-sized ones were joined in the late 2000s by larger, but otherwise similar tablet computers. As in a personal digital assistant (PDA), the input and output are often combined into a touch-screen interface. Smartphones and PDAs are popular amongst those who wish to use some of the powers of a conventional computer in environments where carrying one would not be practical. Enterprise

digital assistants can further extend the available functionality for the business user by offering integrated data capture devices like barcode, radio-frequency identification (RFID) and smart card readers. There are various types of mobile devices, including: mobile computers, digital still cameras (DSC), digital video cameras (or digital camcorders), mobile phones, feature phones, smartphones, pagers, personal navigation devices (PND) and tablet computers. Every day we hear about the innovation of new applications and services for mobile phones that facilitate users to perform routine work through their mobile devices, such as paying utility bills, purchasing online tickets, observing the stock, obtaining directions, observing weather reports, news and television, in addition to the calling and text-messaging facilities [1]. In fact, a report by LogicaCMG from the United Kingdom shows that more than one-fifth of the mobile phone users world-wide use their devices for obtaining these types of information through the internet [2]. The innovation of mobile phone applications and services has speeded up due to the major influence of internet on telecommunication in last two decades. The growth of wireless applications has made it possible for users to use their mobile phones as more than just simple voice communicators [3]. A high-tech mobile device can offer high resolution LCD display with high quality image, text, audio and video features. The usage of wireless industry has been increasing dramatically for the last two decades, and its definitely going up. The development of new wireless standards are one of the reasons for this, as the latest standards tend to have a larger flow of data and a lower price. Network operators are forced to adapt to these standards and to the latest technologies in order to keep-up with competitors. As an example of their adaptation, in the USA network operators are transferring their networks from AMPS (Advance Mobile Phone Services) to TDMA (Time Division Multiple Access) and CDMA (Code Division Multiple Access) in order to provide better quality services to their users. In the meantime, GSM technologies open up to new internet-related data services (like email, browsing, file transferring, etc.), as well as high-quality voice services. [4]

2.2 Mobile Operating Systems

2.2.1 A brief history of execution environments

Android, iOS, BlackBerry, HP webOS, Symbian OS, Bada from Samsung, and Windows Mobile support typical application binaries as found on personal computers with code which executes in the native machine format of the processor (the ARM architecture is a dominant design used on many current models). Theoretically speaking, the first real Operating System for mobile devices was Symbian OS, the first device marketed as a smartphone being the Ericsson R380 Smartphone in 2000 which used Symbian. Later that year, also on a Symbian platform, the Nokia 9210 communicator was introduced, which was the first coloured-screen device produced by Nokia. Historically speaking though, in 1996 the Palm Pilot 1000 personal digital assistant is introduced, alongside its Palm Operating System. Symbian was the number one smartphone platform by market share from 1996 until 2011 when it dropped to second place behind Google's Android OS. In February 2011, Nokia announced that it would replace Symbian with Windows Phone as the operating system on all of its future smartphones1. This transition was completed in October 2011, when Nokia announced its first line of Windows Phone 7.5 smartphones. Nevertheless, Nokia is committed to support its Symbian-based smartphones until 2016, continuing to release OS improvements. In 2002 RIM released their first BlackBerry devices with integrated phone functionality and shifted the positioning of their products from 2-way pagers to email-capable mobile phones. The BlackBerry line evolved into the first smartphone optimized for wireless email use and had achieved a total customer base of about 32 million subscribers by December 2009 [5]. It was only in 2007 that Apple Inc. introduced its first iPhone. It was initially costly, priced at $499 for the cheaper of two models on top of a two year contract. One of the first mobile phones
1

CBC News - Nokia, Microsoft in pact to rival Apple, Google - Technology & Science, 11-02-20011

to use a multi-touch interface, the iPhone was notable for its use of a large touchscreen for direct finger input as its main means of interaction, instead of having a stylus, keyboard, and/or keypad, which were the typical input methods for other smartphones at the time. The iPhone featured a web browser that Ars Technica then described as "far superior" to anything offered by that of its competitors [6]. In July 2008, Apple introduced its second generation iPhone with a lower list price starting at $199 and 3G support2. Released with it, Apple also created the App Store, adding the capability for any iPhone or iPod Touch to officially execute additional native applications (both free and paid) installed directly over a Wi-Fi or cellular network, without the more typical process at the time of requiring a PC for installation. Applications could additionally be browsed through and downloaded directly via the iTunes software client, rather than by searching through multiple sites across the Internet. Featuring over 500 applications at launch, Apple's App Store was immediately very popular, quickly growing to become a huge success3. The Android operating system for smartphones was released in 2008. Android is an open-source platform backed by Google, along with major hardware and software developers (such as Intel, HTC, ARM, Motorola and Samsung, to name a few), that form the Open Handset Alliance4. The first phone to use Android was the HTC Dream, branded for distribution by T-Mobile as the G1. Third-party apps are available via Google Play (released October 2008 as Android Market), including both free and paid apps. The Bada operating system for smartphones was announced by Samsung on 10 November 2009. The first Bada-based phone was the Samsung Wave S8500, released on June 1, 2010 [7].

2.2.2 Mobile OS market shares As it can be seen from Figure 2.1 on the next page, the year 2010 saw the rapid rise of the Google Android operating system from 4 percent of new deployments in 2009 to 33 percent at the beginning of 2011 making it share the top position with the since long dominating Symbian
2 3

Apple Press Info iPhone 3G on Sale Tomorrow, July 2008 Apple Press Info iPhone App Store Downloads Top 10 Million in First Weekend, July 2008 4 Open Handset Alliance Alliance members

OS5. The smaller rivals include Blackberry, iOS, Samsung's recently introduced Bada, HP's heir of Palm webOS and the Microsoft Windows Phone OS which is now supported by Nokia.

Figure 2.1 - World-wide smarphone sales (%) starting from 2007

Figure 2.2 - World-wide smartphone sales (thousands of units) starting from 2007

In the fourth quarter of 2010, Android surpassed Symbian as the most common operating system in smartphones, with 32.9 million units sold versus 31.0 million. Android-equipped phones sold seven times more than in the prior year. Comparing Figure 2.2 to Figure 2.1 one can easily observe that although Symbian had a clear leadership of the world-wide smartphone sales until late 2009, the number of units sold was under 25 000 per quarter, whereas the current sales leader Android is selling almost 4 times as much. This denotes the fact that the smartphone market has exploded from 2009, directly impacting world-wide sales of feature phones which have been decreasing dramatically ever since. As far as Application Store revenues are concerned, Apple is the indisputable leader, having over 80% of the total revenues in 2010 and over 70% in 2011. A study done by iCrossing every February shows the market shares of mobile operating systems in 15 countries. As far as the last study from February 2012 is concerned, the 3 most used are Android, Symbian and iOS.

Mobile Phone Development Gartner Q3 2010, November 2010

The differences between regions and neighbor countries are sometimes surprisingly large. As it can be observed Figure 2.3 (on the next page), the iOS leads in the USA, UK, Germany and France, but BlackBerry even though it is the second in the UK, its almost inexistent in Germany, France or the USA.

Figure 2.3 - iCrossing study of the mobile market shares in 4 countries with big economic power

The same study shows that Androids strongest market is in South Korea, having a stunning 90% of the total market shares [8].

2.3.3 Customer loyalty by operating system

Customer loyalty gauges the likelihood that the user of a smartphone platform whose contract has expired or who has broken or lost their phone will repurchase another one that uses that same platform. According to a survey of more than 6,000 smartphone users through 2010 by mobile analytics firm Zokem, the top five loyalty scores for smartphone platforms are the iPhone at 73%, followed by Google's Android at 40%, Samsung's Bada at 33%, RIM's BlackBerry at 30%, and Symbian at 23%. Windows Mobile and Palm follow at 10% each6.
6

Arbitron Mobile In the US Market, iPhone Outperforms Other Mobile Platforms in User Loyalty, January 2011

2.3 Mobile application development process

2.3.1 Overview

Mobile application development is the process by which application software is developed for low-power hand-held devices such as personal digital assistants, enterprise digital assistants or mobile phones. These applications are either pre-installed on phones during manufacture, can be downloaded by customers from various mobile software distribution platforms, or web applications delivered over HTTP which use server-side or client-side processing (e.g. JavaScript) to provide an "application-like" experience within a Web browser. Generally a mobile application is a kind of software running on a mobile device. More concrete, it could be described as an application supporting interoperability and mobility. This is where mobile application differ most from static applications. A user should be able to employ a mobile device and the mobile applications installed on it on the go [9].

2.3.2 History and development of mobile applications

Considering the development of mobile applications, the last years have been quite interesting, as in previous years mobile application development was rather anonymous, with the hardware retaining the actual development and with no standards available for developers. In the beginning, designing and developing mobile applications was all about compromising. The goal was to make the device as small as possible with a high capacity of power source, offering the user the capability of making calls on the go. The thought of being able to make telephone calls from wherever you are was quite astonishing back then, and no one expected mobile devices to be able to act like computers [9]. In order to bring optimizations and improvements the software had to be rather small and not very intelligent.

To make a short summary, the usage of mobile phones begun in the 1980s with analog devices that supported voice traffic only. It was only in December 1992 that the first SMS (or Short Message Service) was sent7. The SMS was probably the first step in making the user interact with the device in a new way, and as a result the display began to change in being more user-friendly. Also, applications started to be a little more complex, in order to make the SMS writing experience more comfortable for the user. The next important step in the development of mobile devices was to speed up the data transfer, the first big breakthrough happening in the beginning of 2000 when a mobile phone was able to transfer data with up to 2Mb/s. This meant that the gap between fixed networks and mobile networks became smaller, which indeed opened up for broadband internet on mobile devices, letting the user read e-mails and visit Internet sites. From that point, both the user and developer realized what a mobile device was capable of and the demands on applications and devices became bigger [10]. From the point when mobile phones became capable of connecting to the Internet the devices have become smaller, but with an increasing computing power and decreasing power consumption. Today almost every mobile phone is equipped with a camera, GPS, Bluetooth and so on making it a multimedia device and the market for mobile devices has become huge. Standards are getting established for mobile computing, APIs and Operating Systems are being developed. The business world depends on mobile solutions and developers have discovered this new field for creating software solutions [9].

2.3.3 The next generation of mobile applications

In the Overview subchapter a definition of mobile applications was given. A next generation mobile application is a mobile application that also has to offer context awareness, to be user centric, to be able to adapt to different contexts, foresee users intentions, provide recommendations accordingly and protect users privacy at the same time. [11].

BBC Hppy bthdy txt!, December 2002

As it can be seen from Figure 2.4, the mobile computing concept as it is now has to change, to adjust, in order to be able to support a next generation application. Pei Zheng and Lionel Ni describe it their book Smart phone and next generation mobile computing how the three components mobile network terminals are setting infrastructure, and the

applications/services

Figure 2.4 Relation between mobile computing, networks, possibilities for mobile computing. For applications-and the special case needed for next generation devices and applications the developer to create applications

corresponding to the next generation of mobile applications it is necessary for all those three components to enable mobile computing in a suitable way. Otherwise such an application cannot be used properly and the whole idea of the next generation of mobile applications becomes nonsense [12]. To make an idea about the capabilities of mobile computing as they are today, Swedish technical magazine together with automobile manufacturer Volvo presented the possibilities of using an iPhone that has a specialized application in a factory environment8. The idea was to let the iPhone communicate with the computer system in the factory and to feed the device with relevant data through a special software. The data would be presented in an adjusted way directly to the assembler. The working situation for an assembler today includes dealing with a huge amount of different assembling tasks because of the big variation of the products. The assembler gets the instructions and information from computers or from printed lists. The iPhone could present the information directly and the workflow would not have to be interrupted every time the assembler needs new information. Next generation applications have to be user centric, meaning they have to adapt to the users needs according to his preferences. A problem with traditional applications was mobile that they
8

Dagens Industris Technical Magazine article, May 2009

10

are too focused on technology, meaning the applications were traditionally developed for a specific purpose. Mobile applications designed for the future have to be created having the human as primary focus and with a technology transparent to him [13]. In other words an application shall give the user what he wants, anywhere he needs it and in the best possible way. Optimally the application can sense changes in the environment and automatically adapt to those changes in combination with the users preferences. This is a concept referred to as context awareness and an example on the iPhone could be the feature regulating the screen light dependent of the brightness around the device. Such an application measures the brightness and creates the optimal screen view for the user and is additionally saving power. Other implementations could be temperature measurement, pressure measurement, accelerometer information, the users heart beat, or data coming from sensors placed in the environment [11]. To summarize, next generation mobile applications have to be personal applications, useful in different ways for different kind of users. The user does not have to think about the technology behind it and the adaptation should ideally be automatic [9].

2.3.4 Native and portable code in mobile application development

After passing through the the first Webs epoch, that fulfilled the users need for information access, and the second one, which fulfilled their need for virtual socializing, starting with 2010 a new user generation appeared: the mobile generation. The mobile generation wraps together both of the Webs previous eras, adding to it the mobile characteristic. This means that information access and access to social networks represent a must and furthermore there is a need to access them from anywhere and at anytime [15]. Because of the numerous different devices and operating systems present on the market, choosing an appropriate solution for the development of a certain application is crucial, but also difficult. There are multiple factors that need to be taken into account when making this choice, the most important ones being the quality and experience of the programmers in that particular field, the clients needs, maintainability and costs. From the developers point of view, there are three

11

possible approaches: native code, interpreted portable code and portable code with multi-platform compilation.

Figure 2.5 - Development and installation of applications using native code

2.3.4.1 Native code The first and most natural alternative is developing in native code. Native code is code compiled to run with a particular processor and its set of instructions. If the same program is run on a device with a different processor, software can be provided so that the computer emulates the original processor. In this case, the original program runs in emulation mode, and as a consequence more slowly9. Figure 2.5 shows the steps in developing and installation of applications corresponding to different mobile platforms. Some advantages of using native code are high performance levels, direct access to native API, direct debugging, fast reaction to OS-related problems and integrated versioning system, unit testing, simulation system and automated testing. The main disadvantages of using native code are the high costs, extra effort for implementing the same functionalities on different platforms, difficulties in maintaining different versions, difficulties in coordinating the implementation of new features and having to start from zero for each platform [14].

SeachSOA Definition of native code

12

Figure 2.6 - development and installation of applications using portable interpreted/hybrid code

2.3.4.2 Interpreted portable code

The interpreted portable code approach is also knows as hybrid, because it consists of two main parts: a web application and a native container-application that has an instance of a browser and access to the hardware components of the device. Examples of tools for this kind of approach are: PhoneGap, Adobe AIR and WebWorks. Comparing Figure 2.6 with Figure 2.5, one can easily conclude that the major difference between the native code approach and the interpreted portable code approach is that the latter one uses a common source code for all platforms, this being its most important advantage. Other advantages include low maintenance costs, numerous frameworks available, requires web-related competencies only and allows the development team to focus solely on application logic. Disadvantages include lower performance levels, rough debugging process, limited access to platform functionalities and the lack of some user interface controls [14].

Figure 2.7 - Development and installation of applications using compiled portable code

13

2.3.4.3 Multiple platform compilation portable code

Finally, the third approach is multiple platform compilation portable code, that assumes the usage of a common source code and a compiler, as it can be seen in Figure 2.7. The role of the compiler is to interpret the source code and to generate native code for each platform. Specific tools for this kind of approach include Corona Marmelade, MonoTouch, MoSync, Verivo and Titanium. The main advantages of this approach are having a single source code and high performance levels. On the other hand, disadvantages are rough debugging and difficulties in locating bugs. In conclusion, there is no best approach for developing mobile applications. In order to take a decision one has to take into consideration the nature and dimension of the application, as portable code is only recommended for small and medium-sized applications [14].

14

3. Mobile cloud computing

3.1 Cloud computing

3.1.1 Generalities

Cloud computing refers to the delivery of computing and storage capacity as a service to a heterogeneous community of end-recipients, as it can be seen below in Figure 3.1. The name comes from the use of clouds as an abstraction for the complex

infrastructure it contains in system diagrams. Cloud computing entrusts services with a user's data, software and computation over a network. It has considerable overlap with software as a service (or SaaS). End users access cloud-based

applications through a web browser or a light weight desktop or mobile app while the business software and data are stored on servers at a remote location.
Figure 3.1 - Cloud computing diagram

15

Advocates of this kind of services claim that cloud computing allows enterprises to get their applications up and running faster, with improved manageability and less maintenance, and enables IT to more rapidly adjust resources to meet fluctuating and unpredictable business demand [15]. In simple words, cloud computing refers to services sold and delivered over the Internet to different types of devices [16]. At its foundation rely the concepts of converged infrastructure (which packages multiple IT components into a single, optimized computing solution) and shared services. Cloud computing is the fifth generation of computing, after Mainframe, Personal Computer, Client-Server Computing, and the Web. The estimated size of the cloud computing infrastructure at the beginning of 2012 was approximately $40B (billion), taking into account that it was $18B in 2008 [17]. There are hot debates on trying to estimate the numbers for the following years, but the estimates in general are rather optimistic. Analysts at Hewlett-Packard estimate that the cloud computing market will hit $143B by next year [18]. From a customers perspective, cloud computing is driven by faster, cheaper and easier to use applications, ease of access and reduced expenses for storage. On the other hand, from a vendors perspective, it is driven by the ease of targeting customers, low costs of delivering and supporting applications and the ability to drive down data center operational costs. In one word, from both point of views, cloud computing is driven by economics [17].

3.1.2 Cloud computing models

There are three fundamental models of cloud services: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) [19]. They can be seen in Figure 3.2 (on the next page) in a layered-display.

16

3.1.2.1 IaaS (Infrastructure as a Service) IaaS, the most basic model, delivers utility computing capability, typically as raw virtual servers, on demand that customers configure and manage. Here, cloud computing provides grids or clusters or virtualized servers, networks, storage and systems software, usually (but not always) in a multi-tenant architecture. IaaS is designed to augment or replace the functions of an entire data center. This saves cost (time and expense) of capital equipment deployment but does not reduce cost of configuration, integration or management and these tasks must be performed remotely [16]. Examples of IaaS providers include Amazon CloudFormation and its underlying services such as Simple Storage and EC2 (Elastic Compute Cloud), RackSpace Cloud and RightScales.
Figure 3.2 - Cloud computing layers

3.1.2.2 PaaS (Platform as a Service) The middle model, PaaS, delivers virtualized servers (computing platforms) on which customers can run existing applications or develop new ones without having to worry about maintaining the operating systems, server hardware, load balancing or computing capacity. These vendors provide APIs or development platforms to create and run applications in the cloud. Managed Service providers with application services provided to IT departments to monitor systems and downstream applications, such as virus scanning for e-mail, are frequently included in this category [16]. Well-known providers include Microsoft Azure, Heroku, Amazon Elastic Beanstalk, Google App Engine and the US Postal Service offerings.

17

3.1.2.3 SaaS (Software as a Service) SaaS is the most widely used and widely known form of cloud computing. In this model, cloud providers install and operate application software in the cloud and cloud users access the software from cloud clients. The cloud users do not manage the cloud infrastructure and platform on which the application is running. This eliminates the need to install and run the application on the cloud user's own computers simplifying maintenance and support [15]. It also eliminates customer worries about application servers, storage, application development and related common concerns of IT [16]. Figure 3.3 offers a easy to understand perspective about the relation between

providers and users in the field of cloud programming. What is important to note, though, is that the top level can cause recursion, meaning that the SaaS user can also be a SaaS provider. Highest-profile examples of this model are Googles Gmail and Apps, Yahoo, AOL instant messaging, Salesforce.com and Quickbooks Online.
Figure 3.3 - Users and providers of cloud computing

3.2 Mobile cloud computing

3.2.1 Generalities

Mobile cloud computing is the usage of cloud computing in combination with mobile devices. Cloud computing exists when tasks and data are kept on the internet rather than on individual devices, providing on-demand access.

18

Applications are run on a remote server and then sent to the user. Because of the advanced improvement in mobile browsers thanks to Apple and Google over the past couple of years, nearly every mobile has suitable browser. This represents a major breakthrough for developers, as they now have a much wider market to work with, bypassing the restrictions created by mobile operating systems. It also offers new chances for mobile network providers, which have started offering cloud computing services to companies. Examples of such providers are Vodafone10, Orange and Verizon. Mobile cloud computing is considered to be the future of mobile. In an article by Sarah Perez on ReadWriteWeb website, she states that not smartphones, but actually simple feature phones will be the ones responsible for driving mobile cloud computing up to the top. With a Western-centric view of the world, it can sometimes be hard to remember that not everyone owns a smartphone. There are still a large number of markets worldwide where the dominant phone is a feature phone. While it's true that smartphones will grow in percentage and feature phones will become more sophisticated in time, these lower-end phones are not going away anytime soon. And it's their very existence which will help drive the mobile cloud computing trend. Not only is there a broader audience using feature phones in the world, there are also more web developers capable of building mobile web applications than there are developers for any other type of mobile device. Those factors, combined with the fact that feature phones themselves are becoming more capable with smarter built-in web browsers (and more alternative browsers available for download), will have an impact on mobile cloud computing's growth11. Of course, there are potential problems with mobile computing, the biggest issue being the lack of speedy mobile Internet access in some areas, especially suburban ones or poor developed countries. Nevertheless, technologies like HTML5 could help mobile clouds get past these sorts of issues, by making local caching. Furthermore, companies are researching possibilities of making devices communicate directly through SIM cards to mobile clouds, without the need of a browser.

10 11

Vodafone Group White Papers - Connecting to the Cloud: Business advantage from Cloud Services, 2010 Sarah Perez - Why Cloud Computing is the Future of Mobile, ReadWriteWeb website, August 2009

19

3.2.2 Mobile cloud services

While pure mobile cloud services are based on data synchronization, there are also other cloud services in each layer of the cloud computing domain (IaaS, PaaS, and SaaS) that might enable the mobiles for increasing their functional capabilities. These services mainly offer processing data-intensive tasks that are high demanding for a handset. Cloud services can be accessed as SaaS using mobiles if the vendor provides WAP content for delivering the service via Web browser. Common mobile SaaS includes those services released by vendor such as Facebook, Google, Apple, etc. The development of mobile applications that involves the use of cloud services in the infrastructure level is limited to the set of tools provided for each specific cloud vendor [20]. Currently, the most preeminent cloud providers that enable cloud services consumption directly from the handset are Apple Cloud and Googles Application Engine, as their cloud solutions are completely integrated for their own mobile platforms: iOS and Android respectively. In behalf of keeping open standards in cloud technologies, some open source communities have been developing libraries that enable the communication with multiple clouds. However, such libraries are poorly documented and in some cases are not suitable for deploying within the mobile operating system. Among such libraries we can mention the following: Jets3t
12

(developed by James Murty and

used for accessing Amazon storage and Google Storage for Developers), Jclouds (that supports access for 30 cloud providers and cloud software stacks, including Amazon, GoGrid, Ninefold and Azure)13, Typica (able to access the computational service of Amazon EC2 and Eucalyptus) and Amazon Native API.

12 13

JetS3t website - About JetS3t JClouds website - JClouds Overview

20

3.2.3 Device synchronization with mobile cloud services

Mobile synchronization refers to data synchronization which is happening between a device and a portal in the cloud, as it can be seen in Figure 3.4. The cloud is essential for device synchronization as it works as a storage facility for several data

resources that come from different sources, like social networks, email providers, etc.
Figure 3.4- Synchronization architecture for the mobile cloud

Public cloud vendors offer solutions for synchronization based on their own cloud implementations. For instance, Google sync (Google), MobileMe (Apple), MyPhone (Microsoft) Ovi Sync (Nokia) etc. The downside of this kind of providers is that they are usually not able to support synchronization services for other kind of devices beside their own14. Synchronization solutions for private clouds involves the implementation of open source projects, such as Funambol, Horde, and eGroupWar. Funambol, The leading white-label personal cloud solution
15

, is one of the most popular alternatives for synchronization due to the fact that it

enables the integration of several existent technologies through the use of connectors, that in most cases are developed by open communities. It provides solutions for synchronizing personal data, such as pictures, videos, music, documents, contacts and calendar, as well as for pushing e-mails to the device.

14 15

Sarah Perez - Why Cloud Computing is the Future of Mobile, ReadWriteWeb website, August 2009 Funambol Personal Cloud Solutions

21

3.3 Cloud to device messaging

3.3.1 Mobile Cloud Middleware

Mobile Cloud Middleware (or MCM) represents an intermediary level between mobile devices and the cloud, as it can be seen in Figure 3.5. It was designed to be a solution for mobile cloud interoperability, or in other words to overcome the boundaries and limitations caused by platform restrictions and cloud provider technology choices [20].
Figure 3.5 - Mobile Cloud Middleware overview

Cloud-based mobile middleware will enable small to medium size businesses the ability to have mobile enterprise offerings similar to large Fortune 500 companies. As this technology rapidly expands to all industries, look for prepackaged mobile applications to handle standard and homogeneous business processes such as inventory inquiry, while custom development of unique mobile applications that focus on complex business processes and flows will be performed either by internal software development or mobile solutions specialists [21].

22

Figure 3.6 - Mobile Cloud Middleware architecture

Figure 3.6 provides a detailed view of MCMs architecture and key components. When an application tries to connect to a cloud service, it connects to the Transportation Handler (TP Handler) of the middleware, which receives the request. The transportation handler can receive the requests based on several protocols like HTT or XMPP. The request is then processed by the Interoperability API engine, which selects the suitable cloud API and creates a unique adapter that ensures the transactional process with the cloud. When the request is forwarded to the MCM Manager, it creates a session and assigns a unique identifier for saving the system configuration of the device and the requested service

configuration. Once the interoperability API engine decides which API set it is going to use, the MCM Manager requests for the specific routines from the Adapter Servlets. Finally, MCM Manager encapsulates the API and the routine in an adapter for performing the transactions and accessing the SaaS. The result of each cloud transaction is sent back to the handset in JSON format [20].

23

3.3.2 An overview of Android Cloud to Device Messaging Framework

Android Cloud to Device Messaging (or C2DM) is a service that helps developers send data from servers to their applications on Android devices. The service provides a simple, lightweight mechanism that servers can use to tell mobile applications to contact the server directly, to fetch updated application or user data. The C2DM service handles all aspects of queuing of messages and delivery to the target application running on the target device16. There are two alternative ways by which devices can acquire information from the Internet. One approach is known as Polling, meaning the application that needs data periodically polls a server for new information. The downside of this first approach is that there are changes that no new data is present on the server, so device battery and network bandwidth are consumed unnecessary. However, polling rate can be improved by statistical meanings in order to minimize changes of unnecessary information inquiries. The second approach is known as Pushing, meaning that the server that holds data pushes it to the device whenever fresh information is

available. A theoretical example of how a push notification works can be seen in Figure 3.7. Usually, Pushing is preferred over Polling, with the
Figure 3.7 - Illustration of how a push notification works

exception when data changes in a constant manner.

As of Android 2.2, such a Pushing information system is supported, called Cloud to Device Messaging (or short C2DM).

16

Google Developers - Android Cloud to Device Messaging Framework (Overview)

24

3.3.3 Android C2DM architecture and lifecycle

In a C2DM architecture there are three involved parties: a third-party application server, which wants to push messages to the Android device, Googles C2DM servers and the actual Android application, which is registered for receiving the messages. A major advantage of this architecture is that it doesnt impose any restrictions for the language the third-party server is written in (most tutorial examples are based on Java or PHP code, though). The communication between this server and the Google ones is done through simple HTTP posts, that have to conform to a certain model. The C2DM servers route the message to the device. If the device is not online, the message will be delivered once the device is available. Once the message is received on the device, a broadcast is created, waking up the application that registered for that broadcast. Thus, the application does not have to be running in order to receive a message. Requirements for the device of this framework include Android 2.2 or higher, installed Google Play (or Market, as it was known before) and at least one logged in Google account. C2DM messages are limited in size to 1024 bytes and are intended to inform the device about new data, not to transfer it. The typical workflow for transferring data using this framework is that Googles C2DM servers notify the Android application that new data is available, and afterwards the latter fetches the data from a different hosting server17. The framework uses credentials that are used in different stages of C2DM to ensure that all parties have been authenticated, and that the message is going to the correct place. These credentials are the Sender ID (e-mail account associated with the developer; it is typically rolebased rather than being a personal account), Application ID (application that is registering to receive messages, identified by the package name from the manifest), Registration ID (issued by C2DM servers to the application, thus allowing it to receive messages), a Google User Account and a Sender Authentication Token (authorization id for the third-party server, needed to send messages to Googles servers).
17

Lars Vogel - Android Cloud to Device Messaging (C2DM) Tutorial, January 2011

25

Figure 3.8 - Android C2DM lifecycle

Figure 3.8 serves to a better and easier understanding of the C2DM Frameworks lifecycle. The first step that needs to be taken is to enable C2DM service. This is done by registering the application by using one of the Google accounts logged in on the device. Google servers send a the Registration ID, which should be both saved somewhere on the device, but also sent to the third-party server to be saved there. The hand-held has to store the Registration ID, as Google refreshes these ids periodically and the device must be able to detect these changes in order to resend the new id to the third-party server. The latter has to store the id for communicating purposes with the Google servers. After the above steps are done, the user responsible for sending data also has to apply for a unique identifier, using his Google account credentials. This identifier is referred to as Sender Authentication Token. Together with the token, the actual data for the device is transmitted by the user to the third-party server, which adds to this information the corresponding Registration ID and forwards it to Googles C2DM Servers. Finally, when the device is online the application registered for receiving messages gets the data. To conclude, the Android Cloud to Device Messaging Framework offers a convenient way for making push notifications from any kind of third-party server to an Android application. However, implementing such a service is not very straightforward and the user of these services

26

is more difficult than the implementation of the proposed notifications by Apple for the iPhone. Furthermore, C2DM makes no guarantees about delivery or the order of messages18. Significant examples of applications implemented using Android C2DM are Chrome to Phone (used for sending links, maps and contacts from Chrome to a device) and JumpNote (two-way synchronized notepad), both from Google.

18

Google Developers Android Cloud to Device Messaging Framework (C2DM) - Introduction

27

4. CODER Application Design

4.1 Introduction to CODER

CODER stands for Control Device Remotely and is an application that allows controlling certain functionalities of an Android-built device remotely, either from a third-party server or from another device. It makes use of Googles Android Cloud to Device Messaging Framework, which was presented in the previous chapter, in order to establish communication and data-exchange between the third-party servers application and the one installed on the device. CODER consists of three different components: the third-party application server, which offers the main user interface for sending instructions to the device, an application on the hand-held that is used for both registration purposes (registration to Googles C2DM services) and for receiving data ones, and a second Android application, that can be used for remote controlling the device from another device.

28

4.2 CODER Design Model

4.2.1 Application Architecture

CODERs architecture consists of three layers: database, business logic and presentation. The first one, the database layer, handles data access and manipulation. It holds the DAO interface classes and their implementations. This is the repository of the application, and is part of the third-party server. The business logic layer is present in both the third-party server and the device. This layer includes the controllers and services of the applications (the web one and the device ones). Their role is to deal with the business logic and with data manipulation, by using classes from the database layer. Finally, the top level layer, the presentation one, is also present on both the server and the device applications. This is the only visible layer for the user (the client). It includes a web interface for the server and Android interfaces for the device applications. The presentation layer uses controllers from the business logic layer to manipulate data and user commands.

4.2.2 Package structure

The structure of the packages is simple and straightforward, as it can be seen in Figure 4.1. Components belonging to the presentation layer are part of the Interface package. They directly make use of the controllers, belonging to the Controller package, that use components from the Utils and Service packages, and also Model classes. Controller and Service packages represent the business logic layer packages. Components from the Service
Figure 4.1 - CODER's package structure

29

package use DAO components for data manipulation, and the components from both these packages make use of Model classes.

4.2.3 Database structure

The structure of CODERs database is very simple, as is consists of only four tables, none of which are related through foreign keys, as Figure 4.2 shows. The database structure below corresponds to the third-party application server, as the device databases are built-in ORMLite ones.

Figure 4.2 - Database structure for CODER's third-party server

The User table corresponds to the entity class with the same name, and is used for storing both credentials for the applications users, but also for storing authentication tokens and registration ids corresponding to those users. These tokens and ids are necessary for the applications communication with Googles C2DM servers PossibleActions is a table that is used for storing all the actions (instructions) available to the clients of the application. Coordinates and CallEntity tables are used for keeping a history of users last location and latest calls. This information becomes useful when there is no connection between the server and the device.

30

4.3 CODER Analysis Model

4.3.1 Use case diagrams an corresponding use cases

For the following use cases of the CODER application we assume that the third-party server is authenticated to Googles C2DM and up and running and that the Android application that handles data receiving from C2DM servers is installed and registered appropriately. The registration process of the Android application with the Cloud to Device Messaging Framework is described in Chapter 3 and more specifically presented graphically in Figure 3.8 of the same chapter. In addition to the above assumptions, for the first use case presented in Figure 4.3, we assume that the other Android application, used for sending instructions, is installed on a device that will act as the remote controller. This application does not need registration as it communicates with the other Android one via SMS. We will assume though that both devices have running mobile telephony capabilities.

Figure 4.3 - CODER use case showing the flow for sending an instruction from one device to another

The flow for the above use case starts with opening the application on the device that will act as a controller. We will refer to the one responsible for this action as Client. Once the application

31

opens, he can choose from a list of predefined instructions in order to send to the receiving device, referred as Device. The chosen instructions is first validated and then send via SMS to the Clients mobile telecommunication operator, referred as Telecommunication Operator. The latter is responsible for forwarding the SMS to the Device, which reads the instruction sent in the SMS and performs a certain action, corresponding to that instruction.

Figure 4.4 - CODER use case showing the flow for sending an instruction from the third-party server to the receiving device

The second use case, presented above in Figure 4.4, starts with the Clients (the user that is sending an instruction to the receiving device, referred as Device) login on the website. This is preceded by a registration if he has no credentials, meaning that hes using the web application for the first time. After the login a page containing possible instructions is displayed. When the Client chooses one of them to send to the Device, it is first validated and afterwards sent to Googles C2DM Servers. The server forwards the message to the Device when it is found online. Finally, the flow is completed after the device processes the received information and performs a corresponding action.

32

4.3.2 Sequence diagram

A sequence diagram is a kind of interaction diagram that shows how processes operate with one another and in what order. It shows object interactions arranged in time sequence. A sequence diagram (also known as an event diagram) depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario.

Figure 4.5 - Sequence diagram corresponding to the use case of sending an instruction (action) from the third-party server to a device. It shows the sequence in which events happen.

The sequence of events that happen in order to successfully send an instruction (denoted here by action) to the device from a third-party server starts, as in the corresponding use case, with the login procedures, as shown in Figure 4.5. This is followed by the validation of the login and the retrieval of the main page (denoted here as home page) of the web application. In order to

33

populate the page, its controller (Home Controller) requests the list of all possible actions from a Possible Action Service, which forwards this request to the Possible Action Dao. After the population and the retrieval of the page, the user of the third-party application (referred to as Client) chooses one of the available instructions. A Communication Service requests a validation from a Action Validator, and upon successful validation sends the instruction to Googles C2DM Services. Finally, the servers providing these messaging services forward the instruction to the Device. Similarly, the sequence diagram for the second use case (sending an instruction from one device to another) follows the same pattern, with the differences that no login is required and the Communication Service sends the message directly to the Device, without the intermediary C2DM Servers.

4.3.3 Class diagram for the third-party application server

A class diagram is a type of static structure diagram that describes the structure of a system by showing its classes and the relationships among them. Furthermore, it can show the classes attributes, operations (or methods), fields, inner classes, annotations, and so on. For dimension purposes, the third-party server applications class diagram shown in Figure 4.4 (on the next page) is missing some particular functionalities like Coordinates or Calls, with their respective services and data access objects. These above functionalities serve as utilities for keeping information about latest locations and calls (last received), in case of closed or unresponsive communication between the server and the device at the time of an inquiry. They are not critical to the correct flow of the application. Also, for the same dimension purposes, the User class is missing, as it is used by numerous other classes and would have complicated the architecture of the diagram.

34

35
Figure 4.6 - Class diagram for the third-party application server

As it can be seen in Figure 4.6, the most dense component of the third-party server is the HomeController, which manages directly the user interface home page and uses the service layer, UserService and PossibleActionService, in order to bring information about users and possible actions for the user respectively. It uses a validator (HomeValidator) for validation purposes and also makes use of the C2DMessageUtil, a utility class that handles communication with Googles C2DM Servers.

The LoginController and RegistrationController handle the flow of the application when used by a client before the above-mentioned HomeController, as these two classes are responsible for authenticating a user by his credentials for the purpose of using the application. They make use of a common validator (LoginValidator) and of the UserService, in order to keep consistent data with respect to the users. The CommunicationController class is responsible for handling response messages sent by the device. As result of some sent instructions, the device might have to give back certain information to the server, for example its current location or the applications registration id (upon registration). This kind of response data is handled by the CommunicationController. As for the service classes, UserService is the class that links together the controller layer and the database access object layer. It offers functionalities for data exchange with UserDao, its corresponding dao class. The other service used, PossibleActionService, serves the purpose of retrieving the list of available actions (instructions) by using the database class PossibleActionDao. UserDao and PossibleActionDao are the two most important DAO classes, providing data access functionalities for manipulation of Users and PossibleActions. Finally, the AuthenticationUtil class serves as an authentication mechanism for the third-party application server with C2DM Servers. It is used only once, by the server manager, prior to the first client use of the server.

36

4.3.4 Class diagram for the receiving devices Android application

As mentioned earlier in the paper, CODER has two Android applications: one that acts somewhat like the third-party server, as a controller, and one for receiving instructions from both the thirdparty server (via Googles C2DM Servers) and the other Android application. In Figure 4.7 on the next page, the class diagram of the device application that acts like a receiver is presented, as it is more complex and furthermore interesting. The main component of this application is CODERController, that handles almost all functionalities. It uses C2DRegistrationController, that handles registration with Googles C2DM Services and which happens at the first usage of the application. The action of registering is done by the user through RegisterActivity, an activity managed directly by the above-mentioned registration controller. For dealing with incoming messages from the C2DM Servers, CODERController uses C2DMessageUtil, which processes the message in order to instruct CODERController how to handle it. The actual receiving of messages is done by C2DReceiver. For dealing with incoming instructions by the other device application, it makes use of SMSReceiver, which acts like a SMS interceptor for incoming text messages on the device. For responding to the third-party server in case of needed response data, CommunicationService is used. Data is sent back as JSON objects. For the actual executing of instructions from the processed messages, multiple services are used: NotificationService for displaying notifications, AlarmService for setting up alarms, CallService for calling purposes and retrieving latest calls, CameraService for taking pictures, SMSService for sending text messages, and LocationService for getting the current location. For dimension purposes, some utility classes used by the above-mentioned services have been excluded from the diagram. Also, classes intended for database-handling have been excluded for the same purposes, as currently only user credentials are stored in the database.

37

38
Figure 4.7 - Class diagram for the receiving device's application

5. CODER User Manual

5.1 Application overview

The functional specification document, also known as Product Requirement Document (PRD) is the documentation that describes the requested behavior of an engineering system. The documentation typically describes what is needed by the system user as well as requested properties of inputs and outputs. CODER (which stands for Control Device Remotely) is an application that allows controlling (managing certain features of) an Android device remotely, either from a Web application or from another device. It consists of three components (applications): the first application is an Android application and has the role of acting as a receiver of incoming instructions. The second application is available to the user via an internet browser and represents the main controlling facility for the Android application mentioned above, allowing sending of various instructions (also referred to as actions) to it. The third component is a second Android application (referred to as CODER Controller in order to differentiate with the other Android one), which is optional, and that also acts like a controller for the first Android application. Its an alternative way of sending the instructions, being very practical when no Internet connection is available for the user or when he

39

is using another device. The downside of this second Android application is that it does not yet support all functionalities supported by the web one. These three separate applications will be presented one by one in the following subchapters, alongside their requirements and usage examples. CODER can come in handy when the device is stolen, because it can locate the phone in realtime as long as it is connected to the Internet or block the SIM card by toggling the Airplane Mode. Furthermore, current functionalities allow making calls, sending text messages, making notifications, toasting messages on the screen, setting up alarms, audio recording, taking photos and getting the latest calls from the phone log.

5.2 CODER instruction receiver application (Android)

5.2.1 Overview and requirements

The first CODER component is an Android application that plays the role of the instruction receiver. After receiving an instruction it performs a certain action corresponding to it. In order for the application to work, it requires the installation on an Android 2.2 (or higher) device. Furthermore, it requires at least one logged-in Google account on that device, which is necessary for registering and communicated with Googles C2DM Servers. The account has to be the same one used for registering on the Web application. These two are the only requirements needed for the installing the CODER Android application.

40

5.2.2 Usage

Figure 5.1 - Initial frame

Figure 5.2 - No registration id

Figure 5.3 - Notification with registration id

Figure 5.1 represents the first frame that shows upon

installation. As the application is fresh-installed, registration id it has no for

(needed with

communicating

C2DM

Servers), so as a consequence pressing the Show registration id button will just toast a n/a message, as shown in Figure
Figure 5.4 - Registration id Figure 5.5 - Registration id

5.2. Pressing the Register button toggles the registration (Internet connection is required) action, which results in a notification in case of successful registration, as presented in Figure 5.3. The last two figures show the registration id received from Googles servers. Figure 5.4 shows the id as displayed when opening the received notification, whereas Figure 5.5 shows the id as displayed when clicking on Show registration id button. These represent the only interactions of the user with this Android receiver application.

41

5.3 CODER main controller (Web)

5.3.1 Overview and requirements

The second CODER component is represented by the Web application that runs on a third-party server. The role of this application is to act like a controlling unit for the Android application presented in subchapter 5.2. At first deployment, the server has to be authenticated by its manager with Googles C2DM Servers. For registration and login purposes the user (client) needs a Google account, which is important to be the same one used on the receiving Android devices application, for communication purposes (Cloud to Device Messaging will not work otherwise). As for system requirements, in order to access the application the user needs a Web browser. For optimal functionality, the browser must support jQuery.

5.3.2 Usage

5.3.2.1 Login, registration and home pages

When accessing the CODERs web application URL, the user is prompted to a login screen, shown in Figure 5.6. In case of inexistent credentials, he must register an account. The registration page can be accessed by clicking on the New user? Register here link on the bottom of the login form. Clicking on the link
Figure 5.6 - CODER default landing page (login form)

42

opens up the registration form, shown in Figure 5.7. An e-mail address (the same as the one used for the receiver Android application) and a password are needed for registration. The user must also re-type the password for security reasons. In case of trying to register an account with an already existent e-mail address, a User with this email exists. Try to log in message is shown on the screen in red.

Figure 5.7 - Registration form

Figure 5.8 Login example

Figure 5.9 - Invalid login example

Returning to the login page, Figure 5.8 presents an example of filling in the login form. Hitting the Login button after filling in the e-mail and password fields results in two possible outcomes: the first, presented in Figure 5.9, appears when the credentials are not valid. In the figures case, an Invalid password. Please try again message is shown in red. In case of inexistent e-mail, an Invalid username (email) message appears instead. The second possible outcome is a valid login, which leads to a redirect to the main page (also referred to as Home page). Figure 5.10 on the next page presents the main frame on CODERs Home page. A welcome message followed by the appropriate username is displayed on top of the form, followed by a combo-box of User input actions, which is followed by a group of Miscellaneous actions, that do not require user input.

43

Figure 5.10 CODER web applications home page

The list of User input actions is formed by six actions, each requesting different inputs. The input boxes and the hint messages inside them change accordingly depending of the action chosen by the user from the combo-box. Such an example can be seen in Figure 5.10, when the default chosen action Call phone number has as associated input with the hint Phone number, suggesting that a phone number is requested to be completed before submitting the action.

5.3.2.2 User input actions

The list of User input actions as they appear in the combo-box can be seen in Figure 5.11. The next one, Figure 5.12 shows an example of how the inputs and their hint text changes when selecting another instruction, in this case Create a notification.

Figure 5.11 - List of user input actions

Figure 5.12 - Example of change of inputs

44

Call phone number requests a phone number as input and Send SMS a phone number and a text body (in case of an inexistent phone number, the device wont be able to make the call; a validator checks and ensures that the phone number is valid, that is formed by digits). Show message on screen requests a simple text message to be displayed (toast) on the device, Get latest calls from call log requests an integer (greater or equal to zero) which represents the number of latest calls to be retrieved, Set an alarm requests a specific type of input of the form: d days h hours m minutes and s seconds, where d,h,m,s are the number values for days, hours, minutes and seconds respectively, and finally Create a notification which needs a notification title and a notification body, as exemplified in Figure 5.12. By submitting any of the User input actions the server behind the Web applications sends the instruction to Googles servers, which have the role to forward them to the device. In case of a successful sending of the instruction, a Message sent successfully to device appears in green on the bottom of the page, as shown in Figure 5.13. In case of an error in transmitting the message, an error message shown in red as shown in Figure 5.14 appears on the bottom of the page.

Figure 5.13 - Successful sending of a message

Figure 5.14 - Error in sending a message (instruction) to the device

The consequence of the actions is rather simple, each action name being very descriptive. A Call action results in calling the given number, a Create notification action creates a notification, and so on. A special case is the one of Get latest calls from call log, which is a response action, meaning that the device responds to the server by retrieving the latest calls (number given by user) and showing them in a different screen, as shown in Figure 5.15, each delimited by a horizontal line. Information displayed includes the number, name (if any), the type, date (displayed in the language
Figure 5.15 - Example of displaying latest calls

45

of the computer or device used for Web controlling) and duration of the respective call. It is important to mention that in the case of interrupted communication between the device and the Web application (meaning that the device cannot return the requested recent calls), the Web application displays the last received list of calls from the device (if any), meaning that it keeps for historical reasons the latest calls until new ones are received.

5.3.2.3 Miscellaneous actions

The currently available miscellaneous actions are Take a picture, Toggle Airplane Mode, Start audio recording and Get device location, as it can be seen in Figure 5.16. The difference between these actions and the user input ones is that these do not require users input. They are triggered simply by just clicking. Hovering over one of them makes its background color change (in Figure 5.16 the mouse is hovering over Take a picture action), so that the user can visually see that something is happening.

Figure 5.16 - CODER's miscellaneous actions

Take a picture, as its description suggests, takes a picture using the devices built-in camera. The picture is saved on the hand-helds memory card, having the name picture.png, and being situated in a CODER folder (shown in Figure 5.17 on the next page). The person using the phone wont notice the actual taking of the photo, as the sound is muted and the camera does not show on the screen. Thus, the action of taking a picture is performed silently in the background. Toggle airplane mode action toggles the Airplane mode, meaning that it switches to or from Airplane mode if the phone is not in that state. This action can be very useful in case the device is stolen, as trying to exist the Airplane Mode requires entering of the PIN. Entering the PIN cannot

46

be done remotely through the Web application, so if the user toggles Airplane mode and wants to switch back, he will need to manually introduce the PIN number. Start audio recording starts recording audio using the devices built-in microphone.

Clicking again on the element causes the recording to stop. If the recording is not stopped manually, it will continue recording until it has enough storage memory. This feature can also come in useful when the device is stolen or when wanting to monitor someone. The audio recording is saved in the same CODER directory as the picture taken by the application (Figure 5.17), having the name audio_recording.3pg. The last miscellaneous action, Get device location is also a response-like action, meaning that after requesting the devices current location the device retrieves it to the server (if communication can be established). A new page is opened containing a Google Map, focused on the location received (by latitude and longitude), shown in Figure 5.18. The same goes as for Get recent calls, meaning that if the device does not respond, its last saved location will be displayed.
Figure 5.17- CODER folder on the external storage containing an audio recording and a picture taken by the application

Figure 5.18 - Getting the device location action opens a Google Maps page focused on the location

47

5.4 CODER alternative controller (Android)

5.4.1 Requirements

CODER alternative controller refers to the second provided Android application, which can be used as an alternative controller to send instructions to the Android application that acts like a receiver. Although it does not yet support all functionalities supported by the Web controller, this application comes in useful when the user has no access to the Internet, as it sends the instructions by SMS. It can also prove to be optimal when the user is using a device, as there is no need for login and opening a browser. For installation, the application requires a Android 2.2 (or higher) device. In order to succeed in sending the instructions, the device must have a working SIM card that can send text messages.

5.4.2 Usage

The Android CODERs controller layout is presented in Figure 5.19 and consists of six buttons for actions and a user input text-box. Make call and Make toast are the only actions that

require user input. The user has to fill in a phone number or a message to show on the screen respectively. Trying to make a call or a toast without filling in the textbox causes a toast error message to appear on the screen.

Figure 5.19 - CODER's alternative controller layout

48

The message is either Please fill in number (Figure 5.20) or Please fill in toast message text. After the action is submitted, the text from the input is deleted. For making a phone call, the same principle of the Web controller applies in terms of inexistent numbers: if the phone number does not exist or is incorrect, the receiving device will not be able to make the specified call.

Take picture works in the same way as it works on the Web application:

sends an instruction to take a picture, saved on the external storage in the CODER folder having the name coder.png. When pressing Start audio recording a spinner shows up that continues to spin until the user clicks the button again to stop the
Figure 5.20 - Empty phone number warning Figure 5.21 - Start audio spinner animation and text change for button

recording. This behavior is presented in Figure 5.21. While recording, the text on the button changes from Start recording to Stop recording. As in the Web applications case, the recorded audio stream is saved into the CODER folder of the devices external storage, having the name audio_recording.3pg. If the receiving device runs out of available external memory, the recording will force stop. The final two actions, Get location and Get recent calls are response-like actions, like in the case of the Web controller application. The response is given through text messages. In both cases, if the instruction is sent successfully to the receiving device, the latter responds to both the Web application (which stores the received information in the database) and the Android controller one.

49

For the Get location action a text message containing the coordinates (latitude and longitude) of the receiver device is received (shown below in Figure 5.22), whereas for Get recent calls the last five calls are received in a text message, each having the number, name (if any), type, date and duration (shown below in Figure 5.23).

Figure 5.22 - Received SMS with device's coordinates

Figure 5.23 - Received SMS with the 5 most recent calls of the device

5.5 Similar existing applications

The most important to mention similar application is AirDroid, which is a convenient tool that allows managing your Android device remotely, from any web browser. Although it has many additional functionalities comparing to CODER, like data, contacts and application management, as well as multiple language support and file transferring, it lacks in an alternative Android controller and some anti-theft functionalities. On the other hand SeekDroid is an application specialized on anti-theft and security functionalities, having a lot of useful ones that are not yet present in CODER. Nevertheless, this

50

application also lacks in an alternative controller for the Web application and audio recording, which can come in useful for monitoring purposes. A third application is LazyDroid, that has similar (although less) functionalities to AirDroid. In addition to other remote controlling applications, LazyDroid offers a desktop controlling unit and touch sensors values. Although having a lot less functionalities compared to other applications, CODER has the advantage of offering an alternative Android controlling unit, that can prove to be useful.

5.6 Future application improvements

Although CODER is a nice example of the simple and convenient Cloud to Device Messaging opportunities, it still lacks multiple things. Firstly, the Web and Android controller applications should be synchronized, meaning that they should support the same functionalities and behave as similar as possible, in order to achieve a nice and enhanced user-friendly experience. Secondly, the user interfaces for all three applications should be improved and also synchronized, in order to avoid having three different look and feels for three different components of the same application. Future application improvements will include adding more functionalities, like supporting video recording and being able to toggle on/off the Wi-Fi, the Internet connection and GPS. Furthermore, more advanced anti-theft functionalities will be added, like tracking the device using location history, erasing the external storage and getting notified if the device leaves a predefined area. Finally, after reaching a stable Android version, a future target is to add support for other platforms, like iOS, Windows Phone or BlackBerry.

51

6. Conclusions

Together with technology breakthroughs and the constant need for information access from anywhere and at any moment, mobile computing has improved dramatically in the last years in order to fulfill this need. Once mobile applications have fulfilled the demand for information access from wherever, new needs of cloud to device synchronization and messaging arose. Thus, mobile application development started to focus more and more on cloud to device communication. This study presented one of the solutions for handling cloud to device communication: Googles Android Cloud to Device Messaging Framework (C2DM), which is intended for Android 2.2 (or higher) devices and which offers a convenient way to communicate through the Internet cloud from a server to a device by needing just a Google account. CODER (which stands for Control Device Remotely) represents an implementation example of Googles C2DM Services, offering the user remote control functionalities for an Android device from both a Web application and another Android application. Such currently supported remote control functionalities include making calls, sending text messages, retrieving the devices location and phone log, taking a picture, audio recording, setting up alarms or creating notifications. Although it proves the possibilities of cloud to device communication, CODER can be improved with other useful functionalities, such as toggling Internet, GPS and Wi-Fi on/off, erasing the external storage, and other anti-theft improvements.

52

Bibliography

[1]

Ran Wei, Motivations for using the mobile phone for mass communications and entertainment, Telematics and Informatics Volume 25, February 2008.

[2]

Benbunan-Fich Racquel, Benbunan Albert, Understanding user behavior with new mobile applications, Journal of Strategic Information Systems Volume 16, December 2007

[3]

Wesson L. Jannet, Darryn F. van der Walt, Implementing Mobile Services: Does the Platform Really Make a Difference? Proceedings of SAICSIT, pp. 208-216, Sept. 2005

[4]

Harmantzis C. Fotios, Tanguturi V. Praveen, Investment decisions in the wireless industry applying real options, Telecommunications Policy Volume 31, pp. 107-123, March 2007

[5]

Kevin McLaughlin, BlackBerry Users Call For RIM To Rethink Service, CRN News, December 2009

[6] [7] [8] [9]

Jacqui Cheng, iPhone in depth: the Ars review, ArsTechnica, July 2007 Ed Hansberry, Samsung Bailing on Windows Mobile, InformationWeek, November 2009 Gregory Lyons, 2012 Mobile Market Share [Infographic], iCrossing, February 2012 Eva Nordborg, The Next Generation of Mobile Applications. Theoretical and Practical Analysis of the iPhone SDK 3.0, Lulea University of Technology, Division of Mobile Networking and Computing, 2010

53

[10] Eveline van den Heuvel, Cosmas Fonville, Innovations of mobile communications standards and their applications for telecom companies, Rotterdam School of Management, 2007 [11] Agathe Battestini, Christian Del Rosso, Adrian Flanagan, Creating next generation applications and services for mobile devices: challenges and opportunities, The 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, 2007 [12] Pei Zheng, Lionel Ni, Smart Phone & Next Generation Mobile Computing, Morgan Kaufmann Publishing, December 2005 [13] Lim, W.M.; Towards More Usable Mobile Application Development, Mobile Technology Applications and Systems, 2005 2nd International Conference, November 2005 [14] Ionut Ion, Native code vs portable code in mobile application development, 3rd edition of Today Software Magazine (Romanian Version), May 2012 [15] Baburajan Rajani, The Rising Cloud Storage Market Opportunity Strengthens Vendors, InfoTECH Magazine, August 2011 [16] David Burford, Cloud Computing: A brief introduction, LAD Enterprizes (Information Technology Consulting), February 2010 [17] Andy Bechtolsheim, Cloud Computing, Standford online seminars, 2008 [18] Joe McKendrick, Cloud Computing Market Hot, But How Hot? Estimates are All Over the Map, Forbes Magazine (online edition), February 2012 [19] Preston A.Cox, Mobile cloud computing. Devices, trends, issues, and the enabling technologies, IBM DeveloperWorks Technical Topics, May 2011 [20] Huber Flores, Mobile Cloud Middleware, University of Tartu, Faculty of Mathematics and Computer Science, 2011 [21] Ben Lee, Cloud-Based Mobile Middleware: The Future of the Modern Mobile Enterprise, Smartsoft Mobile Solutions, 2011

54

You might also like