Development of a Smartphone Application and Web Services to Demonstrate the Valu e of IT in Business

Abstract With the recent penetration of a new generation of mobile devices in todays socie ty, mobile computing solutions are largely influencing enterprise strategy in th e business environment. Similarly, cloud computing is becoming increasingly more popular amongst businesses and is being widely adopted as the preferred method for accessing and using services. This project involves the merging of mobile an d cloud computing technologies to create a multi-tier solution that demonstrates the value and usefulness of IT in a business environment. This is achieved thro ugh the design and development of a smartphone application using the Android ope n-source software stack for mobile devices. In addition, RESTful web services ha ve been developed using the Windows Communication Foundation framework for build ing service-oriented applications, in conjunction with a Microsoft SQL Server da tabase for data storage. With some requirements provided by a renewable-energy s oftware company, the solution focuses on the application of IT in the renewableenergy sector. The end result of the project is a smartphone application that pr ovides easy access to vital business information and facilitates quick decision making by tracking a portfolio of renewable energy development opportunities. i

Table of Contents Abstract ....................................................................... .................................................................. i 1. Introduc tion ........................................................................... ............................................... 1 1.1 1.2 1.3 2. The Company ... ................................................................................ ............................ 2 Aims & Objectives ............................... ........................................................................ 2 Proje ct Overview .................................................................... ...................................... 3 General Background & Related Work .............................................. .................................... 4 2.1 2.2 2.3 2.4 Smartphones Conceptualisa tion to Realisation .......................................................... 4 Market Experiments in Smartphone Devices ...................................... ......................... 4 The Advent of the iPhone & The Mobile Revolution ... ................................................ 5 The Rise of Android ......... ................................................................................ ............ 7 3. Mobile Development ............................................................. ............................................... 9 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3. 8 3.9 Android Versions & Distribution .......................................... ....................................... 9 The Android Architecture.............. ............................................................................. 12 Android SDK & Development Tools ............................................... .......................... 14 The Android Native Development Kit................ ........................................................ 15 Android Fundamental Concepts & Components ........................................................ 1 6 Web vs. Native Development ................................................... .................................. 20 Enterprise Mobility ...................... .............................................................................. 2 2 Security in Mobile Devices ................................................... ..................................... 25 Conclusion ............................ ................................................................................ ..... 26 4. Web Technologies ............................................................... ............................................... 28 4.1 .NET Framework .......... ................................................................................ .............. 28 Common Language Runtime ...................................... ........................................ 29 .NET Framework Class Library ....... .................................................................. 30 4.1.1 4.1.2 4.2 ASP.NET ........................................................................ ........................................... 31 Page and Controls Framework...... ...................................................................... 31 Securi ty Infrastructure .............................................................. .......................... 31 Web Services Framework ........................... ........................................................ 32 4.2.1 4.2.2 4.2.3 4.3 Distributed Computing ..........................................................

..................................... 32 Distributed Component Object Model .... ............................................................ 33 Common Object Re quest Broker Architecture ................................................... 33 .NET Remoting ................................................................. ................................. 34 4.3.1 4.3.2 4.3.3 ii

4.3.4 4.3.5 4.3.6 4.4 COM+ ........................................................................... ..................................... 34 XML Web Services ...................... ...................................................................... 35 Window s Communication Foundation ..................................................... .......... 35 Web Service Technologies ....................................................... .................................. 37 Simple Object Access Protocol ............ .............................................................. 37 Web Services D escription Language ............................................................ ...... 38 Universal Description, Discovery and Integration ..................... ......................... 39 Representational State Transfer ................... ....................................................... 40 JavaScript Object Not ation .......................................................................... ....... 42 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.5 4.6 5. The Web Services Debate: SOAP vs. REST ......................................... ..................... 43 Conclusion ............................................ ..................................................................... 45 Architecture & Design .......................................................... ............................................. 46 5.1 5.2 5.3 5.4 Sequence Diagra m............................................................................... ....................... 46 Component Diagram ................................... ............................................................... 48 Class Diagram s............................................................................... ............................ 48 Deployment Diagram ............................. .................................................................... 53 6. Implementation ................................................................. ................................................. 55 6.1 6.2 Database Setup .... ................................................................................ ....................... 55 Android Development ................................. ............................................................... 56 Login ....... ................................................................................ ........................... 56 Tab Activity .................................... ................................................................... 59 Portfolio ............................................................................... .............................. 59 Feed ......................................... ........................................................................... 66 L ocation......................................................................... ..................................... 70 Camera ................................ ............................................................................... 73 About ....................................................................... ........................................... 75 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.3 Web Services Development ....................................................... ................................ 76 ASP.NET Mock-up Application ................ ......................................................... 76 Accessing the Datab ase Data ....................................................................... ....... 77 Web Services ........................................................ .............................................. 77

6.3.1 6.3.2 6.3.3 6.4 6.5 7. Testing......................................................................... ............................................... 78 Deployment .................. ................................................................................ .............. 79 Conclusions .................................................................... .................................................... 80 List of References ............................................................. ......................................................... 83 iii

Table of Figures Figure 3-1: Android version distribution (Android Developers, 2012). ........... .......................... 11 Figure 3-2: Android Architecture (Android Develope rs, 2011). ................................................ 13 Figure 3-3: The A ctivity Lifecycle (Android Developers, 2011). .................................. ............ 18 Figure 3-4: Mobile applications in the firm value chain (Adapted from Barnes, 2002). ............ 23 Figure 4-1: .NET Framework in context (MSDN , 2012). .......................................................... 30 Figure 42: Structure of a SOAP Envelope (Skonnard, 2003). .............................. ..................... 38 Figure 4-3: Basic Structure of a WSDL Definition (Skonn ard, 2003). ....................................... 39 Figure 4-4: JSON represen tation of an array (Aziz & Mitchell, 2007). .................................... .. 42 Figure 5-1: Login Activity Sequence Diagram .............................. ............................................ 47 Figure 5-2: Component Diagram .. ................................................................................ ............. 48 Figure 5-3: Login Activity Class Diagram ...................... ........................................................... 49 Figure 5-4: Portf olio Activity Class Diagram .................................................... ........................ 50 Figure 5-5: Feed Activity Class Diagram ............ ....................................................................... 51 Figur e 5-6: Location Activity Class Diagram ......................................... ................................... 52 Figure 5-7: RPM Mobile Deployment Diagram ......................................................................... 53 Fi gure 6-1: Login Screen ......................................................... .................................................. 58 Figure 6-2: Tab Widget ... ................................................................................ ........................... 59 Figure 6-3: Portfolio............................ ................................................................................ ....... 61 Figure 6-4: Portfolio - Project Details ............................. ........................................................... 64 Figure 6-5: Portf olio Project Details PDF ....................................................... ........................ 65 Figure 6-6: Feed ................................... ................................................................................ ...... 67 Figure 6-7: Project Tasks ............................................ ............................................................... 69 Figure 6-8: L ocation Map View ............................................................... ............................... 72 Figure 6-9: Location Satellite View ......... ............................................................................... 73 Figure 6-10: Camera ......................................................... ......................................................... 74 Figure 6-11: About ................................................................................ ..................................... 75 Figure 6-12: RPM Mock-up Web Applicatio n ........................................................................... 76 Table of Tables Table 3-1: Android Versions (Adapted from Android Developers, 2011). ........... ..................... 10 Table 3-2: Mobile applications in the firm value chain (Adapted from Scornavacca & Barnes, 2008). ..................................... ................................................................................ .................... 24 Table 4-1: Descriptions of the core WSDL Elements (Adapt ed from Skonnard, 2003). ............ 39 Table 4-2: REST Data Elements (Adapted from Fielding, 2000). .............................................. 41 iv

Introduction 1. Introduction Currently a new generation of mobile devices including smartphones and tablet co mputers are instigating a major shift towards mobile computing in everyday socie ty. This has led to mobile applications becoming a major influence on enterprise strategy in the business world and along with cloud services and infrastructure , has opened up a new avenue for improved decision making, reduced costs and inc reased employee productivity within the workplace. Mobile computing has now adva nced beyond its traditional purpose as a simple tool for emails and navigation a nd has become a strategic tool that assists in reaching the targets set by the e nterprise. Web services are becoming ever more omnipresent, enabling companies t o expose data or the functionality of an existing code base over the web, which can then be used by other applications in some useful and meaningful way. Compan ies such as Microsoft, Google and Amazon have made early advances in this space in recent times with their respective technologies: Windows Azure, Google App En gine and Amazon Web Services. The author proposes that a smartphone application, along with a set of web services, be developed to showcase the value and potent ial of IT and mobile computing solutions in a business environment. Since contac t had formerly been established with a company that could provide some requireme nts for such, it is possible that the idea could be realised to demonstrate a re al world scenario of the benefits that companies can gain when a solution such a s this is embraced and utilised. 1

Introduction 1.1 The Company Enverian Energy Solutions Ltd provides software for the renewable-energy sector known as Enverian Renewable Portfolio Management (RPM). This allows for the trac king of project progress, identification of potential investments (by ranking op portunities in various jurisdictions across a range of different energy types) a nd the valuation on investment return. The author proposed the initial project c oncept to the company which was regarded as a most beneficial opportunity to dem onstrate the potential of a mobile version of the RPM system. Therefore some req uirements were provided for this project as well as permission to use a portion of the RPM development database that would provide realistic client data. 1.2 Aims & Objectives The aims and objectives of the project are: To develop a multi-tier solution uti lising smartphone technology and cloud based web services. To demonstrate the us efulness of a mobile computing solution in the domain of renewable energy portfo lio management, allowing users to track a portfolio of renewable energy developm ent opportunities. To develop an application that allows quick and easy access t o business information. The ultimate goal is to demonstrate the value and use of IT within a business environment. This would be accomplished through a solution that aids decision making and helps to achieve important targets. Since Enveria n provided some requirements, the 2

Introduction project will be focused on the application of IT within the renewable-energy sec tor. Therefore, with the companys permission, the project has been named RPM Mobi le. 1.3 Project Overview The origin, evolution and success of smartphones in recent times are dealt with in chapter two. The mobile platform that was chosen to develop the project on is discussed in chapter three, detailing development tools, concepts and component s to provide an insight into development for the mobile platform of choice. Web technologies and the various distributed computing technologies that have been u sed over the years are examined in chapter four. This research was used by the a uthor to decide what technologies to use to build the web services for the proje ct. Chapter five provides a high level overview of the main sections of the proj ect using UML to visualise its architecture. The implementation of the project i s dealt with in chapter six, discussing topics such as database setup, mobile de velopment, web service development, testing and deployment. Lastly, the aims and objectives that were achieved and the authors overall experience with the proje ct are recounted in chapter seven. 3

General Background & Related Work 2. General Background & Related Work 2.1 Smartphones Conceptualisation to Realisation Smartphones, the hybrid of computers and communications, are a recent technologi cal innovation. Conceptually, however, their origins date back to the vision of digital convergence between communications and computing, first proposed by Koji Kobayashi in 1977 (National Academy of Engineering, 2001). Dr. Kobayashi envisi oned a future information rich society and subsequently coined the term C and C (c omputers and communications) to describe the combining of computers and communic ations into a single information infrastructure (Koji Kobayashi, 2011). West & M ace (2007) note that as the communications and computing industry evolved over t ime, this decades-old vision of digital convergence was realised with the emerge nce in the 1990s of a mobile computing-enabled device that could provide both vo ice and data communications. Today the category is known as the smartphone. 2.2 Market Experiments in Smartphone Devices West & Mace (2007) suggest that initially smartphone devices were limited by the available hardware required to make them, including LCD screens, fast microprocessors, adequate battery life and reasonable data bandwidth. The Nokia 9000, released in 1996, is widely believed to be the first smartphone, as noted by West & Mace (2007). It was marketed in Europe to be a replacement for a small laptop and included a built in QWERTY keyboard but failed to be a major success due in part to its size and weight. West & Mace (2007) again note that the firs t US PDA phone was Qualcomms pdQ, released in 1998, which incorporated the Palm OS. However, like the Nokia 9000 it was perceived to be too large and heavy so it t oo failed to find a large audience. 4

