Bookfriend report

UNIVERSITY OF MANCHESTER School of Computer Science

Third Year Project Report

Where did this book come from?

Carrie Louise Hall

Internet Computing BSc

May 4th 2011

Supervisor: Dr Alvaro A A Fernandes

Mobile phones and smartphones are now ubiquitous in everyday life and the new and innovative aspects of the web are finally able to be realized on mobile devices. Bookfriend is a mobile phone mashup application developed for Android that creates a companion guide to any book and allows users to find out information about books and explore other books that they may enjoy.

Carrie Louise Hall Chapter 1 | Page 2

Acknowledgements I would like to thank my friends and family, whose continuous support and encouragement helped

me throughout.

I would also like to thank the various developers who work on the APIs used within the project,

especially James Schellenberg from Bibliotravel who gave me full unlimited access to their data.

Most importantly I would like to thank my supervisor Alvaro Fernandes who has supported me and

given me confidence throughout the project, as well as inspiring and contributing to the application

itself.


Table of Contents

Acknowledgements ................................................................................................................................. 2

Table of Contents .................................................................................................................................... 3

List of Figures .......................................................................................................................................... 7

Chapter 1. Introduction to the project ................................................................................................... 9

1.1 The Project .................................................................................................................................... 9

1.1.1 Application features ............................................................................................................... 9

1.2 Previous work................................................................................................................................ 9

1.3 Objectives...................................................................................................................................... 9

1.4 Success Criteria ........................................................................................................................... 10

1.5 Report Structure ......................................................................................................................... 10

Chapter 2. Background ......................................................................................................................... 11

2.1 Mashups ...................................................................................................................................... 11

2.1.1 Challenges of mashups ........................................................................................................ 12

2.2 Web Services and APIs ................................................................................................................ 13

2.2.1 SOAP ..................................................................................................................................... 13

2.2.2 REST ...................................................................................................................................... 14

2.3 Android ....................................................................................................................................... 16

2.3.1 Overview .............................................................................................................................. 16

2.3.2 Architecture ......................................................................................................................... 17

2.3.3 Features ............................................................................................................................... 17

2.3.4 Applications .......................................................................................................................... 18

2.3.5 Android location services ..................................................................................................... 20

2.3.6 Versions ................................................................................................................................ 21

2.4 Current mashup examples .......................................................................................................... 21

2.4.1 Book Mashups ...................................................................................................................... 21

2.4.2 Android Mashups ................................................................................................................. 22

Chapter 3. Requirements ...................................................................................................................... 23

3.1 General Description .................................................................................................................... 23

3.1.1 Product perspective ............................................................................................................. 23

3.1.2 Product functions ................................................................................................................. 23

3.1.3 User characteristics .............................................................................................................. 25

3.1.4 Assumptions and dependencies .......................................................................................... 25


3.2 Specific requirements ................................................................................................................. 25

3.2.1 External interfaces ............................................................................................................... 25

3.2.2 System requirements ........................................................................................................... 25

3.2.3 Performance requirements .................................................................................................. 25

3.2.4 Usability requirements ......................................................................................................... 25

3.2.5 Reliability requirements ....................................................................................................... 26

3.2.6 Supportability requirements ................................................................................................ 26

3.2.7 Speed Requirements ............................................................................................................ 26

3.3 Data sources & APIs .................................................................................................................... 26

3.3.1 List of data sources .............................................................................................................. 26

3.3.2 Diagram ................................................................................................................................ 28

3.4 Summary ..................................................................................................................................... 28

Chapter 4. Design .................................................................................................................................. 29

4.1 Developing for mobile devices .................................................................................................... 29

4.1.1 Hardware considerations ..................................................................................................... 29

4.1.2 Android Best Practices ......................................................................................................... 29

4.1.3 Compatibility ........................................................................................................................ 31

4.1.4 Screen Types ........................................................................................................................ 31

4.1.5 Android User Interface Guidelines ....................................................................................... 32

4.1.6 Guidelines used within bookfriend ...................................................................................... 32

4.2 Designs for bookfriend ................................................................................................................ 33

4.2.1 Logo and icon ....................................................................................................................... 33

4.2.2 Font ...................................................................................................................................... 34

4.2.3 Wireframe ............................................................................................................................ 34

4.2.4 Photoshop design................................................................................................................. 35

Chapter 5. Implementation ................................................................................................................... 36

5.1 Development Process ................................................................................................................. 36

5.1.1 Development environment .................................................................................................. 36

5.1.2 Agile Development ............................................................................................................... 37

5.1.3 Phases of development ........................................................................................................ 38

5.2 Architecture ................................................................................................................................ 41

5.2.1 Project hierarchy .................................................................................................................. 41

5.2.2 Package diagram .................................................................................................................. 42

5.2.3 Core components class diagram .......................................................................................... 42


5.2.4 Helper components class diagram ....................................................................................... 43

5.2.5 Android classes .................................................................................................................... 43

5.3 Object-oriented design ............................................................................................................... 44

5.3.1 Design Patterns .................................................................................................................... 44

5.4 Implementation Details .............................................................................................................. 48

5.4.1 Retrieving data from a data source ..................................................................................... 48

5.4.2 Searching for a book ............................................................................................................ 49

5.4.3 Finding book locations ......................................................................................................... 50

5.4.4 Ensuring data quality ........................................................................................................... 51

5.4.5 System reliability and fallback ............................................................................................. 52

5.4.6 Graceful degradation ........................................................................................................... 53

5.4.7 Cleaning data ....................................................................................................................... 53

5.4.8 Ensuring compatibility across devices ................................................................................. 54

5.5 Improving the user experience ................................................................................................... 55

5.5.1 Finding one particular book ................................................................................................. 55

5.5.2 Speed of results .................................................................................................................... 56

Chapter 6. Final result ........................................................................................................................... 59

6.1 Walkthrough ............................................................................................................................... 59

6.2 Application release ..................................................................................................................... 67

6.2.1 Android statistics.................................................................................................................. 67

6.2.2 Google Analytics ................................................................................................................... 67

6.2.3 Survey ................................................................................................................................... 67

Chapter 7. Testing ................................................................................................................................. 68

7.1 Testing Methodology .................................................................................................................. 68

7.1.1 Testing environment ............................................................................................................ 68

7.1.2 Verification and Validation .................................................................................................. 69

7.1.3 Testing Strategy ................................................................................................................... 69

7.2 Tests undertaken ........................................................................................................................ 70

7.2.1 Incorrect user input ............................................................................................................. 70

7.2.2 ISBN validation ..................................................................................................................... 70

7.2.3 Scan barcode ........................................................................................................................ 70

7.2.4 Web-service failure .............................................................................................................. 70

7.2.5 Web connection unavailable ............................................................................................... 70

7.2.6 Web-service missing data .................................................................................................... 70


7.2.7 Reliability of all APIs ............................................................................................................. 70

7.2.8 Retrieval of books ................................................................................................................ 70

7.2.9 Frequency of results ............................................................................................................. 71

7.2.10 Operating system ............................................................................................................... 71

Chapter 8. Conclusions ......................................................................................................................... 72

8.1 Project Achievements ................................................................................................................. 72

8.2 Lessons learned ........................................................................................................................... 72

8.3 Further work ............................................................................................................................... 72

8.4 Final Remarks .............................................................................................................................. 73

Glossary ................................................................................................................................................. 74

Appendix 1. BookListAdapter................................................................................................................ 78

Appendix 2. Overlay for book locations ................................................................................................ 79

Appendix 3. Image fallback ................................................................................................................... 81

Appendix 4. XML layout for main screen .............................................................................................. 82

Appendix 5. AsyncTask example ........................................................................................................... 83

Appendix 6. BookmoochHelper class .................................................................................................... 84

Appendix 7. Android statistics .............................................................................................................. 86

Platform version ................................................................................................................................ 86

Device ................................................................................................................................................ 86

Country ............................................................................................................................................. 87

Appendix 8. Google Analytics ............................................................................................................... 88

Top Content ...................................................................................................................................... 88

Screen Resolution ............................................................................................................................. 88

Visitor Loyalty.................................................................................................................................... 89

Map Overlay ...................................................................................................................................... 89

Appendix 9. Survey ............................................................................................................................... 90

Appendix 10. Survey results .................................................................................................................. 92

Appendix 11. Google API test class ....................................................................................................... 95

Appendix 12. Testing results ................................................................................................................. 96

Appendix 13. Project Plan ..................................................................................................................... 98

References ............................................................................................................................................ 99


List of Figures

Figure 1: Types of mashup on Programmable Web.............................................................................. 12

Figure 2: SOAP example of querying a phonebook application............................................................ 13

Figure 3: REST example of querying a phonebook application ............................................................ 14

Figure 4: A more complex REST query .................................................................................................. 14

Figure 5: XML representation of a ‘File’ menu ..................................................................................... 15

Figure 6: JSON representation of a ‘File’ menu .................................................................................... 16

Figure 7: Graph showing the percentage of mobile subscribers since October 2009 .......................... 16

Figure 8: Android component stack diagram ....................................................................................... 17

Figure 9: Calling an Activity ................................................................................................................... 18

Figure 10: Some of the Views used within Android .............................................................................. 19

Figure 11: XML resources in Android .................................................................................................... 19

Figure 12: Diagram representing the major components of an Activity .............................................. 20

Figure 13: Android MapView with customized Overlay ....................................................................... 20

Figure 14: Timeline of Google Android SDK versions ........................................................................... 21

Figure 15: Use case diagram for the bookfriend application ................................................................ 24

Figure 16: APIs used and functions they perform ................................................................................ 28

Figure 17: Application Not Responding (ANR) dialog ........................................................................... 30

Figure 18: How the Android platform maps screen densities and screen sizes ................................... 31

Figure 19: Launcher icons used by Android book applications ............................................................ 33

Figure 20: The bookfriend logo ............................................................................................................. 33

Figure 21: The bookfriend launcher icons ............................................................................................ 33

Figure 22: A menu screen and home screen and with the bookfriend launcher icon displayed ......... 34

Figure 23: Font used in the bookfriend application .............................................................................. 34

Figure 24: Wireframe design................................................................................................................. 34

Figure 26: Version 1 of the interface design ......................................................................................... 35

Figure 25: Final design of the interface ................................................................................................ 35

Figure 27: The AVD Manager’s Available Packages panel which shows SDK components .................. 36

Figure 28: Agile development process .................................................................................................. 37

Figure 29: Packages used within the bookfriend application ............................................................... 42

Figure 30: Core components class diagram .......................................................................................... 42

Figure 31: Helper components class diagram ....................................................................................... 43

Figure 32: Android classes .................................................................................................................... 43


Figure 34: Diagram to show how the Façade separates the application from the interface ............... 46

Figure 33: The code to create the BookMashup Façade class within the application ......................... 46

Figure 35: Adapter pattern in the bookfriend application ................................................................... 47

Figure 36: Diagram representing the Observer pattern ....................................................................... 47

Figure 37: The bookfriend customized list view ................................................................................... 48

Figure 38: Entering a book .................................................................................................................... 49

Figure 39: Diagram to show barcode scanning ..................................................................................... 49

Figure 40: Android MapView for searching books by location ............................................................. 50

Figure 41: Marker images for displaying book locations, publisher location and author birthplace ... 50

Figure 42: Activity diagram showing flow of Twitter data .................................................................... 51

Figure 43: Images retrieved from the Bookmooch, Goodreads, and Google API (shown to scale) ..... 52

Figure 44: List of options with no 'Movies' option ............................................................................... 53

Figure 45: Diagram showing XML layout for bookfriend main screen ................................................. 55

Figure 46: Class diagram of the BookmoochHelper and ApiConnector class ....................................... 58


Chapter 1. Introduction to the project This chapter will give an introduction to the aim and objectives of the project, and highlight work

undertaken in the subject area.

1.1 The Project

The proposal for this project was to develop an Android mobile mashup application that creates, on-

the-fly, a companion guide to any book. It is a mashup application which means the information is

retrieved from several web resources about books, such as reviews, characters and synopses, and is

presented to the user as a concise and homogeneous source. These resources may be professionally

written but the primary source of information will come from user-generated data.

1.1.1 Application features A list of terse high-level system features are often included as part of an introductory Vision

document to a project [1]. Usually these lists are less than 10 items and highlight the noteworthy

features of a project from a user’s point of view.

The Android application, named bookfriend, allows a user to:

Read book plots, quotes and genres

Read book reviews

Explore the author information including biography, images of the author and other books

Find tweets about the book, film adaptations and awards won

Find characters and places mentioned within a book

Explore other books by genre, publisher and location

Scan barcodes of books

1.2 Previous work

The project builds from a similar project done several years ago for a web platform, but the flexibility

of the project allowed for different motivations and results. Using a web platform it is possible to

display a lot of information of varying quality whereas on a mobile device it is important that the

information about a book is generally correct, as there is limited screen size and connection speed.

1.3 Objectives

The main objectives of the project were to:

1. Create a useful Android application that finds previously unknown information about any

book including:

o Author information

o Book reviews and other feedback

o Exploration of other books

2. Release the bookfriend application for public use in order to gather feedback from real

users.


1.4 Success Criteria

The following list of criteria is used to rate the success of the bookfriend application:

The application can be installed from the Android market onto any Android device.

The application allows users to search for books and provides some information about any

given book.

The application satisfies the functional and non-functional requirements specified in this

document.

1.5 Report Structure

Chapter 1 discusses the aims and objectives of the project.

Chapter 2 explores the technologies used within the project and some examples of existing

applications.

Chapter 3 provides the detailed requirements of the project and lists the data sources.

Chapter 4 is involved in the graphical design of the application by following best practices.

