Porting of an iPhone Application to Android392324/FULLTEXT01.pdf · Porting of an iPhone Application to Android . Contents 1 Introduction 4 ... developers guide recommends [8] that

Degree Project

Alvin Scudder

2011-01-19

Subject: Computer Science

Level: Bachelor

Course code: 2DV00E

Porting of an iPhone Application to Android

Contents

1 Introduction 41.1 Problem and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Goals and Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 62.1 Android Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 History and Platform Overview . . . . . . . . . . . . . . . . . 62.1.2 Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Android Versions . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Device Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 iPhone Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Other Mobile Platforms . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.1 Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Blackberry OS . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 Bada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Android for the Canvoy client . . . . . . . . . . . . . . . . . . . . . . 12

3 Overview 133.1 Basic Concepts of Android Programming . . . . . . . . . . . . . . . . 133.2 Android Testing and Development Tools . . . . . . . . . . . . . . . . 143.3 Testing on Emulator and Physical Devices . . . . . . . . . . . . . . . 153.4 Overview of the Canvoy client . . . . . . . . . . . . . . . . . . . . . . 16

3.4.1 Web Service Connection . . . . . . . . . . . . . . . . . . . . . 163.4.2 Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4.3 Canvoy Activity and Navigation Overview . . . . . . . . . . . 193.4.4 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.5 Map Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4.6 Tab Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.7 List Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.8 Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.9 Help classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 Implementation 244.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Splash Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Vehicles (start screen) . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4 Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.5 Vehicle Position and Status . . . . . . . . . . . . . . . . . . . . . . . 294.6 Driver Position and Status . . . . . . . . . . . . . . . . . . . . . . . . 304.7 Vehicle Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.8 Driver Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.9 Vehicle Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2

4.10 Driver Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.11 Legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Conclusion and Future Work 385.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Bibliography 40

3

1 Introduction

The smartphone market has grown to a significant size these recent years. Accord-ing to Gartner, 17.3 percent of all phones sold in the first quarter of 2010 weresmartphones, compared to 13.6 in 2009 [2]. Currently several platforms, backedby big companies, are competing against one another – each holding a noticeablemarket share. For developers of applications aimed at the mobile market this meansit might be profitable to deliver their products to more than one platform.

This thesis will present a portation of an existing iPhone application for the An-droid mobile operating system. For a better understanding this thesis will alsoprovide some brief background information about Android and other mobile plat-forms; Android development and deployment and lastly devices compared to theiPhone.

1.1 Problem and Motivation

Transport firms are faced with high gas prices, smaller margins and and an increasedneed for quick decisions. To handle these problems a need has arisen to be able toaccess the companies vehicle and driver statuses in real time.

Transplain AB is a company that delivers software systems to the transport in-dustry. One of their projects, Canvoy, is a fleet management system specially con-structed to meet the aforementioned need. A small box is fitted into the trucks cabinand are attached to the CAN (Controller Area Network) of the vehicle. Informationis then gathered from the tachograph, engine, and together with GPS-data it issent to a central server. This data can then be processed and presented in differentapplications [1].

One of Transplain AB’s products is the iPhone Canvoy client which makes possiblefor personnel to overview the vehicle fleet from their phone in real time. The thesisis written for Softwerk which is developing Canvoy for Transplain.

The problem to solve for this thesis is to widen the potential market of the Can-voy client by porting the application to the Android platform. The motivation forchoosing Android as the next platform is that it has gained tremendous popularityin the last year. According to a report released by Canalys in August 2010, Androidhas grown by 886% since Q2 the year before, making it the biggest mobile operat-ing system in Northern America and the second largest in Europe [3]. A report byGartner predicts that Android will continue to increase its market shares the comingyears, challenging Nokia’s Symbian OS for the top position in 2014 [4].

1.2 Goals and Criteria

The thesis has one main goal and several sub-goals:

• The main goal is to successfully port the Canvoy client application to Android.This goal is reached if the Android version has the exact same functionality asits iPhone counterpart. To achieve this goal a specification document for the

4

iPhone application and access to the source code written in Objective-C willbe used.

• Perform adaptations to the specification to better conform to Android specificfeatures. This goal is reached if the application takes into use the differentAndroid specific features as the menu and back button.

• The implementation should make use of those tools and best practices thatexist for Android to make the application easier to update in the future. Thisgoal is reached by using a clear separation between layout and code logic.

• The application should be compatible with all phones running Android 2.1 orhigher, maintaining a similar presentation on both medium and high resolutionscreens.

The last sub-goal is also a constraint. Obviously it would be good if the applicationalso supports earlier versions of Android as well, but to narrow down the work neededfor compatibility testing a limit has been set on version 2.1 with medium and highresolution.

5

2 Background

This chapter presents background information of the Android platform, the devicesand how to handle their differences in screen size. A brief overview of iPhone andother available smartphone platforms is also provided.

2.1 Android Overview

In this section we present the Android platform with some brief history, its structureand devices.

2.1.1 History and Platform Overview

In November 2007 a business alliance of 34 members, led by Google, called the OpenHandset Alliance was unveiled together with their first product, the Android mobileoperating system version 1.0. Today, the Alliance consists of 78 technology andmobile companies (HTC, Sony Ericsson, NVIDIA to name a few) working togetherin creating an open and commercially successful platform for mobile devices[5].

Android is a software stack with several layers. The kernel is based on Linux2.6, between the kernel and applications are all the open source libraries written inC and C++ used by various components. The application layer is written in Javaand all applications are equal, meaning that even basic components (e.g. picking aring-tone, home screen or reading SMS) easily can be replaced. Every applicationruns in a separate instance with its own instance of the Dalvik virtual machine.Android applications are not converted into class files as normal Java applicationsbut instead use the Dalvik Executable (.dex) format, which is specifically designedfor systems that have limited memory and processor speed [6]. The dex-file is storedtogether with a manifest and resources in a Android package marked by the .apksuffix. Apk-files are the format for distributing Android applications. This filecontains everything for that particular project.

A difference from regular application programming is that Android applicationsdo not have a fixed entry point to the application with a main() function. Instead,an application consists of multiple components which can be instantiated as needed.There are four main types of components:

• Activities; presents a visual interface in which the user can interact. Mostoften the window fills the screen, but sometimes smaller areas.

• Services; runs in the background for an indefinite amount of time. May for in-stance be used to play music or fetch data without showing any visual interfacefor the user.

• Broadcast receivers; receive announcements and react to them. An announce-ment can originate from a system application or be sent from a regular appli-cation.

6

• Content providers; makes a specific part of an applications data available toother applications.

All these components have their different application usage and complement eachother.