General Background & Related Work After the turn of the millennium, the devices began to match the customers expect ations with a number of handsets including the Handspring Treo 180, Research in Motion (RIM) BlackBerry 5810 and the Ericsson p800 becoming key smartphone produ ct milestones (West & Mace, 2007). The improved consumer confidence in smartphon es was short lived however. In 2004, Motorola and Apple joined forces to launch a music phone that could play songs from Apples iTunes music and video service. K nown as the Motorola ROKR and released in the autumn of 2005, it was carried exc lusively by Cingular Wireless (now the wireless unit of AT&T) and was an enormou s disappointment for Apples administration (Sharma et al., 2007). As design conno isseurs, the conspicuous shape of the phone and the clunky interface left them t horoughly dissatisfied. It became apparent to Apple that if they were serious ab out the mobile phone market they would have to design and build their own handse t. In early 2005, the initial concept of the iPhone was pitched by Steve Jobs to Stan Sigman (the then respective CEO of Apple and Chief Executive of Cingular W ireless), who later met and agreed to pursue the idea (Sharma et al., 2007). 2.3 The Advent of the iPhone & The Mobile Revolution Early 2007 saw the announcement of Apples iPhone, a sleek device designed to work as a mobile phone and an iPod music player and which also had web browsing func tionality (Sharma et al., 2007). The iPhone incorporated the features most commo n to other phones including voice connectivity, calendar control, contact list a nd email but had major differences that differentiated it from the competition ( West & Mace, 2010). A touch sensitive screen was to be the focal point of the de vice which, unlike other devices, would be large and consume most of the frontal surface area of the device (Sharma et al., 2007). West & Mace (2010) note that this touchscreen, along with a 5

General Background & Related Work software-defined virtual keyboard for numeric and text input, would replace the physical keypad common to most phones. One of the most prominent features of the iPhone other than its large screen was the built in web browser which was adapt ed from Apples very own Safari web browser for its personal computers and augment ed with touch-enabled interface features that helped manage web browsing on the 320 x 480 pixel resolution screen. With a standard web browser and a larger than normal, touch-enabled screen, Apple aspired to revolutionise the mobile Interne t experience and provide an experience much closer to a PC than any previous mob ile phone. As Mr. Jobs said just a few weeks prior to the launch of the original iPhone, People want the real Internet on their phone. We are going to deliver th at (Block, 2007). Despite an overwhelming torrent of interest, the iPhone became the subject of disdain among sceptics with its high price, lack of 3G support, i nability to download or sync wirelessly and non-removable battery receiving much criticism. However, to many analysts it was the iPhones closed system and its ca rrier exclusivity, initially to Cingular Wireless, that were its most controvers ial features (Claburn, 2007; West & Mace, 2007). While carrier exclusivity was c ommon amongst new phones in the U.S to assure remuneration of an initial handset subsidy by the carrier (West & Mace, 2007), it was seen as an attempt by Apple and Cingular to seize a monopoly in the smartphone market. Apple, in their joint venture with Cingular, would keep unprecedented control over distribution of th e iPhone, Cingular in return would gain a competitive advantage as the sole carr ier of the iPhone, one of the most eagerly awaited consumer electronics devices in years (Sharma et al., 2007). 6

General Background & Related Work Upon the release of the iPhone, the result was an expensive product which ran on ly on the slower 2G EDGE network, didnt allow users to make email searches or vid eo recordings and on which the browser couldnt execute programs written in Java o r Flash. However, this was of little consequence. The iPhone revolutionised the landscape of the wireless industry providing consumers with what was essentially an easy to use handheld computer while the manufacturers gained new bargaining power over the carriers and had more control over what they could produce as car riers sought new ways to revitalise their products. The iPhone later sparked a w ave of development akin to the advent of the PC with the release of a developers kit that allowed anyone to create programs for it and which ultimately made the device even more powerful and popular (Vogelstein, 2008). 2.4 The Rise of Android With the success of the iPhone, Apple seemed destined to rule the mobile market. However, behind the scenes Google was preparing to enter the mobile space with its own OS known as Android. Originally developed by a little known start-up of the same name, Android Inc. and based on a modified version of Linux, the Androi d OS was designed as a modern mobile operating system that could run many applic ations at the same time and which would excel at rendering web pages. In 2005, G oogle procured Android and took over its development work as well as its develop ment team and ultimately decided to make Android open and free by releasing it t hrough the opensource Apache License. This meant that anyone who wanted to use i t could do so and allowed vendors to customise it to differentiate their product s from others (Lee, 2011). This was in stark contrast to Apples strategy of a clo sed system where only Apple products could use the iOS operating system. 7

General Background & Related Work When the first Android phone was launched in 2008, nobody could have predicted h ow quickly the Android platform would take off, how a seemingly insignificant pi ece of software would usher in the mobile revolution and transform the affluence of the worlds biggest tech companies. In July 2011, Google announced it was acti vating 550000 Android phones daily, more than doubling the number of activations in less than a year (Panzarino, 2011). Android is now by far the fastest growin g platform and has soared past Apples iOS to become the biggest smartphone platfo rm in the world (Gartner, 2011). With smartphones and the recent introduction of tablet computers setting the scene for what is possible on mobile devices, the mobile revolution is taking the world by storm and may have the largest impact s ince the advent of the PC. The world is on the cusp of evolving to new heights a s a highly information-oriented society and with instant access to essentially t he entire worlds information via the Internet, Dr. Kobayashis vision from some thr ee decades ago has been realised. 8

Mobile Development 3. Mobile Development Prior to researching the topics in this chapter, the author selected the Android platform as the preferred mobile operating system to develop the RPM Mobile app lication on. The Android platform was chosen over the other mobile platforms inc luding iOS for a number of reasons. Firstly, Android applications are written in Java, a programming language the author is quite familiar with, compared to iPh one development in which applications are written in Objective-C, of which the a uthor has little experience with. Secondly, Android is an open-source developmen t platform. All the development tools including the Eclipse IDE, Android SDK and the ADT plugin for Eclipse can be downloaded freely with no licensing fees. Thi s is a distinct advantage over the competing platforms such as iOS which has a s ignificant cost attached. Additionally, Google have provided extensive documenta tion and tutorials to support developers and there exists a thriving developer c ommunity who are very active on the numerous development forums. 3.1 Android Versions & Distribution There have been many updates to the Android platform since its initial release ( Table 31) with various versions, and the corresponding API levels and codenames being released. The version number illustrates the major and minor releases over time but it is the API level that is the most significant as it determines what applications can be run on a device. 9

Mobile Development Table 3-1: Android Versions (Adapted from Android Developers, 2011). Platform Version Android 4.0 Android 3.2 Android 3.1.x Android 3.0.x Android 2.3 .5 Android 2.3.4 Android 2.3.3 Android 2.3.2 Android 2.3.1 Android 2.3 Android 2 .2.x Android 2.1.x Android 2.0.1 Android 2.0 Android 1.6 Android 1.5 Android 1.1 Android 1.0 API Level 14 13 12 11 Codename ICE CREAM SANDWICH HONEYCOMB MR2 HONEYCOMB MR1 HONEYCOMB 10 GINGERBREAD MR1 9 GINGERBREAD 8 7 6 5 4 3 2 1 FROYO ECLAIR MR1 ECLAIR 0 1 ECLAIR DONUT CUPCAKE BASE 1 1 BASE The aim of any application is to be capable of running on as many devices as pos sible, so deciding what platform version to target when first creating an applic ation is an important decision as it ultimately limits who is going to be able t o use the application. Figure 3-1 shows a snapshot of the platform versions of A ndroid devices that accessed the Android market during a 14-day period, ending o n January 3, 2012. 10

Mobile Development Figure 3-1: Android version distribution (Android Developers, 2012). As can be seen from the distribution chart, there are not many users of the olde r Android 1.5 and 1.6 platform versions. Most likely these users wont be able to upgrade their device to the 2.x versions as their device simply does not have th e relevant firmware and the manufacturers are busy developing new models and so would not have the time to release a firmware upgrade (Gargenta, 2011). Also, it is evident that not many users have the latest version, Android 4.0 as the char t captures just a small percentage of the users running it. However, the number of users running some form of Android 2.x, most notably Android 2.2 and Android 2.3.3, is growing as many devices are being upgraded over the air (OTA) automati cally (Gargenta, 2011). Therefore, Android 2.2 or Android 2.3.3 would currently be a good choice as the minimum development target for the creation of an applic ation. 11

Mobile Development 3.2 The Android Architecture Android is a software stack for mobile devices which is roughly divided into fiv e sections in four main layers (Figure 3-2) spanning from the Linux kernel, whic h is built upon Linux version 2.6, to the applications which ship with the devic e. The layers are not entirely separated but rather they often overlap each othe r (Gargenta, 2011). The Linux Kernel is at the base of the Android stack which h andles core services including security, process and memory management, network and power management and hardware drivers. A layer of abstraction between the ha rdware and the rest of the software stack is also provided by the kernel (Meier, 2010). As indicated by Gargenta (2011), it is not necessary to know too much ab out the underlying hardware features as most of the low-level parts of Linux hav e been written in fairly portable C code and thus allows third parties to easily port Android to various devices. Android consists of an assortment of C/C++ cor e libraries running on top of the kernel (Meier, 2010). All of the code that pro vides the main features of the Android OS is contained in these libraries (Lee, 2011) which are exposed to developers through the application framework to provi de necessary services to the application layer (Gargenta, 2011). Some of the cor e libraries include SQLite for native database support, Webkit for web browsing, SSL for Internet security as well as graphics libraries for 2D and 3D graphics and media libraries for audio and video playback (Meier, 2010). As noted by Garg enta (2011), most of the libraries are used as-is, however, there is one noticea ble exception that is Bionic. Essentially a rewritten version of the standard C library, Bionic is tailor-made for small, battery powered devices. 12

Mobile Development Figure 3-2: Android Architecture (Android Developers, 2011). The Android runtime, the engine that powers the applications, (Meier, 2010) cons ists of a set of core libraries that enable the use of the Java programming lang uage by developers to write Android applications (Lee, 2011). It also consists o f a virtual machine called the Dalvik virtual machine which is register based an d ensures multiple instances can be run efficiently on a device (Meier, 2010). D alvik is purpose-built and designed from the ground up to specifically address t he issues of limited battery life and processing power in mobile devices. It is similar to the Java virtual machine with the difference that when a Java source file is compiled to Java byte code using a Java compiler it is then recompiled a gain with the Dalvik compiler to Dalvik byte code (Gargenta, 2011). It is this D alvik executable format (.dex), optimised to ensure minimal memory footprint, th at is then executed on the Dalvik VM (Meier, 2010). 13

Mobile Development The application framework consists of an abundance of classes, including librari es specifically built for Android, which are exposed to developers to be used by their applications. It also plays host to many of the system-defining capabilit ies that applications can tap into including telephony, sensors, location and Wi -Fi (Gargenta, 2011). It is noted by Meier (2010) that the application framework also manages the user interface and application resources as well as forming a generic abstraction for hardware access. The application layer is made up of bot h the native applications that ship with the device and third party applications that are available to download and install from the Android market (Lee 2011). The application layer runs within the Android runtime with classes and services provided by the application framework (Meier, 2010). 3.3 Android SDK & Development Tools Android applications are developed in Java as Android is just an environment wit hin which to run applications and is not itself a programming language. It is th eoretically possible to create Android applications with any integrated developm ent environment (IDE) that supports Java or even without the use of an IDE by us ing the command-line interface (CLI). However, one particular Java IDE is commen ded by Google and the Open Handset Alliance over any other, this IDE is known as Eclipse and is fully featured and freely available for multiple operating-syste ms including Windows, Mac and Linux. This wide availability means that Android a pplications can be made on almost any computer. Since Eclipse itself was written in Java, it requires the Java Runtime Environment (JRE) to run. However, though the JRE enables Java-based applications to run, it does not allow the user to c reate them. Therefore, it is preferable to download and install the Java Develop ment Kit (JDK) as it contains all the tools and 14

