Degree Project

Porting an iOS Application tothe Android OS Platform.Garantikoll.se

Author: Bjorn OlssonSemester: VT11Subject: Computer ScienceLevel: BachelorCourse code: 2DV00E

Acknowledgements

Thanks to:Rudiger Lincke for beeing lightning fast with responding emails

and giving good answers.Erik Osterlund for helping me understand the iPhone code he has

written, that is “not ment to be read, it’s ment to be fast”1.

1A comment Erik made about the iOS code.

i

Abstract

Storing warranty receipts can sometimes be problematic. Receiptscan be lost, bleached and become illegible or in an extreme case, thestorage area is destroyed.

The company Freck AB offers a service to store these receiptsonline. They also provides a webpage where the user is able to handletheir receipts and an iPhone client for easier uploading.

Since the smartphones are increasing in market share each year,with different operating systems, it causes a market fragmentation. IfFreck AB wants to address more potential customers, the applicationneeds to get ported to more platforms. Currently iOS holds a 15.7%of the market share, and if the application is ported to the AndroidOS platform, 38.4% of the smartphone users will be addressed.

This thesis will present a portation of an iOS application to theAndroid OS platform. It will also discuss basic Android programmingtogether with the Android SDK classes and techniques used.

The portation was considered successful and the subgoals weremet. The application has been tested on multiple emulators and onone physical device with good results.

Keywords: Android - iOS - Smartphone - Porting - Softwerk - Garan-tikoll - Programming - Java - Client - BlackBerry - Windows Phone - Symbian

ii

Contents

1 Introduction 11.1 Problem and Motivation . . . . . . . . . . . . . . . . . . . . . 11.2 Goals and Criteria . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 42.1 Garantikoll.se . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Softwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Android Programming . . . . . . . . . . . . . . . . . . . . . . 52.4 example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Implementation-Variations . . . . . . . . . . . . . . . . . . . . 82.6 Other Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6.1 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.2 Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6.3 BlackBerry . . . . . . . . . . . . . . . . . . . . . . . . 92.6.4 Windows Phone . . . . . . . . . . . . . . . . . . . . . . 9

3 Overview 113.1 Architecture and Design . . . . . . . . . . . . . . . . . . . . . 113.2 Server Connection . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 Garantikoll Android Client Navigation Overview . . . . . . . . 143.6 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.6.1 Tab Activity . . . . . . . . . . . . . . . . . . . . . . . . 163.6.2 ActivityGroup . . . . . . . . . . . . . . . . . . . . . . . 173.6.3 Camera - “Activity” . . . . . . . . . . . . . . . . . . . 17

3.6.3.1 ReceiptCameraActivity . . . . . . . . . . . . 173.6.3.2 ReceiptCameraPreview . . . . . . . . . . . . . 18

3.7 Dataflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.8 Android OS Version 2.1 Support . . . . . . . . . . . . . . . . . 193.9 Image Caching - Restrictions . . . . . . . . . . . . . . . . . . . 203.10 Differences - Android vs. iOS . . . . . . . . . . . . . . . . . . 21

4 Implementation 254.1 Preferences, Login . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Preferences, Logout . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Receipt, View Level 1 . . . . . . . . . . . . . . . . . . . . . . . 284.4 Receipt, View Level 2 . . . . . . . . . . . . . . . . . . . . . . . 29

iii

4.5 Receipt, View Level 3 . . . . . . . . . . . . . . . . . . . . . . . 304.6 Receipt, View Level 4 . . . . . . . . . . . . . . . . . . . . . . . 324.7 My Receipts, View Level 1 . . . . . . . . . . . . . . . . . . . . 334.8 My Receipts, View Level 2.1 . . . . . . . . . . . . . . . . . . . 344.9 My Receipts, View Level 3.1 . . . . . . . . . . . . . . . . . . . 364.10 My Receipts, View Level 2.2 . . . . . . . . . . . . . . . . . . . 374.11 My Receipts, View Level 3.2 . . . . . . . . . . . . . . . . . . . 38

5 Conclusion and Future Work 405.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

iv

1 Introduction

In the mobile market, more and more mobile phones are smartphones. Theyhave increased in market share the last years. Sales to end users in 2010totaled 1.6 billion devices. This is an increase by 31.8% from 2009. Smart-phones are accounted for 19% of the total mobile communication device salesin 2010.

Several platforms are used, where Symbian holds 37.6% and Android�2

holds 22.7% of market share (in the end of 2010) among smartphones ac-cording to Gartner [4]. The Android OS had only 3.9% in the end of 2009and Symbian had 46.9%. iOS have also increased during 2010, from 14.4%in 2009 to 15.7% in 2010. Both Microsoft and RIM have decreased theirmarket share to 4.2% and 16.0% respectively during 2010. Since the mar-ket is fragmented, this results in that applications needs to be written, formore than one platform, if the developer wants to address as many users aspossible.

This thesis will present a porting of an iOS application to the AndroidOS platform. It will also present some brief background in Android program-ming, an overview of the application that has been ported. The thesis willthen continue with a description of the views in the application and in theend, a conclusion and discussion for future work.

1.1 Problem and Motivation

Storing warranty receipts can sometimes be problematic. Receipts can belost, bleached and become illegible or in an extreme case, the storage area isdestroyed. A solution for the problem according to garantikoll.se[1] is to savethe warranty receipts online. One other advantage of the solution is, thatthe warranty receipts can be accessed from any computer with an internetconnection, by accessing the server the receipts are stored at.

The smartphone market is fragmented. And to address as many cus-tomers as possible, giving best device specific user experience, developmentto cover more platforms are needed. The Android OS platform is the nextlogical choice.

1.2 Goals and Criteria

This thesis has one main goal and some sub goals in order to solve theproblem.

2”Android is a trademark of Google Inc. Use of this trademark is subject to GooglePermissions.”

1

Figure 1.1: The market share of smartphones.

� The main goal is to successfully port the iOS application into the An-droid OS platform. The Android OS version, should have the samefunctionality as the iOS version and have a similar look. Some lay-out/design will differentiate from the iOS version since the two oper-ating systems provides different User Interface, UI. This goal is metif the Android application provides the same functionality as the iOSapplication does.