Chapter 5 explains the details of the implementation and structure of the application and project.

Chapter 6 demonstrates the application with screenshots.

Chapter 7 discusses the testing approaches and techniques, the tests undertaken and the results of

these tests.


Chapter 2. Background This chapter gives the context of the application by discussing what mashups are, why they are

popular, and how they are created. It also provides background knowledge about the Android

platform and presents some examples of mashups both on the web and on mobile devices.

2.1 Mashups

The term ‘mashup’ originates in music and is used to describe remixing songs to create new pieces

of work [2].

IBM define mashups as “an exciting genre of interactive Web applications” [3] that combine

complimentary information from multiple sources [4] and present it in a new and innovative way. It

is this unique presentation that makes mashups valuable rather than the data itself [5].

The fundamental steps undertaken to create mashups are [6]:

1. Extract data from a source web site

2. Translate data into a meaningful format

3. Send data to destination source

The data obtained for use in a mashup is typically obtained from publicly available (and often free)

web services, XML feeds, or screen-scraping.

Maps are the most common form of mashup (see Figure 1). Housingmaps1 is an example of a

mashup which uses a Google map to display properties for sale or rent. These properties are

retrieved from a website called Craigslist2, which is an online community containing classified

advertisements.

Mashups have been labelled as the fastest growing eco-system on the web [7] because of the

combination of the rapidly increasing number of web services published by content providers and

the number of mashups made available using these services. In 2010 the growth of APIs doubled;

mainly with the introduction of new social networking APIs such as Facebook creating an API for

their data and Twitter inspiring developers to develop APIs based on sentiment analysis and social

networking.

Often mashups are developed to solve a problem, which may explain why they are popular with

general web users. Some examples of this include DealMine3 which mashes up data from several

discount and reward sites into a comparison shopping API, and Busalert4 which is a real-time tracker

service for bus tracking in Kings County, Washington.

1 http://www.housingmaps.com

2 http://www.craigslist.com

3 http://www.dealmine.com

4 http://www.busalert.me


ProgrammableWeb5 is a directory of mashups and APIs. It contains nearly six thousand mashups

with an average of 2.8 mashups being added every day. Mapping mashups (i.e. mashups that use

maps as a way of displaying data) account for 33% of these. The diagram in Figure 1 shows the

breakdown of mashups listed on ProgrammableWeb.

Figure 1: Types of mashup on Programmable Web

A study of Programmable Web mashups show that mashup developers tend to build mashups from

a small number of popular services rather than a wide range of specialized functions [2].

2.1.1 Challenges of mashups Mashups raise new challenges and problems that need to be considered [8] such as the lack of

standardized approaches to architecture and design. Developers have cited the following problem

areas with mashups; namely data quality, the reliability of the API, documentation, coding details,

legality and semantic meaning [9].

Data quality This is arguably the biggest challenge that mashup developers face when creating a mashup and

refers to the data accuracy and completeness as well as semantic meaning, i.e. the real-world

meaning of a phrase or word [10]. An example of this is when finding results for the search term

‘apple’. This term is ambiguous and without any contextual information it is impossible for a mashup

to determine if the user is looking for information regarding the company or the fruit. This problem

is amplified in a mashup as data is not usually pre-processed or stored by the mashup creator.

API reliability Reliability refers to problems with authentication and performance degradation, as well as a reliance

on the API creator’s priorities and decisions for future development as the operations available may

not be sufficient. Changes to an API that are not backwards-compatible (e.g. the removal of an

operation) will cause disorder within a mashup that relies on this functionality.

Documentation The lack of documentation within APIs is apparent. The reason for this could be that it is expected

that the user of an API is an expert, that is, they are developers that know how to program

applications and know what the general function of the API is [11]. To learn an API, sometimes the

only source available is the documentation written by the API creator. Examples of working code is a

good way to inform users how to call particular functions and is a feature desired by mashup

developers [9].

5 http://www.programmableweb.com


Coding details There can be a large learning curve to develop tools that work with APIs, regardless of the language

the application is implemented in. Mashups compile data from many different sources which can

increase the complexity in the code, both for each individual API and when integrating the sources.

Legality Web services and APIs come with terms and conditions of use that can vary dramatically. Often it is

in the conditions of a free API that the services created using the data must be available to

consumers free of charge as well. This raises questions about the profit potential of mashups that

rely on these APIs. Often advertising is included in order for developers to profit from mashup

applications, including ‘mapvertising’ which is placing sponsored ads onto map screens [12]. Other

terms of use include the need to include a company name or logo on any screen that data from that

service appears (Goodreads include this in their terms) or that data from competitors is prohibited

on the same page . More specific terms can also be provided such as not requesting data more than

once a second, or not storing data for more than 24 hours (if allowed at all). These terms can be very

restrictive to mashup developers.

2.2 Web Services and APIs

The data that powers mashups often comes from Application Programming Interfaces (APIs). Web

APIs facilitate data exchange between applications by providing an interface to request data and

retrieve a response [4]. Many major companies such as Google, Amazon and eBay have provided

free APIs to their data [2].

2.2.1 SOAP Simple Object Access Protocol (SOAP) is an XML-based protocol for exchanging information and is

used within web services [13]. A SOAP message must have a root Envelope element and contain a

Body element. It can also contain a Header element to describe application-specific information

such as authentication. It is platform and language independent and is a W3C recommendation.

In the SOAP example in Figure 2 the task is to query a phonebook application for the details of a

user. The user id is provided and the type of request (GetUserDetails) is an application specific XML

element. The rest of the request is used to declare the message as a SOAP message and to declare

unique namespaces.

Figure 2: SOAP example of querying a phonebook application

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body pb="http://www.acme.com/phonebook">

<pb:GetUserDetails>

<pb:UserID>12345</pb:UserID>

</pb:GetUserDetails>

</soap:Body>

</soap:Envelope>

Application

specific

elements


2.2.2 REST Nowadays it is more common to develop web services and APIs by using Representational State

Transfer (REST). REST is an architectural style for distributed web applications and provides a set of

constraints and principles [14, 15]. REST services are focused around resources, which are unique

and global (e.g. a URI in HTTP), and communication between client and server to identify and

manipulate these resources. The constraints and principles of REST are [15]:

1. REST architecture must be a client-server architecture to promote separation of concerns

between the user interface and data storage, and also allows components to scale

independently.

2. REST architecture is stateless so each request must contain all the necessary information to

fulfil the request as no session state is stored. This improves the reliability and scalability of

the architecture.

3. REST architecture can utilise a cache to improve network efficiency.

4. REST architecture has a uniform interface between components which is more efficient for

use on the Web as information is transferred in a standardised format rather than an

application-specific one.

5. REST architecture is layered to further improve independence and scalability as clients are

not aware of which server or cache they are connected to.

A RESTful web service uses these principles of REST over HTTP and is a collection of resources with a

defined URI and set of operations. These CRUD operations in HTTP are GET, PUT, POST and DELETE.

The GET operation (read) is the most common and has no side-effects on the data. The client

initiates requests using these operations and a response can be sent back in several formats, usually

XML or JSON.

REST is more lightweight than SOAP and it can be argued that there is no functionality that web

services using SOAP can achieve that REST cannot [16].

Many APIs use REST, including Amazon, Twitter and Flickr. It has the advantage of being simple to

implement in any language, is scalable, and is platform and language independent.

The previous example of querying a phonebook looks a lot more straight-forward using REST as it

does not require any of the XML elements required to process a SOAP request. In essence, a REST

request is a URI to a desired resource.

http://www.acme.com/phonebook/UserDetails/12345

Figure 3: REST example of querying a phonebook application

A GET request is sent to this URL and is easy to test by entering the URL into a browser.

More complex queries are made easily by appending parameters to the URL, e.g.

http://www.acme.com/phonebook/UserDetails?fName=John&lName=Doe

Figure 4: A more complex REST query


XML As previously mentioned, REST responses can be in XML. XML is a meta-markup language for text

document markup [17] and is a way of improving informational structure and adding meaning to

data, and can be validated. Furthermore, parsers can be used to interpret the information stored in

XML which can be used to translate information from a document into aspects of an application.

The following code example is an XML document for a File menu within an application. Data is

specified in the form <tag>value</tag>. XML is hierarchical and needs to be properly nested. In

this example there are three items - new, open and close - and each item contains a title and an

action.

Figure 5: XML representation of a ‘File’ menu

JSON Another response format popular with web mashups is Javascript Object Notation (JSON), the “fat-

free alternative to XML”. JSON is a data-interchange format that is both human and machine

readable [18]. It uses familiar programming conventions but is language independent and the data

structures are supported in all modern programming languages and is supported directly in

Javascript [19] .

It is built on name/value pairs of ordered lists of values, e.g.

"key": "value"

Lists can be specified by replacing the value with a set of data enclosed in square brackets ([])

which in itself can contain lists of data. Complex and deep structures of information still appears

lightweight and readable. However, there is much contention in the web community about the

human readability aspect of JSON [20]. It is argued that JSON is not as readable as XML as the syntax

is familiar only to developers. The counter-argument to this is that human readability should come

secondary to the ease of processing.

<?xml version="1.0" ?>

<root>

<menu>File</menu>

<commands>

<item>

<title>New</value>

<action>CreateDoc</action>

</item>

<item>

<title>Open</value>

<action>OpenDoc</action>

</item>

<item>

<title>Close</value>

<action>CloseDoc</action>

</item>

</commands>

</root>


The following JSON construct representa the same File menu previously discussed in XML. Each item

is distinguished by using syntax similar to an array; the square brackets are used to specify a list of

items which contain a title and an action. Individual list elements are separated by a comma.

Figure 6: JSON representation of a ‘File’ menu

2.3 Android

2.3.1 Overview Android is an open source software stack that includes the operating system, middleware, key

applications, and a set of libraries to assist application development [21]. Android provides an open

alternative to traditional smartphones with proprietary operating systems and developers can take

full advantage of the open source framework and powerful SDK libraries [21]. It is this openness

which make Android compelling for developers [22] as the data on the device (such as contacts and

text messages) are easily retrievable using the frameworks provided.

Android now has the largest percentage of mobile subscribers. Figure 7 shows the growth of mobile

subscribers over the last year and a half.

Figure 7: Graph showing the percentage of mobile subscribers since October 2009

{

"menu": "File",

"commands": [

{

"title": "New",

"action":"CreateDoc"

},

{

"title": "Open",

"action": "OpenDoc"

},

{

"title": "Close",

"action": "CloseDoc"

}

]

}


2.3.2 Architecture The components of Android are designed as a stack; the bottom layer is the Linux kernel and the top

layer contains the applications.

Figure 8: Android component stack diagram

Image available from: http://developer.android.com/images/system-architecture.jpg

2.3.3 Features There are many built-in features to Android and it is out of the scope of this project to list them all.

However some of the features that are related to the development of the bookfriend application

include:

Framework APIs for location-based services such as GPS

Map controls within applications including geo-coding

Multimedia hardware control, including recording with the camera

Background applications and processes

SQLite Databases

Many of these functions, such as Google Maps and background services, are not found in other

mobile operating systems.


2.3.4 Applications Android applications are written using Java and XML. The architectural essence of Android

applications is as follows [21]:

Activity Manager

o To control the life cycle of Activities

Views

o The user interfaces for Activities

Notification Manager

o A mechanism to pass messages to the user unobtrusively

Content Providers

o For sharing application data

Resource Manager

o To store non-code resources like strings and graphics

Manifest file

o Presents essential information about the application to the Android system such as

the package name, components, permissions required and libraries used.

Activities Activities are the building blocks of Android and form the basis for all of the user interface screens

[21] by creating a windows in which the UI elements are placed by using a View. Each activity must

be registered with the application by declaring it in the application manifest. Moving between

Activities requires creating an Intent with the name of the class that needs to be loaded, and the

calling the startActivity( ) method to run the new Activity.

Intent intent = new Intent(this, SignInActivity.class);

startActivity(intent);

Figure 9: Calling an Activity

Another way to start an Activity is to use the startActivityForResult( ) method which takes

an extra integer parameter to distinguish where the Activity was called from. This is useful in many

scenarios, for example if an Activity can be started to edit data as well as add data then the integer

can represent the action that needs to be performed. Further to this, an integer representing the

result is passed back to the calling Activity once the new Activity ends.


Views Views are XML-based layout files and are linked with Activities to create a user interface screen.

Android provide many basic types of View including ListView, RelativeLayout, LinearLayout

and GridView.

Figure 10: Some of the Views used within Android

A full list of the Android Views is available at:

http://developer.android.com/resources/tutorials/views/index.html

Resources To maintain separation of concerns, non-code resources are separated from the rest of the code.

Non-code resources include strings, colours, animations and themes but Android allows custom XML

resources to be externalised as well. Resources are kept in separate XML files, e.g. colors.xml. It is

easier to maintain and modify external resources, and allows different resources to be applied in

different circumstances. Strings are of particular importance as externalisation allows easy

localisation of an application into other languages. Some examples of resources in Android are

shown in Figure 11.

Figure 11: XML resources in Android

<string name="app_name">bookfriend</string>

<color name="beige">#ede8dd</color>

<style name="LargeText">

<item name="android:textSize">20sp</item>

</style>

http://developer.android.com/resources/tutorials/views/index.html


Diagram of an Android application

Figure 12: Diagram representing the major components of an Activity

2.3.5 Android location services One of the major features of Android is the availability of the Google Maps API. To create a map in

an application, developers can make use of the MapView layout shown in Figure 13. Maps can be

customized to show marker items by using an Overlay. A GeoPoint is formulated from a longitude

and latitude value of a particular location. To attach a GeoPoint to an Overlay, an OverlayItem

is used which is a collection containing a GeoPoint and a message that can be displayed when the