The most commonly used component is the activity, as almost every applicationhas a visual interface for the user to interact with. Activity windows can be filledwith ready-made views like buttons or textfields as well as custom made views. Allcomponents are activated by asynchronous messages called intents, consisting ofan Intent object. These intents include different data depending on which type ofcomponent that is the recipient. With the help of intents it is possible to launch newactivities, both inside and outside the application, pass data to them and receiveresults back.

For a component to be used it must be declared in the application manifest file.The manifest is a structured XML file containing additional information about theapplication beyond the components, like permissions (e.g. internet and SD cardaccess) and additional libraries used if any. The manifest also contains the entrypoint of the application by setting the main intent filter specified to the launchercategory.

Activities are grouped in a stack called a task. A task is what a user perceives asan application when he or she browses between activities. As activities are highlyindependent of each other an activity in a completely different application couldbe launched for a specific purpose and be put in the same stack. For instance,if an application uses the camera to take a photo, an already existing activity forcapturing photos can be launched and placed in the same stack as the currentrunning task instead of creating a completely new activity for this purpose. Thismeans that if several tasks are run, there are also several stacks. Therefore pressingthe back button on a task the user just switched to does not take the user back tothe previous task, but instead to the previous activity in the current task. If thisbehaviour is not preferred there are a series of flags which change this behaviour aswell.

All Android components have a lifecycle which can be viewed in Figure 2.1. Anactivity has three main states; active or running, paused and stopped. The activitycurrently viewed by the user is in the running state. If the activity is partly coveredby an other activity, losing focus, the activity is put into the paused state and if thewindow is fully covered the activity state is set to stopped. All state and memberinformation stays intact in all different states, but an activity might be terminatedby the operating system if memory is low, starting with activities in a stoppedstate and then moving on to paused activities if needed. To be certain that a useris returned to an activity in the exact same state as when he or she left it, onecan make use of the onSaveInstanceState() method. This method is called beforethe system destroys an activity and provides the option to save primitive types,serializable files and parcable files in a bundle object. This bundle can the be usedin the onRestoreInstanceState() to restore the state [10].

2.1.2 Apps

Android applications are distributed through many different markets and websites,but the main distribution channel is Google’s own Android Market whose down-loader is installed on every phone by default. The market application lets users

7

Figure 2.1: Activity lifecycle

browse published applications by different categories and subcategories, read usercomments and rate installed applications. If a user wants an application he orshe browses to it, pays for it if it is not free and then downloads it to the phone,installation is automatic.

To deploy applications on the Android market a one time developers fee has tobe payed. In addition every uploaded application has to conform to certain require-ments regarding some parameters in the manifest file and also be signed by a privatekey, whose validity period exceeds the 22nd of October 2033. An uploaded applica-tion is added to the market instantaneously with no screening process whatsoever.

If the developer does not want to use any of the available markets, there is nothingthat prevents him or her publishing an apk-file on a website or from distributingit among friends through some other media. Note that applications downloadedfrom outside Android market can only be installed if the user has checked Unknownsources - Allow install of non-Market applications checkbox. This setting is foundunder:

Menu Button→Settings→Applications

2.1.3 Android Versions

Since November 2007, when the first version of Android was released for the pub-lic several additional versions have been released, 1.5 (Cupcake), 1.6 (Donut), 2.1(Eclair) and the latest version 2.2 (Froyo), each ironing out bugs and adding newfunctionality. This rapid evolution of the operating system has created problems

8

for users as older devices in some cases do not have supporting hardware for newerversions. For the phone to even be upgradeable handset makers have to create themiddleware that interfaces between hardware and OS. This middleware called theBoard Support Package can take months to develop causing a delay, resulting innew phones being released with old OS versions with exception for Google brandedphones that are closely manufactured together with Google [7].

From a developers point of view this segregation complicates things as you cannot require users using devices with old firmware to upgrade to the newest versionand by that be certain which version of the operating system they are using. Thedevelopers guide recommends [8] that you determine the lowest possible platformversion to compile against by testing the application successively against lower buildtargets. Devices running newer versions will in most cases also be able to run theapplication as forward compatibility generally is good but developer documentationstates that testing should be made for every version.

Figure 2.2 shows a historic overview the relative number of devices running agiven Android version over a six month period ending on October 1, 2010 with theoldest version on top. The chart also shows that even though newer versions areincreasing steadily, older versions i.e. 1.5 and 1.6 still hold a substantial share ofjust over 25%. This means that developers still have to develop for version 1.5 tonot miss a significant part of the platform user base.

Figure 2.2: Distribution of Android versions[8]

2.1.4 Device Overview

Devices

Phones running the Android platform are created in many shapes and sizes andby many different manufacturers, yet there are several commonalities. All Androidphones have some kind of buttons, either physical or capacitive (regions sensitive totouch). Many have keys for changing volume and using the camera, but there arealso a set of standard buttons which are found on every phone:

• Home button returns to the main home screen, holding it in gives a view ofrecently opened applications.

• Search button gives search options within an application if enabled (this keyis sometimes omitted).

9

• Back takes the user to the previous screen.

• Menu button shows a menu with additional options in an application.

These four keys have well integrated functions in the Android OS and the APIprovides several useful possibilities to utilize them for an application. All of thesekeys can be overridden and have functionality added. For instance, the android APIprovides the means to integrate a search dialog in an application so that a developerdoes not have to think about where to put the search box. It also simplifies theimplementation of that kind of functionality. The menu button provides additionaloptions not directly visible in the user interface but easily available by pressing it.Each activity has a separate implementation of the menu so the options can beunique between them.

The back button presents useful functionality for the developer with no additionalprogramming needed. If not overridden, pressing the button pops the current ac-tivity from the activity stack and shows the new top activity which usually is theprevious activity in the same application. If the stack is empty, the user is takenback to the home screen. This removes any need for back- and/or exit buttons inmost cases.

Pressing the home button puts the current application in a pausing state andtakes the user back to the home screen. It is important to understand and handlethe different activity states so that the application is correctly resumed.

Handling Resolutions

As Android devices come in many different sizes and resolutions a developer has totake some measures to make an application look good on different devices. Whencreating a layout it is better to think of rules instead of exact positions. For thisreason the absolute layout that exists has been deprecated encouraging developersto use either a FrameLayout or RelativeLayout. With the help of a relative layoutit is possible to place views in relation to other added views or its parent. By doingthis all views will have the same placing among each other regardless of screen size.

An other thing to think about is the choice of measurement unit. It might betempting to use pixels (px) as a unit but as the density might differ between differentdevices, a button might become impossible to press on a high density screen. Instead,there is an other unit, density-independant pixels (dip), which assume a 1:1 pixelratio on a 160dpi screen and scale from there. This makes the actual dimensionsstay the same regardless of density. There is also a unit called scaled pixels (sp)which also take the user’s font size into account while doing the scaling.