� The application code should follow the code practices for Java, and alsoseparate the business logic from the UI. The business logic should havea layered design and use interfaces, for more flexibility. This goal ismet if the code follows the code practices for Java and uses commonlyused design patterns.

� The last goal is that the application should be compatible with theAndroid OS version 2.1 or later. This will cover around 90% of themarket share for the Android OS[8]. This goal is met if the applicationcan execute and run successfully, on Android phones with OS versionsin the range of 2.1 to 2.3.4.

2

1.3 Outline

The remaining of the thesis is structured as following; Section 2 discussesbackground knowledge relevant for understanding the thesis. Section 3 dis-cusses architecture and design for the application, where the used patternswill be presented. Section 3 will also includes a description of the serverconnection, SOAP parsing, different activities used, and in the end someapplication specific solutions. Section 4 discusses the implementation of thedifferent views which will be presented with screenshots, description andsome implementation notes. This thesis will end with Section 5 discussingconclusions and future work.

3

2 Background

In this section we will give the reader some background for the thesis. Wewill introduce the involved companies, give an introduction to Android pro-gramming, present some implementation-variations. We conduct with a briefdescription of other platforms that are used on smartphones.

2.1 Garantikoll.se

Garantikoll.se is owned by Freck AB, founded in spring 2010. As discussedin Section 1.1, the business model of Freck AB is to provide a solution forcommon problems with the management of warranty receipts. The solutionis to let the user create an account on the webpage and upload/handle thereceipts there. Freck AB then ensures that the receipts will be stored in afuture-safe way using the garantikoll.se service.

Webpage/webserver

upload upload

upload

TakeImage

TakeImage

AndroidClient

iOSClient

WarrantyReceipt

Figure 2.1: The businessmodel.

4

At the webpage, after the user has logged in, she is able to put a newreceipt into a category, specify some attributes (due date, created, name, etc)and save it. The user is also able to view the receipts and rotate them.

The user can also access these warranty receipts from an iPhone using theiOS application (that can be downloaded from itunes.apple.com [12]). TheiOS application also let the user to take pictures of the receipts and uploadthem to the server.

2.2 Softwerk

Softwerk is a company which “offers software development, integration, andmanagement as well as IT consulting and training”[17]. Their developmentfocus stands in small and medium size enterprises. For the development partthey use Scrum, which is an iterative, incremental framework for projectmanagement, that’s used in agile software development. They also applythe standard ISE/IEC 9126 [18] which ensures high product quality. Thecompany also offers consulting and training in software quality managementand handling software projects. They also offers consulting and training intechnologies used in their projects, i.e. iPhone programming.

Softwerk developed the iOS client being an essential part of garantikoll.se.Porting the iOS application to the Android OS platform, allows garantikoll.seto make the service available for more customers.

2.3 Android Programming

In Android programming, the layout of the applications can be declared intwo ways[7]. The first is to declare UI elements in XML. The second way isto instantiate layout elements at runtime. The advantage of the first way isto separate the presentation of the application from the code that controlsthe behavior. It also enables the programmer to create different layoutsfor different screen sizes, languages, screen orientation etc. Sometimes thisapproach is not sufficient. There might be situations where the UI is builtdynamically. This could be, e.g., a table with a number of rows which is onlyknown at runtime.

When compiling the application, all XML layout files will be compiled intoa View resource. This is stored in the R.java file, which contains an index toall resources defined in the file. Inside the file, each component has a uniqueid. This id is then used to access the resource. From the application code, ifa resource is needed, it can be accessed in the form R.resourcetype.resourceid.Example 2.4, shows a TextView, which corresponds to a JLabel in the JavaSwing package, that we add a text to.

5

2.4 example

This example uses the declaration of UI elements in XML-files. First thedeclaration of the TextView needs to be done in the layout XML file for theapplication. This is done by adding the lines from Listing 1, to the layoutXML file.

<TextView android:id=”@+id/textViewIdandroid:layout width=”fill parent”android:layout height=”wrap content”

/>

Listing 1: A TextView in the layout XML file.

The attributes here are the id, which enables the programmer to refererto the view/component. The two layout attributes specifies the width andheight of the view. In this case the view should have the same width asthe parent view, and the same height as the content in the view. When theapplication compiles, an id is created in the R.java file and it could look likeListing 2.

6

public static final class id {public static final int textViewId=0x4c290000;}

Listing 2: The generated id for the TextView in the R.java file.

When the Activity is created in the application, it calls the onCreate method.To control the behavior (what layout etc that should be used), the activityneeds to override this method. How this is done can be viewed in Listing 3.

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

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

TextView myTextView = (TextView)findViewById(R.id.textViewId);

/* This sets a text to the TextView. */myTextView.setText(”Hello world!”);

/* This loads a String from the string−resources and sets the* text on the TextView to the loaded string.*/

myTextView.setText(getString(R.string.hello world string));}}

Listing 3: This code shows how to override the onCreate() method and loada resource from the layout XML file.

Listing 3 shows also how a string can be loaded from the resources. Byspecifying all the strings in a String XML file, it is easier for the programmerto maintain the program and change a specific string. This also helps theprogrammer with handling multiple languages, by having one XML file foreach supported language in a separate XML file.

7

2.5 Implementation-Variations

There is two highlevel types of applications for smartphones. The applica-tions can be native or developed as a web application.

The first type, native, enables the developer to develop an applicationwhich gets installed on the device. It will be possible for the applicationto access the hardware on the smartphone (if permission is granted). Thehardware can be, e.g., GPS, network access, modifying files on a disk, cameraetc. If the application does not use any network communication, it will bepossible to run it in an offline mode. The application will use disk spaceto store application data and the application itself, which might not be adesired effect.

The second type is a web application. This type of application is accessedover the network and executed in a web browser. The application does notneed any installation and is updated and maintained easily since the deviceswill download it every time it is used, hence the clients will always be upto date. It is also cross-platform compatible and therefor only one type ofclient is usually needed. Since the application is closs-platform, it might notbe possible to access the hardware as for a native client. It also requires theuser to have a network connection to be executed.