item is clicked. The Overlay can also specify the type of image, called a Drawable, which should be

used to display the marker.

Figure 13: Android MapView with customized Overlay

XML Resources

XML Layout

Java code


2.3.6 Versions Google often release updates to the Android SDK regularly. At the start of this project the version of

Android was 2.1 (revision 2) and it was updated several times during the course of the project. The

timeline shown in Figure 14 shows the various releases of Android that were encountered during the

project lifespan.

Figure 14: Timeline of Google Android SDK versions

2.4 Current mashup examples

2.4.1 Book Mashups

Shelfari Shelfari was launched in 2006 and is now owned by Amazon. The creator of Shelfari describes it as a

social media site focused on people that read books [23] and it allows people to list book titles, write

reviews, recommend books to friends and find like-minded bibliophiles. Its primary data source is

Amazon, and gains revenue by using Amazon’s affiliate program to link users of the site back to

Amazon to buy the book.

Oct 2009: 2.0 released

May 2010: 2.1 revision 2

Dec 2010: 2.3 released

Mar 2011: 3.0 released

January 2010: 2.1 released

July 2010: 2.2 released

Feb 2011: 2.3.3 released


Reading Radar Reading Radar takes the New York Times bestseller list data and mashes it with Amazon information

in order to provide the most amount of information about this list of books in one place.

2.4.2 Android Mashups Programmable web only has 16 mashups listed under the Android category, and none of these

relate to books.

IceCondor IceCondor is a GeoRSS feed reader for Android which combines location

data with a Google Map. The data can be retrieved from several social

networking sites, or feed URL’s can be manually added. Markers are then

added to the map and users can click on the marker to see the event.

AroundMe This mashup also uses location as a main theme but

AroundMe identifies the user’s position and allows

users to search for local businesses such as banks or

restaurants. It gathers images from Flickr and

Panoramio, videos from YouTube and information

from Wikipedia.


Chapter 3. Requirements This chapter documents both the functional and non-functional requirements of bookfriend, and

specifies the data sources used to retrieve information.

The following section relating to requirements will be formatted according to the IEEE-Std 830-1993

structure which provides a list of topics that should be included in a Software Requirements

Document. It is a generic specification and can be adapted easily to a wide range of projects. A

requirements document is used to describe the services and functions of a system and the

constraints under which the system must operate [24].

3.1 General Description

3.1.1 Product perspective

Hardware The application will run on Android powered devices.

Software The application will be written in Android version 2.1.

Note: There were major differences between Android v1 and v2 and the decision was made not to

support devices that used the v1 SDK. This decision was made as Android publish the percentage

of users that use each of the versions of the SDK and less than 12% of devices use v1.6 or lower.

Memory The application requires up to 3mb of space once installed.

3.1.2 Product functions

Scenario A scenario is a set of actions that represents a path through the system [1]. Often they are more

helpful to end-users and stakeholders than function lists as they are easier to relate to [25]. A

success scenario for bookfriend is as follows:

The user navigates to the application and loads it. They type in a book keyword and press ‘go’. They

are shown a list of books and select the one that they want to read about. They are shown some

basic information about the book such as the book image, author, plot summary and overall rating.

From there they can explore more detailed information such as reviews and characters. The books

that they explore are saved into a list so that can be retrieved at a later date.


Use case diagrams A use case diagram is used to show the high-level functionality of the system. The features in Figure

15 show the features present at the end of implementation.

Figure 15: Use case diagram for the bookfriend application


3.1.3 User characteristics The users of the bookfriend application are not known explicitly so a wide range of users must be

considered. This includes users of all age ranges and technical ability.

3.1.4 Assumptions and dependencies It is assumed that the device has enough memory to store the application and run it, and that the

device has not been modified in any way that might make it difficult to emulate. The bookfriend

application also assumes that a web connection is available as without a connection the application

cannot function.

3.2 Specific requirements

3.2.1 External interfaces Name of item: Barcode scanner

Description of service: To allow the user to scan a barcode of a book

Source of input: The camera on the user’s device

Accuracy: Provided that the barcode is a valid ISBN, it should be 100% accurate

Timing: It should not take more than 3 seconds to find the ISBN once the camera has found

the barcode

Other information: If the barcode scanner is not installed, the user must be prompted to

install it.

3.2.2 System requirements 1. The application shall allow users to search for books by author, title, ISBN or keyword

2. The application shall allow the user to scan a barcode

3. The application shall validate all user input to ensure that it can be used within the

application

3.2.3 Performance requirements 1. The application shall return a response to a search for a book in under one minute

2. There shall not be any memory leak during the application running state

3. Any time-consuming tasks shall be run on the background thread

4. The application shall respond to user interactions within 1 second

3.2.4 Usability requirements 1. The application shall be developed based on Google’s user interface guidelines

2. During time-consuming tasks, an animated loading icon shall be shown to show the user that

the application is processing

3. The application must show informative messages to the user if any errors or problems occur

4. The interface must be consistent across the different screens within the application

5. The screens within the interface must not take more than 5 seconds for a new user to

understand

6. The system shall allow the user to remove books from their recent books list


3.2.5 Reliability requirements 1. The application shall function as expected when there is an internet connection of any speed

2. The application shall have 95% reliability, i.e. will not fail

3.2.6 Supportability requirements 1. The application shall run on Android 2.1 and above

2. The interface for the application shall be able to be translated into other languages

3.2.7 Speed Requirements 1. Initial loading should be no more than 3 seconds for the splash page, which should be

cancellable on click

2. Response time should be no more than 2 minutes when loading data on a 3G connection

3. Response time should be no more than 1 minute when loading data on a wireless

connection

3.3 Data sources & APIs

During the early stages of this project it became clear that there was a lot of information about

books available from various sources, and there was some overlap in the data provided. It was

decided to integrate many sources in order for the system to gracefully degrade, so that if there is a

failure to connect to a source the application will still function.

Note: The Amazon API is an obvious source of book information and is missing from the

bookfriend application, but as of December 2010 it is not permitted to be used on mobile devices.

For more information see the Amazon Product Advertising API terms and conditions available at:

https://affiliate-program.amazon.com/gp/advertising/api/detail/agreement.html

3.3.1 List of data sources

Google Books

Google provide a data API which does not require authentication and includes full-text searches for

books and retrieves book information, ratings and reviews [26]. It returns book data in XML format.

Bibliotravel

Bibliotravel is a website which combines books and travel in order to find books that are written

about a particular place. It relies heavily on user input for this information and so the list of books is

not comprehensive but it is steadily growing. Bibliotravel do not have a data API but the developers

were contacted and they provided an RSS feed of all the locations of books with links to the books

themselves. This made the website accessible to a parser without needing to use screen-scraping.

Goodreads

Goodreads is a social networking site for readers. Their API requires a developer key and restricts

requests of the API to one per second. Additionally, the Goodreads name or logo must appear on

any location where their data appears, and data cannot be stored for more than 24 hours. The API

provides book, author information and reviews in XML or JSON format.

https://affiliate-program.amazon.com/gp/advertising/api/detail/agreement.html


LibraryThing

LibraryThing is also a social networking site for readers. The APIs are extensive and include tools to

cross reference books, so given an ISBN it is possible to find the title and vice versa. The API requires

a developer key and limit usage to 1000 requests per day. It contains a wide variety of information

about books and authors that is not found in other sources, such as the author place of birth, awards

won, author education history, and quotations from the book.

Bookmooch

The only restriction when using the API for Bookmooch is the limit of 10 requests per second. The

site is a community for exchanging used books and uses Amazon’s Product Advertising API for some

of its data. Along with book information, the API provides lists of users who want or have the book

to ‘mooch’. The results are in XML format.

ISBNDB

The ISBNDB project is a database of books intended to be used for research by expert individuals,

libraries and scientists. The data is heavily cross-linked which allows traversal between authors,

publishers and subjects very easily by changing the response formatting variables used in the

request.

Twitter

Applications that use the Twitter API need to register and receive a developer key. The API is quite

extensive but the for context of this application only the ‘search’ API will be used to find tweets

relating to books or authors. The guidelines for using Twitter content state that the name of the user

who posted the tweet needs to be included and that the content of the tweet must not be modified

in any way.

Flickr

Similar to the Twitter API, the Flickr API contains a large range of functions but only the ‘search’

function for photos is used for this application. The search function allows a free text search and

returns results in XML or JSON format.


3.3.2 Diagram The following diagram (Figure 16) shows the APIs used related to the functions that are present in

the bookfriend application.

Figure 16: APIs used and functions they perform

3.4 Summary

This chapter specified the requirements and features of the bookfriend application, as well as

listing the data sources used to gather information about books for use in the application.


Chapter 4. Design The Design chapter will discuss the issues that are raised when developing mobile applications, and

discuss the Android guidelines and best practice for application design. The chapter will also review

the designs for the bookfriend application.

4.1 Developing for mobile devices

4.1.1 Hardware considerations Developers for desktop or web applications in recent years have gradually moved away from the

idea that hardware is the bottleneck for applications, as hardware is increasingly powerful and less

expensive. Although there are advanced capabilities of mobile devices including accelerometers,

GPS, Wi-fi connectivity, touch-screens and environmental sensors, they are still limited in

comparison to desktop computers due to the size of the device and inability of upgrades. Mobile

devices generally have [21]:

Low processing power

Limited RAM

Limited permanent storage capacity

Small screens with low resolution

High costs associated with data transfer

Slow data transfer rates with high latency

Unreliable data connections

Limited battery life

Low-specification To combat some of these potential problems, developers must be aware and optimize code as much

as possible so that applications run quickly. At the start of this project, Android applications were

only installed to the internal phone memory and did not allow applications to be installed to an SD

card, so applications needed to be as small as possible when compiled. However, Android recently

updated their SDK to allow this so compiled size is less of an issue.

Low connection speeds Mobile devices have an unreliable connection and a wide range of connection speeds [27]. In this

respect, the portability of mobile devices is both a blessing and a curse to mobile developers.

Applications should ensure that if network connections are essential, they will respond within a

suitable time. Furthermore applications should be able to handle losing connections in the middle of

a process [21].

4.1.2 Android Best Practices Android provide several areas that they believe should be the main considerations for an Android

developer, and this includes guidelines on design best practices. These areas are performance,

responsiveness and seamlessness.


Performance Designing for performance ensures that applications are fast and do not waste battery life. The

guidelines that Android provide to improve performance are:

Avoid creating unnecessary objects – garbage collection has a direct impact on user

experience

Make methods static if there is no need for access to an object’s fields – this makes

invocations 15-20% faster

Avoid getters/setters – instance field lookups are much less expensive than virtual method

calls

Use ‘double’ rather than ‘float’ where possible

Use enhanced for-loop syntax, e.g.

public void loop( ) {

int sum = 0;

for ( Foo a : mArray ) {

sum += a.mSplat;

}

}

Responsiveness Responsive applications are those that do not feel sluggish, take a long time to process input, or

freeze for a significant time. If an application does not respond to an input event within 5 seconds

then the Android system will show an Application Not Responding (ANR) dialog (shown in Figure 17).

Figure 17: Application Not Responding (ANR) dialog

If the application has time-consuming background processing, to avoid ANR applications should

show users that progress is being made, e.g. by using a ProgressBar.


Seamlessness Applications should interact seamlessly with the Android system. To do this developers should:

Bear in mind that mobile devices are prone to changes in activity at any time, e.g. if a phone

call is received. Applications need to save their data and state in such an event

Use threading to perform expensive tasks, Android provide an AsyncTask for this purpose

Keep screens to a minimum, i.e. do not overload a screen

Use system themes where possible in order to maintain consistency across applications

4.1.3 Compatibility The range and number of Android devices available means a potentially huge audience for

applications [28]. The manifest file of an application can specify the minimum requirements of an

application so devices that do not meet the requirements will not be able to download the

application from the Android Market. As previously mentioned, new versions of Android are

released regularly. Android commit to protecting applications developed for older versions so that

they are ‘future-proof’.

4.1.4 Screen Types Applications should be intuitive and easy to use when developing an application for a small screen.

This can be achieved by reducing the number of controls and prioritizing the most important

information.

Device screen sizes are separated into the following categories:

Small

Normal

Large

Xlarge

Screen densities are split into these categories:

ldpi (low)

mdpi (medium)

hdpi (high)

xhdpi (extra high)

Figure 18: How the Android platform maps screen densities and screen sizes

Image available from: http://developer.android.com/guide/practices/screens_support.html

http://developer.android.com/guide/practices/screens_support.html


In Android it is possible to provide custom resources, such as images, depending on the screen size

or screen density. Screen density is based on screen resolution and refers to the spread of pixels

across the physical width and height of the screen. UI elements on low density screens will appear

larger than on higher density screens.

It is important to ensure that all of the layouts used within each screen of the application will scale

successfully on differently sized devices. This can be achieved in the XML layouts by following these

basic principles:

1. Do not specify dimensions of elements in pixels, rather use wrap_content or fill_parent

2. Use density or resolution specific resources

3. Avoid AbsoluteLayout as it enforces fixed positions

4. Use density related pixel sizes for text size

4.1.5 Android User Interface Guidelines

Icon Design Android provides some guidelines for designing launcher icons to represent applications on the

Home screen. Icons should be:

Front-facing and top-lit

Clean and contemporary

Simplified and appropriate for small screens

Feature a part of an application as a symbolic representation

Feature non-glossy, textured material

Android provide images for use in Activities, menus and list items. To ensure consistency, these

images should be used where possible.

4.1.6 Guidelines used within bookfriend The bookfriend application was written aligned with the guidelines set out earlier in this chapter.

Different resources were used to account for multiple screen types, and layouts were generally