The manifest takes a series of attributes where you can declare supported screensizes and if density has been put into account in calculations, if not, Android canscale the dimensions for you

If you want to use different layouts or resources depending on densities, this canbe done by adding several folders with the different suffixes -ldpi, -mdpi and -hdpito the resource folder that includes the resources [11].

2.2 iPhone Overview

iPhone is a brand of smartphones designed by Apple, which was first introduced inJanuary, 2007. Since then Apple has released another three versions of the iPhone

10

with better hardware. The first three versions have the same screen resolution of480 x 320, but the latest version, iPhone 4, has exactly doubled(960 x 640) theresolution. By doing this, it is still easy to let every unoptimized application lookthe same on iPhone 4 by using the scaling factor, and letting every one pixel onthe lower resolution phones take up four pixels(scaling factor 2.0) on the more finegrained screen. This simplifies the development of the UI alot since less time has tobe spent testing different screen sizes and optimizing for different aspect ratios.

The platform which consists of the operating system and technologies needed torun applications is called iOS. Other apple products like the iPad and iPod touchalso use iOS. New features have been added to iOS over time but only for devicesthat Apple feel can handle them. For instance, multitasking is only available for the3GS and 4 versions of the iPhone.

To develop an application a Mac OS X computer with the Xcode developmentenvironment is needed. Xcode also contains a simulator, which makes it possibleto develop and test applications without actually owning a device. To test on anactual device you have to purchase an Apple developer account. The programminglanguage for the iPhone is a superset of the ANSI version C known as Objective-C.Objective-C adds object-oriented capabilities to C while providing full backwardssupport.

All applications for the iPhone are distributed through Apple by their app store.Compared to the Android Market where a developer just uploads a produced ap-plication directly to the market, each application has to go through a screeningprocess before being published. This helps increase the overall quality of applica-tions in the store but the downside is that developers have to wait longer beforetheir applications reach consumers. iPhone OS smartphones have, just like Androidsmartphones, increased their market share considerably, from 10.5% in Q1 2009 to15.4% in Q1 2010 [2].

2.3 Other Mobile Platforms

Even though Android and iOS devices are getting a lot of attention right now thereare several other alternatives that have a considerable market share. This chaptergives a brief overview of four other competing platforms.

2.3.1 Symbian

Symbian OS, originally created by Symbian Software is run by an independent non-profit organisation called the Symbian Foundation which was founded in 2008 bythe telecommunications company Nokia. The aim is to keep the Symbian platformroyalty-free and open source. Since 2010, C++ together with the Qt framework formthe standard development environment but several other languages like Python,Ruby and Java ME can be used as well. Symbian is currently the largest platformwith 41% of the smartphone market in Q1 2010[2].

2.3.2 Blackberry OS

The Blackberry operating system is developed by the Canadian company Research inMotion. The platform is best known for its business oriented applications, especiallyregarding to messaging. The devices usually have good battery time and mostdevices have physical keyboards giving them a characteristic look. Third party

11

applications are programmed in Java with a custom API. According to Gartner,Research In Motion stood for 19.4% of the smartphone sales during the first quarterof 2010[2].

2.3.3 Windows Mobile

Windows Mobile operating system is developed by Microsoft for use in smartphonesand other mobile devices. It is designed to have some similarity to the desktop ver-sion, both aesthetically and feature-wise. The platforms market share has declinedsignificantly according to Gartner, from 10.2% in Q1 2009 to 6.8% in Q1 2010, butin enterprise environment Windows Mobile is considerably more popular. A suc-cessor to Windows Mobile, Windows Phone 7, has been officially launched offeringa new user interface. During the presentation Microsoft stated that there will behigh requirements set on the phone manufacturers with set benchmarks that haveto be met, addressing problems with the some windows mobile phones running onlow end hardware giving a bad experience of the platform. Gartner analysts believethat the new OS will counteract the current decline [2].

2.3.4 Bada

Bada is a new Smartphone operating system developed by Samsung. Their visionis not to directly compete with other smartphone systems but instead convert usersof regular feature phones into smartphone users by providing cost-effective phones[14]. Applications are developed in C++ with the Bada SDK and Eclipse IDE.Just as the iPhone, Bada has a central app store where new applications have to beuploaded and certified before released to the public. Samsung hopes that the storewill hold around 7000 apps by the end of 2010.

2.4 Android for the Canvoy client

The Canvoy client puts some basic requirements on the platform. The application istouch based, requires and internet connection and the possibility to integrate Googlemaps. All this is possible in Android and it is therefore an acceptable choice for aportation.

12

3 Overview

This chapter provides a basic introduction to Android programming developmenttools, environment and deployment. It also gives an overview of the Canvoy clientand the components used to implement it in Android.

3.1 Basic Concepts of Android Programming

The user interface of an Android application can be declared either in a providedXML vocabulary or programmatically instantiated at runtime with View and View-Group objects. These two techniques may be mixed in any way but Android’s de-veloper website states that the declaration of the UI in XML has several advantagesits programmatic counterpart. First of all it gives a clear separation between thepresentation and the code for managing behaviour. This also makes it easy to createdifferent layout files depending on orientation and screen sizes. Secondly, declarationof the layout in XML makes it easier to visualize the structure of the UI, therebymaking it easier to debug [13]. This said, sometimes ordinary programmatic layoutis the only option, for instance if the layout is custom created depending heavily ondecisions made on runtime.

To connect all the resources to the Java code, like XML layouts and images, An-droid makes use of the R.java file, which is an automatically generated file containingstatic integers working as an index over all resources. Every file automatically gets apost in the file but Views inside the XML files have to be assigned an ID before theyare added by in the R.java file. The following example shows a TextView (equivalentto the JLabel in Java Swing) containing the string Hello:

<TextViewandroid:id="@+id/hello"

android:layout_width="fill_parent"android:layout_height="wrap_content"android:text="Hello"/>

The first attribute called android:id is for the assignment of the id. The plus signin @+id shows that we wish to create a new id in the R.java file.

When this has been done, the id is automatically generated in R.java:

public static final class id {public static final int hello=0x7f050000;

}

After these steps have been taken, it is possible to access the TextView from theJava code:

public class Example extends Activity {/∗∗ Called when the activity is first created. ∗/@Overridepublic void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);setContentView(R.layout.main);

13

TextView tv = (TextView)findViewById(R.id.hello);tv.setText("New text");

}}

First the XML layout (main.xml) containing the textView is set as the current viewof the activity. After that a textView object is created mapped to the textView inthe XML, followed by changing the contained string.

3.2 Android Testing and Development Tools