Mobile Development libraries required to create Java applications as well as the JRE to run them (D iMarzio, 2008). The JDK and Eclipse form the prerequisites for the Android SDK, where at its core lies the application programing interface (API), an accumulati on of all the code libraries, classes, methods and properties that are required to create applications that run exclusively on the Android platform. Two accompa nying sets of APIs include the Google APIs, which grant the application access to Google services such as Google Maps, and Optional APIs which provide functionalit y that is not provided for by the standard Android APIs (DiMarzio, 2008). The And roid SDK also accommodates a multitude of other debugging and development tools such as an Android emulator, scripts, executables and documentation (Mednieks et al., 2011). Additionally, the Android Developer Toolkit (ADT) plug-in is requir ed to enable Eclipse to perform Android-specific tasks such as launching the And roid emulator, using the emulator to connect to debugging services and editing A ndroid XML files to name but a few. The ADT also allows the SDK Manager and the Android Virtual Device (AVD) Manager to be invoked from within Eclipse. The SDK Manager is used to install one or more build targets to successfully create and build an Android application (Mednieks et al., 2011) while the AVD Manager is a tool that facilitates the simulation of various hardware specifications and soft ware builds available on a range of devices (Meier, 2010). 3.4 The Android Native Development Kit The Android Native Development Kit (NDK) is an add-on or companion tool to the A ndroid SDK (Mednieks et al., 2011) and permits native code and libraries to be c alled, typically through C or C++ language APIs within the Android application (G argenta, 2011). Android uses the Java Native Interface (JNI) segment of the Java standard, 15

Mobile Development which implements the ability to write and call native methods, to access this na tive code (Mednieks et al., 2011). The main incentive to develop aspects of an a pp in native code is for increased performance. However, it is not recommended r ecoding a random method to run in C as this usually does not result in any signi ficant performance increase. Native code should only be used when the Android SD K does not already provide the functionality (Mednieks et al., 2011). It is impo rtant to note also that the same security sand-boxing rules that apply to an And roid application also apply to any native code accessible via the JNI as it stil l runs inside the applications Dalvik VM (Gargenta, 2011). The latest revision of the NDK, Android NDK, Revision 7, was released to the public in November 2011 a nd includes a host of new features to support the latest version of the Android platform, Android 4.0, among other additions and improvements. Android NDK, Revi sion 7 adds a new API for native multimedia support based on the Khronos Group O penMAX AL 1.0.1 standard. This new API now allows applications targeting API lev el 14 to use a new Android-specific buffer queue interface to perform multimedia output directly from native code. NDK Revision 7 also adds native audio support with an update to the API based on the Khronos Group OpenSL ES 1.0.1 standard t hat allows for compressed audio (e.g. MP3, AAC) to be decoded to PulseCode Modul ation (PCM). Also support for CCache, a compiler cache, has been added to speed up large rebuilds (Android Developers, 2011). 3.5 Android Fundamental Concepts & Components Android brings to the programming world some new development concepts which aim to alleviate the difficulty in writing applications for technically limited devi ces and includes some interesting application components that form the building blocks of an 16

Mobile Development Android application. First and foremost are Activities which form the presentati on layer of all Android applications and are generally the most visible part of the application as every screen is an extension of the Activity class. It is com mon for applications to have multiple Activities, as seen in the development of the application in chapter six, which provide navigation through the various scr eens in the application. Using Views to design graphical user interfaces (GUIs), Activities display information and allow for interaction with the user (Meier, 2 010; Gargenta, 2011). With every application comes an application life cycle and Android applications are no exception though it is unique as a considerable amo unt of the Android life cycle is handled by the system. Android observes all run ning processes and can end an Activity to free up required resources depending o n whether the Activity is running as a foreground or background process (DiMarzi o, 2008). Figure 3-3 illustrates the life cycle of an Activity and the states it goes through, from when the Activity is started until it ends. 17

Mobile Development Figure 3-3: The Activity Lifecycle (Android Developers, 2011). The next concept introduced with Android is that of Intents. Sent amid all the m ajor building blocks, Intents are essentially asynchronous messages that carry o ut some functionality such as triggering an Activity to start up or telling a Se rvice to start or stop, while the sender is not required to wait for the task to be completed. For example, if an Activity needs to open a web page via a web br owser, an Intent known as the WEB_SEARCH_ACTION Intent is sent to the Android In tent Resolver which selects the appropriate Activity for the Intent, in this cas e, the Web Browser Activity. Intents can be explicit, where the sender specifica lly indicates what the receiving component 18

Mobile Development should be, or implicit, where just the type of receiver is specified by the send er. Intent Filters are used to describe to the system which implicit Intents can be received by an Activity, Service or Broadcast Receiver and what data should be passed with the Intent (Gargenta, 2011; DiMarzio, 2008). As well as multitask ing, Android was also designed to be able to run background Services. Used for e xactly this purpose, Services may be active for long durations but which may not necessarily be visible on screen. For example, a user can view web pages while a Service plays music or downloads data in the background. Applications can also share functions through long-term connections using Services, similar to how In ternet services such as HTTP and FTP wait to be triggered by a request from a cl ient. Services are similar to Activities but differ in how their life cycle oper ates. Services can be either started or stopped and unlike Activities, the Servi ce life cycle is not so much controlled by the system but rather by the develope r (Gargenta, 2011; Mednieks et al., 2011). As mentioned earlier Intent objects a re delivered to another of Androids communication mechanisms known as Broadcast R eceivers. Similar to Services in that they have a simple life cycle and do not h ave their own user interface, Broadcast Receivers implement a system-wide mechan ism for responding to broadcast Intents that match specific filter requirements. Many broadcast announcements emanate from the system itself, for example, when the battery runs low, a SMS arrives or for an incoming call, and any number of r eceivers could be triggered by them (Mednieks et al., 2011; Gargenta, 2011). Sin ce Android applications run sandboxed in their own virtual machine, they remain completely separate from other applications on the device and cannot directly sh are 19

Mobile Development data. As such, Content Providers are used for sharing data between applications and managing the data model of an application. Content Providers are interfaces comparable to RESTful web services (described in chapter four) in how they are f ound using a Uniform Resource Identifier (URI). Also in parallel to RESTful web services, Content Providers operate using the famous quartet of activities for h andling data, create (insert), read (query), update and delete. There also exist s a class called ContentResolver which assists Content Providers by enabling oth er components to find them (Gargenta, 2011; Mednieks et al., 2011). To link all these components together and to clearly define the contents of an application, an XML file called the AndroidManifest.xml is required and is located at the roo t of the project hierarchy. All the Activities, Services, Broadcast Receivers an d Content Providers included in the application are declared here and their inte ractions, with each other as well as with other applications, are determined usi ng Intent Filters and Permissions. The manifest also defines the structure and m etadata of the application along with providing attributes for defining platform and hardware support requirements as well as for unit tests and security settin gs (Mednieks et al., 2011; Meier, 2010). 3.6 Web vs. Native Development With a web browser and Internet connectivity, it is often questioned whether the re is any need to develop a native Internet-based application when a web-based v ersion could be made instead (Meier, 2010). Benefits of creating a native applic ation include bandwidth, caching and native features. As many consumer devices c ome with strict and expensive bandwidth restraints, it is not ideal for static r esources such as sounds, images and layouts to be downloaded every time the appl ication is loaded. By 20

Mobile Development developing a native application, the bandwidth requirements can be limited to up dated data only. With a browser-based solution, application availability is whol ly dependent on a reliable Internet connection whereas a native application can cache the data and provide the user with a degree of functionality and usability when an Internet connection is unavailable. Also, native features such as locat ion-based services, widgets, accelerometers, cameras and notifications, accessib le through the various APIs, can be combined with the data available online to pr ovide a richer user experience in native applications (Meier, 2010). However, na tive application development is more complicated due to the differences among th e various platforms SDKs. Each platform has its own set of tools, APIs, build syst ems and devices with different capabilities. Web applications are cheaper to dev elop and deploy than native applications as the need to build a different applic ation for each platform is eliminated. While interpreted languages such as JavaS cript are slower than native code, they are holding their own and are rapidly ga ining ground in terms of performance. In fact, JavaScript virtual machine techno logy is now at the forefront of the browser wars with extensive spending by comp anies such as Microsoft, Mozilla, Google, Apple, and Opera fuelling this JavaScr ipt arms race and all trying to surpass competing solutions (ieblog, 2010). The trend is quickly becoming that the web technology stack (HTML, CSS, JavaScript) is running at a low level providing better performance at a lower CPU cost which ultimately leads to longer battery life. The argument that native apps are fast er stands true for 3D games and image processing applications but it does not ho ld much ground anymore for the vast majority of wellbuilt web applications (Char land & Leroux, 2011). It is true that native applications hold an advantage over their web counterpart in terms of easily accessing device data, storage and sen sors through low-level APIs, but this 21

Mobile Development gap is being closed too. In 2008, a hack for the first iPhone OS SDK, known as t he PhoneGap technique, was created to provide developers with a way of creating applications in HTML, CSS and JavaScript while also enabling native device featu res to be called via a common JavaScript API. As virtually all mobile platforms allow an instance of a browser to be instantiated, it is possible to interact wi th its JavaScript interface through native code and from within this Webview it is then possible to call native code from JavaScript. PhoneGap is now an open so urce framework, ported to all the major mobile platforms, that includes the nati ve-code segments that are necessary for interacting with the underlying operatin g system to pass data back up to the JavaScript application running in the Webvi ew container. It currently has support for features such as geolocation and acce lerometer (Charland & Leroux, 2011) and it is highly likely that browsers will h ave access to many more APIs in the not too distant future with the W3C having cr eated a Device API Working Group (Hazael-Massieux, 2011). 3.7 Enterprise Mobility With the breakthrough in mobile Internet technology over the past decade, mobile business, commonly known as m-business, is changing the way many organisations operate, enabling firms to overcome the conventional constraints of the fixed-li ne personal computer and providing an opportunity to gain competitive advantage through the use of m-business applications (Scornavacca & Barnes, 2008, and refe rences therein). It is noted by Scornavacca & Barnes (2008) that previous work p ortrays mobile applications as the advancement for the integration of IT in the value chain, a sequence of interdependent activities that delivers a service or product to the customer, as they can provide valuable business benefits. In Figu re 3-4, Barnes (2002) illustrates an analysis of the plausible opportunities of mobile technologies in a companys value 22

Mobile Development chain and provides examples in Table 3-2 of the possible consequences of mobile applications for businesses. Based on the analysis, Barnes (2002) identified eig ht fundamental advantages which were not mutually exclusive, including: business transformation, connectivity, effectiveness, efficiency, flexibility, interacti vity, locationawareness and ubiquity. SUPPORT ACTIVITIES Infrastructure: Scheduling messaging; wireless networking Human Resources: Mobil e workforce automation Product and Technology Development: Field testing & repor ting Procurement: Mobile procurement systems & electronic markets Inbound Logist ics: Rolling inventory systems Operations: Mobile financial services; Customer ale rts Outbound Logistics: Mobile inventory & delivery systems Sales & Marketing: M obile salesforce; Mobile consumer Service: Equipment maintenance; Diagnostic sys tems PRIMARY ACTIVITIES Figure 3-4: Mobile applications in the firm value chain (Adapted from Barnes, 20 02). 23

Mobile Development Table 3-2: Mobile applications in the firm value chain (Adapted from Scornavacca & Barnes, 2008). Support activities Infrastructure Impact of mobile applications Wireless networks and devices can help to strongly integrate remote, disparate or roaming employees into the corporate infrastruct ure. Handheld training devices and location aware technologies may be useful for remote or roaming workers (e.g. field and sales force automation). The impact o f mobile technologies in product and technology development is quite embryonic. However, field testing and reporting is one area where it is likely to have an i mportant role. Exceptional roaming employees who are involved in procurement mig ht be aided by using mobile IT in the B2B domain. Impact of Mobile Applications Mobile applications can accurately monitor inbound inputs to the firm. By knowin g the location of rolling inventory, times between transactions, manufacture and d elivery can be further reduced. The impact of mobile ICTs on the operations comp onent of the value chain is likely to be enormous. There are many applications s uch as meter reading, customer alerts and credit authorization that would benefi t from the mobile value propositions. Mobile ICTs especially location technologi es can play an important part in outbound logistics. Fleet management systems he lp freight companies to monitor the status of deliveries and other outbound logi stics activities. In many industries, the sales force is becoming increasingly m obile and teleworking is a very real part of sales activity. Mobile technologies allow strong integration of a remote sales force into ERP and other key systems . Mobile marketing is another emerging application in this area of the value cha in. Similarly to the product and technology development activity, devices can be embedded in products to bring benefits to the service activity. Mobile technolo gies can provide information for field workers (e.g. technicians), increasing pr oductivity and customer satisfaction. Human resources Product and technology development Procurement Primary activities Inbound logistics Operations Outbound logistics Sales and marketing Service Basole (2008) suggests that, now more than ever, the logic of the use of mobile ICT by businesses is well recognised as the long-term strategic advantages offer ed by enterprise mobility are being realized. Also, the basic building blocks of the mobile data equation are falling into place as the technology has considera bly improved, leading to devices being more capable for mobile data use, wireles s networks able to handle higher data throughput and mobile applications that ad d value to business operations frequently materializing. Mobile ICT enables work ers to access important data whenever and wherever required meaning that staff c an always remain productive, even when outside of the office and so potentially, organizations, supply chains and markets could be virtually transformed through mobile enterprise solutions (Basole, 2008). 24