RelativeLayout styles which allowed proper scaling of elements. The following baseline

assumptions were made to ensure the bookfriend application reached the largest amount of users:

1. The network connection is slow

2. The devices do not have a touchscreen or keyboard

3. The battery life is short

Using these principles ensures that the application can cope with the ‘worst case’ scenario.


4.2 Designs for bookfriend

4.2.1 Logo and icon The logo was designed early in the development process and adheres to Android’s icon guidelines.

The idea behind it came from the need to show a book to represent the purpose of the application.

Other book applications on Android often show an image of a book and it was desired to have an

icon that is unique. Some examples of icons used by other books are shown in Figure 19:

Figure 19: Launcher icons used by Android book applications

Figure 20: The bookfriend logo

The launcher icons shown in Figure 21 provide an example of how different icon sizes can be

provided to scale up and down as necessary. These icons represent the application on the home

screen.

Figure 21: The bookfriend launcher icons


Figure 22: A menu screen and home screen and with the bookfriend launcher icon displayed

4.2.2 Font The font used for the logo is Colaborate-Bold which is an OpenType font.

Figure 23: Font used in the bookfriend application

4.2.3 Wireframe 1. User enters a book title, ISBN or author

2. The system will display the most likely book to the user. In the case of more than one book a

list of multiple books will be shown.

3. The system will show results to the user, with some information shown and the rest

separated into high level sections.

Figure 24: Wireframe design


4.2.4 Photoshop design The first design for the application has many of the same features that are found in the current

version. The theme was brown and beige to connote the idea that the application was about books,

and titles were used to separate items of information. The design was updated to make it more

readable and usable by including a home button, making the background lighter, increasing the line

spacing and minimising the information displayed on the main screen.

Figure 26: Version 1 of the interface design Figure 25: Final design of the interface


Chapter 5. Implementation The implementation section will discuss the development process and how the work was divided into

iterations. It then highlights the design of the code itself following coding best practices and utilising

design patterns. Detailed discussion of some more complex implementation is explored and finally

the project architecture is shown in order to demonstrate how the system components are

connected.

5.1 Development Process

5.1.1 Development environment The Android SDK was installed which comes bundled with an AVD manager tool (Figure 27: The AVD

Manager’s Available Packages panel which shows SDK components ) which allows downloading of

multiple platform versions (frequently used for testing) as well as samples and documentation.

The project was developed using the Eclipse IDE with an Eclipse plugin called the Android

Development Tools (ADT). The ADT plugin gives developers a fully integrated environment within

Eclipse to create and build Android applications, which includes creating user interfaces, adding

Android framework components using custom XML editors, debugging applications and exporting

.apk files for distribution.

Figure 27: The AVD Manager’s Available Packages panel which shows SDK components


5.1.2 Agile Development At the beginning of the project it was decided that an agile approach would be more beneficial than

a traditional approach for several reasons, namely:

1. There was a high learning curve for Android and using web APIs

2. The likelihood of requirements changing was very high as sources of book data are

frequently updated and added

3. The external environment is very fast paced; this refers to updates to the Android SDK,

frequency of new applications on the Android market, and changes to the terms and

conditions of use for data.

Agile development is a method of building software following fundamental principles and accepts

the idea that changes in projects are common [29].It is ideally suited to small teams that have no

fixed upfront requirements.

There are many agile methodologies and common guidelines include [29]:

Focus on completing features rather than tasks

Work with change instead of preventing it

Documentation is secondary to working functionality

Time-boxing can be used to ensure work is prioritised

This project was split into several phases which were tracked using Basecamp6, an online project

management tool which allowed flexible milestones and to-do lists.

Figure 28: Agile development process

6 http://basecamphq.com/

Requirements

Design

Implementation

Review

http://basecamphq.com/


5.1.3 Phases of development Before each iteration, informal planning was undertaken using a whiteboard and the development

time was estimated. Often the features were developed independently of the overall project so

there was no instability within the application.

Phase 1: Book Input In this phase the initial Android application is set up and the functionality to search for books in

multiple ways is developed

Iteration 1: Beginning APIs

The Google Books API is examined using a Java project with the aim of understanding how to send a

request and obtain results from the API.

Iteration 2: Book Input Phase

This phase is the beginning of the Android implementation and involves setting up several screens

which allow the user to type in the name of a book and have a list of books presented to them by

using the Google Books API code previously written.

Iteration 3: Find Books by Location

The Bibliotravel feed of locations are geo-coded and mapped using a Google Map view in the

Android application.

Iteration 4: Scanning Phase

The ZXing Android library for scanning barcodes is added and integrated into the Android

application.

Phase 2: Gathering Book Data Using a Java project, the different APIs are integrated into a set of basic re-usable components.

Iteration 1: Core Components

Creation of basic components are implemented such as Book, Review and ImageGallery.

Iteration 2: Google integration

Book information from Google is integrated into core components.

Iteration 3: Goodreads

Information from Goodreads is integrated into core components.

Iteration 4: Flickr API

Information from Flickr is integrated into core components.


Phase 3: Integrating Book Data At this point we have some information about books which needs to be moved to the Android

application. During this phase a bridge is created between the API connectors and the screens. To

separate the components, the façade design pattern is used to create a single point of contact

between the two sub-systems.

Iteration 1: Integration

All the core components are added to the Android project and tested to ensure data is still

retrievable.

Iteration 2: Façade

A BookMashup is created with functions to call the API classes. From this point on no calls to the API

classes are made from within the Android classes.

Iteration 3: Calling the Façade

The screens which were previously filled with dummy data are populated with information from the

APIs, called through the BookMashup.

Iteration 4: Testing

The application is tested on a wide range of books in order to locate and correct any bugs with the

Android layouts or the back-end functionality.

Phase 4: Performance enhancing The code is evaluated to ensure that it will run quickly and follows best practices.

Iteration 1: Background processes

Time consuming API calls are moved onto background threads so that the user interface does not

hang when data is being retrieved. The data is then fed in as it becomes available meaning the time

the user has to wait for some data is greatly reduced.

Iteration 2: Refactoring

During this iteration the project is refactored to ensure that there is no duplicated or unused code,

and any repeated information is abstracting into hierarchies.

Iteration 3: Book Input

This phase includes validating ISBN numbers and matching the most likely book to the keyword that

the user entered, rather than displaying a list of books.


Phase 5: Integration of more APIs More APIs can be added easily to the project at this stage, as the hierarchy is established and fully

working, so new APIs simply need a list of elements to retrieve and a place on the screens to display

the data.

Iteration 1: LibraryThing API

Information from LibraryThing is integrated into core components.

Iteration 2: BookMooch API

Information from BookMooch is integrated into core components.

Iteration 3: Data fallback

Several sources contain the same information so the system should use other sources if one is not

available.

Phase 6: User Interface At this stage there Is a lot of information about books and a number of screens which are tidied up to

ensure consistency and evaluated to make sure they are intuitive.

Iteration 1: Analysis

The screen designs were examined and the flow through the screens edited if necessary.

Iteration 2: Ensure consistency

The menu bars, text spacing, margins and buttons must be consistent across screens.

Iteration 3: User feedback

When a background task is being undertaken the user needs to be informed by unobtrusive means

such as loading images.

Phase 7: Integration of more APIs The addition of more APIs is undertaken. As every API is added, the screens are coded to the same

standard as the refactored code, designed to be compatible with the other screens, and tested to

ensure no inconsistencies surface.

Iteration 1: Twitter API

Information from Twitter is integrated into core components.

Iteration 2: ISBNDB API

Information from ISBNDB is integrated into core components.


5.2 Architecture

5.2.1 Project hierarchy Bookfriend src

bookfriend

Contains the Activities within the Application

adapters

Contains Adapters for binding data to screens

barcode

Contains classes to integrate the barcode scanner

core

Contains basic classes such as Book, or Tweet

helpers

Contains API connector classes

isbn

Contains classes to validate ISBN

gen

Created by Android automatically when built and contains just one file, R.java, which

is an index to all of the resources contained within the application.

assets

Contains the font used for the bookfriend title

lib

Contains external libraries used by the bookfriend application

res

drawable

Contains images that are independent of screen type

drawable-hdpi

Contains images for high-definition screens

drawable-ldpi

Contains images for low-definition screens

drawable-mdpi

Contains images for medium-definition screens

layout

Contains the layout XML files for each Activity

menu

Contains the menu XML files

values

Contains XML files for non-code resources

AndroidManifest.xml

The Manifest file for the bookfriend application.


5.2.2 Package diagram The following diagram (Figure 29) show the packages used in the bookfriend application. The size of

the packages in the diagram demonstrate the relative size of each package within the code.

Figure 29: Packages used within the bookfriend application

5.2.3 Core components class diagram These components are provide the base for the application and are independent from the Android

functionality.

Figure 30: Core components class diagram


5.2.4 Helper components class diagram

Figure 31: Helper components class diagram

5.2.5 Android classes A class diagram is not appropriate to demonstrate the Android classes because each one represents

a screen and they do not communicate with each other. Rather, the next diagram (Figure 32)

explains the flow of screens within the application. The yellow stars represent screens that contain a

custom adapter which will be explained in the next section.

Figure 32: Android classes


5.3 Object-oriented design

5.3.1 Design Patterns Design Patterns are a named and well known problem/solution pair for any programming context

[1]. Named patterns are powerful and succinct yet connote a lot of information [30] and help

developers with various levels of experience to communicate easily. One of the important things to

note about design patterns are that they do not provide exact implementation details, rather they

change the way developers think about problems by providing a set of principles.

These principles are called General Responsibility Assignment Software Patterns (GRASP) and are

based upon patterns of assigning responsibility, which help developers to understand object design.

The ‘Gang of Four’ (GoF) patterns are a set of 23 named design patterns which build on GRASP

principles.

This next section will first highlight some the GRASP principles that apply to the development of the

bookfriend application, and continues to discuss GoF design patterns that were used.

Chapter 4 of this report highlighted some Android guidelines for developing responsive and efficient

applications and some of these guidelines contradict those set out by the GRASP principles. The

Android guidelines were favoured over these principles when they were in direct contradiction.

GRASP principles

Information Expert A class should be given responsibility only when they have the information necessary to fulfil the

responsibility.

Creator Only assign class B the responsibility to create class A when:

B contains / aggregates A

B records A

B closely uses A

B has the initialising data for A

Low Coupling Dependencies and links between classes should be kept to a minimum so that changes to code make

less impact.

High Cohesion Each class should be focused on one task so that they are easier to understand and maintain.

Polymorphism When alternative behaviours are present for a class, assign responsibility using polymorphic

operations that implement a common interface.


Pure Fabrication Create fabricated classes to interface with real-world concept classes when necessary to keep

coupling low and cohesion high.

Indirection Assign intermediate objects the responsibility to mediate between components in order to keep

coupling low.

Protected Variations Identify points of variation and provide stable interfaces around them. Also known as Information

Hiding.

GoF design patterns

Façade Façades are a common unified interface to a disparate set of classes or subsystems [1]. By using the

Façade Pattern a complex subsystem can be accessed though a single, easy-to-use interface.

Singleton Façades are often accessed via the Singleton pattern and ensures that only one instance of an object

is created. In Java this can be ensured by making the constructor private so that instances of the

class cannot be instantiated. It moves away from the idea that objects need to be passed around and

instead can be accessed globally without creating multiple objects. To do this, the method to return

the singleton must be static and it can be synchronised so it is thread-safe.

Adapter Adapters are used to resolve incompatible interfaces by using Polymorphism to provide a stable

interface.

Observer The idea of separation of concerns aims to keep the application logic separated from the user

interface. The Observer pattern “defines a one-to-many dependency between objects so that when

one object changes state, all of its dependents are notified and updated automatically” [31].


Decisions for the bookfriend application

Façade The BookMashup is a Pure Fabrication and was created as a Façade created using a Singleton and

promotes Indirection and Low Coupling between the GUI classes and the core components.

The Facade class calls various methods from within the Helper classes to get information about

books. It also performs some more complex functions to organise the data, which keeps the API

classes Highly Cohesive.

An interesting point to note, is the generic Façade pattern encourages lazy initialisation which means

that the instance is not created until it is requested. Lazy initialisation is preferred as it avoids

expensive creation work if the instance is never actually accessed. However, eager initialisation was

used for the bookfriend application for the following reasons:

1. The BookMashup instance will always be needed.

2. In eager initialisation an there is no check if the instance is null.

Figure 34: Diagram to show how the Façade separates the application from the interface

private static BookMashup instance = new BookMashup( );

/* Gets the bookmashup instance */

public static BookMashup getInstance( ) {

return instance;

}

private BookMashup( ) {

}

Figure 33: The code to create the BookMashup Façade class within the application


Adapter The API class hierarchy is an example of the Adapter pattern. All of the classes are subclasses of

APIConnector, which is focused on creating and maintaining a connection to a data source. This

leaves the API classes solely responsible for parsing the response ensuring all classes are Highly

Cohesive and guarantees Protected Variations.

Traditionally the class names should include ‘Adapter’, i.e. ClassAdapter. However, Adapters are

used within Android as a bridge between data and the graphical interface and for this reason the API

classes were named ‘Helper’, as shown in Figure 35.

Figure 35: Adapter pattern in the bookfriend application

Observer In the bookfriend application the Android Adapter classes are examples of the Observer pattern

which are Highly Cohesive and provide Protected Variations.

Figure 36: Diagram representing the Observer pattern

An example of an Adapter using the Observer pattern is for the generation of the list of books

when a user enters a keyword. It is possible in Android to simply attach an ArrayList of elements

to a BaseAdapter.


In the bookfriend application more customization was required so that the layout could include a