Android development is supported on Windows (XP and newer), Mac OS X (10.5.8or later, intel based) and Linux (Ubuntu Hardy Heron has been officially tested)with the Java development toolkit (JDK) installed. To start development the An-droid SDK has to be downloaded from Android’s developer site(http://developer.android.com). These tools are sufficient to create a Android projectthrough a terminal command:

android create project --target android-7 --path ./Canvoy --activitySplash --package com.exjobb.canvoy

The android create project command takes a number of arguments. The abovecommand creates a new project called Canvoy with a entry activity called Splash.javain the package com.exjobb.canvoy. The target set to android-7 declares the lowestandroid API level (7 corresponds to version 2.1) the application should run on. Tosimplify this process, an Android Development Tools (ADT) plugin for the EclipseIDE is available. The plugin provides a wizard for creating new projects, integrateddebugging monitor (DDMS), an XML editor for layouts and a exporter for creatingsigned and unsigned apk-files among other things.

The Android Debug Bridge (adb) handles connected android powered devicesand running emulators. It consists of three components, client, server and daemon.The client is run on the development machine, if no server is connected it startsone. One daemon is run for every emulator or device currently running. The servermanages communication between client and daemon. The adb can be used directlyfor installing applications, adding and removing files among other things. Adb is alsoused by a debugging tool included in the Android SDK known as the Dalvik DebugMonitor Server (DDMS). As mentioned in chapter 2.1.1 every application runs inits own process. An individual connection to each process by connecting to everyVM debugger through the adb, assigning them port numbers starting from 8600 andincrementing by one for every new process. The DDMS provides an assortment ofhelpful tools for debugging:

• Thread analyzer.

• Heap statistics and the possibility to force garbage collection.

• State simulation of telephone status, actions (phone calls, sms) and GPS input.

• A graphical file explorer for putting and pulling files.

• Allocation tracker, very useful for tracking down and eliminating memory is-sues.

14

• Screen capture to easily take screenshots of the current device view.

• LogCat, shows device log messages from running processes.

The list only shows some of the many uses that the DDMS has to offer. The toolhas been well integrated into the Eclipse IDE using the ADT plugin, providing itwith its own tab so that in does not have to be externally launched.

3.3 Testing on Emulator and Physical Devices

To test a created application without a physical device an Android Virtual Devicehas to be created (AVD). An AVD consists of:

• A hardware profile, defining which hardware features the emulated device hase.g. camera, physical keyboard, memory, and so on.

• Android version running on the virtual device.

• Emulator appearance, screen dimensions and density.

• Data storage, an area on the development machine which is dedicated forstoring user data. An emulated SD card may be created as well.

Creation of an AVD is easiest done by the graphical AVD manager that is acces-sible in Eclipse after the ADT plugin has been installed.

Testing on a physical device is very simple. First of all a checkbox called USBdebugging must be checked. It is found on the telephone under:

Menu Button→Settings→Applications→Development

After that the telephone is automatically recognized by the adb and debug outputstarts to show in the Eclipse LogCat window.

Test running an Android application in Eclipse is just as easy as running a regularJava application. The only difference is to select Run as Android Application insteadof Java application. If any one device is connected (both virtual or physical) Eclipsewill automatically deploy the application on the device and run it as long as thedevice runs a version of Android equal to or higher than the version the applicationis compiled for. In the case that several devices are attached, an option dialog isopened letting the developer select which device to deploy on. In the case thatno emulator is running yet, Eclipse automatically starts an emulator with a fittingversion for the current application.

For the thesis, testing of Canvoy Android client has been done on both an emulatorrunning Android 2.1 with the Google API emulating a medium resolution screen,and on a physical device. The physical device is an Acer Liquid s100 with a 768MHzQualcomm Snapdragon processor, 256 MB RAM and a WVGA 800x480 resolution.The Android version running on the phone is 2.1.

15

3.4 Overview of the Canvoy client

The Canvoy clients core function is to visualize data collected from a Web Service.Presentation of the data should be as close as possible to the Canvoy Client Specifi-cation provided by Softwerk. Due to the intellectual property rights agreement, it isnot possible to publish the specification with the thesis. In addition testing has beenmade on the iPhone version of the application with Xcode simulator, together withactual examination of source code to further the understanding of the applicationsbehaviour.

All the different screens containing data share some commonalities. The Figure3.1 shows a wireframe over the most common screen for the Canvoy client. At the topthere is a header showing the user what he or she is currently viewing together withtwo buttons for navigation to different views. On iOS this is an existing componentknown as the UINavigationBar. This class also enables the developer to add one ormore buttons to it with different shapes available to choose from. On Android thiscomponent does not exist at all. To retain the same look and functionality for theAndroid version a gradient has been used as the header background together witha TextView for the center text and Button views are added with custom graphicsadded if an other shape than the traditional button is used.

Underneath is a subheader with more specific information about the currentlyviewed data. This is a simple TextView with the width set to fill_parent and thebackground set to gray.

The main area has different content depending on the current view. This wire-frame shows a list view which is used in a majority of the screens. Below the mainwindow there is a tab view that can be pressed to switch content above the tab be-tween different views. Both list and tabs have clear equivalents in form of subtypesof the activity class. These two subtypes are explained more thoroughly later in thischapter.

3.4.1 Web Service Connection

The Web Service with the Canvoy data runs the SOAP protocol that uses XML forits layout. A typical message from the service has the following layout:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body>

<ns:getLastPositionForVehicleResponse xmlns:ns="http://webservice.canvoy.softwerk.se"><ns:return type="se.softwerk.canvoy.webservice.datatypes.PositionScreenData" xmlns:ax21="http://

datatypes.webservice.canvoy.softwerk.se/xsd"><ax21:avgFuelConsumption>30.076518200720784</ax21:avgFuelConsumption><ax21:cardInsertTime>2010−10−21T04:56:00.000Z</ax21:cardInsertTime><ax21:cardRemoveTime>2010−10−21T10:11:59.000Z</ax21:cardRemoveTime><ax21:companyIndex>1.1933544</ax21:companyIndex><ax21:companyTrend>0.45461014</ax21:companyTrend><ax21:driver1Id>V 0000000000009310</ax21:driver1Id><ax21:driverName>Tobias Thor</ax21:driverName><ax21:lastActivity>2</ax21:lastActivity><ax21:lastActivityChangeTime>2010−10−21T10:11:03.000Z</ax21:lastActivityChangeTime><ax21:latitude>56.883729</ax21:latitude><ax21:longitude>14.729456</ax21:longitude><ax21:ongoing>false</ax21:ongoing><ax21:registration>VZM923</ax21:registration><ax21:speed>0</ax21:speed><ax21:time>2010−10−21T10:13:33.000Z</ax21:time><ax21:unitId>85397070512403</ax21:unitId><ax21:vehicleIndex>0.96651965</ax21:vehicleIndex>

16

Figure 3.1: Screen wireframe

<ax21:vehicleTrend>−1.2451123</ax21:vehicleTrend></ns:return>

</ns:getLastPositionForVehicleResponse></soapenv:Body>

</soapenv:Envelope>

As the client relies heavily on Web Service calls in almost every activity, the firststep was to develop a solid set of classes for making the Web Service calls. Asconnections have to established from many different activities it made sense to makethe connection class globally available, eradicating any need to instantiate a newconnection class for every new activity. This could be done with static methods, butAndroid provides another method that has been used for the thesis; an Applicationclass which can be extended to add a global state to the application. After the classhas been added to the manifest, it will automatically be launched, before any otheractivity when the application is opened. The class and its methods are then readilyavailable through the getApplication() method in all classes extending the Activityclass.

public class WSInterface extends Application{...public PositionScreenData getLastPositionForVehicle(long unitId){

SOAPCall sc = new SOAPCall(SOAPCall.GET_POS_VEHICLE,Envelope.getLastPositionForVehicle(sessionKey, unitId));

return ((PositionScreenDataHandler)connect(sc)).getData();}...

17

}

public class Position extends MapActivity{...@Overrideprotected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);setContentView(R.layout.position);storage = (WSInterface)getApplication();storage.getLastPositionForVehicle(unitId);...

}...

}