In this particular case, the native version was selected. The motivationfor this, is that the user should be able to use the application even if thereis no network connection, if the user is logged in and looses the networkconnection, it is still possible to use the application. The user should alsobe able to access the camera and store files on the phone. When this thesiswas written the requirements was that the user first needs to login to use theapplication. But a different workflow have been discussed and this alternativewould change that requirement.

2.6 Other Platforms

The Android OS platform is not the only major platform used on smart-phones. This thesis will very briefly describe four other platforms used onsmartphones.

2.6.1 iOS

The iOS is a mobile operating system created by Apple. iPhones are run-ning the iOS system along with the iPad and the iPod. For developing anapplication to the iOS platform, the Xcode IDE are provided by Apple. ThisIDE also simulates devices, which enables testing of the application without

8

access to a hardware device. If the developer wants to test the applicationon a actual device, she needs to be a registered apple developer[2].

Supported programming language is Objective-C, which is an object ori-ented programming language. The language is influenced by both Smalltalkand C. Distribution of applications are made through the App Store. Thisis similar to the Android market. One big difference between the App Storeand Android market is that, in the Android market, the applications can beadded as long as the developer has a developer account. There is no control ofthe contents of the application. For the App Store, the code is run through ascreening process, which guarantees a high standard of the application. Theconsequence of this is, that an application takes longer time to be uploadedto the App Store than to the Android market.

2.6.2 Symbian

Symbian OS is currently maintained by Nokia and is an operating systemintended for smartphones. It was bought from the software developmentcompany Symbian Ltd. in 2008. The programming language of choice fordeveloping to the Symbian OS is Symbian C++, which has been designed torun efficiently on devices with limited power and memory resources accordingto Nokia[16]. In 5th of April 2011, Nokia announced that Symbian will bereleased under a new license, which is a proprietary license[15].

2.6.3 BlackBerry

BlackBerry OS is used by BlackBerry devices and is developed by the Cana-dian company Research In Motion, RIM.

Developing for BlackBerry is possible using the proprietary APIs providedby RIM. The programming language supported of the platform is Java. Ifthe application needs to use restricted functionality, it must first be digitallysigned, which will then bind the developers account to the application. Bysigning the application, there is a guarantee of the authorship of the appli-cation. But compared to the iOS, there is no screening process of the sourcecode. For the user to access the applications, they will be accessed from theBlackBerry App World.

2.6.4 Windows Phone

The platform for a Windows Phone is called the Windows Phone Applica-tion Platform. This platform enables developers to create applications thatruns on a windows phone. It uses some tools and technologies provided byMicrosoft such as Visual Studio, Expression Blend, Silverlight and the XNA

9

Framework [13]. Supported programming languages are those who are sup-ported by the .NET framework, e.g. C#.

The Silverlight framework “is the ideal framework for creating Rich In-ternet Application-style user interfaces”[13]. It gives access to some featuressuch as event driven application framework, embedding video inside the ap-plication and HTML web browser controls. The controls also match thewindows phone visual style to improve the look and feel.

The XNA framework are intended to game developers. The frameworkprovides the essential technology, for professional developing of games onseveral platforms. These platforms are Windows 7, Xbox 360, Zune HDand Windows Phone. Games created with this framework are both 2D and3D games. According to Microsoft, the XNA framework provides a “highperformance game framework”[14].

Distribution of the applications created by developers, are made on theWindows Phone Marketplace.

10

3 Overview

This section will give the reader some overview for the application. It willstart with presenting the architecture and design used in the application.After that, the server connection and parsing of messages will be brieflydiscussed. Section 3.5 will show the different views in the application andhow they are connected. After that, different activities used in the applicationwill be described.

The three last subsections will describe how an image is uploaded to theserver (Section 3.7), how the differences between Android OS 2.1 and 2.2affects the application (Section 3.8) and lastly a brief discussion about therestrictions for the image caching (Section 3.9).

3.1 Architecture and Design

The application uses two types of software architecture patterns (except fromthe higher level client-server pattern). These are the Model-View-Controllerpattern (MVC) and the Layer pattern. The application consists of manyclasses representing the views. These are connected to the controllers (theServerController class). Both the views and the controller are using themodels (the entity classes). The ServerController class is the only controllerand are responsible for the server connection. See Figure 3.1 on how thislooks in the application.

ServerController

Views Models

Figure 3.1: A Model-View-Controller pattern.

These three elements are divided into three major packages, see Figure3.2. The ServerConnection, Views and Entities packages. The view packagecontains all the views, and is further divided into packages in regard to whattab (in the tabview) the view belongs to. The entity package contains allthe entity classes used in the application. This makes the code cleaner andeasier to extend.

The third package is the ServerConnection package. This package uses alayered design pattern which enables a clean interface towards the UI. It alsoabstracts the connection to the server, see Figure 3.3. In the first layer there

11

ServerConnection

Views

Entities

Server

se.softwerk.garantikoll.client.android

Figure 3.2: The package diagram for the Android client.

is the ServerController class. This class is Singleton, which mean that onlyone instance of this class can exist and the instance is accessed in a static way,ServerController.getInstance(). This enables the UI to easily use the class.On the second level there is an implementation of the IRequestDispatcherinterface. The class implementing the interface, will be responsible for theactual communication to the server. The class sends & receives messagesand sends the response to the next layer, layer three. This layer contains animplementation of the interface IRequestParser, which parses the responsefrom the server and handles the result. In those cases where user-data isreceived, the parser creates entity objects, and updates the ServerControllerwith the new data.

ServerControllerSingelton pattern.

IRequestDispatcherSends/receivesrequests to/fromthe server.

IRequestParserParses the responsefrom the server.

ServerConnection

Figure 3.3: The layers in the ServerConnection package with the responsi-bilities.

3.2 Server Connection

The server uses the SOAP protocol for the communication with the clients.The Android client relies on the server connection and fetches all the data

12

(except from cached images, see Section 3.7 for more details) from the server.For the application to have access to an internet connection, it needs tohave the internet permission. This is done by adding the permission to theAndroidManifest.xml file.

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

To access the webservice the client first need a valid username and pass-word. When this is sent to the server and a sessionkey is returned (if they arevalid). This sessionkey is stored and used when fetching data from the server(or uploading data). The sessionkey has a timeout and if this is reached, theapplication automatically refreshes the sessionkey.