Mobile Development 3.8 Security in Mobile Devices Security is a major issue for any device that may contain sensitive information and which can access the Internet, especially for the enterprise user. Recent re search suggests that the real security issue lies with the platforms these devic es run on and the applications that can be downloaded through the online app sto res. For example, the rigorous quality control that Apple holds over its iTunes store is not replicated by the Android Market as Android apps are part of an ope n-source framework meaning the Android Market is accessible by any and all appli cation developers. The positive side to this is that more and a greater variety of apps would be available to users but the shortcomings rest with the security features of Androids openness which presents security vulnerabilities and become s a target for malware writers. Some people claim that application stores, such as the Android Market, are not doing enough with regards to security and argue t hat the security of the programs that are available are not sufficiently tested to determine if the applications contain malware. Others feel that the Android o perating system and its developers have a good grasp on security and that the pr oblem lies predominantly with the applications and how they are used, claiming t hat many users access and download applications without a second thought as to w hether it comes from a trusted source (Amorosi, 2011). Through extensive researc h, Winder (2011) notes that mobile phone security was somewhat overhyped through out the years but those concerns are now valid as smartphones and tablets become omnipresent and app development becomes easier. Smartphone platforms have becom e a target for hackers but the Android platform in particular is being targeted above all else due to its recent growth as the dominant mobile operating system. However, this does not mean that other mobile operating systems are without the ir own security problems. In fact, Apples iOS has come under 25

Mobile Development fire due to its lack of a file system. Winder (2011) notes that iPhone and iPad users within businesses are blindly making use of cloud-based consumer services to share confidential information without the slightest regard for corporate and IT security policies leaving IT and security teams with no account of what ente rprise data has been shared. Despite the security problems in mobile devices, it is unlikely that the security risk will reach the level seen on Windows as hack ers have a lot more to gain for a lot less work by targeting data stored in SQL databases or on web servers (Winder, 2011, and references therein). 3.9 Conclusion Upon completion of the research contained within this chapter the author gained a valuable insight into the world of mobile development, specifically on the And roid platform. The initial research focused on topics such as Android versions a nd distribution, the Android architecture, SDK and development tools and the fun damental concepts and components. This research empowered the author with crucia l knowledge to help understand Android development and the critical decisions th at need to be made early in the development of the application such as what vers ion of the Android OS to target. An understanding of the various concepts and co mponents that make up Android development facilitated the author with the develo pment of the application, especially with regards to Activities, the Activity li fecycle and Intents. The later research topics of the chapter dealt with the mat ters of web vs. native development, enterprise mobility and security in mobile d evices. This research was carried out to gain an understanding of some of the in dustry-wide issues related to mobile development. The discussion on web vs. nati ve applications is interesting as it highlights an alternative route for develop ment, one which may prove to be a more 26

Mobile Development desirable option when the tools and technology mature to a standard on par with native development. The subject of enterprise mobility is particularly important to this project as the final version of the software would ultimately be used i n a business environment. The research details the benefits a business can gain by using enterprise mobile applications and how businesses are slowly coming to terms with and realising its true potential. Lastly, the discussion on mobile se curity delved into what may be the root cause of security breaches on mobile dev ices detailing two sides to the argument, one which claims that the operating sy stem and its developers are not taking necessary measures and the other which cl aims that a lack of awareness by the user is to blame. The significance of mobil e security in the business environment was also discussed detailing the blatant disregard for security policies by many employees. 27

Web Technologies 4. Web Technologies The subsequent topics were researched as web services played a significant role in the development of the project. This chapter gives an insight into the web te chnologies of the past and the present to provide an understanding of how the au thor chose which technologies to use to build the web services that would help r un the RPM Mobile application. Such topics include the .NET Framework and ASP.NE T, the various distributed computing technologies that have come and gone over t he years leading up to the modern day web services, their technologies and the l atest APIs to build them. The .NET Framework and ASP.NET are discussed as they ar e integral in the development of the web services that were developed. Rounding out the chapter is a discussion on the debate of SOAP vs. REST detailing the adv antages and disadvantages of both technologies and how REST is rapidly gaining p opularity in the computing world. 4.1 .NET Framework The .NET Framework is Microsofts latest application development platform for buil ding, deploying and running the next generation of applications and web services . In designing the .NET Framework, Microsoft set out to accomplish a number of o bjectives: To provide a dependable object-oriented programming environment. To m inimize software deployment and versioning conflicts. To promote safe execution of code. To eliminate the performance problems of scripted or interpreted enviro nments. To make a consistent developer experience across a range of application types. To build upon industry standards for easier code integration. 28