To give access to Internet the application has to have the right permission in themanifest file:

<uses-permission android:name="android.permission.INTERNET" />

To be able to use the Web Service, the user must have a valid login and password.These credentials are sent to the web server that returns a session key which mustbe forwarded with all other calls. The key is valid for the whole session, but may bereleased if not used for some time. The client may also send a logout(sessionKey)request to release the key earlier. As it is fully possible for a user to start theapplication, do something else, and then come back to it later, the application hasto detect this and reconnect using the stored credentials and then resend the originalWeb Service call. If more than three calls are sent without success, an error messageis shown.

The classes used for Web Service connection are:

• WSInterface, extending the Application class giving global access to all thedifferent Web Service calls. It saves the sessionkey and renews it, doing anautomatic login request if needed before attempting the original request again.The class also contains methods for every different Web Service call returninga handler (described more in Section 3.4.2. For example:

public PositionScreenData getLastPositionForVehicle(long unitId){SOAPCall sc = new SOAPCall(SOAPCall.GET_POS_VEHICLE,

Envelope.getLastPositionForVehicle(sessionKey, unitId));return ((PositionScreenDataHandler)connect(sc)).getData();

}

• Envelope, containing static methods taking needed input and returning com-plete SOAP envelopes. An example:

public static String getLastPositionForVehicle(String sessionkey,long unitId){return new String(head+"<web:getLastPositionForVehicle>" +

"<web:sessionKey>"+sessionkey+"</web:sessionKey>" +"<web:unitId>"+unitId+"</web:unitId>" +"</web:getLastPositionForVehicle>"+endBody);

}

The head and endBody are Strings common to every envelope created.

• SOAPCall, this is the object sent by the WSInterface to the WSConnector.Depending on which method that is called, it is automatically loaded with theappropriate handler for parsing the response.

18

• WSConnector, makes calls to the Web Service through a DefaultHttpClientobject and parses the responses with the handler given by the SOAPCall objectpassed by the WSInterface using a SAXParser.

3.4.2 Parsing

Parsing of incoming envelopes is done with a SAXParser and handlers, which havethe AbstractHandler superclass that derives from the org.xml.sax.helpers.DefaultHandlerbase class [12]. Every response has a simple data class with setters and getters, anda corresponding handler. Parsing is done in the WSConnector class:

...SaxParserFactory factory = SAXParserFactory.newInstance()SaxParser parser = factory.newSAXParser();...public void makeCall(SOAPCall soapCall){

AbstractHandler handler = soapCall.getHandler();...parser.parse(he.getContent(), handler);

The parse method runs the received message through the handler and saves allthe necessary data. The AbstractHandler adds a flag that checks if the receiveddata was accepted or not and a getData-method that returns an Object type filledby the handler. This object is then used in the activities for showing information.The use of the handler makes it easy to add new handlers without having to changeanything in the class concerned with the parsing.

public class PositionScreenDataHandler extends AbstractHandler{private PositionScreenData currentPos;@Overridepublic void characters(char[] ch, int start, int length) throws SAXException {

super.characters(ch, start, length);current += new String(ch,start,length);

}@Overridepublic void endElement(String uri, String localName, String qName)throws SAXException {

//Adds the "current" String to by comparing the localName String to different.if(localName.equals("longitude")){

currentPos.setLongitude(Float.parseFloat(current));}...current ="";

}@Overridepublic PositionScreenData getData() {

if(isOK()){return currentPos;

}else

return null;}...

}

3.4.3 Canvoy Activity and Navigation Overview

The Figure 3.2 shows an overview of the main views in the Canvoy client application.The entry point is shown at the top with the large arrow. Thick arrows representa creation of a new activity and thin arrows represent changes in the view. Thedirection of the arrows shows the available means of navigation for the user. These

19

different screens are more thoroughly presented in chapter 4. Note that the Androidback button always makes it possible to close the current activity and return tothe previously visited activity in the task. Views that are grouped within the greyrectangles share the same view.

Figure 3.2 clearly shows how the Canvoy client is divided into two different partsdecided by an initial choice after login has been established. The left part corre-sponds to the vehicle selection and all different data that can be viewed from thereand the right part reflects the driver selection.

The activity with the asterisk is the Legend (Section 4.11) activity. It is anactivity of its own and can be access in all other activities with exception of thesplash screen 4.2 and configuration screen 4.1. Those lines have not been drawn toretain the clarity of the image.

Figure 3.2: Application structure, section screen numbers are provided

20

3.4.4 Activities

The client only operates while the user is actively using it meaning that no services,broadcast receivers or content provider components have to be used, only the activityclass and subtypes to it are needed. Android provides several activity subtypes thatwrap common UI patterns into activity subclasses. Special subtypes of interest forCanvoy are presented in the next subchapters.

3.4.5 Map Activity

MapActivity is a special Activity subclass for embedding Google maps in to anapplication. For map embedding to work, several steps have to be taken:

• An Android version including the GoogleAPI has to be chosen as a build targetfor the application.

• As the Map API is not part of the standard library, the library has to be addedin the AndroidManifest.xml file as a child of the < application > element:

<uses-library android:name="com.google.android.maps" />

• Internet permission has to be added to the manifest.

• An API key has to be generated and added to the Mapview. A key is only validfor applications signed by a single certificate. To attain a key, the certificatesfingerprint must be provided to Google. This fingerprint is can be found byusing the keytool which is found in the JDK folder. After providing the finger-print (Can be done here: http://code.google.com/intl/sv-SE/android/maps-api-signup.html) and accepting the terms of agreement, a key is provided.

$ keytool -list -keystore path/.android/debug.keystore...Certificate fingerprint (MD5):94:1E:43:49:87:73:BB:E6:A6:88:D7:20:F1:8E:B5:98

• A MapView has to be added to the Activity XML file using the API key:

<com.google.android.maps.MapViewxmlns:android="http://schemas.android.com/apk/res/android"android:id="@+id/mapview"android:layout_width="fill_parent"android:layout_height="fill_parent"android:apiKey="API key"

/>

Placing points on the map is done with the help of Overlays, which are a typeof layers that place custom icons on top of the map. Canvoy uses a single Over-lay(PositionOverlay.java) when mapping the vehicle/driver position in section 4.5and 4.6.

21

3.4.6 Tab Activity

A Tab Activity can run several embedded activities or views inside it. The XMLlayout of the activity has to have three components.

• TabHost Container for the both tab buttons and tab content. Must haveandroid:id @android:id/tabhost.

• TabWidget implements the tab selection row. Each tab contains a text andmay also have an icon added to it. Must have android:id equivalent to @an-droid:id/tabs.

• FrameLayout working as a container for the tab contents where each is a childof the FrameLayout. Must have the android:id of @android:id/tabcontent.

By moving the tabWidget and FrameLayout it is possible to put the tab selectionrow either at above or below the view.

As mentioned before, both Views and Activities may be added to a TabActivity.In most cases it is preferable to use views instead of Activities as a View is a lightweight component and thereby uses less resources. As mentioned in 3.4.3 and seenin Figure 3.2, most screens are grouped together into one activity, but one screen onboth driver and vehicle side has an activity by itself. This is the position activity (4.5and 4.6). The main reason for this was to be able to make use of the MapActivityfor the map screen.

3.4.7 List Activity

The ListActivity shows a single list (Attached by using as special id in the XML)on the screen and provides helpful methods for e.g. adding data or showing a textwhen the list is empty. Even though Canvoy uses lists heavily, no ListActivitieshave been used. The reason for this is as the lists share activity with other lists,the ListActivities help methods are not of use as it does not support multiple listswithin the same activity.

3.4.8 Graphs

The Analyze Tabs (4.10) and (4.9) make use of pie charts and vertical/horizon-tal bar charts. Android’s API does not provide any graphing classes. Withoutany third party libraries graphing has be done from using the 2D drawing pack-age. For the thesis I decided to search the Internet for good, free libraries withcapabilities of showing the needed chart types. There were several alternativesbut only one was both free and supported all the needed graphs; AChartEngine(http://www.achartengine.org/).

Implementing the different charts with AChartEngine was easy but unfortunatelythe created graphs did not get at all the same look as the iPhone version found in thethe specification document. Therefore, the majority of the drawing was overriddento create a more fitting look.

3.4.9 Help classes

Some noteworthy helper classes for the Canvoy client:

22

• ViewAnimations, contains static methods that return transition animationsused when traversing between driver sessions and vehicle analytics.

• TimeHelper, Dates and times are sent to and received from the Web Servicein the following format yyyy-MM-ddThh:mm:ss.000Z. The TimeHelper classgives several methods for converting dates into many different formats. Thereare also methods for setting calendars used when browsing between weeks inthe vehicle and driver session view.

• SessionHelper divides the session data from the Web Service into a formatsuitable for the weekly session overview for vehicles and drivers.

• DialogHandler is instantiated by the WSInterface enabling text and loadingdialogs to be used in every activity.

23

4 Implementation

In this chapter we introduce the Android client screen by screen. We explain itsfunctionality, when Web Service calls are made and which java and XML-files areinvolved in each activity. The section numbers match the screen numbers in Figure3.2.

4.1 Configuration

Figure 4.1: Configuration screen

Description

The user is taken to the configuration screen either by an error during start up(section 4.2) or by accessing it through the Vehicle screen (section 4.3). Here theuser can:

• Change the username, password and server address to connect to.

• Use [Default settings] button to restore the textfields to their default values.These values give access to the demo server.

• Login with the newly configured settings. On a successful login both usernameand password are stored in the applications shared preferences file and will beused as the default credentials for future login attempts. Any old details areoverwritten.

24

Java File and XML Layout Involved

Settings.java and settings.xml.

Web Service API

• Obtain sessionkey: login(username,password)

• Get list of Vehicles: getVehicleList(session)

• Get list of Drivers: getDriverList(session)

Navigation

• Login with the newly configured settings:

– Success: The Vehicle activity (4.3) is launched and the login settings arestored on file for future use by the application.

– Failure: An error dialog is shown stating that the login failed.

4.2 Splash Screen

Figure 4.2: Splash screen

Description

Canvoy splash screen displayed during startup while initialization is performed. Dur-ing the process three webservice calls are made, login, getDriverList and getVehi-cleList. First the login call is made with the user details stored from earlier launches

25

of the application. If it is the first launch of the application the default values areused.

After a successful login the other two web service calls are made. If they aresuccessful the values are stored in the Storage class and the Vehicle activity (4.3) islaunched.

If any of the calls fail the configuration (4.1) activity is launched instead.


Splash.java and splash.xml

Web Service API

• Obtain sessionkey: login(username,password)



4.3 Vehicles (start screen)

Figure 4.3: Vehicles screen

Description

Shows a list of all vehicles a user has access to. Each row in the list contains thefollowing information:

• Vehicle registration number.

26

• The name of the current/last driver of the vehicle.

• Current/last activity as an icon (driving, working, taking break, available orcard removed).


VehicleDriverTab.java

Web Service API



• Logout session key logout(session), called if the user presses the [Back] button.

Navigation

• Top menu:

– [Settings] shows the configuration screen (4.1).

– [Reload] Reloads the the list data.

• [List entry] Launches the driver (4.3) activity.

• Bottom Menu

– [Vehicles] Current screen viewed.

– [Drivers] Changes view to the Driver view (4.4).

• [Android Menu] View Legend activity (4.11).

• [Back] button, performs a logout and exits the application.

4.4 Drivers

Description

Shows a list of all drivers a user has access to. Each row in the list contains thefollowing information:

• Driver name.

• Registration number of last vehicle used by the driver.

• Current/last activity as an icon (driving, working, taking break, available orcard removed).


VehicleDriverTab.java, vehicledriver_tab.xml

27

Figure 4.4: Drivers screen

Web Service API



• Logout session key logout(session), called if the user presses the [Back] button.

Navigation

• Top menu:

– [Settings] shows the configuration screen (4.1).

– [Reload] Reloads the the list data.

• [List entry] Launches the driver (4.4) activity.

• Bottom Menu

– [Vehicles] Changes view to the Vehicle view (4.4).

– [Drivers] The currently shown view (4.3).

• [Android Menu] View Legend activity(4.11).

• [Back] button, performs a logout and exits the application.

28

Figure 4.5: Position and status screen

4.5 Vehicle Position and Status

Description

The top bar shows the selected vehicle registration number. Below the bar severalbits of information is shown:

• When the latest session started.

• When the session ended or if it is still ongoing.

• Last known activity, and the time is was registered.

• Average fuel consumption for the vehicle.

• Current Speed.

• Environmental index for both vehicle and company in total and the currenttrend.

Below the information a map is shown with the current position of the vehicle.The map can be moved around and the zoom level changed. If the device is turnedto horizontal mode everything(including the bottom navigation controls) is hiddenapart from the map which is expanded to fit the whole screen. The original view isrestored if turned to portrait view.


Position.java, position.xml

29

Web Service API

• getLastPositionForVehicle(UnitId).

Navigation

• Top menu:

– [Reload] Makes a new webservice call and reloads all data.

– [Position] The currently shown view.

– [Sessions] Takes the user to the session view (4.7).

– [Analyze] Shows the analyze view (4.9).

• [Android Menu] View Legend activity (4.11).

• [Back] Closes the activity and takes the user back to the 4.3 activity.

4.6 Driver Position and Status

Figure 4.6: Position and status screen

Description

The top bar shows the name of the selected driver. Below the bar several pieces ofinformation are shown:

• When the latest session started.

• When the session ended or if it is still ongoing.

30

• Last known activity, and the time is was registered.

• Average fuel consumption for the vehicle.

• Current Speed.

• Environmental index for both vehicle and company in total and the currenttrend.

Below the info a map is shown with the current driver position. The map canbe moved around and the zoom level changed. If the device is turned to horizontalmode everything(including the bottom navigation controls) is hidden apart fromthe map which is expanded to fit the whole screen. The original view is restored ifturned to portrait view.


Position.java, position.xml

Web Service API

• getLastPositionForDriver(DriverId).

Navigation

• Top menu:

– [Reload] Makes a new webservice call and reloads all data.

– [Position] The currently shown view.

– [Sessions] Takes the user to the session view(4.8).




4.7 Vehicle Session

Description

The vehicle session screen gives a weekly overview of a vehicles driving sessionsdivided by day. The top bar shows the selected vehicle registration number, andbuttons to show the previous or next week. If the user is viewing the current week,the next week button is hidden. The subheader shows which week that is currentlyviewed. The different sessions are shown in a listview divided by day. Every entryin the list contains day, driver, start and end of session.


SessionAnalyzeVehicle.java, sessionanalyzevehicle_tab.xml

Web Service API

• getAllDrivingSessionsForVehicleInWeek(UnitId,week,year).

31

Figure 4.7: Vehicle session

Navigation

• Top menu:

– [Reload] Makes a new web service call and reloads all data.

– [Position] Takes the user to the vehicle position and status view (4.5).

– [Sessions] Currently viewed view(4.7).




4.8 Driver Session

Description

The driver session screen has three levels, the first gives a weekly overview of avehicles driving sessions divided by day, the second shows every available session fora selected day and the third gives a detailed overview of a selected session.

The top bar shows the selected driver, and buttons to show the previous or nextweek in the first view. If the user is viewing the current week, the next week buttonis hidden. In the second and third view the week selection is replaced with a backbutton which takes the user back to the previous view. The subheader shows whichweek or day that is currently viewed depending on the which level the user is viewing.

The different sessions in the first view are shown in a listview divided by day.Every entry in the list contains day, vehicle, start -and end of session. The seconddivides the sessions of a selected day into different list rows so that they may be

32

Figure 4.8: Driver session

individually selected. The third view gives a detailed view of the session with totaltime spent, time spent on each different activity, start and stop of session, distancedriven and a chronological list with a detailed view of which activity has beenperformed and for how long.


SessionAnalyzeDriver.java, sessionanalyzedriver_tab.xml, sessions.xml, sessions_-day.xml, session_high_detail.xml and analyze_driver.xml.

Web Service API

• Overview: getAllDrivingSessionsForDriverInWeek(UnitId,week,year)

• Detailed view: getActivitiesForDrivingSession(UnitId,startTime)

• Update chart to new session: getSummaryStatisticsForDrivingSession(UnitId,time)

Navigation

• Top menu:

– [Reload] Makes a new webservice call and reloads all data for the currentview.

– [WXX Button] Changes the currently viewed week to the number shownon the button.

– [Week] Back Button, which takes the user back to the weekly overview.

– [Day] Back button, taking the user back to the daily session overview.Only shown if the user has passed through the daily session overviewwhen moving on to the high detailed overview.

• List Views:

33

– Week session overview: If the selected day contains more than one sessionthe user is taken to the middle view in the figure 4.8. If the day entry onlycontains one single entry the user is taken directly to the high detailedview at the right in figure 4.8.

– Day session: The needed webservice is called and the user is taken to thehigh detailed view.


– [Sessions] Currently shown view (4.7).




4.9 Vehicle Analyze

Figure 4.9: Vehicle analyze charts

Description

The vehicle analyze screen consists of a fixed top bar with the registration number ofthe currently selected vehicle and a reload button. The bottom of the screen holdsthe tab controls for switching between the different vehicle views. The center mainpart of the screen consists of three different charts that are held by a viewflipperview that presents one chart at a time. Attached to the chart is a OnGestureListenerthat registers fling motions. Depending on the direction of the motion the view ischanged to the left or right. The charts are connected at both ends meaning thata drag motion to the left if currently on the far left chart, takes the user to the farright chart and the other way around.

The first chart shown to the user is the summary screen shown to the left in figure4.9 with a pie chart. The summary screen shows average fuel consumption in litresper 100km, total fuel consumption, percent of time driving faster than 80km/h and

34

the total distance driven in km. The pie chart shows the distribution of activitiesfor the current vehicle divided in to driving, other work, and break/rest. The totalutilization percentage for the vehicle is also shown.

The middle view with a horizontal bar chart shows the current average fuel con-sumption for the vehicle per driver. The average fuel consumption across all differentvehicles a driver has driven is also shown in parenthesis next to the current vehicleaverage.

The right view containing a vertical chart displays a review of the average fuelconsumption (l/100km) for the current year, divided into months. Every monthshows both consumption for the selected vehicle as well as the average for all vehiclesin the fleet.


SessionAnalyzeVehicle.java, sessionanalyzevehicle_tab.xml, summary.xml, analyze.xml,avg_fuel_consumption.xml, avg_fuel_consumption_time.xml

Web Service API

• getVehicleTotals(unitId)

• getAvgFuelConsumptionAndDriverNamesForVehicleInMonth(unitId,month,year)


Navigation

• Top menu:

– [Reload] Makes new web service calls and reloads all data.

• Bottom menu:


– [Sessions] Takes the user to the vehicle session view(4.7).

– [Analyze] Currently viewed view (4.9).


• Horizontal touch screen drag motions, move between the chart views.

• [Back] Closes the activity and takes the user back to the vehicle selectionactivity 4.3.

4.10 Driver Analyze

Description

The driver analyse screen consists of a fixed top bar with the name of the currentlyselected driver and a reload button. The bottom of the screen holds the tab controlsfor switching between the different vehicle views. The center main part of the screenconsists of a summary screen with a pie chart. The summary screen shows averagefuel consumption in litres per 100km, total fuel consumption, percent of time driving

35

Figure 4.10: Driver Analyze Pie Chart

faster than 80km/h and the total distance driven in kilometres. The pie chart showsthe time spent between different activities for the current driving session, dividedin to driving, other work, and break/rest. The total session time is also shown inhours and minutes.


SessionAnalyzeDriver.java, sessionanalyzedriver_tab.xml, analyze_driver.xml

Web Service API

• getVehicleTotals(unitId)



Navigation

• Top menu:

– [Reload] Makes new web service calls and reloads all data.

• Bottom menu:


– [Sessions] Takes the user to the vehicle session view(4.7).

– [Analyze] Currently viewed view (4.9).

36


• [Back] Closes the activity and takes the user back to the vehicle selectionactivity 4.3.

4.11 Legend

Figure 4.11: Legend activity

Description

The legend activity is accessed from the menu button in all vehicle and driver ac-tivities. The activity is very basic, containing a legend describing all the differentgraphics used in the application.


Legend.java, legend.xml

Web Service API

none

Navigation

[Back Button] Close the activity and returns the user to the previously visitedactivity in the task.

37

5 Conclusion and Future Work

5.1 Conclusion

The problem addressed by this thesis is to widen the potential market of the CanvoyClient application by porting it from iOS to Android. This problem has been solvedby meeting the different goals setup for the thesis. The associated goals have beenreached as follows:

The main goal of the thesis was to create a Android version of the Canvoy client,using the iPhone source code and requirements specification. This goal was success-fully achieved by the full creation of all the different activities in accordance withthe requirement specification. Small details have also been checked in the iPhoneversion source code so that they perform the same calculations on both platforms.

Figure 5.1: Vehicle position screen on Android and iOS

The second goal was to make changes to the code to better conform to Androidparadigm. This has been taken into account by removing all buttons for movingbackwards if it is between activities utilizing the built in back button on Androiddevices and moving access to the legend from a small icon overlapping the list viewsto the Android menu function.

An example can be seen in figure 5.1 with the same view (Vehicle position 4.5) onAndroid to the left and iOS on the right. The top left button is missing as it takesthe user backwards and the small information icon for the Legend has been movedto the menu. Apart from this the structure of the of screen is identical. iOS has

38

a glossy finish to all its different components, this has not been copied as it is thespecial look used by iOS. Android has a matte finish to its different components.

Maintainability has been taken into account by putting the majority of the UI inXML, dividing presentation and logic and by using a good object oriented design.

Compatibility with Android 2.1 has been successful. Extensive testing has beenmade on both emulator and phone running version 2.1. Forward compatibility hasbeen tested briefly on an Emulator with version 2.2 without any difficulty.

5.2 Future work

There are several things which could be done in the future. Currently Canvoy onlyworks on Android 2.1 and higher. Doing a test run on Android 1.6 there were somegraphical bugs which would have to be fixed and maybe other things as well. Allthough, as time passes less and less of the active devices are running versions lowerthan 2.1.

It would also be good to test on more physical devices as it has currently onlybeen tested on one actual physical device (Acer Liquid). For instance, it would beinteresting to test the performance on devices with slower as well as faster processors.

Some improvement could be made to the graph drawing. As almost all of theparts of AChartEngine have been overridden, it would be nice to completely removethe library and replace those parts that are still in use. Also, the painted graphs arenot 100% screen size independent, so some tweaking could be added there as well.

39

Bibliography

[1] Transplain official website, http://www.transplain.com/ latest date of use:2010-10-24

[2] Gartner Says Worldwide Mobile Phone Sales Grew 17 Per Cent in FirstQuarter 2010, http://www.gartner.com/it/page.jsp?id=1372013 latestdate of use: 2010-10-24

[3] Android smart phone shipments grow 886% year-on-year in Q2 2010,http://www.canalys.com/pr/2010/r2010081.html latest date of use:2010-09-17

[4] Gartner Says Android to Become No. 2 Worldwide Mobile OperatingSystem in 2010 and Challenge Symbian for No. 1 Position by 2014,http://www.gartner.com/it/page.jsp?id=1434613 latest date of use:2010-09-17

[5] Open Handset Alliance FAQ, http://www.openhandsetalliance.com/oha_-faq.html latest date of use: 2010-09-17

[6] Android Developers, What is Android?,http://developer.android.com/guide/basics/what-is-android.htmllatest date of use: 2010-09-17

[7] Wired.com, http://www.wired.com/gadgetlab/2010/03/android-version-confusion/ latest date of use: 2010-09-17

[8] Android Developers, Platform Versions, http://developer.android.com/resources/dashboard/platform-versions.html latest date of use: 2010-10-24

[9] Android Developers, Application Fundamentals,http://developer.android.com/guide/topics/fundamentals.htmllatest date of use: 2010-09-17

[10] Android Developers, Application Fundamentals,http://redmondmag.com/articles/2010/08/13/microsoft-windows-mobile-loses-ground-in-smartphone-market.aspx latest date of use:2010-10-02

[11] The Busy Coder’s Guide to Android Development 3.1 , Mark L. Murphy2010

[12] Working with XML on Android, http://www.ibm.com/developerworks/opensource/library/x-android/index.html latest date of use: 2010-10-20

[13] Declaring Layout, http://developer.android.com/guide/topics/ui/declaring-layout.html latest date of use: 2010-10-21

40

[14] What is bada?, http://www.bada.com/whatisbada/ latest date of use:2010-10-24

[15] ADT Plugin for Eclipse, http://developer.android.com/sdk/eclipse-adt.htmllatest date of use: 2010-10-24

41

SE-351 95 Växjö / SE-391 82 Kalmar

Tel +46-772-28 80 00

[email protected]

Lnu.se

Documents

Porting of an iPhone Application to Android392324/FULLTEXT01.pdf · Porting of an iPhone Application to Android . Contents 1 Introduction 4 ... developers guide recommends [8] that