3.3 SOAP

SOAP is a protocol used for Remote Procedure Calls (RPC), which is aninter-process communication for calling a subroutine to execute in anotheraddress space. This other address space is usually on another computer.SOAP uses HTTP requests. The protocol is used in e.g. webservices anduses Extensible Markup Language (XML) to format the messages.

A SOAP message contains of three parts[10], envelope, header and body.The envelope has two child-properties which is the header and the body. Thebody contains the data that is send. A sample SOAP message can look likeListing 4, where there is data in both the header and body. The header hassome attributes (priority, expires) and the body has one attribute (msg).

3.4 Parsing

The Android Software Development Kit (SDK) does not support any SOAPAPI. Therefore, the application needs to manually establish a connection tothe server using HTTP requests and parse the response.

The parsing uses different techniques depending of the request. The loginmethod basically searches for the session key, and if it is found, the parser setsthis value in the ServerController. If the key is not found, basically nothinghappens other than the user got notified of that the login was unsuccessful.

The parsing of the entity data, from the server, uses a DOM parser totraverse the XML string. The methods creates entity objects, representingthe data from the server, and returns an ArrayList< T > where T stands forthe object/entity type. These methods then sets the corresponding data inthe ServerController class, which will later be accessed from the UI. Lastly isthe response from the server when the application has uploaded an image to

13

the server. The parser basically searches for the new name for the image. Ifa name is found in the response, the method uses a callback-thread to handlethe result. This thread basically renames the file to the new filename andmoves it from the upload folder to the download folder (since the upload wassuccessfull).

<env:Envelope xmlns:env=”http://www.w3.org/2003/05/soap−envelope”><env:Header><n:alertcontrol xmlns:n=”http://example.org/alertcontrol”><n:priority>1</n:priority><n:expires>2001−06−22T14:00:00−05:00</n:expires>

</n:alertcontrol></env:Header><env:Body><m:alert xmlns:m=”http://example.org/alert”><m:msg>Pick up Mary at school at 2pm</m:msg>

</m:alert></env:Body>

</env:Envelope>

Listing 4: A sample SOAP message.

3.5 Garantikoll Android Client Navigation Overview

Figure 3.4 shows the three different activities that are first seen when switch-ing to a new tab. Note that for the preference tab, the logout view is visibleinstead of the login. This is since the receipt tab and my receipts tab are notvisible when the login view is active (the user is not logged in).

Figure 3.5 on page 23, describes the different views contained in each tab.When the tabview is shown, it is always possible to return from the currentview to the start-view for a tab (Figure 3.4). It is also possible to go to a“lower view level” by pressing the back button on the phone. For instance,if the user views my receipts level 3-1 and presses the back button, the userwill see the view my receipts level 2-1. The arrows in Figure 3.4 and Figure3.5 indicates where the user is able to navigate from a specific view.

3.6 Activities

One thing that differs Java Swing programming and Android smartphoneprogramming from each other. Is that instead of using the classes JFrameand JPanel to add child components to (as in Java Swing), a class called

14

Receipt tab

My receipts tab Preference tab

Figure 3.4: The client navigation diagram for the tabs.

Activity is used. In the documentation for the Android API the followingcan be read about the activity class.

“An activity is a single, focused thing that the user can do. Al-most all activities interact with the user, so the Activity classtakes care of creating a window for you in which you can placeyour UI with setContentView(View). While activities are oftenpresented to the user as full-screen windows, they can also beused in other ways: as floating windows (via a theme with win-dowIsFloating set) or embedded inside of another activity (usingActivityGroup)”[5].

15

The application uses one direct subclass and one indirect subclass of theActivity class. The indirect subclass is the TabActivity class (see Section3.6.1). In the implementation, the TabActivity class uses the direct subclassActivityGroup (see Section 3.6.2).

Activities in the system are managed in an activity stack. If a new activityis created, it is put on top of the stack and becommes a running activity.When that activity stops to run, it is poped from the stack and the previousactivity will run again. An Activity has a lifecycle which is illustrated infigure 3.6 on page 24. The figure shows what methods are called in differentevents/states of the activity. To control what happens for instance whencreating an activity, the onCreate() method can be overriden (see listing 3for an example). If some data needs to be stored when the user exits theactivity, it can be done by overriding the onDestroy() method.

3.6.1 Tab Activity

Another activity used in the implementation is the TabActivity class. Thisclass differs from the Activity class, in that way where this class holds mul-tiple activities in tabs. This means that it can run serveral embedded activ-ities inside it (and also ActivityGroups, see Section 3.6.2). A TabActivityhas three major parts.

� TabHost: This is a container for the tabbed window view. It holdstwo objects as children, the FrameLayout and TabWidget. This viewmust have the id android:id=“@android:id/tabhost”.

� TabWidget: The TabWidget is the list of tabs displayed in the Tab-Host, where one tab is representing a “page”. In the standard imple-mentation of a tab, it holds one ImageView and one TextView. Thiscan easily be changed and customized by defining a new layout in aXML file (as in this application). The TabWidget must have the idandroid:id=“@android:id/tabs”.

� FrameLayout: The second child of a TabHost is the FrameLayout.This is where the contents of each tab is rendered and displayed. Thelayout must have the id android:id=“@android:id/tabcontent”.

By setting different “layout weights” for the TabWidget and FrameLay-out, it is possible to display the tabs on the top of the TabActivity or on thebottom. In this application, the last is used.

16

3.6.2 ActivityGroup

An ActivityGroup is a direct subclass of the Activity class. This class holdsand runs multiple embedded activities. It can be described as an “activityof activities”. It shows one activity at a time and can dynamically change todisplay another activity. This is useful when the application needs to havemultiple activities in one tab (if using the TabActivity).

The class has one major drawback when used in the implementation.It does not know which previous activity was used. Therefore a new class,ExtendedActivityGroup, was created extending the ActivityGroup. This classhave five methods which manipulates the internal activity stack.

� startChildActivity(): Which starts a new child activity, puts in ontop of the stack and displays it.