book title, author name, and book image as shown in Figure 37.

Figure 37: The bookfriend customized list view

Before the user enters a keyword, the ListView element below the text box is empty. Once they

send their request, a loading image is shown and the request to the Google Books API is made on a

background thread using Android’s AsyncTask. Once the list of books is retrieved and converted

into an ArrayList, an event is published to tell the system that the activity has completed which

prompts the ArrayList to be bound to the ListView.

The full code listing for an adapter is in Appendix 1.

5.4 Implementation Details

In this section more details about various aspects of the application will be discussed.

5.4.1 Retrieving data from a data source Android does not provide any classes for an application to retrieve data from a web source.

However, as Android is written in Java, it was possible to utilise other Java classes, in this case

HttpUrlConnection, in order to open connections and retrieve data. The connection to a data

source is made only in the APIConnector class mentioned in the Adapter Design Pattern section

earlier in this chapter. The URLs to connect to are found within the subclasses of APIConnector

and are passed into the superclass, which opens a connection to the URL provided using the

openConnection method. Next, the details of the connection are attached which include the read

and connect timeout in milliseconds and the type of HTTP request required which in this case is GET.

The connection is then madr.

If successful, an InputStream is used to read the response by the data source and a

DocumentBuilder parses the request into a Document. The root of the document is saved to a

variable which is then parsed by the individual classes that extend the APIConnector. Finally the

connection is closed. Errors during any of these steps are handled by writing errors to the log and

returning an empty result which then will display a notification on the screen.


5.4.2 Searching for a book

Manual entry The bookfriend application allows the user to search by book keyword, author, or ISBN. In theory

the user can search any combination of keywords and still retrieve the correct results, but this

separation has been made as there are slight differences in how a search is performed in each case.

Figure 38: Entering a book

When searching by ISBN the system first validates the ISBN is correct by using the check digit at the

end of the ISBN which has an 11-digit range from 0 to 10 (where 10 is represented by X). In this

application this check was achieved by including the Apache commons package into the bookfriend

project. Using this validation means that incorrect ISBNs are found very quickly in comparison to

sending the ISBN through to the Google Books API, which would return no results for an incorrect

ISBN.

If a book keyword is chosen then the user can enter any keyword including titles, keywords,

descriptions and subject and the query is sent as a request to the Google Books API.

An author search returns more results initially than a book search and also modifies the request to

include the inauthor search operator which only searches the author field for a match.

http://books.google.com/books/feeds/volumes?q=inauthor:jane+austen

Barcode scanning The functionality for barcode scanning comes from another Android application named Barcode

Scanner created by ZXing. Barcode Scanner is not included as part of the core application and due to

this, it is necessary to have the application installed onto the device. The bookfriend application

first checks to see if the application is installed, if it is then it carries on as normal and if not then it

prompts the user to install the application. This is shown in Figure 39.

Figure 39: Diagram to show barcode scanning


Next the system loads the Barcode Scanner application which runs the camera and the user can scan

a barcode. The barcode is then sent back to the bookfriend application which validates if it is a

correct ISBN. If it is not correct then a notification is shown to the user. Once a correct ISBN has been

found, the system queries the Google Books API which returns the book.

Searching by location Bibliotravel provided a feed of locations with books for each location they have in their database.

Each location has a longitude and latitude value, which was then translated into an Android

GeoPoint. A MapView was created containing an Overlay with these items and a marker image

(shown in Figure 40). Once a location is selected, the application requests the books about that

location from Bibliotravel and displays them to the user.

Figure 40: Android MapView for searching books by location

5.4.3 Finding book locations MapViews are also used to display locations that are mentioned within a book. These fall under the

categories of book locations, publisher location and author place of birth, and comes from the

LibraryThing API as place names e.g. London. To find the latitude and longitude of the location, it

must be geocoded using the Android GeoCoder class. The full code listing for the Overlay can be

found in Appendix 2.

A separate Overlay was created for each of these categories. Figure 41 shows the marker items

that are used to represent these locations.

Figure 41: Marker images for displaying book locations, publisher location and author birthplace


5.4.4 Ensuring data quality As mentioned in Chapter 2, one of the most difficult challenges in creating mashups is ensuring the

data is correct.

Unique references Rather than searching for strings such as author name or book title, more specific identification was

provided in the request for data. Information about a particular book was referenced by its ISBN

where possible. An issue was raised whereby if the book was a specific edition then less information

may be retrieved which is not desirable for items such as plot summary or genres. However, for

reviews this was a positive aspect as the reviews were more relevant.

In addition to this, some APIs use custom internal ids for elements such as authors. In such a

scenario, the id was retrieved and used to formulate a request which led to more accurate results.

Searching for tweets The Twitter API is unique in the way it searches for matching tweets because it does not search for a

phrase, rather it searches for the words in any order. This means that a search for Wuthering

Heights is likely to find tweets that are related to the book itself, but a search for Lost in a Good

Book may find unrelated tweets. To combat this, the search for tweets in the bookfriend application

initially searches for the book and the author, and progressively removes search items until enough

results have been found. This is shown in Figure 42.

Figure 42: Activity diagram showing flow of Twitter data


5.4.5 System reliability and fallback The system has 8 different data sources and many of these overlap with regard to the content about

books that they provide. An API may fail to retrieve data for several reasons:

1. The API is unavailable due to server-side failure or too many requests by the application

2. No data was available about a particular aspect, e.g. book summary

One of the key aspects of the bookfriend application is that if a data source is unavailable, others

are used. These are prioritised so that the most reliable data source is the primary source. The

reliability of the data source refers to the quality of the data that is retrieved rather than the

likelihood of unavailability.

Book image preview The order of data sources for a book image preview was

1. Bookmooch

2. Goodreads

3. Google

The images retrieved using the Google Books API were found to be physically small and low quality

so were chosen to be the least prioritised image source. However, the larger images from

Bookmooch and Goodreads were not available for some books. The images shown in Figure 43 show

the sizes of the images from these data sources.

Figure 43: Images retrieved from the Bookmooch, Goodreads, and Google API (shown to scale)

This fallback method was achieved in the application by requesting a Bookmooch image first and if

one is found then it is retrieved, else it moves onto the Goodreads API where the process is repeated

and finally the Google API is used. The code snippet is shown in Appendix 3.


Book summary Retrieving a book summary functions in a similar way to book images. One issue was raised during

the development whereby sometimes book summaries are retrieved that are not complete or are

badly formatted. More common however was that some summaries are more detailed than others

and it was for this reason it was decided that summaries should be able to be manually changed by

the user. The user can bring up a menu and choose to change the book summary and are then

shown another screen displaying the available summaries, where they can select to save that

summary as the book summary. If the book is retrieved again through the recent books menu then

the updated summary is shown.

5.4.6 Graceful degradation There are some aspects to the bookfriend application that have only one source of information, such

as awards and film adaptations of books from LibraryThing. If this information is not available about

a book it may be due to a failed connection or the book itself may not have any of this data. In either

event, the system does not show the link in the list to avoid confusion with the user.

Figure 44: List of options with no 'Movies' option

5.4.7 Cleaning data At various stages when running the application and retrieving information, data needs to be

transformed so it is in a usable format.

User input The user input needs to be trimmed of any extra whitespace and spaces must be converted into plus

symbols ready for the transformation into a valid request to the Google Books API. A request is

made to the following URL, where bookToSearch is replaced by the converted string.

http://books.google.com/books/feeds/volumes?q= + bookToSearch + "&start-

index=" + startIndex + "&max-results=" + maxResults;

http://books.google.com/books/feeds/volumes?q=


Data retrieved Some of the information retrieved using the LibraryThing API was contained within a single element

and it was necessary to format these strings in order to style them in a readable arrangement. The

extract below is an example of some strings retrieved for awards that a book has won.

Waterstones Books of the Century (1997, No 24)

ALA Best books (1979)

Guardian top 100 (Sci fi and fantasy)

The format is not consistent but a more readable format would be to move the information within

brackets to a new line. The following examples are of film adaptations that contain a similar issue.

Hitchhikers guide to the Galaxy (1981 | tt0038937)

Hitchhikers guide to the galaxy (1984 | VG | tt8988348 )

The bookfriend application splits the string at the brackets and displays this information on the line

below. In the case of film adaptations, the text in the brackets before the first pipe symbol (|) are

shown. The final result is:

Waterstones Books of the Century

1997, No 24

ALA Best books

1979

Guardian top 100

Sci fi and fantasy

ALA Best books

1979

Hitchhikers guide to the Galaxy

1981

Hitchhikers guide to the galaxy

1984

5.4.8 Ensuring compatibility across devices One of the requirements of the application is the application needs to be consistent across many

devices and as such should not explicitly define the sizes of elements on the screen. In all screens

where possible, the Android RelativeLayout was used, which aligns elements relative to sibling

elements and allows nesting of layouts which is used to create complex layouts.


The following diagram (Figure 45) shows the layout for the main screen in the bookfriend

application. It contains two layouts; one for the title bar and the other for the rest of the elements.

The XML layout can be found in Appendix 4.

Figure 45: Diagram showing XML layout for bookfriend main screen

5.5 Improving the user experience

5.5.1 Finding one particular book When a user is manually searching for books, generating a list from Google Books can be time-

consuming. If a user is searching for a particular book, e.g. ‘The Eyre Affair’, then the application

displaying a list of books that match is unimportant and wastes time as the book they are looking for

is likely to come first in the list.

The bookfriend application deals with this problem by following the following steps

1. The user types a query with the ‘book’ option selected

2. A connection is made to the Google Books API requesting only one book

3. This book title is matched to the user query and if it ‘matches’ then this book is shown to

the user to confirm

Alternative Scenario

4. If the book title does not match then another connection is made to the Google Books API

requesting more books starting at item 2 onwards.

5. The books are then added to the list for the user to choose

Key

Element

Layout


The book titles are matched using Levenshtein distance. The Levenshtein algorithm is designed to

measure the similarity of strings by calculating the number of edits that are needed to turn one

string into another [32]. An implementation of the algorithm in Java has been made publicly

available by Apache in their ‘commons’ package and was included in the bookfriend project. An

example of how this affects searching for books using the bookfriend application is as follows. The

user types a phase into the search box:

fforde eyre affair

The system requests for a list of books from the Google Books API and the first book returned is:

The Eyre Affair

Jasper Fforde

The calculated distance is 7 and the system has a maximum tolerance of 12. This number is

deliberately set high as it was decided that recall is preferable to precision. That is, it is preferred

that sometimes the application is incorrect in its assumption of the books matching rather than

sometimes not matching books that are the same.

5.5.2 Speed of results The speed of the application was an important consideration in the development of bookfriend. As

information is gathered from data sources and cannot be stored, there is a limitation on how fast

the application can respond. To improve performance, the application was coded to Android best

practices which included creating the minimum amount of objects and accessing variables directly.

Major performance boosting techniques included the use of threading, and improving the way in

which the data from a data source was accessed

Threading To guarantee that the application will not show an ANR dialog, it must respond within a short

amount of time which could be difficult if the application is retrieving data. In this scenario, the

screen was loaded but was filled with placeholder “loading” data. For a fast WIFI connection this is

shown for less than a second but the delay becomes more pronounced on a slower connection.

Android provide an AsyncTask class to enable operations to be run on a background thread and

publish results on the user interface thread, which usually means changing the contents of elements

on the screen. AsyncTask is an abstract class which has the following methods:

onPreExecute( ) – this method is run before the background thread begins and can be

used to set up the task, such as starting the animation of a loading image

doInBackground( ) – this method is the main background thread and is used for

background computation. It cannot modify the user interface layer.

onProgressUpdate( ) – during a complex background task, a publishProgress

method can be called in the doInBackground method which will then call this method.

This method can access the user interface layer so can be used to animate a progress bar.

onPostExecute( ) – this is the final step of the AsyncTask and is called once the

doInBackground method has complete and is responsible for updating the user interface

to reflect the results of the background thread.


AsyncTasks were used throughout the bookfriend application wherever requests for data were

made. An example is included in Appendix 5. This improved speed as it meant that the user did not

have a lengthy loading screen at any point and instead the data would be shown as it comes in,

meaning that quicker retrievals (such as book summaries and genres) could be explored as the

lengthier retrievals were completing (such as book reviews and images).

Multiple access to a data source As previously mentioned, all API classes are subclasses of APIConnector which is responsible for

establishing, maintaining and destroying a connection to a data source.

Although some APIs can return data in both XML and JSON format, others only returned data in XML

so it was decided to retrieve data in XML. This helped to reduce the code required to retrieve data

which made debugging easier, but the main reason for this choice was due to the way in which the

document can be processed. Usually responses are sent back as a large document which may

require a lot of processing to extract the information needed by the bookfriend application so to

improve speed, this document was accessed at multiple points at the same time to extract only the

information required. This ensured that parsing of elements not used by the bookfriend application

was not performed, and partial requests for data were much faster. The diagram below explains the

steps taken.

Step 1. The bookfriend application makes a request for data to the BookMashup façade

Step 2. The BookMashup sends asynchronous requests for data to each of the APIs needed to fulfil

that request.

Step 3. Each API opens a connection to the individual APIs and retrieves each response document.

BookMashup

BookMashup

BookMooch

Goodreads

Flickr

…

BookMooch

Helper

BookMooch

API

request

response


Step 4. The elements of the response document needed to fulfil the request are extracted

asynchronously and separately.

The structure of the BookmoochHelper class is shown in Figure 46. The structure is the same in

every helper class where the getX() method provides the URL to connect to and saves the full

document response, and the findX() methods are used to jump to the desired part of the

document response to retrieve the data. Part of the code is included in Appendix 6.

Figure 46: Class diagram of the BookmoochHelper and ApiConnector class

