UNIVERSITY OF MANCHESTER                                  School of Computer Science            Third Year Project Report ...
AcknowledgementsI would like to thank my friends and family, whose continuous support and encouragement helpedme throughou...
Table of ContentsAcknowledgements............................................................................................
3.2 Specific requirements ...................................................................................................
5.2.4 Helper components class diagram .......................................................................................
7.2.7 Reliability of all APIs ...............................................................................................
List of FiguresFigure 1: Types of mashup on Programmable Web.................................................................
Figure 34: Diagram to show how the Façade separates the application from the interface ............... 46Figure 33: The co...
Chapter 1. Introduction to the projectThis chapter will give an introduction to the aim and objectives of the project, and...
1.4 Success CriteriaThe following list of criteria is used to rate the success of the bookfriend application:       The a...
Chapter 2. BackgroundThis chapter gives the context of the application by discussing what mashups are, why they arepopular...
ProgrammableWeb5 is a directory of mashups and APIs. It contains nearly six thousand mashupswith an average of 2.8 mashups...
Coding detailsThere can be a large learning curve to develop tools that work with APIs, regardless of the languagethe appl...
2.2.2 RESTNowadays it is more common to develop web services and APIs by using Representational StateTransfer (REST). REST...
XMLAs previously mentioned, REST responses can be in XML. XML is a meta-markup language for textdocument markup [17] and i...
The following JSON construct representa the same File menu previously discussed in XML. Each itemis distinguished by using...
2.3.2 ArchitectureThe components of Android are designed as a stack; the bottom layer is the Linux kernel and the toplayer...
2.3.4 ApplicationsAndroid applications are written using Java and XML. The architectural essence of Androidapplications is...
ViewsViews are XML-based layout files and are linked with Activities to create a user interface screen.Android provide man...
Diagram of an Android application            XML Layout                                                                   ...
2.3.6 Versions Google often release updates to the Android SDK regularly. At the start of this project the version of Andr...
Reading RadarReading Radar takes the New York Times bestseller list data and mashes it with Amazon informationin order to ...
Chapter 3. RequirementsThis chapter documents both the functional and non-functional requirements of bookfriend, andspecif...
Use case diagramsA use case diagram is used to show the high-level functionality of the system. The features in Figure15 s...
3.1.3 User characteristicsThe users of the bookfriend application are not known explicitly so a wide range of users must b...
3.2.5 Reliability requirements    1. The application shall function as expected when there is an internet connection of an...
LibraryThingLibraryThing is also a social networking site for readers. The APIs are extensive and include tools tocross re...
3.3.2 DiagramThe following diagram (Figure 16) shows the APIs used related to the functions that are present inthe bookfri...
Chapter 4. DesignThe Design chapter will discuss the issues that are raised when developing mobile applications, anddiscus...
PerformanceDesigning for performance ensures that applications are fast and do not waste battery life. Theguidelines that ...
SeamlessnessApplications should interact seamlessly with the Android system. To do this developers should:       Bear in ...
In Android it is possible to provide custom resources, such as images, depending on the screen sizeor screen density. Scre...
4.2 Designs for bookfriend4.2.1 Logo and iconThe logo was designed early in the development process and adheres to Android...
Figure 22: A menu screen and home screen and with the bookfriend launcher icon displayed4.2.2 FontThe font used for the lo...
4.2.4 Photoshop designThe first design for the application has many of the same features that are found in the currentvers...
Chapter 5. ImplementationThe implementation section will discuss the development process and how the work was divided into...
5.1.2 Agile DevelopmentAt the beginning of the project it was decided that an agile approach would be more beneficial than...
5.1.3 Phases of developmentBefore each iteration, informal planning was undertaken using a whiteboard and the developmentt...
Phase 3: Integrating Book DataAt this point we have some information about books which needs to be moved to the Androidapp...
Phase 5: Integration of more APIsMore APIs can be added easily to the project at this stage, as the hierarchy is establish...
5.2 Architecture5.2.1 Project hierarchyBookfriend        src                 bookfriend                         Contains t...
5.2.2 Package diagramThe following diagram (Figure 29) show the packages used in the bookfriend application. The size ofth...
5.2.4 Helper components class diagramFigure 31: Helper components class diagram5.2.5 Android classesA class diagram is not...
5.3 Object-oriented design5.3.1 Design PatternsDesign Patterns are a named and well known problem/solution pair for any pr...
Pure FabricationCreate fabricated classes to interface with real-world concept classes when necessary to keepcoupling low ...
Decisions for the bookfriend applicationFaçadeThe BookMashup is a Pure Fabrication and was created as a Façade created usi...
AdapterThe API class hierarchy is an example of the Adapter pattern. All of the classes are subclasses ofAPIConnector, whi...
In the bookfriend application more customization was required so that the layout could include abook title, author name, a...
5.4.2 Searching for a bookManual entryThe bookfriend application allows the user to search by book keyword, author, or ISB...
Next the system loads the Barcode Scanner application which runs the camera and the user can scana barcode. The barcode is...
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Bookfriend report
Upcoming SlideShare
Loading in...5
×

Bookfriend report