� finishFromChildGoToStart(): This method finishes the current ac-tivity, removes all activities from the stack (except the last on index 0)and displays the that activity.

� finishFromChild(): The method basically destroys the current activ-ity, removes it from the stack and starts the topmost activity from thestack.

� restartActivity(): Since some activities might need to be restarted,this method destroys the current activity and starts it again.

� onBackPressed(): This method is called when the user presses theback button on the phone. The method fetches the current activity andcalls finish() on it. By calling the finish() method on an activity, it willbe closed and the parent activity is started again.

3.6.3 Camera - “Activity”

In the application, the user is able to take pictures using the hardware cam-era. This is implemented with two classes, ReceiptCameraActivity whichextends the Activity class, and ReceiptCameraPreview which extends theSurfaceView and implements the interface SurfaceHolder.Callback.

3.6.3.1 ReceiptCameraActivity

The ReceiptCameraActivity class is an activity with one FrameLayout (whichis displaying the camera preview) and a menu at the bottom. This menuconsists of buttons for different actions (retake, take picture, use etc). When

17

the user presses the “take picture” button, three callbacks are made fromthe Camera object. The first is a ShutterCallback which is the first callbackcalled when a picture is taken. The second callback is a PictureCallbackwhich contains the actual data for the image. The third callback is also aPictureCallback, which is called when a compressed version of the image isavailable, and contains the compressed data version.

Before the application can use the camera, the camera permission needsto be enabled. This is done by adding the following line to the AndroidMan-ifest.xml file.

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

3.6.3.2 ReceiptCameraPreview

The ReceiptCameraPreview class is responsible for displaying the preview ofthe camera. It extends the SurfaceView class which provides an embeddeddrawing surface inside a view hierarchy.

The class also implements the interface SurfadeHolder.Callback. By im-plementing this interface, the activity is able to receive information aboutchanges to the surface. The camera can then send the preview data to thisclass, which will then be displayed by the SurfaceView, and the user will beable to “see what the camera can see”.

3.7 Dataflow

This section will describe how a newly taken picture, is sent within the client,before the handling of it is finished. The flow starts when a user has takena picture using the CameraActivity class. A raw byte-array are stored asa plain bytefile in the application folder (all applications on the AndroidOS platform has an own folder where it can store files). This byte-arraycontains the data for the image. For the application to be able to write tothe filesystem it need the permissions for this. This is done by adding thefollowing line to the AndroidManifest.xml file.

<uses-permission

android:name="android.permission.WRITE_EXTERNAL_STORAGE"

/>

The file has a temporary filename, myFile, that will be used by the nextactivity, ReceiptSetDescriptionActivity. This activity is started when the userhas accepted the newly taken picture, and choosen to use it by pressing the“use” button. It is in this activity where the user sets a description for theimage. If the user presses the save button, three major things happens:

18

� The description will be the new name for the image.

� The image will be moved to a folder called “upload”.

� A broadcast is sent.

If the user does not press the save button, the image will be overwrittenthe next time the user takes a picture.

The upload folder contains all images that are not yet uploaded to theserver. When the broadcast has been sent, the receiver ConnectionReceiver,receives the broadcast and starts to work. The receiver checks if there is aninternet connection and if there are any files in the upload folder. This alsorequires a permission (to read the network state). To add the permission,the following line needs to be added to the AndroidManifest.xml file.

<uses-permission

android:name="android.permission.ACCESS_NETWORK_STATE"

/>

For each file in the folder, the receiver tries to upload the file to the server.If the file got uploaded successfully, the file is moved to the download folder.This folder contains all downloaded images (the result is that the applicationdoes not need to download each image, every time the application needsthe image). If the image was not successfully uploaded to the server, it willremain in the upload folder until a new try is made (when the same eventhappens with another image, or the phone regains connectivity).

The receiver also listens to changes in the network. If the phone loosesconnection and then the connection returns, the receiver does the same pro-cedure as when the first broadcast was sent. This makes the uploading ofimages automatic, and the user does not need to run the application manuallyto upload images to the server.

3.8 Android OS Version 2.1 Support

The first versions of the application was developed for Android OS version2.2 (API level 8). This was because the developer had a smartphone withthis OS version and could test the application directly. Since one of the goals(refer to Section 1.2) is to support Android OS version 2.1, two changes hadto be made.

The application used the Base64 class (from android.util.Base64), thatwas provided by the Android API. But this class was added on API level 8and since the Android OS 2.1 uses API level 7, the class could not be used (it

19

does not even exists). To solve this problem, a class from the Public Domainwas added[11], version 2.3.7, and worked as a good replacement.

The orientation of the camera on the Android phone, compared to thecamera preview, is rotated 90 degrees. The user will then experience a rotatedpreview which does not corresponds to how the user is holding the phone.To solve this orientation problem, the preview can from Android OS 2.2 berotated, by the calling the method “setDisplayOrientation(int degrees)” onthe camera object. Using an API level pre Android 2.2 (API level < 8), thisis not possible. The solution for this is quite comprehensive.

First of all the CameraActivity was set to the landscape screen orientation(all other activities have the portrait orientation). The menu and buttonswas then on the side and not at the bottom of the screen. To solve this, thebuttons was moved to the right side of the landscape screen. While holdingthe phone in portrait mode, the buttons will appear as “on the bottom ofthe screen”. The problem then, was that the text of the buttons was notrotated. The standard Android API library (API level 7) does not supportwriting text in a specific angle. The solution was then to create new classes,that extended the standard classes used (TextView and Button). And byoverriding the onDraw(Canvas canvas) method for those, and rotating thecanvas, it was possible to write text in a different angle.

3.9 Image Caching - Restrictions

Since the application caches the images used (see Section 3.7 for more de-tails), a restriction for the folder was made. The main reason is that the ap-plication shouldn’t use more space than necessary. Some testing was madefor the size of the images, and an “average” image was estimated to takearound 500kB of space. The cache was then set to 5MB as a default value.When the application checks if the limit is reached, it tries to read a Shared-Preference-value. If the value does not exists the default value is returned,else the preference values is returned. This simplifies future development forletting the user to set this value in some way.

There are two situations where the restriction can be compromised andneeds to be checked.