The purpose of retrieving data in this way is to separate the sets of information so that if some

information is quicker to retrieve then it will be displayed on the screen faster. It also means that no

parsing is undertaken unless absolutely required, which saves memory.

BookMooch

response

saleData

bookPrice

bookImage

bookGenres

editorial


Chapter 6. Final result This chapter will demonstrate the screens within the bookfriend application and how the user

interacts with them. Finally the release of the application is discussed with references to the feedback

that has been collected.

6.1 Walkthrough

The following images will be used to show the user input actions.

TAP The user touches the screen

SPREAD The user touches their thumb and forefinger to the screen and moves them apart

TOUCH AND HOLD The user touches the screen and holds their finger for a second

FLICK The user touches the screen and moves their finger along the screen in a flick motion

PINCH The user touches their thumb and forefinger to the screen and moves them together

Once the user has navigated to the application in their home menu

it is loaded and they are shown this screen. The recent books that

they have explored are shown to them and can be retrieved again by

clicking on the book preview.

The three options show the different ways to find books to explore.

The first option to explore will be the manual book entry.


The input book screen is loaded, the user types the keyword and selects the type of search (book,

author or ISBN). They select the search button which then loads the books below the search box,

making it very easy to perform another search.

The next example shows how the system shows the book directly if the first book is a likely match to

the user input.


Before continuing to look at the data retrieved, the other ways to input a book will be mentioned.

Barcode scanning cannot be demonstrated using the emulator as there no camera functionality. The

third way to input a book is to browse by location.

The next screen is the main summary screen which contains

some information about the book and links to more information.

Initially they are shown loading messages which are replaced by

data as it feeds in.


This is a demonstration of all the information available on this screen, although only some is visible

at any one time. The user can slide the screen up and down to view more information.

Note. clicking on another

book by the author will

load that book into

bookfriend.


The next diagram shows how tweets appear on the bookfriend application. The links can be clicked

and loaded in the browser.

Awards are the next item to be demonstrated. The star images used in this list are Android standard

images.

The next diagram shows the characters screen which also uses standard Android icons for the list

item thumbnail.


The next diagram shows the reviews screen, which shows the star rating as well as the review text.

Note. The Android emulator does not display the stars correctly.

The book used in this walkthrough so far does not contain many places mentioned, so for the

purpose of this walkthrough the next screens are from the book Wuthering Heights.

Another feature of the bookfriend application is film adaptations of books. Again the book

Wuthering Heights was used for this demonstration.


The next demonstrations will be the explorations of other books. First, other books with the same

genre can be explored by allowing the user to choose between various themes within the book and

then browsing books that have the same theme.

Books by the same publisher are shown below.


The next set of diagrams show how the book summary of the book can be changed.

The user can press the home button at any time to jump back to the home page, where they will see

their recent books. Clicking on a recent book will load it, and the user can also delete books from this

list. Also, the book image for Going Postal has changed during the gathering of these screenshots,

this shows how different images are used if a web service is temporarily unavailable.

Step 1 Step 2 Step 3

Step 4 Step 5


6.2 Application release

The Android Market is used to distribute both free and paid Android applications to compatible

Android devices [21]. Bookfriend was released to the Android Market on March 2nd 2011 under the

category of ‘Books and Reference’. Since that date there have been 156 installs of bookfriend and

some feedback has been retrieved.

6.2.1 Android statistics The first form of feedback comes from the Android statistics that are provided on the developer

website. It shows the platform versions of all the devices that have installed the application as well

as the makes of devices themselves. It also shows the language and country of origin. This helped in

the development as it confirmed the platforms and devices that needed to be tested. The full set of

results is provided in Appendix 7.

6.2.2 Google Analytics The second form of feedback was obtained using Google Analytics. Google Analytics is a free web

analytics solution providing traffic data for websites. Google have provided an SDK for including this

analysis in Android devices. It allows developers to specify which parts of the application to monitor,

such as pageview tracking or event tracking. For this application, all screens had a separate tracking

event so it was possible to see the popularity of pages and other features such as the barcode

scanning. Using Google Analytics was complimentary to the Android statistics as it provided

previously unknown information such as how many visits there were per day, how long a user was

on a screen for, and the resolutions of the screens.

To set-up Google Analytics, first a unique key needed to be generated using the website. The SDK

was provided as a JAR file which needed to be included on the project buildpath. The unique code

was provided within the BookMashup Façade class.

public static String GOOGLE_ANALYTICS = "UA-21705236-1";

The code to track a page was included on every relevant screen.

tracker = GoogleAnalyticsTracker.getInstance( );

tracker.start( BookMashup.GOOGLE_ANALYTICS, 10, this );

The full set of results is provided in Appendix 8.

6.2.3 Survey

The final form of feedback was an online survey created on SurveyMonkey7 . This survey was made

public and the link is provided when a user downloads the application. The full survey is provided in

Appendix 9 and the results are in Appendix 10.

7 http://www.surveymonkey.com/

http://www.surveymonkey.com/


Chapter 7. Testing

7.1 Testing Methodology

7.1.1 Testing environment

Android Emulator Part of the Android SDK is an emulator which is used to run applications directly from within Eclipse.

When setting up an emulator developers are able to control the appearance and screen size, as well

as specifying network connection settings.

Running on a device The drawback to using the emulator is the response time is lower and the colours are not as clear. It

is possible to run applications directly on Android devices from within Eclipse. The bookfriend

application was developed using both of these approaches – the device was used primarily and the

emulator was used to test different screen types.

Android Debug Bridge The Android Debug Bridge is a tool provided by the Android SDK to manage the state of the

emulator or the device running Android. The logcat logging functionality within this is a shell of log

output for the device enabled. It is also possible to filter messages so it only shows messages that

contain particular tags as shown below:

This shows logs that are tagged with Bookfriend and have the priority of ‘info’ or above. The

remainder of the code sets the rest of the tags (i.e. those not tagged with Bookfriend) to silent.

There are five types of log: Verbose (v), Debug (d), Information (i), Warning (w) and Error (e) and

messages can be written to the log as follows:

Eclipse Android applications can be debugged using the Eclipse Debug menu in the same way as Java

projects. If an application is run in debug mode then the Debug window is displayed and breakpoints

can be set at various points in the code.

Log.e( "BookFriend", "Scan result null." );

$ adb logcat BookFriend:I *:S


7.1.2 Verification and Validation Both during and after the implementation process, it is vital to ensure that the project meets its

specifications and delivers the expected functionality [33]. The two important questions to ask are:

Are we building the product right?

Are we building the right product?

Verification The first question refers to verifying that the software conforms to the specification, which involves

checking that the functional and non-functional requirements have been fulfilled as well as testing to

ensure the system is fully-operational, without defects and has high performance and reliability.

Validation Validation is a more general process than verification and the main aim is to ensure the system does

what was expected of it.

Debugging An important process that was undertaken continually throughout the project was debugging. This

was achieved by following routes through the system until all possible routes are exhausted. The

Android Debug Bridge was loaded and connected to the device so that if a bug is encountered at any

stage then the error log will be updated. Bugs are fixed by applying common knowledge to the

situation and looking for characteristic programming errors.

7.1.3 Testing Strategy The application was tested at the end of every relevant iteration of the project. Module testing was

completed to ensure that the new features introduced in the iteration did not contain bugs and that

they worked as expected. Integration testing was then taken to ensure that these new features did

not affect the rest of the functionality within the application.

The procedure for the testing usually involved running the application on the device as previously

mentioned and inputting data that is both acceptable and extreme in order to monitor how the

system responds. When new functionality was introduced, the procedure was repeated to ensure

that all screens of the application still functioned as expected. This meant that there was not a need

for a large amount of system testing relating to functionality at the end of the project, as it was

completed at every stage.

A separate testing project was established to ensure the reliability of the data sources used within

the application. This was independent of the Android functionality but retained the core

components and API classes. There were two sets of book data that were used for the various tests

run with this project; namely the top 100 books from the Guardian website and a random collection

of books.

A final aspect of the testing was related to the Android screens and ensuring consistency between

different devices. This was tested by creating different devices using the emulator with different

screen types.


7.2 Tests undertaken

7.2.1 Incorrect user input There is only one area in which the user has any input to the bookfriend application that can cause

defects, and that area is when inputting a book. The testing for manual entry involved checking that

empty input was rejected by the system with appropriate feedback for the user. Extreme data for

this test included very long strings of text and non-word characters.

7.2.2 ISBN validation If the user has chosen to search for an ISBN then the system must validate the ISBN before sending

the request for data. If invalid, the system should inform the user and not perform the search.

7.2.3 Scan barcode One test for the scanning functionality involved checking that the system responds with the correct

book when an ISBN is scanned. The system also should reject a non-ISBN barcode (such as a product

barcode) and provide feedback to the user.

7.2.4 Web-service failure This test simulated a web service failure by changing the request parameters so that either the

target API URL or key was incorrect. This meant that the system was not able to establish a

connection with the data source and should fall back to using other data sources, or should

gracefully degrade and not show the user the unavailable actions.

7.2.5 Web connection unavailable The bookfriend application relies on a data connection to retrieve information about books. This

test was to ensure that the application shows a useful error message if a connection is not available.

7.2.6 Web-service missing data A data source may not contain a particular piece of information, for example a book summary. In

this scenario another data source should be used until all data sources had been exhausted. As a

test, this was difficult to simulate so instead a wide range of books was input into the bookfriend

application until this scenario occurred.

7.2.7 Reliability of all APIs The previous tests have been aimed at the bookfriend application, but using the application cannot

accurately measure the reliability of the APIs used so the testing project was used. This test would

repeatedly requests data from the data sources on a timed basis and monitors the connections.

7.2.8 Retrieval of books The only data source that is relied upon within the bookfriend application is the Google Books API

which is used to retrieve books that the user has searched for. This reliance meant that the data

source must be reliable and must retrieve the correct books most, if not all, of the time. The ISBNs of

sample books were request from the API and the known book title was matched to the retrieved


title. Due to slight inconsistencies with the titles, the test class needed to transform some of the

titles automatically. The code for the test class is in Appendix 11.

7.2.9 Frequency of results Using the testing project, requests to all the various data sources were made to find the likelihood of

the system retrieving data, such as images or book summaries.

7.2.10 Operating system The bookfriend application started as an Android v2.1 application and several SDK versions were

made available during the implementation, namely v2.1, 2.2, 2.3 and 2.3.3. The emulator was set up

with several devices running these SDK versions and the application was run on each to ensure

compatibility.

The results of the tests are available in Appendix 12.


Chapter 8. Conclusions

8.1 Project Achievements

The main objectives of the project were to:

Create a useful Android application that finds previously unknown information about any book

including author information, book reviews and other feedback, exploration of other books.

The bookfriend application at the end of development includes all of this functionality as well as

other features so this objective has been fulfilled.

Release the bookfriend application for public use in order to gather feedback from real users.

The application has many users and a great deal of feedback has been gathered, so this objective has

also been fulfilled.

The application can be installed from the Android market onto any Android device and allows users

to search for books and provides some information about any given book, so these areas of the

success criteria have been achieved.

Finally, the application does satify the functional and non-functional requirements that have been

specified in this report.

8.2 Lessons learned

One of the major hindrances to the application being fully seamless and homogenous was from the

restriction placed upon developers from some APIs. This meant that some data had to advertise its

source, for example the Goodreads reviews on the review page needed to be labelled as such.

More frustrating was the inability to save data, which is the one aspect that prevents the application

from appearing as a single source of book information and could cause user frustration.

8.3 Further work

Due to the nature of the implementation, it is very straight-forward to add new APIs so more data

about books could make the application more interesting. It can be argued that in several years,

there will be more data available through public APIs so could be a good source of growth.

One aspect that was considered during the early stages was localisation. In Android, the text used

within the screens can be separated from the code into XML files which can be sent for translation.

The language of the data retrieved from the APIs however would not be known. Further work could

be done with the application so it allows translation of this text automatically into the user’s

language.


Much more work could be done on the social networking aspects to the application in order to make

it more exciting for the users involved. Some ideas considered were to have ways of finding out

other books that people are currently exploring on bookfriend, the ability to leave comments and

feedback on books, and the integration of other social networking sites.

8.4 Final Remarks

There is room for expansion of the bookfriend application but it may detract from its core purpose

of discovering previously unknown information about books. As it is now, it is a lightweight

application that does this very well and the feedback about the usability and functionality of the

application has been very good.

From a personal perspective, Android was a steep learning curve but it was learning how to use

Android well that was painstaking and difficult at times.

The project overall was highly enjoyable and I am very pleased with my result.

Final word count: 14,992

Carrie Louise Hall Glossary | Page 74

Glossary A

Abstract class: A class that has no instances and is created solely for other classes to inherit from it

API: (Application Programming Interface) An interface implemented by a software program to

enable interaction with other software

B

Blog: A personal on-line journal usually maintained by an individual with regular commentaries and

diary entries

Breakpoints: A stopping point in a program used for debugging purposes and allows the developer

to understand the state of a program at a particular time

Bridge: A device or piece of code used to pass messages between two components

Bug: A fault or defect in a computer system

C

Cache: Auxiliary memory used for high-speed retrieval

Class: A construct in object-oriented programming which is used as a template to create objects

Client: A desktop computer or workstation that is capable of connecting and retrieving data from a

server

Concurrence: A property of a system in which several computations are executed simultaneously.

D

Debugging: Identification and removal of errors from a computer system

E

Emulator: A system which duplicates the functions and behaviours of another system.

G

Geo-coding: The process of finding geographic co-ordinates from other geographic data.


GPS: (Global Positioning System) Accurate worldwide navigational facility based on signals retrieved