Web Technologies The .NET Framework is made up of two main components: the common language runtim e and the .NET Framework class library (MSDN, 2012). 4.1.1 Common Language Runti me The common language runtime (CLR) establishes the foundation of the .NET Framewo rk and manages memory, code execution, thread handling, compilation, verificatio n of code safety and other system services for the managed code that is executed under control of the CLR (e.g. code written in C# or VB .NET). Security is main tained by allocating various levels of confidence in the managed components base d on a number of factors including their origin so that managed components may o r may not be able to perform sensitive functions. The CLR implements an infrastr ucture called the common type system (CTS) to enforce code robustness which ensu res that all managed code is self-describing. The managed code generated by all the language compilers conforms to the CTS. Developer productivity is enhanced b y the CLR as an application can be developed in the programmers language of choic e while still taking full advantage of the runtime, class library and components written in other languages. The CLR was also designed to improve performance, a s such, the source code of an application is not directly compiled to machine co de but rather the managed code compiler converts the code to Microsoft Intermedi ate Language (MSIL), a low level and platform-independent language, which is the n compiled to machine code by a feature known as the Just-In-Time compiler (JITT ER). Performance is further increased by the memory manager by removing the poss ibility of fragmented memory and increasing memory locality-of-reference (MSDN, 2012). It is worth noting that unmanaged code runs outside the CLR (e.g. COM or ActiveX components and Win32 API functions). 29

Web Technologies 4.1.2 .NET Framework Class Library The .NET Framework class library is an accumulation of reusable types that integ rate with the CLR. It is object-oriented and provides types for managed code to derive functionality from, making it easier to use the .NET Framework and reduci ng the time required to learn its new features. This allows for a range of stand ard programming functionality to be accomplished including file access, string m anagement, database connectivity and data collection. The class library also ena bles the programmer to use the .NET Framework to develop specialized application s and services including Windows Forms, console applications, web services, ASP. NET applications and more (MSDN, 2012). Figure 4-1 shows the relationship of the CLR and the class library to the overall system and applications. Figure 4-1: .NET Framework in context (MSDN, 2012). 30

Web Technologies 4.2 ASP.NET ASP.NET is the part of the .NET Framework that enables the development of web ap plications and web services. ASP.NET pages and ASP.NET web services can be coded in any language compatible with the CLR. 4.2.1 Page and Controls Framework The ASP.NET page and controls framework runs on a web server to dynamically rend er markup (such as HTML) and produce ASP.NET web pages to the requesting browser or client device. These ASP.NET pages are fully object-oriented and within them , HTML elements can be worked with using methods, properties and events. The imp lementation details regarding the separation of the client and server, character istic of web-based applications, is removed by the ASP.NET page framework by pre senting a way to respond to client events in code that runs at the server. Featu res provided by the ASP.NET page and controls framework, such as themes and skin s, can be used to control the look and feel of a web site while master pages can be defined to create a consistent layout across all pages, or a group of pages in the application, where the layout of the master page is combined with the con tent of the content page. The pattern for URLs used in the web site can also be defined by the ASP.NET page framework which helps with search engine optimizatio n (SEO) and makes URLs more userfriendly (MSDN, 2012). 4.2.2 Security Infrastruc ture ASP.NET implements advanced security features for authenticating and authorizing user access and performing other important security-related tasks. Users can be authenticated using Windows authentication supplied by Internet Information Ser vices (IIS) or by using ASP.NET forms authentication and ASP.NET membership in 31

Web Technologies conjunction with the database. Authorization to the systems capabilities and inf ormation can be managed using Windows groups or by using ASP.NET roles to create a custom role database, in which it is easy to add to, remove or replace these schemes depending on what the application requires (MSDN, 2012). 4.2.3 Web Services Framework ASP.NET supports XML web services, components which contain business functionali ty that allow for the exchange of information across firewalls using standards s uch as HTTP and XML messaging. XML web services are not bound by a particular co mponent technology or object-calling convention and so virtually any program can access them regardless of the language the program was written in, the componen t model used or even the operating system the program is running on (MSDN, 2012) . 4.3 Distributed Computing A distributed computing system shares or exchanges data and is made up of numero us independent software components located on multiple computers that work toget her by transmitting messages over a communication network. These messages are ca lled distributed objects and can exist anywhere on the network. Since a communic ations system segregates these objects, any language and compiler can be used to create them. This means that the client does not need to know where the distrib uted object is located or what operating system it runs on (Hoque, 1998). There exists many APIs for creating distributed systems, the latest of which is Windows Communication Foundation (described in section 4.3.6). When creating a distribu ted system it is important to take note whether the system will be used exclusiv ely in-house or if access to the systems functionality is required by external u sers. If running an in-house application, a specific distributed API could be se lected to 32

Web Technologies bind the development to a particular programming framework or operating system f or performance purposes. However, if the system is being built to accommodate ex ternal users, a more flexible distributed API will be required to ensure the fur thest reach of the application (Troelsen, 2010). 4.3.1 Distributed Component Obj ect Model The Distributed Component Object Model (DCOM) was used before the .NET platform was introduced and provided a way of building distributed systems using COM obje cts and the system registry. DCOM allowed for client software to be programmed s uch that the physical locations of the remote objects were not hard-coded in the application, this meant that the code base would remain neutral, regardless of where the remote object was located, because the actual location was recorded ex ternally in the system registry. This became known as location transparency. Despi te its usefulness, DCOM could not be used to create solutions involving multiple operating systems nor could it promote sharing of data between various architec tures so it quickly became a legacy programming model and is now considered by m ost to be a deprecated technology (Troelsen, 2010). 4.3.2 Common Object Request Broker Architecture Common Object Request Broker Architecture (CORBA), introduced in the early 1990s, is a specification for distributed objects and was the Object Management Groups (OMG) answer to the need for interoperability between systems. With the implemen tation of the Object Request Broker (ORB) and utilising the Interface Definition Language (IDL) along with the APIs that allow for client/server object interacti on, an infrastructure was created that enabled objects, located locally or remot ely, to communicate with each other regardless of their platform or how they wer e implemented. The end of 1994 marked the release of the CORBA 2.0 specification 33

Web Technologies which further enhanced interoperability by allowing ORBs by different vendors to interoperate via TCP/IP using the ORB transport protocol known as Internet Inter -Orb Protocol (IIOP). In its day, CORBA came across as being the ideal solution for distributed objects, supported by over 500 member organizations it held many advantages over the competing technologies such as DCOM including vendor, langu age and operating-system independence. However, it was this variance that contri buted to its eventual downfall. With each company having their own unique implem entation of CORBA, no ORB ever reached the universal adoption or performance see n with Microsofts COM standard (Hoque, 1998; Ferrara & MacDonald, 2002). 4.3.3 .N ET Remoting When DCOM became a legacy distributed API after the release of the .NET platform , the .NET base class libraries, shipped with the .NET remoting layer, took its place and allowed multiple computers to distribute objects, but only if the appl ications all ran under the .NET platform. This meant that interoperability betwe en other programming architectures was still not directly possible (Troelsen, 20 10). 4.3.4 COM+ Where DCOM paved the way for exchanging information between two segments of COMbased software, it was Microsofts subsequent technology, initially released as Mi crosoft Transaction Server (MTS) and later renamed to COM+, which would take dis tributed computing to a new level allowing for feature-rich solutions to be buil t and which could be used by COM programmers and .NET programmers alike. The bas e class libraries of the .NET platform have provided a namespace called System.E nterpriseServices which allows .NET programmers to install managed libraries int o the COM+ runtime to gain access to the same services as a conventional COM+ aw are COM server. When a COM+ aware library was installed into the COM+ runtime, 34

Web Technologies it was designated a serviced component. These serviced components can take advan tage of an abundance of features including object lifetime management, transacti on management, a role based security system, a loosely coupled event model, pool ing services and much more. This was convenient for developers as it supplied th em with a built in solution rather than make it compulsory to manually code them . COM+ is still somewhat in use today, however it can only be used on the Window s platform and has since been surpassed by newer technologies such as web servic es (Troelsen, 2010). 4.3.5 XML Web Services XML web services, described previously, provide an easy way to allow external ca llers to access the functionality of remote components by exposing the functiona lity through standard web protocols. The .NET Framework has provided programmers with excellent support for building and consuming XML web services with the Sys tem.Web.Services namespace. Often times, it is as simple as just applying the [W ebMethod] attribute to the public methods that need to be given access to. Web s ervices allow for a high level of interoperability and data exchange as they are based on open industry standards including HTTP, XML and SOAP (described in sec tion 4.4.1) rather than proprietary systems and wire formats, as was the case wi th DCOM and .NET remoting. However, web services are not without their drawbacks , performance issues hinder them due to the use of HTTP and XML data representat ion and they are not the most ideal solution for in-house applications as binary formatting of data could be used along with a TCP-based protocol to ensure maxi mum performance (Troelsen, 2010). 4.3.6 Windows Communication Foundation Windows Communication Foundation (WCF), introduced in .NET 3.0, is an API design ed specifically for building and deploying services on Windows. Unlike other 35

Web Technologies distributed APIs such as DCOM, .NET remoting and XML web services, WCF allows fo r interaction with distributed technologies that were previously quite diverse b y providing a single, unified and extendable programming object model (Troelsen, 2010). By providing a runtime environment for services, WCF enables CLR types t o be exposed as services and similarly, other services can be consumed as CLR ty pes. It is important to note however that WCF is not essential for the creation of services but it makes it significantly easier to do so. Interoperability betw een services is gained through WCF as Microsoft designed it to a set of industry standards that define type conversions, service interactions, protocol manageme nt and marshalling (Lowy, 2010). WCF provides a wide range of techniques to expo se services to callers. For example, if all machines for an in-house application are Windows based, various TCP protocols can be used to ensure the best perform ance while the XML web-service-based protocol can also be used to expose this sa me service to external callers that wish to make use of its functionality. WCF a lso provides other major features including: Support for strongly typed and unty ped messages. Support for multiple bindings. Support for the newest and best web service specifications. Support for stateful and stateless messages. Security m odel based on Windows security protocols and web service standards. Lastly, WCF has another benefit as it is based on the design principles of the serviceorient ed architecture (Troelsen, 2010). 36

Web Technologies 4.4 Web Service Technologies 4.4.1 Simple Object Access Protocol Simple Object Access Protocol (SOAP) is a lightweight protocol for exchanging in formation between computers. Initially focussed on accessing objects, SOAP was e ventually generalised to accommodate a wider audience and thus moved towards an extensible messaging framework defined by XML technologies which is usable over various network protocols and which is independent of programming models (Skonna rd, 2003). The messaging framework is the key component of the SOAP specificatio n and defines a number of XML elements for encapsulating XML messages being tran sferred between systems. Such elements include: Envelope, Header, Body and Fault . The root element of a SOAP message is always the Envelope element which makes it straightforward for any application to identify a SOAP message by just identi fying the name of the root element. The Header element is an optional element th at is contained within the Envelope element and acts as a universal container fo r control information. It can contain any amount of elements, referred to as hea der blocks, which contain information that impacts payload processing. The Heade r element is followed by the mandatory Body element which, like the Header eleme nt, is a generic container made up of any amount of elements, but which represen t the message payload. Essentially, the data to be sent is contained within the Body element. Lastly, the Fault element is defined by the messaging framework to represent errors within the Body element. This is important as it makes it poss ible for generic infrastructure to differentiate between success and failure (Sk onnard, 2003). 37

Web Technologies <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Hea der> <!-- optional --> <!-- header blocks go here... --> </soap:Header> <soap:Bo dy> <!-- payload or Fault element goes here... --> </soap:Body> </soap:Envelope> Figure 4-2: Structure of a SOAP Envelope (Skonnard, 2003). As mentioned previously, SOAP allows messages to be exchanged over a range of di fferent protocols including HTTP, TCP, MSMQ and SMTP. Considering that the SOAP message framework is separated from the underlying protocol, any of the protocol s could be used without affecting the SOAP message. However, a standard protocol binding is required to ensure that there is a high level of interoperability ac ross SOAP applications and infrastructure. The protocol binding represents preci sely how the SOAP message should be transmitted by the protocol. For example, th e HTTP binding details the rules for using SOAP over HTTP. An important point to note is that the SOAP request/response maps easily to the HTTP request/response model which is why HTTP is so widely used (Skonnard, 2003). 4.4.2 Web Services Description Language Web Services Description Language, or WSDL, is a specification written in XML fo r describing web services. WSDL is platform and language-independent and essenti ally represents a contract for application communication. WSDL enables a client to invoke any public method of a web service. The WSDL specification is made up of a number of elements, the root of which is the Definitions element which itse lf may contain other elements (Table 4-1) including Types, Message, PortType, Bi nding and Service (Skonnard, 2003). Figure 4-3 illustrates the basic structure o f a WSDL definition. 38

Web Technologies <!-- WSDL definition structure --> <definitions name="MathService" targetNamespa ce="http://example.org/math/" xmlns="http://schemas.xmlsoap.org/wsdl/" > <!-- ab stract definitions --> <types> ... <message> ... <portType> ... <!-- concrete de finitions --> <binding> ... <service> ... </definition> Figure 4-3: Basic Structure of a WSDL Definition (Skonnard, 2003). WSDL definitions produce the code that details exactly how to interact with the web service it describes, making it easier to send and receive SOAP messages ove r the various protocols (Skonnard, 2003). Table 4-1: Descriptions of the core WSDL Elements (Adapted from Skonnard, 2003). Element Name Types Message PortType Binding Service Description A container for abstract type definitions defined using XML schema. A definition of an abstract message that may consist of multiple parts, each par t may be of a different type. An abstract set of operations supported by one or more endpoints (commonly known as an interface); operations are defined by an ex change of messages. A concrete protocol and data format specification for a part icular portType. A collection of related endpoints, where an endpoint is defined as a combination of a binding and an address (URI). 4.4.3 Universal Description, Discovery and Integration Universal Description, Discovery and Integration (UDDI) is a specification found ed in 2000 by Microsoft, IBM and Ariba which lays the groundwork for registering and discovering web services within and between enterprises. UDDI was designed to 39

Web Technologies support development tools, automation and to allow adding attributes to web serv ice and protocol listings by way of a simple categorization structure to make th em searchable. The UDDI specification does not specify the description language, rather it remains entirely neutral which allows non-XML services to be describe d (MSDN, 2012). 4.4.4 Representational State Transfer Representational State Transfer (REST) is an architectural style for distributed hypermedia systems (Fielding, 2000: 76). A software architectural style specifies the elements that can be used to implement a software system and abides by a sp ecific set of constraints. The World Wide Web is effectively the worlds largest, most scalable and most popular distributed application. REST builds upon the cli ent-server architecture popularised by the Web and enables software to be built in a way in which clients can make requests of services or endpoints (Flanders, 2009). The constraints surrounding REST are based on the same principles that re gulate the Web which include: Clients communicate with resources (anything that can be named and represented), which are requested via a unique Uniform Resource Identifier (URI). Communication with resources is achieved using the standard H TTP verbs (GET, POST, PUT, and DELETE). The resources media type (XML, JSON, JPG , etc.) can also be declared using the HTTP Content-Type header. Resources are s elf-descriptive. Links to other resources are contained within resources. The key aspect of REST is the nature and state of an architectures data elements, compared to the distributed object style in which the key aspect is the encapsu lation of 40

Web Technologies all data within the processing components (Fielding, 2000). REST recognises six data elements: a resource, resource identifier, representation, representation m etadata, resource metadata and control data, illustrated in Table 4-2. Table 4-2: REST Data Elements (Adapted from Fielding, 2000). Data Element Resource Resource Identifier Representation Representation Metadata Resource Metadata Control Data Modern Web Examples The intended conceptual target of a hypertext reference URL, URN HTML document, JPEG image Media type, last-modified time Source link, alter nates, vary If-Modified-Since, cache-control A resource is the key abstraction of information in REST and can be anything tha t can be named, for example, a document or an image. The resource identifier (UR I) identifies the resource involved in the communication among components. A rep resentation is a sequence of bytes that captures the current or intended state o f the resource while the representation metadata describes the representation it self. The resource metadata describes the resource and the control data describe s the intention of a message between components such as the action being called (Fielding, 2000). REST provides some compelling features and benefits over RPC t echnologies (Flanders, 2009). These include: Caching. Easy to Scale-Out. Idempot ent. Interoperability. Simplicity. 41

Web Technologies 4.4.5 JavaScript Object Notation JavaScript Object Notation (JSON) is a lightweight text format for data storage and exchange. When an application communicates with a remote computer, a data fo rmat and exchange protocol is required. For example, SOAP-based web services use XML to exchange data between applications. Similar to XML, JSON is human-readab le and platform independent, however, XML has some drawbacks that make JSON a mo re favourable option in some cases. XML documents are often substantial in size, are quite difficult to parse and have a steep learning curve requiring the deve loper to use several technologies including XPath and XML Schema. JSON, however, has a very concise syntax where most of what is displayed is the data itself. J SON is relatively easy to parse, understand and implement and has practically no learning curve for developers experienced in JavaScript or some of the other pr ogramming languages such as Python and Ruby (Aziz & Mitchell, 2007). Figure 4-4 shows the output of an array in its JSON representation. Figure 4-4: JSON representation of an array (Aziz & Mitchell, 2007). 42

Web Technologies 4.5 The Web Services Debate: SOAP vs. REST A common question asked among developers is which is better, SOAP or REST? This is actually not very easily answered as SOAP and REST are significantly differen t to each other. SOAP is a protocol specification that allows data to be exchang ed between two endpoints. REST is an architectural style for the development of client-server applications and is really just an archetype on how to use HTTP fo r interacting with resources. It would be more reasonable to compare REST with t he remote procedure call (RPC) style of developing client-server applications wh ich, like REST, is a style and not a protocol. RPC uses a proxy in the client to make contact with the server whereby the proxys interface emulates the servers i nterface. SOAP does not necessarily need to use the RPC style though most SOAP t oolkits do tend to take this approach. REST, however, omits the proxy leading to extremely loose coupling and leaves it to the consumer to decide how the data i s represented and in what format it appears in. Also, since REST is based on the constraints of HTTP, it is possible to cache the (GET) requests. This is genera lly not possible with RPC as it lacks the necessary infrastructure and even exec uting RPC over HTTP using SOAP still does not allow caching as SOAP uses the HTT P POST verb, which is recognised as being unsafe. SOAP seems to deliberately ave rt HTTP in favour of promoting it to work over a variety of protocols. Overall R EST is simple, efficient and can access resources with virtually no compatibilit y issues. REST can even be used in conjunction with JSON, forming a very effecti ve transport system. With no SOAP envelope or the clunky XML format, REST and JS ON together are a perfect match for retrieving data frequently and allow platfor ms such as mobile devices, which have limited SOAP toolkits, to easily access da ta. On the other hand, it is claimed that REST is not particularly suited for ex ecuting business actions with complex business logic such as a submit order, cal culating the 43

Web Technologies price of an item or a user login. It appears that both REST and SOAP can be used for similar purposes but it is suggested by some that SOAP should only be used when absolutely necessary and that the advantages of REST make it the preferable choice otherwise (Saurenmann, 2008; Flanders, 2009). Another question asked qui te often is whether REST is as secure as SOAP. The short answer to this is yes, in fact it is equally just as easy as SOAP to make a RESTful service secure. Gen erally with REST or SOAP the security system is the same, often using HTTP-based authentication as well as secure sockets layer (SSL). However, due to the extra protocols defined in the various web service specifications (WS-*), SOAPbased s ervices support end-to-end message security. This means that if a SOAP message i s passed through multiple endpoints over the same or different protocols, the me ssage will remain secure. If an application needed this specific feature, REST w ould not be an option (Flanders, 2009). Interoperability is a property which is often questioned in the debate of SOAP vs. REST. Since the SOAP specification wa s created to enhance interoperability, many people question whether REST could a ctually be better than the very technology that was designed for that specific p urpose. The problem is that on the way to widespread interoperability, the numer ous web service specifications in the WS-* stack actually made SOAP services les s interoperable rather than more interoperable. REST has a significant advantage because all that is required to use REST is a HTTP stack which the vast majorit y of platforms and devices have so it would certainly seem like REST has wider i nteroperability than SOAP. Also, with more and more devices, such as smartphones , tablet computers, TVs and dvd players, coming equipped with Internet connectiv ity, it is becoming increasingly more unlikely that a SOAP toolkit can be 44

Web Technologies provided for all platforms and even if a particular platform does have a SOAP to olkit, it is not guaranteed to work with another platforms implementation (Flande rs, 2009). 4.6 Conclusion Upon completion of the research contained within this chapter the author was equ ipped with the necessary knowledge to make an informed decision on what technolo gies to use to build the web services for the project. Research suggests that Mi crosofts latest API for service-oriented applications, WCF, is the de-facto stand ard for creating web services on the .NET Framework and has since replaced the o nce popular .asmx web services enabling developers to implement the latest indus try-standard and platformneutral web services. The research carried out on the t opics of SOAP and REST enabled the author to decide which type of web service to develop as WCF supports both SOAP-based and RESTful web services. The research suggests that REST is fast outpacing SOAP, attributed to its ease of use and fas t integration. This worked to the authors advantage as Android does not support S OAP natively (though some third-party SOAP libraries such as ksoap2 do exist), b ut it does however support REST. With the addition of support for the JSON data exchange format as well as XML, REST became the obvious choice for developing we b services for the project. 45

Architecture & Design 5. Architecture & Design This chapter provides a high level overview of the project using UML to visualiz e its architecture. Due to the fact that development involved a great deal of ex ploratory programming, the design diagrams were created after much of the applic ation had been built. Using Visual Paradigms Smart Development Environment (SDE) for Eclipse, snapshots of the code base were reverse-engineered to form some of the UML diagrams, namely the sequence and class diagrams. The UML diagrams in th is chapter illustrate just some of the main parts of the application and do not represent its entirety. 5.1 Sequence Diagram Figure 5-1 depicts the LoginActivity class in the form of a sequence diagram ill ustrating interactions between objects of the class in the sequential order that they occur. The time sequence of the interactions is represented from top to bo ttom on the vertical dimension while the object instances that are interacted wi th are represented on the horizontal dimension. Object instances that are part o f the sequence are represented as Lifelines across the top of the diagram while the messages that are sent to these object instances are represented as a line w ith an arrowhead. Subsequent messages are always added to the diagram below the previous message. Alternation combination fragment notation is used to represent the classic if-then-else programming statements where a frame is drawn with the t ext alt set as its name. Standard programming if-then statements are represented wit h the option combination fragment notation. To depict an option combination a fr ame is drawn with the text opt set as its name. Any messages that are part of the option are placed in the content area of this frame. 46

Architecture & Design Figure 5-1: Login Activity Sequence Diagram 47

Architecture & Design 5.2 Component Diagram Figure 5-2 illustrates a component diagram showing the structural relationships between the components of the system. The various components of the mobile appli cation contact the web services through an interface. The web services then cont act the database to retrieve the necessary data. Figure 5-2: Component Diagram 5.3 Class Diagrams Figures 5-3 through to 5-6 illustrate class diagrams for some of the main classe s that make up the mobile application. Each class is represented as a rectangle made up of three compartments. In the top is the classs name, the middle contains the classs attributes and the bottom holds the classs operations or methods. When modelling a large system, Packages are used to organise classes into namespaces . These packages are represented as a rectangle with a tab in the top left corne r and make the system 48

Architecture & Design easier to understand as each package represents a specific section of the applic ation. The diagrams also illustrate the relationship between certain objects. In ner classes are depicted with the UML nesting connector (a circle with a plus sy mbol) that shows the source class is nested within the target class. Association s are also depicted between classes as a solid line with an open arrowhead point ing to the known class. The associations also include a role name and a multipli city value for the known class indicating how many instances are associated with it. Figure 5-3: Login Activity Class Diagram 49

Architecture & Design Figure 5-4: Portfolio Activity Class Diagram 50

Architecture & Design Figure 5-5: Feed Activity Class Diagram 51

Architecture & Design Figure 5-6: Location Activity Class Diagram 52

Architecture & Design 5.4 Deployment Diagram A deployment diagram illustrates the relationships between the hardware and soft ware components of a system. Figure 5-7: RPM Mobile Deployment Diagram 53

Architecture & Design Figure 5-7 illustrates the deployment of the RPM Mobile application to an Androi d device, depicting an instance of the applications archived (.apk) file and its components being deployed to the Android execution environment. The diagram sho ws how the application can also be installed on external storage such as the dev ices SD card. 54

Implementation 6. Implementation This chapter gives an insight into the development of the project including data base setup, Android development, web service development, testing and deployment . As mentioned in the introduction at the very beginning, some requirements were provided by the company since the original concept was to develop a mobile appl ication based on an already existing and functioning web application. These requ irements would be used to develop just the Portfolio section of the mobile appli cation (described in section 6.2.3). As development progressed and the Portfolio section neared completion, the author envisioned additional useful functionalit y and thus the Feed and Location sections of the mobile application were conceiv ed (6.2.4 and 6.2.5 respectively). The overall look and feel of the mobile appli cation was not defined in the requirements provided by the company, so the autho r had complete control from a design perspective. It is also worth noting at thi s point that the SQL code for some of the web services was jointly developed bet ween the author and an employee of the company, due in part to the complex natur e of the systems database. 6.1 Database Setup In the early stages of the project it was decided that using the entire RPM data base was unnecessary for the mobile application and so a smaller database, made up of just the necessary tables, was created. During development of a project, E nverian use a demo database, structured exactly the same as the live database, o nly it contains dummy data. It was this demo database that the RPM Mobile databa se was based on. To quickly and easily create the database a SQL script was gene rated to copy the database schema and all the necessary objects in it. This scri pt was then used to import the tables and data to the RPM Mobile database. It is also worth noting that when the script was generated, 55

Implementation the foreign keys in the database were intentionally omitted from the database to ease development since there was a high possibility that more tables and data w ould need to be added to it throughout development. This would have no impact on the functionality of the application. 6.2 Android Development 6.2.1 Login The purpose of the login screen is to implement some basic security whereby full access to the application is permitted only to authorised users. The software li stens for the login button to be clicked where, if the username and/or password f ields are not empty, a web service call is made to establish whether access to t he application can be permitted. The web service queries the database to determi ne if the credentials are valid and then returns back a boolean value of true or false. It is important to note that the passwords in the database are encrypted with the MD5 Message-Digest Algorithm for security purposes. This requires the software to run the MD5 algorithm on the login credentials before making the web service call. This is good practice as the application is not only adhering to security constraints on the server side, but also to the standard security proce dure of sending encrypted data across the network instead of its plain-text coun terpart. Upon retrieving the returned value from the web service, the applicatio n can permit or deny the user access to the functionality of the application. If the credentials are valid, an Intent is launched to start the Activity of the m ain application, otherwise permission to access the application is denied. A not e of interest here is that the username and encrypted password are being passed to the Intent using the method putExtra(String name, String value). This is nece ssary as all the web methods called by the application 56

Implementation require authentication before data can be retrieved. The Activity specified in t he Intent is then started using the startActivity(Intent intent) method. The sof tware also provides a link to the company website, by means of a long click on t he company logo, providing instant access to the companys latest news and updates . Lastly, if no internet connection is detected when the application is run, an alert dialog is displayed to inform the user that Internet access is required to proceed. 57

Implementation Figure 6-1: Login Screen 58

Implementation 6.2.2 Tab Activity As soon as the Intent is launched from the login screen, a TabActivity is starte d which allows multiple Activities or views to be embedded within a single scree n enabling the user to switch between them using a tab widget. It is here where the text and icon of the tabs are set using the tabHost.newTabSpec(String tag) m ethod. Intents are created for each of the various Activities and are assigned t o each tab on the widget using the setContent(Intent intent) method. Attached to each of these Intents are the username and password, passed over from the login Activity. Below the tab widget is a FrameLayout object which displays the conte nts of the Activity launched when a tab is clicked. Figure 6-2 illustrates the t ab widget created for this project. Figure 6-2: Tab Widget 6.2.3 Portfolio This section of the application provides an overview of the portfolio of renewab le energy development opportunities with key information for each project. The P ortfolio tab is set as the default tab so when the application loads, the portfo lio Activity is started. Since there is a lot of network activity involved, a se parate thread from the main thread is used to load the data, allowing a progress dialog to be displayed until the data has been retrieved. Multithreading is gen erally advised for performing most network activity. If it were carried out on t he main thread the application would be unresponsive until the task is complete and a progress indicator could not even be shown since it cannot update itself w hile the thread is in use. To carry out the multithreading process 59

Implementation the AsyncTask API is used. From the onCreate() method, which is called when the Activity is started (and is therefore the main application thread), the AsyncTas k downloads the data from the web server by calling a web method and passing it the users username and password (which were both passed to this Activity by the T abActivity). When the data is downloaded, the ListView needs to be populated but this cannot be done from the AsyncTask as GUI components can only be updated fr om the main application thread. Instead the Handler framework is used in the onC reate() method where an object of the Handler class is created and waits for a m essage to be sent to it from the AsyncTask. As soon as the data is downloaded, t he AsyncTask sends the message to the handler in the main thread which causes th e handleMessage() method of the handler to be called, from where the ListView ca n be updated with the data by calling the setMyPortfolioProjects() method. The h andleMessage() method will always be called in the main application thread becau se the handler itself was created there. A few issues need to be addressed when using the AsyncTask or Handler framework. When the Activity is finished, it is i mportant to also finish any background work otherwise it will continue until eit her the process is finished or the Java Virtual Machine is terminated. It is bad practice to let the application keep using the CPU and memory of the device aft er the Activity is finished. This is solved by simply cancelling the task in the onDestroy() method. It is important to also allow the user to cancel the backgr ound task at any time. To solve this issue, cancellation is detected within the parsing loop where the data is being downloaded. The work is finished and the ha ndler is only sent a message if the task was not cancelled. Lastly, the progress dialog must also be cancellable. To achieve this, the setCancelable(true) metho d is used on the progress dialog object. 60

Implementation Figure 6-3: Portfolio 61

Implementation When the ListView is populated a project can be selected to view its details, wh ere a new screen displays all the relevant information for the selected project. The software goes through a number of procedures to achieve this. First of all, a ViewFlipper object is used in the XML layout where multiple views have been a dded to it, one for each screen in the portfolio section of the application. The ViewFlipper takes care of animating between these views, where only one child v iew is shown at a time. Next, in the main application thread, an onClickListener () method on the ListView waits for a list item to be clicked, when such an even t occurs the ViewFlipper changes view and a new background task is started but t his time the id of the selected project is passed to it as well. This is obtaine d by retrieving the text contained within the TextView of the selected row in th e ListView. It is important to note that the TextView containing the id of the p roject is hidden and that is why it is not visible to the user. The background t ask executes similarly to before only this time it calls a different web method, one which returns the project details for the specific project using the projec t id that was passed to it. When the data has been downloaded, the AsyncTask sen ds a message to a handler in the main thread, this time a different handler whic h will update the ListView on the project details screen by calling the setProje ctDetails() method. The background task on this screen addresses the issues that arise when using the AsyncTask and Handler framework, as described earlier. How ever, since clicking a project to show its details changes the displayed view, i t is now also necessary to provide a way to navigate back to the projects screen when the back button is pressed. This is solved by overriding the onBackPressed () method which sets the view depending on what the currently displayed view is. Another feature of the application is the ability to refresh the details of whi chever screen is displayed. This feature is added to the application as a menu i tem and is achieved by 62

Implementation overriding just a few methods. By overriding the onCreateOptionsMenu() method it is possible to initialise the contents of the Activitys standard options menu. A lternatively the onCreateContextMenu() method can be overridden if a context men u is used instead of the Activitys standard options menu. The onMenuItemSelected( ) method is then overridden to handle the click event on the menu items and here , a switch statement determines the appropriate action for each item in the menu . Since multiple views can be navigated, sliding animations were used to enhance the experience, sliding from left to right and vice-versa depending on which sc reen the user is navigating to. This is quite easily achieved by simply creating an XML file that alters properties of the target object, such as background col our or alpha value over a specified amount of time. This animation resource is t hen attached to the ViewFlipper object using the appropriate animation attribute . One last feature of the Portfolio section of the application is the ability to view a pdf report for a project. This is a powerful feature that provides a det ailed analysis of the entire project. However, this functionality had to be simu lated for this project. Ideally, when the pdf icon for a project is clicked, the application should make a web service call requesting a pdf file for the projec t. The app would download the file in the background and then allow the user to open or save it. The RPM web application incorporates functionality to generate pdf reports but the necessary web service to expose this functionality over the web has not yet been developed. To simulate the functionality, a sample pdf file is saved directly to the SD card of the device whose path is searched for by th e onClick() method within the listener on the pdf icon. If the file is located, an Intent is launched to open the file with the devices pdf reader. 63

Implementation Figure 6-4: Portfolio - Project Details 64

Implementation Figure 6-5: Portfolio Project Details PDF 65

Implementation 6.2.4 Feed This section of the application provides a project status report in the form of a news feed. When a projects status changes, which could happen when a task is co mpleted or falls behind schedule, the status change is flagged and the project i s added to the feed with the appropriate information instructing whether it requ ires attention. The feed works in a similar fashion to the Portfolio section of the application. The AsyncTask API and the Handler framework are used to downloa d the information in the background while a progress dialog is displayed until t he download is finished. All issues regarding the AsyncTask and Handler framewor k, as described earlier, are also taken care of. The software utilises the stand ard project management technique of colour coding the relevant information and d isplaying an icon to report on the overall project health. This has some degree of complexity involved. Normally, if the data is static, an instance of the Simp leAdapter class is used to map the data to views defined in an XML layout file. Typically an ArrayList of Maps would be used with the adapter where each entry i n the ArrayList would correspond to a row in the list and where the Maps contain the data for each row. If it was not a requirement to act upon the data, the Si mpleAdapter class would suffice, however since it was necessary to change the co lour of the text and display a status icon in each row depending on the status o f the project, a custom adapter class that extends the SimpleAdapter class had t o be created. In this custom adapter class the getView() method was overridden a nd the logic for setting the icon and the colour of the text for each row could then be defined. 66

Implementation Figure 6-6: Feed 67

Implementation The application also allows for an item in the news-feed to be selected, providi ng an entire overview of the projects tasks, which ultimately facilitates quickdecision making and showcases the true power and potential of the application. T he project-tasks screen is developed in a similar fashion to the project-details screen in the Portfolio Section of the application. Again a ViewFlipper object is used in the XML layout to animate between the news-feed view and the project tasks view and just as before, an onClickListener() method waits for a list item to be clicked. When such an event occurs, the ViewFlipper changes view and a ne w background task is started to download the details of all the tasks for the pr oject the user clicked on. Using the AsyncTask API, a web method is called and t he users username and password are passed to it for web method authentication, al ong with the id of the project to retrieve only the data for the selected projec t. As normal, a progress indicator is displayed until the download has completed after which a message is sent to a handler in the main thread to populate the L istView with the downloaded data and then display it on screen. When the ListVie w for the project tasks is being populated with the data, a status icon also has to be assigned to each row, similar to that seen earlier for the first screen i n the news-feed. This time the icon will be set depending on a number of factors . If a task is 100% complete, it is assigned a green OK icon and the Progress fiel d is highlighted. If a task falls behind schedule, a red warning icon is assigne d to the task and the Estimated End Date field is highlighted. If a task is on s chedule it is assigned an in progress icon and will not be flagged until either it is completed or falls behind schedule. This functionality is carried out in a s imilar manner to the news-feed where a custom adapter class is used, in which th e getView() method is overridden allowing the logic to be applied to enable each row to dynamically display the appropriate status icon and text colour. 68

Implementation Figure 6-7: Project Tasks 69

Implementation 6.2.5 Location The purpose of the Location section of the application is to provide a world map view displaying the locations of all the projects assigned to the user. This is a powerful feature which could be expanded upon in the future to provide other useful services such as directions or details about each site. Included with the Google API add-on, the Google Maps library was required to develop this map vie w and was installed using the Android SDK and AVD Manager. Since the Maps librar y is not included in the standard Android library, it is necessary to declare it in the Android Manifest. Internet access is required to retrieve map tiles so p ermission to allow the application access to the Internet must be declared in th e manifest as well. When incorporating Google Maps into an application, an impor tant part is the API Key that is required to prove that the application and sign er certificate have been registered with the Maps service. This is necessary to receive the map data and can be done quite easily since the Android developers we bsite has extensive coverage and provides tutorials on how to do so. Once the AP I Key has been obtained it is assigned to the apiKey attribute which holds the M aps API Key for the application. To make use of the important map capabilities p rovided by the Maps library, the Activity must extend MapActivity which is a sub -class of the Activity class. Every MapActivity requires a method called isRoute Displayed() which checks to see if any route information is being displayed. In this case there is not so the method was overridden to return a boolean value of false. All that was left at this point to display the map on screen was to add the standard onCreate() method to the class in which the layout file is specifie d. Lastly, the ability to zoom on the map is implemented using the built in feat ure of the MapView class where the setBuiltInZoomControls method is assigned a b oolean value of true. Now a working map view had been achieved and the 70

Implementation important feature of displaying the map markers for the locations of the project s could be added. Before the map markers can be set, the coordinates for each lo cation must first be retrieved. When the map view is being set, a task is run in the background which makes a web service call to download and return the coordi nates for the projects. As the parsing process takes place, all the data is stor ed in a HashMap where each piece of data is assigned a key to identify the data and then the HashMap is added to an ArrayList. When the task has finished downlo ading and parsing the data, a message is sent to a handler in the onCreate() met hod which calls a method to set the project coordinates. This method loops aroun d the ArrayList and for each valid set of coordinates the GeoPoint class is used to define them for the map overlay item. However, the GeoPoint coordinates must be specified in micro-degrees so the coordinates are multiplied by 1E6 (1 10^6) before being passed to the GeoPoint constructor. The OverlayItem constructor th en accepts the GeoPoint location, a string for the title of the item and a strin g for the description of the item. All thats left then is to add the OverlayItem to the collection of overlays using the CustomItemizedOverlay object and then ad d the CustomItemizedOverlay to the MapView. Further enhancements to the Location section of the application include the ability to animate the map to the users c urrent location and display a map marker representing their position on the map while also displaying the current gps coordinates. In addition, the map can be s witched from the map view to satellite view and vice-versa. This functionality i s implemented as a range of menu options on the users device. 71

Implementation Figure 6-8: Location Map View 72

Implementation Figure 6-9: Location Satellite View 6.2.6 Camera The purpose of the camera section of the application is to give the user access to the camera functionality of the device from within the application. This woul d allow the photographs to be taken while on site and remotely upload them to a server or attach 73

Implementation them to a project task to view within the application. Unfortunately due to time constraints and the experimental nature of this feature of the application, muc h of this functionality has not been implemented in the current build of the app lication. Figure 6-10: Camera 74

Implementation 6.2.7 About The purpose of the About screen is to provide general information about the appl ication such as the current application version number or a detailed description of the application. Since the description for the RPM Mobile application has no t been finalised at this time, the information displayed is that of the RPM web application for demonstration purposes. Figure 6-11: About 75

Implementation 6.3 Web Services Development 6.3.1 ASP.NET Mock-up Application Early in the development of the project it was decided that the web services wou ld be contained within a mock-up web application. In a live project they would i ndeed be integrated into the live RPM web application. With this in mind, the au thor was able to quickly create an ASP.NET web application and using the Visual Studio default layout, a basic .aspx web page could be created to simulate the r eal RPM system. This was done purely for demonstration purposes to emphasise tha t in reality the user would navigate to the RPM system as normal and would remai n unaware that new web services have been added to it which effectively power th e mobile application. Figure 6-12: RPM Mock-up Web Application 76

Implementation 6.3.2 Accessing the Database Data In order to access and use the data contained within the SQL database, the data access tools included in ASP.NET were used. By adding a DataSet to the project a TableAdapter for each web service could be created. However, without a connecti on to the database the TableAdapters cannot be populated with the data. Using the TableAdapter configuration wizard a connection to the database can be created. This connection, when established, is represented as a connectionString in the W eb.config file in the ASP.NET project. Once a data connection has been chosen to connect the application to the database, a command type can be chosen specifyin g how the TableAdapter should access the database. The TableAdapter configuratio n wizard gives three options: use SQL statements, create new stored procedures o r use existing stored procedures. In this project the first option, use SQL stat ements, was chosen. This allows a custom SQL statement, or a statement construct ed with the configuration wizards Query Builder, to be used to fill the TableAdap ters DataTable with the data returned by the statement. This is where the custom SQL statements, some of which were written in collaboration with the company, we re used to return the precise data that is needed by the mobile application. The final step is to choose what methods should be generated. These methods load an d save data between the application and the database. In the case of each web se rvice, just a single method with an appropriate name should be generated to retu rn the DataTable filled with the results of the SQL statement. 6.3.3 Web Service s Once the DataSet containing the necessary TableAdapters was created, the web met hods themselves could be written. By adding a WCF Service item to the project tw o files were generated, an interface that defines the services contract and a cla ss that contains the code that implements the interface. The contract specifies the methods clients can 77

Implementation call, arguments passed to the methods or values returned by the methods. Using t he ServiceContract attribute the interface is defined as a service contract and using the OperationContract attribute, methods are exposed to the client. Also t he DataContract attribute is added to a class definition to make the class seria lizable and the DataMember attribute is added to each member of the class that m ust be serialized. Essentially the service contract specifies what the service c an do while the data contract specifies what data can be exchanged between the s ervice and client. The class (.svc) file that implements the interface contains the logic for each web method. There are six web methods, one for authentication purposes and five others which are called by the mobile application to retrieve necessary data. The authentication web method is called when the user logs into the mobile application but it is also called every time the mobile application makes a request to any of the other five web methods. This is done for security purposes and means that the web methods that return sensitive business informati on cannot be called without first authenticating the caller. The five other web methods work quite similarly to one another. The caller is first authenticated w ith the parameters that are passed to it and if the credentials are valid the app ropriate DataTable is accessed and its data is stored in a list which is then re turned to the caller. If the callers credentials are invalid, an empty list is r eturned. 6.4 Testing Due to the fact that development consumed almost all available time for the proj ect, only functional testing was carried out, followed by debugging sessions whe never the application did not behave as it should. This was also done for the we b services to ensure that the correct data was returned for every web service ca ll. 78

Implementation 6.5 Deployment Early in development, the WCF web services were hosted in IIS locally on the dev elopment machine, even when they had been fully developed. It was not until the mobile application was significantly developed that the web services were migrat ed over to the company server for testing and demonstration purposes. Using the FileZilla client, the entire RPM mock-up web application was uploaded to the ser ver under a newly registered domain. This enabled the web services to be called over the web, allowing the mobile application to retrieve the data wherever an I nternet connection is available. Using WiFi or mobile Internet networks to conne ct to the Internet, users would now be able to use the RPM Mobile application vi rtually anywhere. As the mobile application neared completion, a way to distribu te it efficiently and effectively was needed. Publishing the application in the Android market was not an option as ultimately a system such as this is intended to be used only by the companys clients. Instead, for demonstration purposes, it would be distributed through an internal company website. An Android applicatio n is distributed by exporting a single, digitally signed .apk file. All installa ble Android applications must be digitally signed with a certificate, the privat e key of which is held by the application developer or the company the developer works for. The certificate is used to identify the authenticity of the applicat ion. When the .apk file was exported from the project it was then uploaded to th e company server. Using a devices built in web browser and navigating to the addr ess where the application is located on the server, it could be downloaded and i nstalled to any number of compatible devices. This would benefit the executives of the company who would later demo the application to their clients. 79

Conclusions 7. Conclusions The author was first exposed to the RPM system while on a college work placement with Enverian. Taking place over a number of days, a series of software design sessions were carried out to establish the systems architecture and design. The a uthor gained an incredible insight into the low-level implementation issues that arise when developing a complex software system and came away with a newfound u nderstanding of the importance of the architecture and design of a software solu tion. As soon as the decision was made to pursue the idea for the project, some requirements were acquired through deeply involved discussions with the company and it was from this point on that the project took on a life of its own. In rev iew of the entire project, it is apparent that the goals that were set out to be achieved have been substantially realised, much to the authors delight. The firs t goal, To develop a multi-tier solution utilising smartphone technology and clou d based web services, has been achieved since mobile and cloud computing technolo gies were utilised to create a three-tier solution made up of an Android mobile application, WCF web services and a SQL database. The second goal which aimed to demonstrate the usefulness of a mobile computing solution in the domain of rene wable energy portfolio management has been significantly realised. The mobile ap plication tracks a portfolio of renewable energy development opportunities and p rovides the user with a comprehensive overview of the projects details and relat ed tasks. The third goal, To develop an application that allows quick and easy ac cess to business information, has been achieved as originally intended though a d evelopment 80

Conclusions oversight leaves this goal somewhat unsatisfied. Since the mobile application do es not currently have any offline support, the user must always enter the login credentials to use the application which can become a tedious process if the app is being used frequently. The ultimate goal to demonstrate the value and use of IT within a business environment has been largely realised as the solution prov ides access to vital business information to aid decision making and to help ach ieve important targets. However, the author can see how things could have been d one differently from a development point of view. If the application does not ha ve offline support then it is questionable whether the application should have b een developed as a mobile web application rather than a native mobile applicatio n. As the research in section 3.6 suggests, a mobile web application may hold an advantage in this case. This is an interesting matter, one which was not forese en but will be considered with careful thought in future projects. The implement ed solution in its current form is still an early build, therefore, there are ma ny features that could be included in future versions. The application is limite d to just allowing the user to consume information and does not provide a way to update data in any way. A useful feature would be to allow comments to be made on the status of a project or a project task, while the geolocation feature of t he application could be expanded to provide directions to any of the project loc ations from the users current position. Also, the camera functionality of the app lication, as previously mentioned, has only been partially implemented in this b uild of the application and it is a feature the author would be eager to fully i mplement given more time and a better understanding of how to approach its imple mentation. 81

Conclusions Having never designed and implemented a software solution on this scale before, the author is left feeling a great sense of accomplishment and satisfaction upon completion. However, it must be said that many obstacles were encountered along the way. Due to the steep learning curve of the Android platform and the invest ment of a significant amount of time to learn WCF, many ideas and features had t o be omitted from the current build of the application. This is of little conseq uence however because in undertaking this project an ability to work closely wit h a company has been demonstrated, commitment to the project has been shown by m eeting regularly with the company to clarify the requirements and to demonstrate successive builds of the application. Independent thought and innovative work h as also been demonstrated through the formation of new functional requirements t hat are very much applicable to the project, while excellent communication skill s have been proven to be necessary for success. Overall, the author is extremely satisfied with the outcome of the project and believes the knowledge and experi ence gained will serve well in the future. 82

List of References List of References Android Developers, 2011. Android API Levels. [online] Available at: http://deve loper.android.com/guide/appendix/api-levels.html [Accessed 7 December 2011] Andr oid Developers, 2011. What is Android? [online] Available at: http://developer.a ndroid.com/guide/basics/what-is-android.html [Accessed 25 November 2011] Android Developers, 2011. Activities. [online] Available at: http://developer.android.c om/guide/topics/fundamentals/activities.html [Accessed 27 November 2011] Android Developers, 2011. Download The Android NDK. [online] Available at: http://devel oper.android.com/sdk/ndk/index.html [Accessed 7 December 2011] Android Developer s, 2012. Platform Versions. [online] Available at: http://developer.android.com/ resources/dashboard/platform-versions.html [Accessed 6 January 2012] Amorosi, D. , 2011. News Feature: Time to Avoid the Droid? Info Security, April 18, 2011. [o nline] Available at: http://www.infosecurity-magazine.com/view/17407/newsfeature -time-to-avoid-the-droid [Accessed 19 December 2011] Aziz, A. & Mitchell, S., 20 07. An Introduction to JavaScript Object Notation (JSON) in JavaScript and .NET. MSDN Library, February, 2007. [online] Available at: http://msdn.microsoft.com/ en-us/library/bb299886.aspx [Accessed 30 January 2012] Barnes, S.J., 2002. Unwir ed Business: Wireless Applications in the Firms Value Chain. In: Sixth Pacific As ia Conference on Information Systems, Tokyo, Japan. Basole, R.C., 2008. Enterpri se mobility: Researching a new paradigm. Information Knowledge Systems Managemen t (e-journal) 7 (1/2), 1-7. Available through: EBSCO Host database [Accessed 17 December 2011]. Block, R., 2007. Steve Jobs live from D 2007. Engadget, May 30, 2007. [online] Available at: http://www.engadget.com/2007/05/30/steve-jobs-livefrom-d-2007/ [Accessed 5 November 2011] Charland, A. & Leroux, B., 2011. Mobile Application Development: Web vs. Native. Communications of the ACM (e-journal) 5 4(5), 49-53. Available through: EBSCO Host database [Accessed 16 October 2011]. Claburn, T., 2007. Is a Closed iPhone Doomed to Fail. InformationWeek, January 1 1, 2007. [online] Available at: http://www.informationweek.com/news/196802882 [A ccessed 14 November 2011] DiMarzio, J., 2008. Android A Programmers Guide. McGra w-Hill. 83

List of References Ferrara, A. & MacDonald, M., 2002. Programming .Net Web Services. OReilly Media, Inc. Fielding, R.T., 2000. Architectural Styles and the Design of Network-based Software Architectures. Ph. D. University of California, Irvine. Flanders, J., 2 009. An Introduction to RESTful Services With WCF. MSDN Magazine [blog], January 2009. Available at: http://msdn.microsoft.com/enus/magazine/dd315413.aspx [Acce ssed 22 January 2012] Flanders, J., 2009. More On REST. MSDN Magazine, [blog] Ju ly 2009. Available at: http://msdn.microsoft.com/en-us/magazine/dd942839.aspx [A ccessed 29 January 2012] Gargenta, M., 2011. Learning Android. Sebastopol, CA: OR eilly Media, Inc. Gartner, 2011. Gartner Says Sales of Mobile Devices Grew 5.6 P ercent in Third Quarter of 2011, Smartphone Sales Increased 42 Percent. Gartner, November 15, 2011. [online] Available at: http://www.gartner.com/it/page.jsp?id =1848514 [Accessed 16 November 2011]. Hazael-Massieux, D., 2011. Device APIs Work ing Group Charter. [online] Available at: http://www.w3.org/2011/07/DeviceAPICha rter [Accessed 6 December, 2011]. Hoque, R., 1998. CORBA 3. Foster City, CA: IDG Books Worldwide. ieblog, 2010. HTML5 and Real World Site Performance: Seventh I E9 Platform Preview Available for Developers. IEBlog [blog] 17 November 2010. [o nline] Available at: http://blogs.msdn.com/b/ie/archive/2010/11/17/html5-and-rea l-world-site-performanceseventh-ie9-platform-preview-available-for-developers.as px [Accessed 6 December 2011]. Kobayashi, K., 2011. Encyclopaedia Britannica Onl ine. [online] Available at: http://www.britannica.com/EBchecked/topic/320750/Koj i-Kobayashi [Accessed 01 November, 2011]. Lee, W-M., 2011. Beginning Android App lication Development. Indianapolis: John Wiley & Sons. Lowy, J., 2010. Programmi ng WCF Services. Third Edition. Sebastopol, CA: OReilly Media Inc. Mednieks, Z., Dornin, L., Blake Meike, G., & Nakamura, M., 2011. Programming Android. Sebastop ol, CA: OReilly Media, Inc. Meier, R., 2010. Professional Android 2 Application D evelopment. 2nd Edition. Indianapolis: Wiley Publishing, Inc. MSDN, 2012. ASP.NE T Overview. [online] Available at: http://msdn.microsoft.com/enus/library/4w3ex9 c2.aspx [Accessed 5 January 2012]. 84

List of References MSDN, 2012. .Net Framework Conceptual Overview. [online] Available at: http://ms dn.microsoft.com/library/zw4w595w.aspx [Accessed 4 January 2012]. MSDN, 2012. Ma naged Execution Process. [online] Available at: http://msdn.microsoft.com/en-us/ library/k5532s8a.aspx [Accessed 4 January 2012]. MSDN, 2012. UDDI Specification Index Page. [online] Available at: http://msdn.microsoft.com/en-us/library/ms953 967.aspx [Accessed 30 January 2012] National Academy of Engineering, 2001. Memorial Tributes. Volume 9. National Aca demies Press Panzarino, P., 2011. Android: 550000 phones activated a day, 130M d evices, 6B downloads. thenextweb.com, 14 July 2011. [online] Available at: http: //thenextweb.com/google/2011/07/14/there-are-now-550000-android-phonesactivatedevery-day/[Accessed 15 November 2011]. Saurenmann, R., 2008. REST vs. SOAP. MSDN Blogs, [blog] 28 November. Available at: http://blogs.msdn.com/b/swiss_dpe_team /archive/2008/11/28/rest-vs-soap.aspx [Accessed 29 January 2012] Scornavacca, E. & Barnes, S.J., 2008. The strategic value of enterprise mobility: Case study in sights. Information Knowledge Systems Management (e-journal) 7 (1/2), 227241. Av ailable through: EBSCO Host database [Accessed 17 December 2011]. Sharma, A., Wi ngfield, N., & Yuan, L., 2007. How Steve Jobs Played Hardball in iPhone Birth. W all Street Journal Online, February 17, 2007. [online] Available at: http://facu lty.coloradomtn.edu/jtroeger/business/assignments/week_06/readings/How% 20Steve% 20Jobs%20Played%20Hardball%20In%20iPhone%20Birth.pdf [Accessed 5 November 2011]. Skonnard, A., 2003. Understanding SOAP. MSDN, March 2003. [online] Available at : http://msdn.microsoft.com/en-us/library/ms995800.aspx [Accessed 19 January 201 2]. Skonnard, A., 2003. Understanding WSDL. MSDN, March 2003. [online] Available at: http://msdn.microsoft.com/en-us/library/ms996486.aspx [Accessed 21 January 2012]. Troelsen, A., 2010. Pro C# 2010 and the .NET 4 Platform. Fifth Edition. U SA: Apress Media LLC. Vogelstein, F., 2008. The Untold Story: How the iPhone Ble w Up the Wireless Industry. Wired Magazine, January 9, 2008. [online] Available at: http://www.wired.com/gadgets/wireless/magazine/16-02/ff_iphone?currentPage=a ll [Accessed 15 November 2011]. West, J., & Mace, M., 2007. Entering a mature in dustry through innovation: Apples iPhone strategy. DRUID Summer Conference 2007. [online] Available at: http://www2.druid.dk/conferences/papers.php?cf=9 [Accesse d 2 November 2011]. 85

List of References West, J., & Mace, M., 2010. Browsing as the killer app: Explaining the rapid suc cess of Apples iPhone. Telecommunications Policy (e-journal) 34 (5/6), 270-286. A vailable through: ScienceDirect database [Accessed 12 October 2011]. Winder, D., 2011. The State of Smartphone Security. Infosecurity (e-journal) 8 (4), 3639. A vailable through: ScienceDirect database [Accessed 19 December 2011]. 86