The first situation is when the user downloads a new image that is notalready stored in the cache. The application then first checks if the limit isreached, if it is reached, the application removes the oldest image until thetotal space is less than the maximum size. It then downloads the new imageand stores it in the cache. The last event is a new check again (in case thelimit was reached again).

The second and last situation is when the user has taken a new image

20

and the application uploads it to the server. Since the application does notdownload this image from the server, the first situation is not triggered. Thisproblem was solved by first uploading the new image, and then move it tothe download folder (see Section 3.7). After that a new control of the foldersize is made, in the same way as the first step in the first situation. Thisresults in that the download folder will never be bigger than the specifiedmaximum size plus the size of one image (the one newly taken).

3.10 Differences - Android vs. iOS

There are some differences between the Android version and the iOS ver-sion. The section will give the reader a brief overview of the most importantdifferences.

API Differences

There is one important difference between the two APIs. The iOS versionmakes use of a class called NSNotificationCenter [3]. The class provides a wayfor the developer to broadcast information within the system. For instancecan a server-connection, update information the UI makes use of, and the UIwill be able to display the updated data. Objects register to the notificationcenter to receive notifications. The following quote explains the flow when anotification is posted to the notification center.

“When an object (known as the notification sender) posts a no-tification, it sends an NSNotification object to the notificationcenter. The notification center then notifies any observers forwhich the notification meets the criteria specified on registrationby sending them the specified notification message, passing thenotification as the sole argument.”[3]

The notification center is quite lightweight. The Android OS API pro-vides a similar functionality for the developer. To communicate within anapplication in the Android OS platform, a broadcast is sent using an Intent(compare to the NSNotification class). If an activity shall listen to a broad-cast, it has to extend the BroadcastReceiver class[6]. Compare to the iOSNSNotificationCenter, where the object does not need to extend any class toreceive notifications.

Implementation Differences

There is a lot of differences between the implementation of the two versions.Mainly because the two platforms uses different coding practices and different

21

API. The most important differences are briefly described in the followinglist.

� Database storage

– iOS - Stores the data in a local database. The iOS platformprovides a database, with support for Object-relational mapping(ORM).

– Android - Have no support for ORM and uses a cursor techniqueinstead. Since there are at least three different data objects fromthe server, which have an internal dependency, a cursor solutionwould not be satisfying.

� Defining of layout

– iOS - Uses an interface builder to build the interfaces (availablein Xcode). The builder make use of an XML file, but compiles itto binary code.

– Android - There exists an interface builder in Android, but it isstill on an early stage and therefor, layouts are defined by havingthe developer composing the XML “by hand”.

� Flow of data

– iOS - Uses a lot of different states for the images. They have e.g.a state if they are uploaded or not and if they have an id or not.

– Android - Uses two folders for the images, one for uploaded im-ages and one for images that are queued for upload. Refer toSection 3.7 and 3.9 for a detailed description of the dataflow.

� Caching of images

– iOS - Caches the images on the disk, but have no maximum limitof the used space.

– Android - Cashes the images on the disk, but have a maximumlimit for the used space. If the space is consumed, the oldest imagewill be removed from the cache (oldest as in usage).

� Download of data

– iOS - Both versions uses asynchronous download of data from theserver. The iOS version downloads the data sequentially.

– Android - Since there are three different types of data that isdownloaded, these are downloaded asynchronous and in parallel.

22

Receipts tab My receipts tab Preference tab

Receipt level 1

Receipt level 2

Receipt level 3

Receipt level 4

My receipts level 1

My receipts level 2-1 My receipts level 2-2

My receipts level 3-1 My receipts level 3-2

Preferences - login

Preferences - logout

Figure 3.5: The client navigation diagram.

23

Figure 3.6: The lifecycle for an Activity. Taken from http://developer.android.com/reference/android/app/Activity.html.

24

4 Implementation

This section presents the different views in the application. For each viewthere will be a brief description of the view, a screenshot, list of files involved,the methods used of the web service API, and next the navigation from theview (what other views that an be accessed from the specific view).

Most of the views are using the serverconnection package and are there-fore omitted from the views. This holds for all the entity classes.

4.1 Preferences, Login

Figure 4.1: The login view.

25

Description

This is the first view the user will see after starting the application. Theuser needs to enter the username and password to access the rest of theapplication. If the user used the application before, and have not logged out,the application automatically fetches the username and password and logsin the user. The first and second tab are disabled as long as the user is notlogged in.

If the login succeeds, the application makes three parallel calls to theserver which fetches information about the receipts. After that, the othertwo tabs get enabled and the application automatically selects the first tab(tab “Receipt”). It also changes the layout for this tab to the preferences,logout view (described in Section 4.2).

If the login fails, the application notifies the user that the login failed,and the user will then be able to try again. There is no maximum numberof tries of login. The login can fail mainly of two reasons. The first is thateither the username and/or the password is wrong. The second is that thephone might not have an internet connection. This can be because of badreception, or disabled service from within the phone (the user have disablednetwork communication).

Files involved

PreferencesActivity.java, login activity.xml, button custom.xml.

Web Service API

public void loginUser(String username, String password);public void fetchCategories(String sessionKey);public void fetchItems(String sessionKey);public void fetchReceipts(String sessionKey);

Listing 5: IRequestDispatcher methods used.

Navigation

The user is not able to go anywhere before she has logged in, except fromexiting the application.

26

Figure 4.2: The logout view.

4.2 Preferences, Logout

Description

The logout view is only visible if the user is logged in to the system. This viewhas basically one action, which is to let the user logout from the application.This is done by pressing the “logout” button. If the user logs out from thesystem, the view will change to the preferences, login view (described inSection 4.1) and the other two tabs will be disabled.

This view also shows the current client version and what user is currentlylogged in.

Files involved

PreferencesActivity.java, login activity logged in mode.xml, button custom.xml.

27

Web Service API

public void logoutUser(String sessionKey);

Listing 6: IRequestDispatcher methods used.

Navigation

From this view the user is able to access the other two tabs by pressingthe desired one. The user is also able to access the preferences, login view(described in Section 4.1), by pressing the “logout” button.

4.3 Receipt, View Level 1

Figure 4.3: The first receipt level view.