752

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
752
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Bookfriend report

  1. 1. 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 FernandesMobile phones and smartphones are now ubiquitous in everyday life and the new andinnovative aspects of the web are finally able to be realized on mobile devices. Bookfriend is amobile phone mashup application developed for Android that creates a companion guide to anybook and allows users to find out information about books and explore other books that theymay enjoy.
  2. 2. AcknowledgementsI would like to thank my friends and family, whose continuous support and encouragement helpedme 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 andgiven me confidence throughout the project, as well as inspiring and contributing to the applicationitself.Carrie Louise Hall Chapter 1 | Page 2
  3. 3. Table of ContentsAcknowledgements................................................................................................................................. 2Table of Contents .................................................................................................................................... 3List of Figures .......................................................................................................................................... 7Chapter 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 ......................................................................................................................... 10Chapter 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 ................................................................................................................. 22Chapter 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 .......................................................................................... 25Carrie Louise Hall Chapter 1 | Page 3
  4. 4. 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 ..................................................................................................................................... 28Chapter 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................................................................................................................. 35Chapter 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 .......................................................................................... 42Carrie Louise Hall Chapter 1 | Page 4
  5. 5. 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.................................................................................................................... 56Chapter 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................................................................................................................................... 67Chapter 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 .................................................................................................... 70Carrie Louise Hall Chapter 1 | Page 5
  6. 6. 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 ............................................................................................................... 71Chapter 8. Conclusions ......................................................................................................................... 72 8.1 Project Achievements ................................................................................................................. 72 8.2 Lessons learned ........................................................................................................................... 72 8.3 Further work ............................................................................................................................... 72 8.4 Final Remarks .............................................................................................................................. 73Glossary ................................................................................................................................................. 74Appendix 1. BookListAdapter................................................................................................................ 78Appendix 2. Overlay for book locations ................................................................................................ 79Appendix 3. Image fallback ................................................................................................................... 81Appendix 4. XML layout for main screen .............................................................................................. 82Appendix 5. AsyncTask example ........................................................................................................... 83Appendix 6. BookmoochHelper class.................................................................................................... 84Appendix 7. Android statistics .............................................................................................................. 86 Platform version................................................................................................................................ 86 Device................................................................................................................................................ 86 Country ............................................................................................................................................. 87Appendix 8. Google Analytics ............................................................................................................... 88 Top Content ...................................................................................................................................... 88 Screen Resolution ............................................................................................................................. 88 Visitor Loyalty.................................................................................................................................... 89 Map Overlay ...................................................................................................................................... 89Appendix 9. Survey ............................................................................................................................... 90Appendix 10. Survey results .................................................................................................................. 92Appendix 11. Google API test class ....................................................................................................... 95Appendix 12. Testing results ................................................................................................................. 96Appendix 13. Project Plan ..................................................................................................................... 98References ............................................................................................................................................ 99Carrie Louise Hall Chapter 1 | Page 6
  7. 7. List of FiguresFigure 1: Types of mashup on Programmable Web.............................................................................. 12Figure 2: SOAP example of querying a phonebook application............................................................ 13Figure 3: REST example of querying a phonebook application ............................................................ 14Figure 4: A more complex REST query .................................................................................................. 14Figure 5: XML representation of a ‘File’ menu ..................................................................................... 15Figure 6: JSON representation of a ‘File’ menu .................................................................................... 16Figure 7: Graph showing the percentage of mobile subscribers since October 2009 .......................... 16Figure 8: Android component stack diagram ....................................................................................... 17Figure 9: Calling an Activity ................................................................................................................... 18Figure 10: Some of the Views used within Android .............................................................................. 19Figure 11: XML resources in Android .................................................................................................... 19Figure 12: Diagram representing the major components of an Activity .............................................. 20Figure 13: Android MapView with customized Overlay ....................................................................... 20Figure 14: Timeline of Google Android SDK versions ........................................................................... 21Figure 15: Use case diagram for the bookfriend application ................................................................ 24Figure 16: APIs used and functions they perform ................................................................................ 28Figure 17: Application Not Responding (ANR) dialog ........................................................................... 30Figure 18: How the Android platform maps screen densities and screen sizes ................................... 31Figure 19: Launcher icons used by Android book applications ............................................................ 33Figure 20: The bookfriend logo ............................................................................................................. 33Figure 21: The bookfriend launcher icons ............................................................................................ 33Figure 22: A menu screen and home screen and with the bookfriend launcher icon displayed ......... 34Figure 23: Font used in the bookfriend application.............................................................................. 34Figure 24: Wireframe design................................................................................................................. 34Figure 26: Version 1 of the interface design ......................................................................................... 35Figure 25: Final design of the interface ................................................................................................ 35Figure 27: The AVD Manager’s Available Packages panel which shows SDK components .................. 36Figure 28: Agile development process .................................................................................................. 37Figure 29: Packages used within the bookfriend application ............................................................... 42Figure 30: Core components class diagram .......................................................................................... 42Figure 31: Helper components class diagram ....................................................................................... 43Figure 32: Android classes .................................................................................................................... 43Carrie Louise Hall Chapter 1 | Page 7
  8. 8. Figure 34: Diagram to show how the Façade separates the application from the interface ............... 46Figure 33: The code to create the BookMashup Façade class within the application ......................... 46Figure 35: Adapter pattern in the bookfriend application ................................................................... 47Figure 36: Diagram representing the Observer pattern ....................................................................... 47Figure 37: The bookfriend customized list view ................................................................................... 48Figure 38: Entering a book .................................................................................................................... 49Figure 39: Diagram to show barcode scanning ..................................................................................... 49Figure 40: Android MapView for searching books by location ............................................................. 50Figure 41: Marker images for displaying book locations, publisher location and author birthplace ... 50Figure 42: Activity diagram showing flow of Twitter data .................................................................... 51Figure 43: Images retrieved from the Bookmooch, Goodreads, and Google API (shown to scale) ..... 52Figure 44: List of options with no Movies option ............................................................................... 53Figure 45: Diagram showing XML layout for bookfriend main screen ................................................. 55Figure 46: Class diagram of the BookmoochHelper and ApiConnector class ....................................... 58Carrie Louise Hall Chapter 1 | Page 8
  9. 9. Chapter 1. Introduction to the projectThis chapter will give an introduction to the aim and objectives of the project, and highlight workundertaken in the subject area.1.1 The ProjectThe 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 isretrieved from several web resources about books, such as reviews, characters and synopses, and ispresented to the user as a concise and homogeneous source. These resources may be professionallywritten but the primary source of information will come from user-generated data.1.1.1 Application featuresA list of terse high-level system features are often included as part of an introductory Visiondocument to a project [1]. Usually these lists are less than 10 items and highlight the noteworthyfeatures 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 books1.2 Previous workThe project builds from a similar project done several years ago for a web platform, but the flexibilityof the project allowed for different motivations and results. Using a web platform it is possible todisplay a lot of information of varying quality whereas on a mobile device it is important that theinformation about a book is generally correct, as there is limited screen size and connection speed.1.3 ObjectivesThe 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.Carrie Louise Hall Chapter 1 | Page 9
  10. 10. 1.4 Success CriteriaThe 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 StructureChapter 1 discusses the aims and objectives of the project.Chapter 2 explores the technologies used within the project and some examples of existingapplications.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 ofthese tests.Carrie Louise Hall Chapter 1 | Page 10
  11. 11. Chapter 2. BackgroundThis chapter gives the context of the application by discussing what mashups are, why they arepopular, and how they are created. It also provides background knowledge about the Androidplatform and presents some examples of mashups both on the web and on mobile devices.2.1 MashupsThe term ‘mashup’ originates in music and is used to describe remixing songs to create new piecesof work [2].IBM define mashups as “an exciting genre of interactive Web applications” [3] that combinecomplimentary information from multiple sources [4] and present it in a new and innovative way. Itis 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 sourceThe 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 amashup which uses a Google map to display properties for sale or rent. These properties areretrieved from a website called Craigslist2, which is an online community containing classifiedadvertisements.Mashups have been labelled as the fastest growing eco-system on the web [7] because of thecombination of the rapidly increasing number of web services published by content providers andthe 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 fortheir data and Twitter inspiring developers to develop APIs based on sentiment analysis and socialnetworking.Often mashups are developed to solve a problem, which may explain why they are popular withgeneral web users. Some examples of this include DealMine3 which mashes up data from severaldiscount and reward sites into a comparison shopping API, and Busalert4 which is a real-time trackerservice for bus tracking in Kings County, Washington.1 http://www.housingmaps.com2 http://www.craigslist.com3 http://www.dealmine.com4 http://www.busalert.meCarrie Louise Hall Chapter 2 | Page 11
  12. 12. ProgrammableWeb5 is a directory of mashups and APIs. It contains nearly six thousand mashupswith an average of 2.8 mashups being added every day. Mapping mashups (i.e. mashups that usemaps as a way of displaying data) account for 33% of these. The diagram in Figure 1 shows thebreakdown of mashups listed on ProgrammableWeb. Figure 1: Types of mashup on Programmable WebA study of Programmable Web mashups show that mashup developers tend to build mashups froma small number of popular services rather than a wide range of specialized functions [2].2.1.1 Challenges of mashupsMashups raise new challenges and problems that need to be considered [8] such as the lack ofstandardized approaches to architecture and design. Developers have cited the following problemareas with mashups; namely data quality, the reliability of the API, documentation, coding details,legality and semantic meaning [9].Data qualityThis is arguably the biggest challenge that mashup developers face when creating a mashup andrefers to the data accuracy and completeness as well as semantic meaning, i.e. the real-worldmeaning 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 mashupto determine if the user is looking for information regarding the company or the fruit. This problemis amplified in a mashup as data is not usually pre-processed or stored by the mashup creator.API reliabilityReliability refers to problems with authentication and performance degradation, as well as a relianceon the API creator’s priorities and decisions for future development as the operations available maynot be sufficient. Changes to an API that are not backwards-compatible (e.g. the removal of anoperation) will cause disorder within a mashup that relies on this functionality.DocumentationThe lack of documentation within APIs is apparent. The reason for this could be that it is expectedthat the user of an API is an expert, that is, they are developers that know how to programapplications and know what the general function of the API is [11]. To learn an API, sometimes theonly source available is the documentation written by the API creator. Examples of working code is agood way to inform users how to call particular functions and is a feature desired by mashupdevelopers [9].5 http://www.programmableweb.comCarrie Louise Hall Chapter 2 | Page 12
  13. 13. Coding detailsThere can be a large learning curve to develop tools that work with APIs, regardless of the languagethe application is implemented in. Mashups compile data from many different sources which canincrease the complexity in the code, both for each individual API and when integrating the sources.LegalityWeb services and APIs come with terms and conditions of use that can vary dramatically. Often it isin the conditions of a free API that the services created using the data must be available toconsumers free of charge as well. This raises questions about the profit potential of mashups thatrely on these APIs. Often advertising is included in order for developers to profit from mashupapplications, including ‘mapvertising’ which is placing sponsored ads onto map screens [12]. Otherterms of use include the need to include a company name or logo on any screen that data from thatservice appears (Goodreads include this in their terms) or that data from competitors is prohibitedon the same page . More specific terms can also be provided such as not requesting data more thanonce a second, or not storing data for more than 24 hours (if allowed at all). These terms can be veryrestrictive to mashup developers.2.2 Web Services and APIsThe data that powers mashups often comes from Application Programming Interfaces (APIs). WebAPIs facilitate data exchange between applications by providing an interface to request data andretrieve a response [4]. Many major companies such as Google, Amazon and eBay have providedfree APIs to their data [2].2.2.1 SOAPSimple Object Access Protocol (SOAP) is an XML-based protocol for exchanging information and isused within web services [13]. A SOAP message must have a root Envelope element and contain aBody element. It can also contain a Header element to describe application-specific informationsuch 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 auser. The user id is provided and the type of request (GetUserDetails) is an application specific XMLelement. The rest of the request is used to declare the message as a SOAP message and to declareunique namespaces. <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> Application <pb:UserID>12345</pb:UserID> specific </pb:GetUserDetails> elements </soap:Body> </soap:Envelope>Figure 2: SOAP example of querying a phonebook applicationCarrie Louise Hall Chapter 2 | Page 13
  14. 14. 2.2.2 RESTNowadays it is more common to develop web services and APIs by using Representational StateTransfer (REST). REST is an architectural style for distributed web applications and provides a set ofconstraints and principles [14, 15]. REST services are focused around resources, which are uniqueand global (e.g. a URI in HTTP), and communication between client and server to identify andmanipulate 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 adefined 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 clientinitiates requests using these operations and a response can be sent back in several formats, usuallyXML or JSON.REST is more lightweight than SOAP and it can be argued that there is no functionality that webservices using SOAP can achieve that REST cannot [16].Many APIs use REST, including Amazon, Twitter and Flickr. It has the advantage of being simple toimplement 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 itdoes not require any of the XML elements required to process a SOAP request. In essence, a RESTrequest is a URI to a desired resource.http://www.acme.com/phonebook/UserDetails/12345Figure 3: REST example of querying a phonebook applicationA 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=DoeFigure 4: A more complex REST queryCarrie Louise Hall Chapter 2 | Page 14
  15. 15. XMLAs previously mentioned, REST responses can be in XML. XML is a meta-markup language for textdocument markup [17] and is a way of improving informational structure and adding meaning todata, and can be validated. Furthermore, parsers can be used to interpret the information stored inXML 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 isspecified in the form <tag>value</tag>. XML is hierarchical and needs to be properly nested. Inthis example there are three items - new, open and close - and each item contains a title and anaction. <?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>Figure 5: XML representation of a ‘File’ menuJSONAnother 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 machinereadable [18]. It uses familiar programming conventions but is language independent and the datastructures are supported in all modern programming languages and is supported directly inJavascript [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 appearslightweight and readable. However, there is much contention in the web community about thehuman readability aspect of JSON [20]. It is argued that JSON is not as readable as XML as the syntaxis familiar only to developers. The counter-argument to this is that human readability should comesecondary to the ease of processing.Carrie Louise Hall Chapter 2 | Page 15
  16. 16. The following JSON construct representa the same File menu previously discussed in XML. Each itemis distinguished by using syntax similar to an array; the square brackets are used to specify a list ofitems which contain a title and an action. Individual list elements are separated by a comma. { "menu": "File", "commands": [ { "title": "New", "action":"CreateDoc" }, { "title": "Open", "action": "OpenDoc" }, { "title": "Close", "action": "CloseDoc" } ] }Figure 6: JSON representation of a ‘File’ menu2.3 Android2.3.1 OverviewAndroid is an open source software stack that includes the operating system, middleware, keyapplications, and a set of libraries to assist application development [21]. Android provides an openalternative to traditional smartphones with proprietary operating systems and developers can takefull advantage of the open source framework and powerful SDK libraries [21]. It is this opennesswhich make Android compelling for developers [22] as the data on the device (such as contacts andtext messages) are easily retrievable using the frameworks provided.Android now has the largest percentage of mobile subscribers. Figure 7 shows the growth of mobilesubscribers over the last year and a half.Figure 7: Graph showing the percentage of mobile subscribers since October 2009Carrie Louise Hall Chapter 2 | Page 16
  17. 17. 2.3.2 ArchitectureThe components of Android are designed as a stack; the bottom layer is the Linux kernel and the toplayer contains the applications.Figure 8: Android component stack diagramImage available from: http://developer.android.com/images/system-architecture.jpg2.3.3 FeaturesThere 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 applicationinclude:  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 DatabasesMany of these functions, such as Google Maps and background services, are not found in othermobile operating systems.Carrie Louise Hall Chapter 2 | Page 17
  18. 18. 2.3.4 ApplicationsAndroid applications are written using Java and XML. The architectural essence of Androidapplications 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.ActivitiesActivities 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 mustbe registered with the application by declaring it in the application manifest. Moving betweenActivities requires creating an Intent with the name of the class that needs to be loaded, and thecalling the startActivity( ) method to run the new Activity. Intent intent = new Intent(this, SignInActivity.class); startActivity(intent);Figure 9: Calling an ActivityAnother way to start an Activity is to use the startActivityForResult( ) method which takesan extra integer parameter to distinguish where the Activity was called from. This is useful in manyscenarios, for example if an Activity can be started to edit data as well as add data then the integercan represent the action that needs to be performed. Further to this, an integer representing theresult is passed back to the calling Activity once the new Activity ends.Carrie Louise Hall Chapter 2 | Page 18
  19. 19. ViewsViews 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, LinearLayoutand GridView.Figure 10: Some of the Views used within AndroidA full list of the Android Views is available at:http://developer.android.com/resources/tutorials/views/index.htmlResourcesTo 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 XMLresources to be externalised as well. Resources are kept in separate XML files, e.g. colors.xml. It iseasier to maintain and modify external resources, and allows different resources to be applied indifferent circumstances. Strings are of particular importance as externalisation allows easylocalisation of an application into other languages. Some examples of resources in Android areshown in Figure 11. <string name="app_name">bookfriend</string> <color name="beige">#ede8dd</color> <style name="LargeText"> <item name="android:textSize">20sp</item> </style>Figure 11: XML resources in AndroidCarrie Louise Hall Chapter 2 | Page 19
  20. 20. Diagram of an Android application XML Layout Java code XML Resources Figure 12: Diagram representing the major components of an Activity2.3.5 Android location servicesOne of the major features of Android is the availability of the Google Maps API. To create a map inan application, developers can make use of the MapView layout shown in Figure 13. Maps can becustomized to show marker items by using an Overlay. A GeoPoint is formulated from a longitudeand latitude value of a particular location. To attach a GeoPoint to an Overlay, an OverlayItemis used which is a collection containing a GeoPoint and a message that can be displayed when theitem is clicked. The Overlay can also specify the type of image, called a Drawable, which should beused to display the marker.Figure 13: Android MapView with customized OverlayCarrie Louise Hall Chapter 2 | Page 20
  21. 21. 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. January 2010: July 2010: Feb 2011: 2.1 released 2.2 released 2.3.3 releasedOct 2009: May 2010: Dec 2010: Mar 2011:2.0 released 2.1 revision 2 2.3 released 3.0 released 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. Carrie Louise Hall Chapter 2 | Page 21
  22. 22. Reading RadarReading Radar takes the New York Times bestseller list data and mashes it with Amazon informationin order to provide the most amount of information about this list of books in one place.2.4.2 Android MashupsProgrammable web only has 16 mashups listed under the Android category, and none of theserelate to books.IceCondorIceCondor is a GeoRSS feed reader for Android which combines locationdata with a Google Map. The data can be retrieved from several socialnetworking sites, or feed URL’s can be manually added. Markers are thenadded to the map and users can click on the marker to see the event.AroundMeThis mashup also uses location as a main theme butAroundMe identifies the user’s position and allowsusers to search for local businesses such as banks orrestaurants. It gathers images from Flickr andPanoramio, videos from YouTube and informationfrom Wikipedia.Carrie Louise Hall Chapter 2 | Page 22
  23. 23. Chapter 3. RequirementsThis chapter documents both the functional and non-functional requirements of bookfriend, andspecifies the data sources used to retrieve information.The following section relating to requirements will be formatted according to the IEEE-Std 830-1993structure which provides a list of topics that should be included in a Software RequirementsDocument. It is a generic specification and can be adapted easily to a wide range of projects. Arequirements document is used to describe the services and functions of a system and theconstraints under which the system must operate [24].3.1 General Description3.1.1 Product perspectiveHardwareThe application will run on Android powered devices.SoftwareThe 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 tosupport devices that used the v1 SDK. This decision was made as Android publish the percentageof users that use each of the versions of the SDK and less than 12% of devices use v1.6 or lower.MemoryThe application requires up to 3mb of space once installed.3.1.2 Product functionsScenarioA scenario is a set of actions that represents a path through the system [1]. Often they are morehelpful to end-users and stakeholders than function lists as they are easier to relate to [25]. Asuccess scenario for bookfriend is as follows:The user navigates to the application and loads it. They type in a book keyword and press ‘go’. Theyare shown a list of books and select the one that they want to read about. They are shown somebasic 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 booksthat they explore are saved into a list so that can be retrieved at a later date.Carrie Louise Hall Chapter 3 | Page 23
  24. 24. Use case diagramsA use case diagram is used to show the high-level functionality of the system. The features in Figure15 show the features present at the end of implementation.Figure 15: Use case diagram for the bookfriend applicationCarrie Louise Hall Chapter 3 | Page 24
  25. 25. 3.1.3 User characteristicsThe users of the bookfriend application are not known explicitly so a wide range of users must beconsidered. This includes users of all age ranges and technical ability.3.1.4 Assumptions and dependenciesIt is assumed that the device has enough memory to store the application and run it, and that thedevice has not been modified in any way that might make it difficult to emulate. The bookfriendapplication also assumes that a web connection is available as without a connection the applicationcannot function.3.2 Specific requirements3.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 application3.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 second3.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 listCarrie Louise Hall Chapter 3 | Page 25
  26. 26. 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 fail3.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 languages3.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 connection3.3 Data sources & APIsDuring the early stages of this project it became clear that there was a lot of information aboutbooks available from various sources, and there was some overlap in the data provided. It wasdecided to integrate many sources in order for the system to gracefully degrade, so that if there is afailure 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 thebookfriend 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.html3.3.1 List of data sourcesGoogle BooksGoogle provide a data API which does not require authentication and includes full-text searches forbooks and retrieves book information, ratings and reviews [26]. It returns book data in XML format.BibliotravelBibliotravel is a website which combines books and travel in order to find books that are writtenabout a particular place. It relies heavily on user input for this information and so the list of books isnot comprehensive but it is steadily growing. Bibliotravel do not have a data API but the developerswere contacted and they provided an RSS feed of all the locations of books with links to the booksthemselves. This made the website accessible to a parser without needing to use screen-scraping.GoodreadsGoodreads is a social networking site for readers. Their API requires a developer key and restrictsrequests of the API to one per second. Additionally, the Goodreads name or logo must appear onany location where their data appears, and data cannot be stored for more than 24 hours. The APIprovides book, author information and reviews in XML or JSON format.Carrie Louise Hall Chapter 3 | Page 26
  27. 27. LibraryThingLibraryThing is also a social networking site for readers. The APIs are extensive and include tools tocross reference books, so given an ISBN it is possible to find the title and vice versa. The API requiresa developer key and limit usage to 1000 requests per day. It contains a wide variety of informationabout books and authors that is not found in other sources, such as the author place of birth, awardswon, author education history, and quotations from the book.BookmoochThe only restriction when using the API for Bookmooch is the limit of 10 requests per second. Thesite is a community for exchanging used books and uses Amazon’s Product Advertising API for someof its data. Along with book information, the API provides lists of users who want or have the bookto ‘mooch’. The results are in XML format.ISBNDBThe 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 therequest.TwitterApplications that use the Twitter API need to register and receive a developer key. The API is quiteextensive but the for context of this application only the ‘search’ API will be used to find tweetsrelating to books or authors. The guidelines for using Twitter content state that the name of the userwho posted the tweet needs to be included and that the content of the tweet must not be modifiedin any way.FlickrSimilar 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 andreturns results in XML or JSON format.Carrie Louise Hall Chapter 3 | Page 27
  28. 28. 3.3.2 DiagramThe following diagram (Figure 16) shows the APIs used related to the functions that are present inthe bookfriend application.Figure 16: APIs used and functions they perform3.4 SummaryThis chapter specified the requirements and features of the bookfriend application, as well aslisting the data sources used to gather information about books for use in the application.Carrie Louise Hall Chapter 3 | Page 28
  29. 29. Chapter 4. DesignThe Design chapter will discuss the issues that are raised when developing mobile applications, anddiscuss the Android guidelines and best practice for application design. The chapter will also reviewthe designs for the bookfriend application.4.1 Developing for mobile devices4.1.1 Hardware considerationsDevelopers for desktop or web applications in recent years have gradually moved away from theidea that hardware is the bottleneck for applications, as hardware is increasingly powerful and lessexpensive. Although there are advanced capabilities of mobile devices including accelerometers,GPS, Wi-fi connectivity, touch-screens and environmental sensors, they are still limited incomparison to desktop computers due to the size of the device and inability of upgrades. Mobiledevices 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 lifeLow-specificationTo combat some of these potential problems, developers must be aware and optimize code as muchas possible so that applications run quickly. At the start of this project, Android applications wereonly installed to the internal phone memory and did not allow applications to be installed to an SDcard, so applications needed to be as small as possible when compiled. However, Android recentlyupdated their SDK to allow this so compiled size is less of an issue.Low connection speedsMobile devices have an unreliable connection and a wide range of connection speeds [27]. In thisrespect, 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 asuitable time. Furthermore applications should be able to handle losing connections in the middle ofa process [21].4.1.2 Android Best PracticesAndroid provide several areas that they believe should be the main considerations for an Androiddeveloper, and this includes guidelines on design best practices. These areas are performance,responsiveness and seamlessness.Carrie Louise Hall Chapter 4 | Page 29
  30. 30. PerformanceDesigning for performance ensures that applications are fast and do not waste battery life. Theguidelines 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; } }ResponsivenessResponsive applications are those that do not feel sluggish, take a long time to process input, orfreeze for a significant time. If an application does not respond to an input event within 5 secondsthen the Android system will show an Application Not Responding (ANR) dialog (shown in Figure 17).Figure 17: Application Not Responding (ANR) dialogIf the application has time-consuming background processing, to avoid ANR applications shouldshow users that progress is being made, e.g. by using a ProgressBar.Carrie Louise Hall Chapter 4 | Page 30
  31. 31. SeamlessnessApplications 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 applications4.1.3 CompatibilityThe range and number of Android devices available means a potentially huge audience forapplications [28]. The manifest file of an application can specify the minimum requirements of anapplication so devices that do not meet the requirements will not be able to download theapplication from the Android Market. As previously mentioned, new versions of Android arereleased regularly. Android commit to protecting applications developed for older versions so thatthey are ‘future-proof’.4.1.4 Screen TypesApplications 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 importantinformation.Device screen sizes are separated into the following categories:  Small  Normal  Large  XlargeScreen 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 sizesImage available from: http://developer.android.com/guide/practices/screens_support.htmlCarrie Louise Hall Chapter 4 | Page 31
  32. 32. In Android it is possible to provide custom resources, such as images, depending on the screen sizeor screen density. Screen density is based on screen resolution and refers to the spread of pixelsacross the physical width and height of the screen. UI elements on low density screens will appearlarger than on higher density screens.It is important to ensure that all of the layouts used within each screen of the application will scalesuccessfully on differently sized devices. This can be achieved in the XML layouts by following thesebasic 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 size4.1.5 Android User Interface GuidelinesIcon DesignAndroid provides some guidelines for designing launcher icons to represent applications on theHome 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 materialAndroid provide images for use in Activities, menus and list items. To ensure consistency, theseimages should be used where possible.4.1.6 Guidelines used within bookfriendThe 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 generallyRelativeLayout styles which allowed proper scaling of elements. The following baselineassumptions 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 shortUsing these principles ensures that the application can cope with the ‘worst case’ scenario.Carrie Louise Hall Chapter 4 | Page 32
  33. 33. 4.2 Designs for bookfriend4.2.1 Logo and iconThe 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 anicon that is unique. Some examples of icons used by other books are shown in Figure 19:Figure 19: Launcher icons used by Android book applicationsFigure 20: The bookfriend logoThe launcher icons shown in Figure 21 provide an example of how different icon sizes can beprovided to scale up and down as necessary. These icons represent the application on the homescreen.Figure 21: The bookfriend launcher iconsCarrie Louise Hall Chapter 4 | Page 33
  34. 34. Figure 22: A menu screen and home screen and with the bookfriend launcher icon displayed4.2.2 FontThe font used for the logo is Colaborate-Bold which is an OpenType font.Figure 23: Font used in the bookfriend application4.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 designCarrie Louise Hall Chapter 4 | Page 34
  35. 35. 4.2.4 Photoshop designThe first design for the application has many of the same features that are found in the currentversion. 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 morereadable and usable by including a home button, making the background lighter, increasing the linespacing and minimising the information displayed on the main screen.Figure 26: Version 1 of the interface design Figure 25: Final design of the interfaceCarrie Louise Hall Chapter 4 | Page 35
  36. 36. Chapter 5. ImplementationThe implementation section will discuss the development process and how the work was divided intoiterations. It then highlights the design of the code itself following coding best practices and utilisingdesign patterns. Detailed discussion of some more complex implementation is explored and finallythe project architecture is shown in order to demonstrate how the system components areconnected.5.1 Development Process5.1.1 Development environmentThe Android SDK was installed which comes bundled with an AVD manager tool (Figure 27: The AVDManager’s Available Packages panel which shows SDK components ) which allows downloading ofmultiple 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 AndroidDevelopment Tools (ADT). The ADT plugin gives developers a fully integrated environment withinEclipse to create and build Android applications, which includes creating user interfaces, addingAndroid 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 componentsCarrie Louise Hall Chapter 5 | Page 36
  37. 37. 5.1.2 Agile DevelopmentAt the beginning of the project it was decided that an agile approach would be more beneficial thana 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 acceptsthe idea that changes in projects are common [29].It is ideally suited to small teams that have nofixed 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 prioritisedThis project was split into several phases which were tracked using Basecamp6, an online projectmanagement tool which allowed flexible milestones and to-do lists. Requirements Review Design ImplementationFigure 28: Agile development process6 http://basecamphq.com/Carrie Louise Hall Chapter 5 | Page 37
  38. 38. 5.1.3 Phases of developmentBefore each iteration, informal planning was undertaken using a whiteboard and the developmenttime was estimated. Often the features were developed independently of the overall project sothere was no instability within the application.Phase 1: Book InputIn this phase the initial Android application is set up and the functionality to search for books inmultiple ways is developedIteration 1: Beginning APIsThe Google Books API is examined using a Java project with the aim of understanding how to send arequest and obtain results from the API.Iteration 2: Book Input PhaseThis phase is the beginning of the Android implementation and involves setting up several screenswhich allow the user to type in the name of a book and have a list of books presented to them byusing the Google Books API code previously written.Iteration 3: Find Books by LocationThe Bibliotravel feed of locations are geo-coded and mapped using a Google Map view in theAndroid application.Iteration 4: Scanning PhaseThe ZXing Android library for scanning barcodes is added and integrated into the Androidapplication.Phase 2: Gathering Book DataUsing a Java project, the different APIs are integrated into a set of basic re-usable components.Iteration 1: Core ComponentsCreation of basic components are implemented such as Book, Review and ImageGallery.Iteration 2: Google integrationBook information from Google is integrated into core components.Iteration 3: GoodreadsInformation from Goodreads is integrated into core components.Iteration 4: Flickr APIInformation from Flickr is integrated into core components.Carrie Louise Hall Chapter 5 | Page 38
  39. 39. Phase 3: Integrating Book DataAt this point we have some information about books which needs to be moved to the Androidapplication. During this phase a bridge is created between the API connectors and the screens. Toseparate the components, the façade design pattern is used to create a single point of contactbetween the two sub-systems.Iteration 1: IntegrationAll the core components are added to the Android project and tested to ensure data is stillretrievable.Iteration 2: FaçadeA BookMashup is created with functions to call the API classes. From this point on no calls to the APIclasses are made from within the Android classes.Iteration 3: Calling the FaçadeThe screens which were previously filled with dummy data are populated with information from theAPIs, called through the BookMashup.Iteration 4: TestingThe application is tested on a wide range of books in order to locate and correct any bugs with theAndroid layouts or the back-end functionality.Phase 4: Performance enhancingThe code is evaluated to ensure that it will run quickly and follows best practices.Iteration 1: Background processesTime consuming API calls are moved onto background threads so that the user interface does nothang when data is being retrieved. The data is then fed in as it becomes available meaning the timethe user has to wait for some data is greatly reduced.Iteration 2: RefactoringDuring 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 InputThis phase includes validating ISBN numbers and matching the most likely book to the keyword thatthe user entered, rather than displaying a list of books.Carrie Louise Hall Chapter 5 | Page 39
  40. 40. Phase 5: Integration of more APIsMore APIs can be added easily to the project at this stage, as the hierarchy is established and fullyworking, so new APIs simply need a list of elements to retrieve and a place on the screens to displaythe data.Iteration 1: LibraryThing APIInformation from LibraryThing is integrated into core components.Iteration 2: BookMooch APIInformation from BookMooch is integrated into core components.Iteration 3: Data fallbackSeveral sources contain the same information so the system should use other sources if one is notavailable.Phase 6: User InterfaceAt this stage there Is a lot of information about books and a number of screens which are tidied up toensure consistency and evaluated to make sure they are intuitive.Iteration 1: AnalysisThe screen designs were examined and the flow through the screens edited if necessary.Iteration 2: Ensure consistencyThe menu bars, text spacing, margins and buttons must be consistent across screens.Iteration 3: User feedbackWhen a background task is being undertaken the user needs to be informed by unobtrusive meanssuch as loading images.Phase 7: Integration of more APIsThe addition of more APIs is undertaken. As every API is added, the screens are coded to the samestandard as the refactored code, designed to be compatible with the other screens, and tested toensure no inconsistencies surface.Iteration 1: Twitter APIInformation from Twitter is integrated into core components.Iteration 2: ISBNDB APIInformation from ISBNDB is integrated into core components.Carrie Louise Hall Chapter 5 | Page 40
  41. 41. 5.2 Architecture5.2.1 Project hierarchyBookfriend 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.Carrie Louise Hall Chapter 5 | Page 41
  42. 42. 5.2.2 Package diagramThe following diagram (Figure 29) show the packages used in the bookfriend application. The size ofthe packages in the diagram demonstrate the relative size of each package within the code.Figure 29: Packages used within the bookfriend application5.2.3 Core components class diagramThese components are provide the base for the application and are independent from the Androidfunctionality.Figure 30: Core components class diagramCarrie Louise Hall Chapter 5 | Page 42
  43. 43. 5.2.4 Helper components class diagramFigure 31: Helper components class diagram5.2.5 Android classesA class diagram is not appropriate to demonstrate the Android classes because each one representsa 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 acustom adapter which will be explained in the next section.Figure 32: Android classesCarrie Louise Hall Chapter 5 | Page 43
  44. 44. 5.3 Object-oriented design5.3.1 Design PatternsDesign 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 helpdevelopers with various levels of experience to communicate easily. One of the important things tonote about design patterns are that they do not provide exact implementation details, rather theychange the way developers think about problems by providing a set of principles.These principles are called General Responsibility Assignment Software Patterns (GRASP) and arebased 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 GRASPprinciples.This next section will first highlight some the GRASP principles that apply to the development of thebookfriend application, and continues to discuss GoF design patterns that were used.Chapter 4 of this report highlighted some Android guidelines for developing responsive and efficientapplications and some of these guidelines contradict those set out by the GRASP principles. TheAndroid guidelines were favoured over these principles when they were in direct contradiction.GRASP principlesInformation ExpertA class should be given responsibility only when they have the information necessary to fulfil theresponsibility.CreatorOnly 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 ALow CouplingDependencies and links between classes should be kept to a minimum so that changes to code makeless impact.High CohesionEach class should be focused on one task so that they are easier to understand and maintain.PolymorphismWhen alternative behaviours are present for a class, assign responsibility using polymorphicoperations that implement a common interface.Carrie Louise Hall Chapter 5 | Page 44
  45. 45. Pure FabricationCreate fabricated classes to interface with real-world concept classes when necessary to keepcoupling low and cohesion high.IndirectionAssign intermediate objects the responsibility to mediate between components in order to keepcoupling low.Protected VariationsIdentify points of variation and provide stable interfaces around them. Also known as InformationHiding.GoF design patternsFaçadeFaçades are a common unified interface to a disparate set of classes or subsystems [1]. By using theFaçade Pattern a complex subsystem can be accessed though a single, easy-to-use interface.SingletonFaçades are often accessed via the Singleton pattern and ensures that only one instance of an objectis created. In Java this can be ensured by making the constructor private so that instances of theclass cannot be instantiated. It moves away from the idea that objects need to be passed around andinstead can be accessed globally without creating multiple objects. To do this, the method to returnthe singleton must be static and it can be synchronised so it is thread-safe.AdapterAdapters are used to resolve incompatible interfaces by using Polymorphism to provide a stableinterface.ObserverThe idea of separation of concerns aims to keep the application logic separated from the userinterface. The Observer pattern “defines a one-to-many dependency between objects so that whenone object changes state, all of its dependents are notified and updated automatically” [31].Carrie Louise Hall Chapter 5 | Page 45
  46. 46. Decisions for the bookfriend applicationFaçadeThe BookMashup is a Pure Fabrication and was created as a Façade created using a Singleton andpromotes 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 aboutbooks. It also performs some more complex functions to organise the data, which keeps the APIclasses Highly Cohesive.An interesting point to note, is the generic Façade pattern encourages lazy initialisation which meansthat the instance is not created until it is requested. Lazy initialisation is preferred as it avoidsexpensive creation work if the instance is never actually accessed. However, eager initialisation wasused 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. 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 Figure 34: Diagram to show how the Façade separates the application from the interfaceCarrie Louise Hall Chapter 5 | Page 46
  47. 47. AdapterThe API class hierarchy is an example of the Adapter pattern. All of the classes are subclasses ofAPIConnector, which is focused on creating and maintaining a connection to a data source. Thisleaves the API classes solely responsible for parsing the response ensuring all classes are HighlyCohesive and guarantees Protected Variations.Traditionally the class names should include ‘Adapter’, i.e. ClassAdapter. However, Adapters areused within Android as a bridge between data and the graphical interface and for this reason the APIclasses were named ‘Helper’, as shown in Figure 35.Figure 35: Adapter pattern in the bookfriend applicationObserverIn the bookfriend application the Android Adapter classes are examples of the Observer patternwhich are Highly Cohesive and provide Protected Variations. Figure 36: Diagram representing the Observer patternAn example of an Adapter using the Observer pattern is for the generation of the list of bookswhen a user enters a keyword. It is possible in Android to simply attach an ArrayList of elementsto a BaseAdapter.Carrie Louise Hall Chapter 5 | Page 47
  48. 48. In the bookfriend application more customization was required so that the layout could include abook title, author name, and book image as shown in Figure 37.Figure 37: The bookfriend customized list viewBefore the user enters a keyword, the ListView element below the text box is empty. Once theysend their request, a loading image is shown and the request to the Google Books API is made on abackground thread using Android’s AsyncTask. Once the list of books is retrieved and convertedinto an ArrayList, an event is published to tell the system that the activity has completed whichprompts the ArrayList to be bound to the ListView.The full code listing for an adapter is in Appendix 1.5.4 Implementation DetailsIn this section more details about various aspects of the application will be discussed.5.4.1 Retrieving data from a data sourceAndroid 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 caseHttpUrlConnection, in order to open connections and retrieve data. The connection to a datasource is made only in the APIConnector class mentioned in the Adapter Design Pattern sectionearlier in this chapter. The URLs to connect to are found within the subclasses of APIConnectorand are passed into the superclass, which opens a connection to the URL provided using theopenConnection method. Next, the details of the connection are attached which include the readand 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 aDocumentBuilder parses the request into a Document. The root of the document is saved to avariable which is then parsed by the individual classes that extend the APIConnector. Finally theconnection is closed. Errors during any of these steps are handled by writing errors to the log andreturning an empty result which then will display a notification on the screen.Carrie Louise Hall Chapter 5 | Page 48
  49. 49. 5.4.2 Searching for a bookManual entryThe bookfriend application allows the user to search by book keyword, author, or ISBN. In theorythe user can search any combination of keywords and still retrieve the correct results, but thisseparation has been made as there are slight differences in how a search is performed in each case.Figure 38: Entering a bookWhen searching by ISBN the system first validates the ISBN is correct by using the check digit at theend of the ISBN which has an 11-digit range from 0 to 10 (where 10 is represented by X). In thisapplication this check was achieved by including the Apache commons package into the bookfriendproject. Using this validation means that incorrect ISBNs are found very quickly in comparison tosending the ISBN through to the Google Books API, which would return no results for an incorrectISBN.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 toinclude the inauthor search operator which only searches the author field for a match.http://books.google.com/books/feeds/volumes?q=inauthor:jane+austenBarcode scanningThe functionality for barcode scanning comes from another Android application named BarcodeScanner created by ZXing. Barcode Scanner is not included as part of the core application and due tothis, it is necessary to have the application installed onto the device. The bookfriend applicationfirst checks to see if the application is installed, if it is then it carries on as normal and if not then itprompts the user to install the application. This is shown in Figure 39.Figure 39: Diagram to show barcode scanningCarrie Louise Hall Chapter 5 | Page 49
  50. 50. Next the system loads the Barcode Scanner application which runs the camera and the user can scana barcode. The barcode is then sent back to the bookfriend application which validates if it is acorrect ISBN. If it is not correct then a notification is shown to the user. Once a correct ISBN has beenfound, the system queries the Google Books API which returns the book.Searching by locationBibliotravel 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 AndroidGeoPoint. 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 thatlocation from Bibliotravel and displays them to the user.Figure 40: Android MapView for searching books by location5.4.3 Finding book locationsMapViews are also used to display locations that are mentioned within a book. These fall under thecategories of book locations, publisher location and author place of birth, and comes from theLibraryThing API as place names e.g. London. To find the latitude and longitude of the location, itmust be geocoded using the Android GeoCoder class. The full code listing for the Overlay can befound in Appendix 2.A separate Overlay was created for each of these categories. Figure 41 shows the marker itemsthat are used to represent these locations.Figure 41: Marker images for displaying book locations, publisher location and author birthplaceCarrie Louise Hall Chapter 5 | Page 50

×