from orbiting satellites.

H

HTTP: (Hypertext Transfer Protocol) The data transfer used on the World Wide Web

HTTPS: (Hypertext Transfer Protocol Secure) A combination of HTTP and SSL/TLS protocol to provide

encrypted and secure communication

I

IDE: (Integrated Development Environment) A GUI workbench for developing applications

Instance: An object of a given class

Instantiation: The process of creating instances of a class

Interface: A set of named operations that can be invoked in order for classes to communicate.

ISBN: (International Standard Book Number) A 10 or 13 digit number that is used to identify a

particular title and edition of a book

J

Jar file: A standard way of packaging many Java files in order to distribute libraries

Java: A high level programming language

JSON: (Javascript Object Notation) A lightweight computer data interchange format

K

Kernel: The central component of a computer system used as a bridge between applications and

data processing

L

Library: A collection of classes used to develop software

M

Mashup: An application that uses or combines data from two or more sources to create a new

service


N

Namespace: An abstract container which provides context and allows disambiguation for items

Nesting: The process of organizing information into layers containing similar objects

P

Parser: A computer program that analyses and extracts information from a data source

Polymorphism: A programming language feature which allows values of different data types to be

handled using a uniform interface

Protocol: A set of rules determining the format and transmission of data

R

Radio button: A graphical user interface element that allows the user to choose from a set of

predefined options

S

Screen scraping: A technique in which a computer program extracts data from human-readable

source such as a website

SDK: (Software Development Kit) A set of development tools that allow for the creation of

applications for a particular software framework or hardware platform

Shell: A piece of software providing an interface for users to access the services of a kernel

SSL: (Secure Socket Layer) A cryptographic protocol which provides secure communications over

World Wide Web

Stack trace: A report of the execution of a program, often used for debugging

Subclass: A class that inherits properties from a superclass

Subsystem: A group of related components that are part of a larger system

Superclass: Also known as parent class, and is a class from which other classes are defined

T

Thread: A task that is concurrently run by a computer system

Time-boxing: A method to split development into iterations of a fixed length to ensure that the team

deliver valuable software within a short period


TLS: See SSL

U

URI: (Uniform Resource Identifier) A set of characters used to define a name or resource on the

internet

User Interface: The part of a software application that a user sees and interacts with

V

Variable: A facility for storing data

W

W3C: (World Wide Web Consortium) The main international standards organisation for the World

Wide Web

Web service: APIs that can be accessed over a network and executed on a remote system hosting

the requested services

X

XML: (Extensible Markup Language) A flexible text format for creating structured documents

Carrie Louise Hall Appendix | Page 78

Appendix 1. BookListAdapter

public class BookListAdapter extends BaseAdapter {

private Context context;

private ArrayList<Book> bookList;

public BookListAdapter( Context context, ArrayList<Book>

bookCollection ) {

this.context = context;

this.bookList = bookCollection;

}

public int getCount( ) {

return bookList.size( );

}

public Object getItem( int position ) {

return bookList.get( position );

}

public long getItemId( int position ) {

return position;

}

public View getView( int position, View convertView, ViewGroup

parent ) {

Book book = bookList.get( position );

return new BookAdapterListView( this.context, book );

}

}


Appendix 2. Overlay for book locations The following code snippet shows how a set of string locations are transformed into GeoPoints and

set to an overlay based on the type of location. Several image resources are used to distinguish

between the location types. The geocoding is achieved by the getFromLocationName( ) method

which retrieves latitude and longitude which is then converted into microdegrees.

class BookLocations extends ItemizedOverlay {

private List<OverlayItem> locations = new ArrayList<OverlayItem>( );

private Drawable marker;

public BookLocations( Drawable marker, ArrayList<Location> places ) {

super( marker );

this.marker = marker;

// For every location, find the geolocation

for ( Location loc : places ) {

Geocoder geocoder = new Geocoder( getBaseContext( ), Locale

.getDefault( ) );

try {

List<Address> addressResult = geocoder.getFromLocationName( loc

.getLocationName( ), 1 );

if ( !addressResult.isEmpty( ) ) {

Address resultAddress = addressResult.get( 0 );

// Latitude

BigDecimal b = new BigDecimal( resultAddress.getLatitude( ) );

BigDecimal c = b.multiply( BigDecimal.valueOf( 1000000 ) );

BigInteger d = c.toBigInteger( );

int e = d.intValue( );

// Longitude

BigDecimal i = new BigDecimal( resultAddress.getLongitude( ) );

BigDecimal f = i.multiply( BigDecimal.valueOf( 1000000 ) );

BigInteger z = f.toBigInteger( );

int h = z.intValue( );

GeoPoint g = new GeoPoint( e, h );

if ( loc.getLocationType( ).equals( "BookLocation" ) ) {

OverlayItem overlayitem = new OverlayItem( g, loc

.getLocationName( ), getString( R.string.mapbooklocations )

+ " " + mashup.getBook( ).getTitle( ) );

locations.add( overlayitem );

} else if ( loc.getLocationType( ).equals( "AuthorLocation" ) ) {


.getLocationName( ), getString( R.string.mapauthorlocations ) );


} else if ( loc.getLocationType( ).equals( "PublisherLocation" ) ) {


.getLocationName( ),

getString( R.string.mappublisherlocations ) );


}

}

} catch ( IOException e ) {

Log.e( "BOOKFRIEND", e.toString( ) );

}

}

populate( );

}

}


@Override

public void draw( Canvas canvas, MapView mapView, boolean shadow ) {

super.draw( canvas, mapView, shadow );

boundCenterBottom( marker );

}

@Override

protected OverlayItem createItem( int i ) {

return locations.get( i );

}

@Override

protected boolean onTap( int index ) {

OverlayItem item = locations.get( index );

AlertDialog.Builder dialog = new AlertDialog.Builder( c );

dialog.setTitle( item.getTitle( ) );

dialog.setMessage( item.getSnippet( ) );

dialog.show( );

return true;

}

@Override

public int size( ) {

return locations.size( );

}


Appendix 3. Image fallback This code shows how the bookfriend system chooses between data sources and is located in the

BookMashup class. Some of the access to variables within the Book class have been directly

accessed which is an Android recommendation.

public Drawable getBookPreview( ) {

String location = "http://carriehall.co.uk/bookfriend/booknotfound.jpg";

Drawable d = null;

//Bookmooch

if ( book.ISBN10 != null && !book.ISBN10.trim( ).equals( "" ) ) {

bookmoochHelper.getBook( book.ISBN10 );

if ( bookmoochHelper.findBookImage( ) != null

&& !bookmoochHelper.findBookImage( ).equals( "" ) ) {

d = getImage( bookmoochHelper.findBookImage( ) );

if ( d != null ) {

return d;

}

}

}

// Goodreads

grHelper.getGoodReadsReviews( book.getISBN13( ), 1, 6 );

String temp = grHelper.findBookImage( );

if ( !temp.equals( "" ) ) {

if ( !temp.equals( "http://www.goodreads.com/images/nocover-111x148.jpg" ) ) {

d = getImage( temp );

if ( d != null ) {

return d;

}

}

}

// Google

if ( !book.link.equals( "" ) ) {

d = getImage( book.getLink( ) );

if ( d != null ) {

return d;

}

}

return getImage( location );

}


Appendix 4. XML layout for main screen

<?xml version="1.0" encoding="utf-8"?>

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"

android:layout_width="fill_parent" android:layout_height="fill_parent">

<RelativeLayout android:id="@+id/titleArea" style="@style/TitleLabel"

android:layout_width="fill_parent" android:layout_height="wrap_content">

<ImageButton android:id="@+id/jumpHome"

android:layout_height="wrap_content"

android:layout_width="wrap_content"

android:layout_alignParentRight="true" style="@style/TitleLabelImage"

android:scaleType="fitCenter" android:background="@null"

android:layout_centerInParent="true" />

<TextView style="@style/TitleLabelText" android:id="@+id/TitleLabel"

android:layout_toLeftOf="@+id/jumpHome"

android:layout_width="fill_parent"

android:layout_height="wrap_content" />

</RelativeLayout>

<TextView style="@style/RecentBooksLabel"

android:layout_width="fill_parent" android:text="@+string/recent_books"

android:layout_below="@+id/titleArea" android:layout_height="wrap_content"

android:id="@+id/RecentBooks" android:layout_alignLeft="@+id/TitleLabel"

android:layout_alignRight="@+id/TitleLabel"></TextView>

<Gallery android:id="@+id/GalleryBooks" android:layout_width="fill_parent"

android:layout_below="@+id/RecentBooks"

android:layout_height="wrap_content"

android:layout_alignLeft="@+id/RecentBooks"

android:layout_alignRight="@+id/RecentBooks"></Gallery>

<TextView style="@style/SectionLabel" android:layout_below="@id/GalleryBooks"

android:id="@+id/FindBookSectionLabel" android:layout_width="fill_parent"

android:layout_height="wrap_content" android:text="@string/first_search" />

<ListView style="@style/ChooseList" android:id="@+id/FirstView"

android:layout_width="fill_parent" android:layout_height="fill_parent"

android:layout_below="@+id/FindBookSectionLabel"

android:layout_alignLeft="@+id/GalleryBooks"

android:layout_alignRight="@+id/GalleryBooks"></ListView>

</RelativeLayout>


Appendix 5. AsyncTask example This code excerpt demonstrates an asynchronous task in the bookfriend application. The purpose of

it is used to retrieve the other books by an author. It begins by setting the spinning progress bar to

visible as displayed below in . The background task involves invoking the BookMashup and getting

the author books. Once retrieved, a BookAdapter is established which simply displays book previews

as shown below and sets them so that when clicked the book is loaded. If no books are found a

simple message is displayed using a string from the XML resource.

private class getAuthorOtherBooksTask extends

AsyncTask<Integer, Integer,

RecentBooksAdapter> {

private ArrayList<Book> books;

protected void onPreExecute( ) {

progressBar.setVisibility( View.VISIBLE );

}

protected RecentBooksAdapter doInBackground( Integer... authId ) {

books = bookMashup.getAuthorBooks( authId[ 0 ] );

RecentBooksAdapter bookAdapter = new RecentBooksAdapter( instance,

books );

return bookAdapter;

}

protected void onPostExecute( RecentBooksAdapter bookAdapter ) {

progressBar.setVisibility( View.INVISIBLE );

if ( !bookAdapter.isEmpty( ) ) {

g.setAdapter( bookAdapter );

g.setClickable( true );

if ( g.isClickable( ) ) {

g.setOnItemClickListener( new OnItemClickListener( ) {

public void onItemClick( AdapterView parent, View v, int

position, long id ) {

BookMashup.getInstance( ).setBook( books.get( position ) );

Intent myIntent = new Intent( v.getContext( ),

GetSummary.class );

startActivityForResult( myIntent, 13 );

}

} );

}

;

} else {

String[ ] text = new String[ ] { getString(

R.string.no_books_found_for_author ) };

ArrayAdapter<String> arr = new ArrayAdapter<String>( instance,

android.R.layout.simple_gallery_item, text );

g.setAdapter( arr );

}

}

}


Appendix 6. BookmoochHelper class The following code is an excerpt from the BookmoochHelper class. The getBook( ) method

constructs a URL to request data about a particular book which is referenced by its ISBN. The

retreiveData( ) method is a method of the superclass, APIConnector and returns the full

response document. The Bookmooch API response had a bug in which genres could not be extracted

properly unless the document was normalised which moves all text nodes into a normal form. See

the full blog post about this bug at: http://bookfriend.posterous.com/normalise

The findX( ) methods parse the document by finding the elements based on the known tag name.

These methods can be called asynchronously which means data is retrieved quickly in comparison to

doing one set of parsing.

public class BookmoochHelper extends APIConnector {

private Element docEle;

public void getBook( String isbn ) {

String url = "http://api.bookmooch.com/api/asin?asins=" + isbn;

docEle = retrieveData( url );

if ( docEle != null ) {

docEle.normalize( );

}

public String findBookImage( ) {


NodeList nl = docEle.getElementsByTagName( "LargeImage_URL" );

for ( int i = 0; i < nl.getLength( ); i++ ) {

return nl.item( i ).getTextContent( );

}

}

return "";

}

public ArrayList<String> findBookGenres( ) {

ArrayList<String> genres = new ArrayList<String>( );

Node childNode = null;


NodeList nl = docEle.getElementsByTagName( "Topics" );

Node reviewNode = nl.item( 0 );

if ( reviewNode != null ) {

for ( int j = 0; j < reviewNode.getChildNodes( ).getLength( ); j++ ) {

childNode = reviewNode.getChildNodes( ).item( j );

for ( int k = 0; k < childNode.getChildNodes( ).getLength( ); k++ ) {

genres.add( childNode.getChildNodes( ).item( k ).getNodeValue( ) );

}

}

}

}

return genres;

}

public String findEditorialReview( ) {


NodeList nl = docEle.getElementsByTagName( "EditorialReview_Content" );

for ( int i = 0; i < nl.getLength( ); i++ ) {

return nl.item( i ).getTextContent( );

}

}

return "";

}

}

http://bookfriend.posterous.com/normalise


System.out.println( "there were " + hashtable.size( ) + " elements " );

System.out.println( "there were " + numberOfTrue + " true matches" );

System.out.println( "there were " + numberOfMaybe + " maybe matches " );

System.out.println( "there were " + numberOfNo + " without matches " );

}

private String stripUnwanted( String string ) {

String s = string;

if ( string.toString( ).toLowerCase( ).startsWith( "the " ) ) {

s = string.substring( 4 );

}

if ( string.toString( ).toLowerCase( ).startsWith( "a " ) ) {


}

if ( string.toString( ).toLowerCase( ).startsWith( "at " ) ) {


}

s = s.replaceAll( "\\'", "" );

return s;

}