28

Description

This is the first view the user will see after she has logged in successfully.This view describes how to take a picture (described by the background im-age) and what to do next. The view also shows the number of unhandledreceipts the user has. This view is the first view that is contained in the ac-tivitygroup, ReceiptTabGroup. See Section 3.6.2 for more information aboutactivitygroups.

Files involved

ExtendedActivityGroup.java, ReceiptTabGroup.java, ReceiptActivity.java, re-ceipt activity.xml, button custom.xml.

Web Service API

None.

Navigation

From this view the user is able to access the other two tabs by pressing thedesired one. The user is also able to access the camera view described inSection 4.4.

4.4 Receipt, View Level 2

Description

This view is the camera view. It shows a preview of what the camera cansee and it contains two buttons. One for cancel the “take picture action” (goback), and one for taking the actual picture. The view also differs from theother views in the way that this view uses the whole screen (the fullscreenflag is set). It is also the only view that uses the landscape mode instead ofthe portrait mode (see Section 3.6.3 and Section 3.8).

Files involved

ReceiptCameraActivity.java, ReceiptCameraPreview.java, RotatedButton.ja-va, RotatedTextView.java, camera activity.xml, silver rectangle.xml, button-gray custom.xml.

29

Figure 4.4: The second receipt level view.

Web Service API

None.

Navigation

The user is able to go to the previous view (Section 4.3) by pressing the“cancel” button or the hardware “back” button. The user is also able toproceed and take a picture by pressing the “take picture” button.

4.5 Receipt, View Level 3

Description

This view shows the current snapshot of the image taken. It is a preview be-fore the last view for taking pictures. It uses the same classes as the previous

30

Figure 4.5: The third receipt level view.

view (Section 4.4), but uses a different part of the camera activity.xml -filefor layouting.

Files involved

ReceiptCameraActivity.java, ReceiptCameraPreview.java, RotatedButton.java,RotatedTextView.java, camera activity.xml, silver rectangle.xml, button gray-custom.xml.

Web Service API

None.

31

Navigation

The user is able to go to the first view (Section 4.3) by pressing the “retake”button or the hardware “back” button. The user is also able to proceed andset a description for the picture by pressing the “use” button.

4.6 Receipt, View Level 4

Figure 4.6: The fourth and last receipt view.

Description

This is the last view for the creation of a new receipt on this client. In thisview, the user will enter a description and then press the “save” button toproceed. When this have happened, the image will be queued for uploadingand the user will be moved to the receipt level 4 view (described in Section

32

4.3). For a detailed description of the events, see the dataflow section (Section3.7).

Files involved

ReceiptSetDescriptionActivity.java, receipt set description activity.xml, but-ton custom.xml.

Web Service API

The following methods are used indirectly via the ConnectionReceiver class.

public void sendReceipt(byte[] data, String fileName, String sessionKey,ResultCallback resultCallback);

public void fetchCategories(String sessionKey);public void fetchItems(String sessionKey);public void fetchReceipts(String sessionKey);

Listing 7: IRequestDispatcher methods used.

Navigation

The user is able to go to the first view (Section 4.3) by pressing the “save”button or the hardware “back” button.

4.7 My Receipts, View Level 1

Description

This view is the first view for the second tab. It shows the categories theuser have specified and also a section for the new receipts (unhandled re-ceipts). This view is the first view that is contained in the activitygroup,ReceiptTabGroup.

Files involved

ExtendedActivityGroup.java, MyReceiptsTabGroup.java, MyReceiptsActiv-ity.java, my receipts activity.xml, rectangle whole.xml.

Web Service API

None.

33

Figure 4.7: The first my receipts level view.

Navigation

From this view the user is able to access the other two tabs by pressing thedesired one. The user is also able to go to a detailed view for a category (if ithas any items in it) or the new receipts “category”. This is done by selectingthe desired category.

4.8 My Receipts, View Level 2.1

Description

If the user has selected the “new receipts” category (Section 4.7), she willsee this view. It lists all receipts that has not yet been handled. This is thesecond view in the activity group used. The view uses the DateUtilTools-classto format the dates.

34

Figure 4.8: The new receipts list view.

Files involved

ExtendedActivityGroup.java, MyReceiptsTabGroup.java, MyReceiptsInfor-mationActivity.java, DateUtilTools.java, my receipts information.xml, my-receipts list row.xml, my receipts table row.xml.

Web Service API

None.

Navigation

From this view the user is able to access the other two tabs by pressing thedesired one. The user is also able to press on an item to view a detailedview for a specific receipt (see Section 4.9). The user is also able to go the

35

previous view by pressing the hardware “back” button.

4.9 My Receipts, View Level 3.1

Figure 4.9: The specific new receipt view.

Description

This is the last view for an unhandled receipt. It displays the image for thereceipt and when it was created. The user is able to zoom in/out on theimage.

Files involved

ExtendedActivityGroup.java, MyReceiptsTabGroup.java, MyReceiptsSpeci-ficReceiptActivity.java, specific receipt activity.xml.

36

Web Service API

public byte[] fetchImage(String sessionKey, String imageName);

Listing 8: IRequestDispatcher methods used.

Navigation

From this view the user is able to access the other two tabs by pressing thedesired one. The user is also able to press the hardware “back” button to goto the previous view.

4.10 My Receipts, View Level 2.2

Figure 4.10: The handled (category “Ovrigt”) receipt view.

37

Description

This view shows all the receipts for a specific category. The screenshot showsthe three receipts that belongs to the category “Ovrigt”.

Files involved

ExtendedActivityGroup.java, MyReceiptsTabGroup.java, MyReceiptsInfor-mationActivity.java, DateUtilTools.java, my receipts information.xml, my-receipts list row.xml, my receipts table row.xml.

Web Service API

None.

Navigation

From this view the user is able to access the other two tabs by pressing thedesired one. The user is also able to press on an item to view a detailedview for a specific receipt (see Section 4.11). The user is also able to go theprevious view by pressing the hardware “back” button.

4.11 My Receipts, View Level 3.2

Description

This is the last view for a handled receipt. It displays the image for thereceipt and when it was created, bought etc. The user is able to zoom in/outon the image.

Files involved

ExtendedActivityGroup.java, MyReceiptsTabGroup.java, MyReceiptsSpeci-ficReceiptActivity.java, specific receipt activity.xml.

Web Service API

public byte[] fetchImage(String sessionKey, String imageName);

Listing 9: IRequestDispatcher methods used.

38

Figure 4.11: The specific (receiptname “Bulle”), receipt view.

Navigation

From this view the user is able to access the other two tabs by pressing thedesired one. The user is also able to press the hardware “back” button to goto the previous view.

39

5 Conclusion and Future Work

This section will give the reader a conclusion of the work and product. Itwill also compare the product with the goals, and briefly discuss if they aremet or not. The section will end with a subsection of suggestions for futurework. It will present suggestions on what can be done, and if there are anyproblems or preparations made for the suggestion.

5.1 Conclusion

This section will present the conclusion of the thesis and after that, presentsome suggestions for future work. The general goal of porting the application,from the iOS platform to the Android OS platform, has been successfully met.It has been solved by meeting the goals presented in the Goals and Criteriasection (Section 1.2).

The application provides the same functionality as the iOS version, whichhas been confirmed by extensive testing. Some design differs between thetwo versions and the Android client has been adapted to conform with theAndroid paradigm. The differences are presented in Figure 5.1. Instead ofthe top-left back button in the iOS client, the hardware back button is usedin the Android version. The three tabs also have a different design. This isbecause the Android SDK provides a tabview that is different from the oneprovided by the iOS. It has been customized to fit the blue theme better.

The second goal was to fulfill code practices for Java and to separate thebusiness logic from the UI. The code conforms with the code practices andseparates the business logic from the UI since the UI uses the serverconnec-tion-package to communicate with the server. The serverconnection packageis also well documented and uses well defined interfaces between the layers.

The last goal was to support Android OS version 2.1 to 2.3.4. Testinghas been done within this range in an emulator and is considered successful.The application has also been tested on a real device, a HTC Desire withAndroid OS version 2.2, and the application works to it is full extent on thisdevice.

5.2 Future Work

An alternative workflow for taking a image have been discussed. The currentimplementation requires the user to first login, and then the applicationdownloads some data, and after that the user will be able to take an image.The alternative workflow is to login and download the data, in parallel toactivate the first tab and let the user take an image. If the user wants to

40

(a) (b)

Figure 5.1: An image showing the differences between 5.1(a) the Android OSclient and 5.1(b) the iOS client.

access the second or third tab, he/she has to wait for the login and downloadto finish. If this workflow will be changed, the will probably be minor changes(if any) in the serverconnection package to support this.

There is one other “problem” that need to be handled. In the first viewlevel for tab 1 (see Figure 4.3), there is a yellow label at the bottom thatdisplays the number of unhandled receipts. This data is fetched from theserver after the user has been logged in. If the label will be displayed beforethe data is downloaded it needs to be stored. I suggest the number of un-handled receipts will be stored with the SharedPreferences-class[9] and savedwith the Activity.onDestroy() method.

The application always downloads all the data from the server to ensure itis up to date. This takes time and unnecessary transfer of data. A solutioncould be to hash all the users data, and store this on both the client andserver. The data also needs to get stored on the client. After the login, theclient can send the hash to the server, and if the hash is not equal, the server

41

sends all the data back.The webpage www.garantikoll.se have changed design during this thesis,

and there is a possibility that the design of the Android client need to beupdated accordingly.

Since the application only been tested on one physical device, it wouldbe interesting to test it on more devices. Preferred on devices with differentCPU speed and network connections.

42

References

[1] Freck AB. garantikoll.se. http://www.garantikoll.se/, March 2011.

[2] Apple. ios dev center. http://developer.apple.com/devcenter/ios/index.action, May 2011.

[3] Apple.com. Nsnotificationcenter class reference. http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSNotificationCenter Class/Reference/Reference.html, July2011.

[4] Pettey C. and Goasduff L. Gartner says worldwide mobile device salesto end users reached 1.6 billion units in 2010; smartphone sales grew72 percent in 2010. http://www.gartner.com/it/page.jsp?id=1543014,February 2011.

[5] Google.com. Activity. http://developer.android.com/reference/android/app/Activity.html, March 2011.

[6] Google.com. Broadcastreceiver. http://developer.android.com/reference/android/content/BroadcastReceiver.html, July 2011.

[7] Google.com. Declaring layout. http://developer.android.com/guide/topics/ui/declaring-layout.html, March 2011.

[8] Google.com. Platform versions. http://developer.android.com/resources/dashboard/platform-versions.html, March 2011.

[9] Google.com. Sharedpreferences. http://developer.android.com/reference/android/content/SharedPreferences.html, April 2011.

[10] M. Gudgin, M. Hadley, and N. Medelsohn. Soap version 1.2 part1: Messaging framework (second edition). http://www.w3.org/TR/soap12-part1/, March 2011.

[11] Robert Harder. Something sun should have included long ago. http://iharder.sourceforge.net/current/java/base64/, April 2011.

[12] Apple Inc. Garantikoll klient for iphone. http://itunes.apple.com/se/app/garantikoll-klient-for-iphone/id386575823?mt=8&ls=1, March2011.

[13] Microsoft. Application platform overview for windows phone. http://msdn.microsoft.com/en-us/library/ff402531(v=VS.92).aspx, May 2011.

43

[14] Microsoft. The silverlight and xna frameworks for windowsphone. http://msdn.microsoft.com/en-us/library/ff402528(v=VS.92).aspx, May 2011.

[15] Nokia. Not open source, just open for business. http://symbian.nokia.com/blog/2011/04/04/not-open-source-just-open-for-business/, April2011.

[16] Nokia. Symbian c++. http://www.forum.nokia.com/Develop/OtherTechnologies/Symbian C++/, May 2011.

[17] Softwerk. Softwerk. http://softwerk.se/index.php, April 2011.

[18] Wikipedia. Iso/iec 9126. http://en.wikipedia.org/wiki/ISO/IEC 9126,August 2011.

44

351 95 Vaxjo / 391 82 KalmarTel 0772-28 80 00dfm@lnu.seLnu.se/dfm