public void getTop100ItemsToTable( ) {

hashtable = new Hashtable<String, String>( );

try {

FileInputStream fstream = new FileInputStream( "topbooks.csv" );

DataInputStream in = new DataInputStream( fstream );

BufferedReader br = new BufferedReader( new InputStreamReader( in ) );

String strLine;

while ( ( strLine = br.readLine( ) ) != null ) {

String[ ] split = strLine.split( "," );

String[ ] split2 = split[ 3 ].split( ":" );

hashtable.put( split[ 2 ], stripUnwanted( split2[ 0 ] ) );

}

in.close( );

} catch ( Exception e ) {// Catch exception if any

System.err.println( "Error: " + e );

}

}

public void getRandomBooksToTable( ) {

hashtable = new Hashtable<String, String>( );

try {

FileInputStream fstream = new FileInputStream( "input.csv" );

DataInputStream in = new DataInputStream( fstream );

BufferedReader br = new BufferedReader( new InputStreamReader( in ) );

String strLine;

while ( ( strLine = br.readLine( ) ) != null ) {

String[ ] split = strLine.split( ":" );

String isbn = split[ 0 ].substring( 0, 10 );

String title = split[ 0 ].substring( 11, split[ 0 ].length( ) );

hashtable.put( isbn, title );

}

in.close( );

} catch ( Exception e ) {// Catch exception if any

System.err.println( "Error: " + e );

}

}

}


Appendix 7. Android statistics

Platform version

Device


Country


Appendix 8. Google Analytics The following screenshots demonstrate the use of the bookfriend application with data gathered

using Google analytics. The actual figures used within the content section are not representative as

the bounce rate and exit rate do not apply to mobile applications, and not all pageviews are

recorded.

Top Content

Screen Resolution


Visitor Loyalty

Map Overlay


Appendix 9. Survey

Continued on next page



Appendix 10. Survey results The results from the survey are shown below.

How useable and intuitive is the interface of bookfriend?

How reliable were the results?

How interesting and useful were the results?

1 (not intuitive)

2

3

4

5 (easy to use)

1 (not reliable)

2

3

4

5 (very reliable)

1 (useless)

2

3

4

5 (very useful)


How fast did you find bookfriend when it retrieved data.

Which features would you most like to see in bookfriend? 1- not interested, 5 – very interested

Option Average rating

Book prices and options to buy a book 2.8

More author information (including education and awards) 4

More reviews (including filtering of reviews) 4.4

Twitter results about the book/author 4

Images of book locations 3.4

Did you experience any errors when using bookfriend?

The error was that the application would not accept numbers into the search bar when the user

tried to search for 1984 by George Orwell. At the time of this survey response there were no radio

buttons to select if the user wants to search for ISBN, it was assumed it was an ISBN if it was only

numeric digits. Upon receiving this report, the radio buttons were added in to ensure this problem

does not occur.

1 (very slow)

2

3

4

5 (fast)

Yes

No


Will you continue to use bookfriend?

Would you recommend bookfriend to a frend?

Yes

No

Yes

No


Appendix 11. Google API test class

public class GoogleTester {

Hashtable<String, String> hashtable;

public static void main( String[ ] args ) {

new GoogleTester( );

}

public GoogleTester( ) {

// use comments to choose which books to load

getTop100ItemsToTable( );

// getRandomBooksToTable( );

GoogleHelper gHelper = new GoogleHelper( );

Enumeration<String> e = hashtable.keys( );

int numberOfTrue = 0;

int numberOfMaybe = 0;

int numberOfNo = 0;

while ( e.hasMoreElements( ) ) {

String key = ( String ) e.nextElement( );

ArrayList<Book> books = gHelper.getGoogleBooks( key, 1, 1, false );

if ( books.size( ) == 0 ) {

System.out.println( "no books found for isbn " + key );

numberOfNo++;

} else {

if ( hashtable.get( key ).toString( ).toLowerCase( ).equals(

gHelper.getGoogleBooks( key, 1, 1, false ).get( 0 ).getTitle( )

.toLowerCase( ) ) ) {

System.out.println( "true" );

numberOfTrue++;

} else {

if ( hashtable.get( key ).toString( ).toLowerCase( ).startsWith(

stripUnwanted( gHelper.getGoogleBooks( key, 1, 1, false ).get( 0 )

.getTitle( ).toLowerCase( ) ) ) ) {

numberOfTrue++;

} else {

// "Does bookx match BookX?"

System.out.println( "Does \""

+ hashtable.get( key )

+ "\" match \""

+ stripUnwanted( gHelper.getGoogleBooks( key, 1, 1, false )

.get( 0 ).getTitle( )

+ "\" ?" ) );

Scanner sc = new Scanner( System.in );

String res = sc.next( );

if ( res.equals( "y" ) ) {

numberOfTrue++;

} else {

numberOfMaybe++;

}

}

}

}

}

System.out.println( "there were " + hashtable.size( ) + " elements " );

System.out.println( "there were " + numberOfTrue + " true matches" );

System.out.println( "there were " + numberOfMaybe + " maybe matches " );

System.out.println( "there were " + numberOfNo + " without matches " );


Appendix 12. Testing results TC1: Incorrect Manual User Input

Purpose The system should not allow empty strings to be searched Pre-requisite None Test Data Empty string Steps Press the go button with no data entered Result The application passed the test. When the ‘search’ button is pressed with no

input, the system rejects the search and shows an Android notification to the user that they need to input a book. This is also the case if only blank spaces are input.

TC2: Incorrect ISBN

Purpose The system should not allow incorrect ISBNs to be searched Pre-requisite None Test Data Random set of characters and the ISBN radio button selected Steps Enter a set of random numbers, select an ISBN search and press the ‘search’

button Result test passed – notification is shown to the user to inform them of invalid ISBN

TC3: Scan Barcode

Purpose The system should show a notification if a non-ISBN item is scanned using the Barcode Reader

Pre-requisite Barcode Reader needs to be installed, and a camera needs to be present. Test Data Product barcode Steps Scan the product barcode Result The application passed the test. The system returns to the search book page and

displays a notification that the barcode was not an ISBN

TC4: Web connection unavailable

Purpose The system should show a message that a data source is not available Pre-requisite None Test Data The Eyre Affair by Jasper Fforde Steps Set up the device to have no internet Result The application passed the test. Book images fall back to using Google, awards

are not shown, and plot summary falls back to using the Google summary

TC5: Web-service failure

Purpose The system should not show links to data that has not been retrieved Pre-requisite None Test Data The Eyre Affair by Jasper Fforde Steps Change the URL or API key of each API one by one and run the application and

find the same book. Result The application passed the test. Book images fall back to using Google, awards

are not shown, and plot summary falls back to using the Google summary

TC6: Web connection unavailable

Purpose The system should show a useful error message if there is no data connection found when searching for a new book.

Pre-requisite There should be no data connection on the device Test Data The Eyre Affair by Jasper Fforde Steps Load a recent book then search for a new book Result The application partially failed the test. When loading a recently viewed book

then the system correctly displays no information and does not fail. When a new search is done, the system feeds back very quickly but the message is ‘no book found’ which should be changed to mention the connection


TC7: Web-service missing data

Purpose The system should fall back to using other sources if the web service does not contain any information

Pre-requisite None Test Data Various books Steps Keep searching books and viewing the different summaries to see which ones

were loaded automatically Result The application passed the test, although the expected data for a book was

found first by running the java project which has the same API connectors.

TC8: Reliability of all APIs

Purpose To determine the reliability of the APIs Pre-requisite None Test Data The Eyre Affair by Jasper Fforde Steps Request data in a loop and monitor the connections and count any failed

responses Result Google: 100% success

Goodreads: 100% success Bookmooch: 100% success ISBNDB: not tested Twitter: not tested Bibliotravel: not tested

TC9: Retrieval of books

Purpose Determine how accurate the Google Books API is when giving it a set of ISBNs and matching these to titles

Pre-requisite None Test Data Top 100 books from the Guardian, and random 100 books Steps Run the GoogleTester class within the BookFriendTester project, and choose

which set of books to test Result Top 100 books: 100% accurary

Random 100 books: 97% accuracy These results are acceptable so the test is considered a success.

TC10: Frequency of results

Purpose To determine how likely the system is to retrieve data as a whole Pre-requisite None Test Data Top 100 books from the Guardian, and random 100 books Steps Run the BookMashupTester class within the BookFriendTester project, and

choose which set of books to test Result Top 100 books:

Book image: 100% Book summary: 67% Random 100 books: Book image: 100% Book summary: 86% The test results were acceptable

TC11: Operating system

Purpose To ensure the system functions on every version of the Android operating system from 2.1

Pre-requisite Emulators for each versions of the operating system must be established Test Data The Eyre Affair by Jasper Fforde Steps Run through the system along every path, on each of the emulators Result Test passed


Appendix 13. Project Plan The following screen shot is from Basecamp, the online project management tool which was used to

track the development of the bookfriend application.


References 1. Larman, C., Applying UML and Patterns. 2004, New Jersey: Pearson Education.

2. Shuli Yu, C.J.W., Innovation in the Programmable Web: Characterizing the Mashup

Ecosystem Lecture Notes in Computer Science, 2009. 5472: p. 136-147.

3. Merril, D. Mashups: The new breed of Web app. 2009 24 Jul 2009 [cited 2010 April 5];

Available from: http://www.ibm.com/developerworks/xml/library/x-mashups/index.html.

4. Murugesan, S., Understanding Web 2.0. IEEE IT Professional 2007. 9(4): p. 34 - 41.

5. Eric van der Vlist, D.A., Erik Bruchez, Joe Fawcett, Professional Web 2.0 Programming. Wrox

Professional Guides. 2006: John Wiley & Sons.

6. Yee, R., Pro Web 2.0 Mashups. 2008, New York: Springer.

7. Berlind, D., What is a mashup?, in At The Whiteboard Videos. 2006, ZDNet.

8. Maximilien, E.M., An Online Platform for Web APIs and Service Mashups. Internet

Computing, IEEE 2008. 12(5): p. 32 - 43.

9. Nan Zang, M.B.R., Vincent Nasser, Mashups: who? what? why? Extended abstracts on

Human factors in computing systems, 2008.

10. Matteo Picozzi, M.R., Cinzia Cappiello, Maristella Matera, Quality-Based Recommendations

for Mashup Composition. Current trends in web engineering, 2010.

11. Wernick, D., API Documentation: How to Explain so Experts will Understand. 2003.

12. Ferrate, A., Money, Ads, and Maps: Is Mapvertising the Key to Monetizing Mashups?, in

ProgrammableWeb Blog. 2008.

13. Francisco Curbera, M.D., Rania Khalaf,William Nagy,Nirmal Mukhi, Sanjiva Weerawarana,

Unraveling the Web Services Web. Internet Computing, IEEE 2002. 6(2): p. 86 - 93

14. Costello, R., Building Web Services the REST Way. 2007.

15. Fielding, R.T., Architectural Styles and the Design of Network-based Software Architectures.

2000, University of California: California.

16. Elkstein, M. Learn REST. 2008; Available from: http://rest.elkstein.org/.

17. Robbins, J., Web Design in a Nutshell. 3rd ed. 2006, California: O'Reilly Media.

18. Nurzhan Nurseitov, M.P., Randall Reynolds, Clemente Izurieta Comparison of JSON and XML

Data Interchange Formats:. 2009, Montana State University.

19. json.org. JSON. 2003 [cited 2011 April 20th]; Available from: http://www.json.org/.

20. Allamaraju, S., RESTful Web Services Cookbook. 2010, California: O'Reilly Media.

21. Meier, R., Professional Android 2. 2010, Indiana: Wiley Publishing.

22. Saha, A.K., A Developer’s First Look At Android, in Linux For You. 2008. p. 3.

23. Cook, J., Shelfari an online meeting place for bibliophiles, in Seattlepi. 2006.

24. Ian Sommerville, G.K., Requirements Engineering. 1998, San Francisco: John Wiley & Sons.

http://www.ibm.com/developerworks/xml/library/x-mashups/index.html

http://rest.elkstein.org/

http://www.json.org/


25. Pressman, R.S., Software Engineering, a practitioner's approach. 5th ed. 2005, New York:

McGraw-Hill.

26. Google. Data API: Developer's Guide, Protocol. 2011 [cited 2011 14th April]; Available from:

http://code.google.com/apis/books/docs/gdata/developers_guide_protocol.html.

27. Licia Capra, W.E., Cecilia Mascolo, Middleware for Mobile Computing. UCL Research Notes,

2001.

28. Google. Android Developer's Guide. 2011 [cited 2011 April 22nd]; Available from:

http://developer.android.com/guide/practices/compatibility.html.

29. Schuh, P., Integrating Agile Development in the Real World. 2005, Massachusetts: Charles

River Media

30. Eric Freeman, E.F., Head First Design Patterns. 2004, California: O'Reilly.

31. Erich Gamma, R.H., Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable

Object-Oriented Software. 1994, New Jersey: Pearson Education.

32. Gilleland, M. Levenshtein Distance. 2001 [cited 2011 19th April]; Available from:

http://www.merriampark.com/ld.htm.

33. Sommerville, I., Software Engineering. 8th ed. 2007, Essex: Pearson Education.

http://code.google.com/apis/books/docs/gdata/developers_guide_protocol.html

http://developer.android.com/guide/practices/compatibility.html

http://www.merriampark.com/ld.htm

Bookfriend report

Technology

social networking site

numberofno

numberoftrue

numberofmaybe

javascript object notation

requisite nonetest data

requisite nonetest data

full code listing