development of a location-based iphone application for ...mdv/courses/cm30082/projects... ·...
TRANSCRIPT
Development of a location-based
iPhone application for sport tracking
for the degree of BSc (Hons) Computer Information Systems of the
University of Bath 2009 – 2010
i
This dissertation may be made available for consultation within the University Library and may be photocopied or lent to other libraries for the purposes of consultation.
Signed:
Gareth Talty
ii
Development of a location-based iPhone application
for sport tracking
Submitted by: Gareth Talty
COPYRIGHT Attention is drawn to the fact that copyright of this dissertation rests with its author.
The Intellectual Property Rights of the products produced as part of the project belong to the University of Bath (see http://www.bath.ac.uk/ordinances/#intelprop).
This copy of the dissertation has been supplied on condition that anyone who consults it is understood to recognize that its copyright rests with its author and that no quotation from the dissertation and no information derived from it may be published without the prior written consent of the author.
Declaration This dissertation is submitted to the University of Bath in accordance with the requirements of the degree of Batchelor of Science in the Department of Computer Science. No portion of the work in this dissertation has been submitted in support of an application for any other degree or qualification of this or any other university or institution of learning. Except where specifically acknowledged, it is the work of the author.
Signed:
Gareth Talty
iii
CW submission sheet
iv
Abstract
This dissertation develops a location-based application for the Apple iPhone aimed specifically at runners called ‘RunningCoach’. While this project is not directly concerned by the functionality of RunningCoach, attention is paid to the iPhone SDK as a platform for developing such applications. A thorough literature review is included, covering the key aspects of developing mobile running assistants and the software development of RunningCoach is documented. The project provides extensions to the existing iPhone SDK to improve the effectiveness of the SDK for creating ‘CoreLocation’ applications – applications that use GPS to determine the geolocation of the user. These results are discussed and an evaluation of the results is presented.
~
v
Acknowledgements
I would firstly like to thank my dissertation supervisor, Mr Alan Hayes, without whom this project would not have been at all possible. Such a consistent source of guidance, knowledge, and direction has helped this project become what it is today. I am indebted to Mr Hayes for his support both as a Project Supervisor and Director of Teaching for the Department of Computer Science.
I also express my appreciation to everyone who participated and contributed towards this dissertation, both directly and indirectly. Again, without your input, this project would have fallen at the very first hurdle.
Finally it’s my greatest pleasure to express my love and gratitude towards all of my close friends and family who have supported me in unthinkable ways throughout the lifetime of this project.
~
vi
Contents
1! Introduction 1!1.1! Project Overview....................................................................1!1.2! Project Roadmap....................................................................2!
2! Literature Survey 3!2.1! Introduction ...........................................................................3!2.2! Background & Domain Research ...........................................3!
2.2.1!Apple, iPhone & The App Store 3!2.2.2!Mobile Sport Tracking & Analysis 4!2.2.3!User Interaction Channels 4!
2.2.3.1! Visual Interaction 5!2.2.3.2! Haptic Interaction 5!2.2.3.3! Auditory Interaction 5!2.2.3.4! Gesture Based Interaction 6!
2.2.4!Mobile Positioning & Geolocation 6!2.2.4.1! Cell Identifier (Cell ID) 7!2.2.4.2! GPS 7!2.2.4.3! aGPS 8!2.2.4.4! Broadband Satellite Network 8!2.2.4.5! Comparative Analysis 8!
2.3! Existing Solutions...................................................................9!2.3.1!From The App Store 9!
2.3.1.1! iMapMyRun 9!2.3.1.2! MotionX-GPS 11!2.3.1.3! RunKeeper Pro 12!
2.3.2!Alternative Implementations 13!2.3.2.1! Nike+iPod 13!
2.3.3! Solution Accuracy 14!2.3.3.1! Test Conclusions 14!
2.4! Implementation .................................................................... 15!2.4.1!Objective C 2.0 15!2.4.2! iPhone Design Patterns 15!
2.4.2.1! Delegation & Target/Action 15!2.4.2.2! Model-View-Controller 16!
2.4.3! iPhone SDK & Software 16!2.4.3.1! Cocoa Touch 17!2.4.3.2! Tools 17!
2.4.4! iPhone Development Environment 18!2.5! Conclusions & Next Steps .................................................... 18!
2.5.1! Software Development Process 18!
vii
3! Requirements 20!3.1! Introduction ......................................................................... 20!3.2! Requirements Elicitation ...................................................... 20!
3.2.1!Literature Review 20!3.2.2!Google Survey 20!
3.3! Requirements Prioritisation ................................................. 22!3.4! Hardware & Software Requirements.................................... 23!3.5! Functional Requirements ..................................................... 24!3.6! Non-Functional Requirements.............................................. 27!
4! Design 28!4.1! Introduction ......................................................................... 28!4.2! Architectural Design ............................................................ 28!
4.2.1!Persistent Data 29!4.3! UML Modelling .................................................................... 30!
4.3.1!Class Diagram 30!4.3.2! Sequence Diagram 31!4.3.3!Proposed Methods 31!
4.3.3.1! Profile Class 31!4.3.3.2! RunningCoachViewController Class 32!4.3.3.3! Run Class 34!4.3.3.4! Common Methods 34!
4.4! User Interface Design ........................................................... 35!4.4.1!Application User Interface 35!4.4.2!Profile View 36!4.4.3!RunningCoach View 37!4.4.4!History View 37!4.4.5! Settings View 38!
4.5! Advancing To Implementation............................................. 38!
5! Implementation & Testing 39!5.1! Introduction ......................................................................... 39!5.2! CoreLocation ........................................................................ 39!
5.2.1! Implementing CoreLocation 39!5.2.2!Rapid Target Test 40!5.2.3!Host Environment Simulation 41!
5.3! Implementing The User Interface ........................................ 42!5.3.1!Profile User Interface 43!
5.3.1.1! Final Implemented Interface 44!5.3.2!RunningCoach User Interface 44!
5.3.2.1! Mapping Actions & Outlets 44!5.3.2.2! Final Implemented Interface 46!
viii
5.3.3! Settings User Interface 46!5.4! Testing ................................................................................. 47!
5.4.1!Requirements Verification 47!5.4.2!Failed Requirements 47!5.4.3!Performance Testing 48!
5.4.3.1! Testing Memory Leaks 48!5.4.3.2! CPU Testing 49!
5.4.4!Beta Testing 50!
6! Results & Evaluation 51!6.1! CoreLocation Simulation ...................................................... 51!6.2! CoreLocation Accuracy ........................................................ 51!6.3! CoreLocation Implementation Guidelines ............................ 52!6.4! RunningCoach Evaluation.................................................... 52!
7! Conclusion 55!7.1! Project Overview.................................................................. 55!7.2! Future Work ........................................................................ 57!
8! References 58!
9! Appendices 62!Appendix A – Survey & Results ................................................. 62!Appendix B – Requirements Verification Testing Log ............... 64!
9.1.1!Hardware & Software Requirements 64!9.1.1.1! Target Requirements 64!9.1.1.2! Host Requirements 64!
9.1.2!Functional Requirements 64!9.1.2.1! Profile Requirements 64!9.1.2.2! RunningCoach Requirements 65!9.1.2.3! History Requirements 66!9.1.2.4! Settings Requirements 66!9.1.2.5! User Interface Requirements 67!
9.1.3!Non-Functional Requirements 67!9.1.3.1! Application Requirements 67!9.1.3.2! User Interface Requirements 68!
Appendix C – Source Code ......................................................... 69!
ix
Table of Figures Fig. 1.1: Project Roadmap 2!
Fig. 2.1: iTunes App Store Submissions (148Apps.biz, 2009) 3!
Fig. 2.2: Example of Network Triangulation (SearchEngineLand, 2008) 7!
Fig. 2.3: iMapMyRun Map Interface 9!
Fig. 2.4: MotionX-GPS Interface 11!
Fig. 2.5: RunKeeper Pro Interface 12!
Fig. 2.6: Nike+iPod Sports Kit 13!
Fig. 2.7: Model-View-Controller Design Pattern (developer.Apple.com, 2009) 16!
Fig. 2.8: iPhone SDK Architecture 16!
Fig. 2.9: Software Development Process (Waterfall Model) 18!
Fig. 2.10: Spiral Software Process Model 19!
Fig. 3.1: iPhone Owners 20!
Fig. 3.2: Application Use 21!
Fig. 3.3: Social Networking Site Usage 21!
Fig. 3.4: RunningCoach Important Functionality 22!
Fig. 4.1: High-Level Architectural Design 28!
Fig. 4.2: SQLite Database Structure 29!
Fig. 4.3: RunningCoach Class Diagram 30!
Fig. 4.4: RunningCoach ‘Start Run’ Sequence Diagram 31!
Fig. 4.5: RunningCoach Action Sheet Example 33!
Fig. 4.6: Typical Apple Tab Bar 35!
Fig. 4.7: Custom RunningCoach Tab Bar 35!
Fig. 4.8: Profile Wireframe Design 36!
Fig. 4.9: RunningCoach Wireframe Design 37!
Fig. 4.10: Settings Wireframe Design 38!
Fig. 5.1: Initialising LocationManager 39!
x
Fig. 5.2: RunningCoach Rapid Test 40!
Fig. 5.3: CoreLocation Simulator Workaround 41!
Fig. 5.4: Interface Builder in Mac OS X 42!
Fig. 5.5: Linking UITableView to dataSource outlet 43!
Fig. 5.6: Profile UI: Wireframe to Implementation 44!
Fig. 5.7: Connecting totalDistanceTravelledLabel Outlet 45!
Fig. 5.8: Connecting startButton Action / Outlet 45!
Fig. 5.9: RunningCoach UI: Wireframe to Implementation 46!
Fig. 5.10: Settings UI: Wireframe to Implementation 46!
Fig. 5.11: 'Instruments' Performance Testing 48!
Fig. 5.12: RunningCoach CPU Profiling 49!
Fig. 6.1: iPhone Development Paradigm 51!
xi
Table of Tables
Table 2.1: GPS Positioning Techniques. Rao & Minakakis (2003) 8!
Table 2.2: Solution Testing 14!
Table 3.1: Target Requirements 23!
Table 3.2: Host Requirements 23!
Table 3.3: Profile Requirements 24!
Table 3.4: RunningCoach Requirements 24!
Table 3.5: History Requirements 25!
Table 3.6: Settings Requirements 26!
Table 3.7: User Interface Requirements 26!
Table 3.8: Application Requirements 27!
Table 3.9: User Interface Requirements 27!
Table 6.1: RunningCoach Benchmarking 53!
1
1 Introduction The 21st Century has seen a growing adoption of technology in the area of Health and Fitness. Alongside an increase in obesity levels in young adults and teenagers, the technological community has begun to explore the potential for technology to play a stronger role in promoting healthier lifestyles (Campbell et al., 2008).
There has been a particular increase in adoption of ‘exergaming’; games and applications that offer physical exercise as part of the gaming experience (Wylie & Coulton, 2008), and to date, a large number of technologies have been used successfully to increase energy expenditure in young people, such as the Nintendo Wii (Durant, 2009).
This increase in exergaming is supported by two important factors. Firstly, the processing power of mobile devices has increased dramatically in the past 10 years, and with the increasing popularity of powerful mobile devices (e.g. smartphones such as the iPhone), the potential for mobile exergaming is a real possibility for improving health and well being (Wylie & Coulton, 2008). Secondly, as of 2007 the penetration of mobile devices in Europe stands at 110% (International Telecommunication Union, 2008), implying that each member of the public now owns at least one mobile phone.
While this project is not necessarily concerned with exergaming per se, these recent changes in technology adoption have motivated the importance of this project, which will seek to utilise the Apple iPhone and its SDK to create mobile applications for runners. While a few similar applications exist, this project is unique since it contributes to the iPhone development community by exploring the SDK and its effectiveness for creating such applications.
1.1 Project Overview The main aim of this project is to design and implement an interactive, ‘mobile running assistant’ application named “RunningCoach” for use on the Apple iPhone. The project will not be directly concerned with providing a feature rich application, but rather will focus on assessing and (if necessary) improving the iPhone SDK to allow developers to enhance their use of the SDK for creating mobile applications, specifically mobile running assistants. This dissertation provides a number of key outcomes:
• Identification and feasibility study of the available mechanisms of physical tracking with the iPhone (e.g. GPS, mast-triangulation, …)
• Evaluation of similar existing products and services
2
• An integrated iPhone application that is capable of tracking physical activity
• Numerous enhancements to the iPhone SDK for creating mobile tracking applications
• An evaluation of effectiveness of the iPhone SDK for creating mobile tracking applications
• A framework and set of code that will aid geolocation development for the iPhone
1.2 Project Roadmap Fig. 1.1 illustrates the roadmap for this dissertation, with each phase representing an individual section of this report.
The project will formally begin with a Literature Review (pg. 3) that will identify relevant literature and resources for the purpose of this project, to ensure work is not simply repeated and this dissertation adds extra value to the domain. The software development will be documented in the Requirements (pg. 20), Design (pg. 28) and Implementation & Testing (pg. 39) chapters. The Results (pg. 51) of the software development will be discussed, before providing a thorough Evaluation and project Conclusion (pg. 55).
Fig. 1.1: Project Roadmap
Project Start Literature Review
Requirements
Design Implementation & Testing
Results
Evaluation Conclusion Project End
3
2 Literature Survey 2.1 Introduction Prior to designing and developing this application, it is necessary to fully understand the domain my application will enter, as this will help define the scope, relevance and importance of this project.
In order to avoid replication of existing work, this literature survey aims to identify the existing technologies, tools, concepts and applications available and to provide a thorough critique of the necessary technologies required to produce a mobile running assistant for the iPhone. At a slightly higher level, this literature survey will be used as a foundation for the initial requirements elicitation.
2.2 Background & Domain Research Before this project can formally begin, it is necessary to have a thorough understanding of many different aspects of the project development, such as the technologies and tools that will make this project possible.
2.2.1 Apple, iPhone & The App Store Apple’s App Store is the source of all certified Apple iPhone applications. Despite recent downfalls in the global economy, both supply and demand are exceptionally high for iPhone applications – Apple announced in 2009 that despite economic troubles, over 500 million applications have been
downloaded from the App store (CNet, 2009). Fig. 2.1 illustrates the increasing number of applications submitted per month to the App Store since its launch in May 2008. Apple announced that there are now 85,000 iPhone/iPod Touch applications available via the iTunes
App Store (Estilow, 2009). iPhone development has gained such popularity due to the success of the iPhone, plus the power of the iPhone SDK (section 2.4.3 – pg. 16). Although this project will not involve submission of the
Fig. 2.1: iTunes App Store Submissions (148Apps.biz, 2009)
"!#"""!$"""!%"""!&"""!'""""!'#"""!'$"""!
4
application to the App Store (due to University Intellectual Property Rights restrictions), it is worth noting that the App Store will be the resource for purchasing and downloading existing iPhone applications for the purposes of this project.
2.2.2 Mobile Sport Tracking & Analysis Many studies have been performed to support the justification of Mobile technologies for sports tracking and analysis. Rowland et al. (2009) discuss two mobile applications developed specifically for creating ‘mobile experiences’ for cyclists. Their research discusses the challenges of creating these mobile experiences and they derive eight conclusions that can be used to successfully create this type of application.
Although their study focuses on creating experiences for cyclists, they draw upon Human Computer Interaction based conclusions that can also be applied to running. The most vital aspect of their study is these conclusions, which focus mainly on the interaction between the user and application:
“HCI must be supported by studies concentrating on all the different modes [of transport], since each will have its own distinctive nature”. (Rowland et al., 2009)
They also begin to discuss the distinctive design choices to be made when choosing between providing user feedback through audio or visual based interaction channels. This discussion led me to further research in the area of User Feedback Interaction Channels (Section 2.2.3).
2.2.3 User Interaction Channels Although the iPhone provides a novel process of user interaction, based on touch screen technology and interactive gestures, Rowland et al. (2009) state that “digital media must adapt to cycling”, and indeed any physical sport. For this reason, the interaction between the user and RunningCoach will be carefully considered. As the application will be required to interact with the user in some form, it is necessary to understand the implications of the different types of interaction channels. It is to be assumed that while the user is interacting with the application (i.e. running) they will not be controlling and interacting with the visual interface. Using a mobile device under temporary unavailability of vision is often coined “blind use” (Silfverberg, 2003), and in these cases alternative methods of user interaction become essential.
5
2.2.3.1 Visual Interaction An important safety consideration for this project is that of safe visual interaction with the application. Lumsden & Brewster (2003) argue that for mobile devices that are being used in motion, users should not devote all or any of their “visual resource to interacting with the mobile device – it must remain with the primary task (e.g. walking or navigating the environment)”. This may seem a trivial point, however it is a necessary requirement that the majority of visual interaction with RunningCoach will be performed before running, and that all subsequent visual interaction is restricted to an absolute minimum.
2.2.3.2 Haptic Interaction Haptic interaction relates to the sense of touch, which includes both kinesthetic and tactile factors (Drake, 2003):
Kinesthetic Kinesthetic interaction takes place relating to the perception of the position of the body. In the case of the iPhone, kinaesthetic interaction can take place based on the runner’s spatial information; the physical location, orientation and the associated information (Siltanen et al., 2008). For example, if the application user physically passes between point X and point Y in Z seconds, either X, Y, or Z could be used to trigger an automated interaction with the application. The iPhone will constantly use the phone geolocation in order to provide interaction between the user and RunningCoach.
Tactile Tactile interaction originates from receptors in the skin, for example the feeling of direct pressure. This could take place whereby the iPhone provides the user with feedback by vibration.
2.2.3.3 Auditory Interaction Silfverberg (2003) argues that when visual interaction is unavailable, the auditory modality is often used as compensation. The author continues to explain that in public contexts, the use of auditory information is often limited by factors of social acceptability and privacy. Whilst this is an important aspect of auditory interaction, for the purposes of this project, auditory interaction may provide a valuable substitute in the trade off between privacy and safety.
Although the iPhone 3GS has built-in voice recognition, the iPhone 3G does not. For this reason, any auditory interaction between RunningCoach and the user will be a one-way communication channel from the application to the runner. The iPhone has a built-in internal speaker, with a frequency response
6
of 20Hz to 20,000Hz (Apple, 2009) and a standard 3.5-mm stereo headphone mini-jack to support this communication.
2.2.3.4 Gesture Based Interaction The iPhone supports the use of gestures, that is the physical manipulation of the handheld device, such as shaking or tilting (Siltanen et al., 2008). In a similar light to that of visual interaction, for the purposes of this project, gesture based interaction will not be used as an active form of communication. However, it may be necessary for the application to receive passive gestures from the user to perform certain actions. For example, RunningCoach could perform a passive test every 5 minutes to see if the iPhone Accelerometer detects motion (i.e. the user is running) and if not, turn off the geolocation tracking in order to preserve mobile battery life, or prompt the user in some way.
2.2.4 Mobile Positioning & Geolocation The Federal Communications Commission (FCC) in the United States, introduced a law called the wireless Enhanced 911 edict (E911), that stipulated mobile phone operators must be able to geographically locate a mobile phone making an emergency call (FCC.gov, n.d.). As this law was passed, the mobile community began to see the potential for providing services based on user locations, thus the domain of Location Based Services (LBS) was born (Golding 2008, pp.496-497).
The emergence of agile technologies such as GPS, mobile phone identification, and network mast triangulation have become more accessible and accurate in the mobile domain, paving the way for LBS to proliferate and aspirations for new and innovative LBS to increase (Rao & Minakakis, 2003).
This project relies on the requirement that LBS can be provided with the iPhone as the mobile device. Rao & Minakakis (2003) discuss 4 platforms that support LBS over existing mobile networks; Cell Identifier, Global Positioning Systems (GPS), Assisted Global Positioning Systems (aGPS) and Broadband Satellite Network. Each individual platform is useful for supporting certain types of application, and therefore advantages and disadvantages exist for each technique.
7
2.2.4.1 Cell Identifier (Cell ID) Cell ID tracking is perhaps the most rudimentary form of mobile phone positioning, and can vary greatly in accuracy, depending on the proximity and signal strength of nearby network masts. In order to improve the accuracy of position, network triangulation can be used, however it is still difficult to pin down an exact location within a few meters (Rao & Minakakis, 2003). Although triangulation (see Fig. 2.2) is a fairly basic method of positioning compared with the advanced position technologies available with modern
smartphones, it is worth mentioning that technologies such as assisted GPS (aGPS) are a hybrid concept that utilise both network-based geolocation (network triangulation) and typical GPS positioning. aGPS is covered in section 2.2.4.3 (pg. 8), with section 2.2.4.5 (pg. 8) providing a comparative analysis of identified techniques, with specific relevance to iPhone development and mobile running assistants.
2.2.4.2 GPS Like many modern smartphones, the iPhone (3G and later) has an inbuilt Global Positioning System (GPS) receiver as part of the ‘CoreLocation Framework’, a part of the iPhone SDK covered later in section 2.4.3 (pg. 16). GPS is a popular choice for modern mobile positioning, mainly due to it’s high level of accuracy (Saddique & Amir, 2005). GPS is normally accurate within 1-10 meters, which makes it an adequately accurate technique for tracking runners, although one of the challenges of using GPS as a mobile tracking tool is that there must be a clear line-of-sight between the device (the iPhone) and the satellite1, and that performance deteriorates in thickly populated urban areas (Saddique & Amir, 2005). While at first this disadvantage may not seem a problem, if a direct line of sight between a satellite and the iPhone is interrupted (e.g. the runner goes into a subway), design choices must be made to cope with this.
1 The Global Positioning System consists of 24 satellites that circle the Earth in a particular form so that several satellites fall within line of sight of any GPS receiver on Earth. (Saddique & Amir, 2005)
Fig. 2.2: Example of Network Triangulation (SearchEngineLand, 2008)
8
2.2.4.3 aGPS To combat the aforementioned limitation of GPS, Assisted GPS is often used, which is an aggregation of standard GPS technology and Cell ID tracking. This hybrid concept provides superior accuracy, availability and coverage (Djuknic & Richton, 2001). Assisted GPS may be the most logical candidate for tracking runners through an iPhone application, as the iPhone OS uses a framework called CoreLocation (see section 2.4.3: iPhone SDK – pg. 16) that enables this positioning technique (Mark & LaMarche, 2009).
2.2.4.4 Broadband Satellite Network Broadband Satellite Network’s would not be an appropriate method of geolocating a mobile phone. This method is more suitable for government architectures, as it is highly expensive and complex to maintain.
2.2.4.5 Comparative Analysis Table 2.1 displays an overview of the advantages and disadvantages of each technique. Table 2.1: GPS Positioning Techniques. Rao & Minakakis (2003)
Location Technology
Advantages Disadvantages
Cell ID Widespread infrastructure Low accuracy
GPS Good accuracy Expensive
aGPS Excellent accuracy Expensive
Broadband Satellite Network
Lower signal latency Complex to maintain
It is possible to deduce from Table 2.1 that the most appropriate tracking solution to use would be aGPS for the purposes of tracking runners. The iPhone 3G has a built in framework for management of aGPS applications, and for this reason, aGPS will be the selected technology for RunningCoach. Rao & Minakakis (2003) identify aGPS techniques to be ‘expensive’, both monetarily, and computationally. Computational expensiveness is important, as the iPhone 3G has 128MB of physical RAM and running out of memory is “very, very, easy” (Mark & LaMarche, 2009). For this reason it will be crucial to carefully consider memory allocation when designing and implementing the application.
9
2.3 Existing Solutions At the time of beginning this project, there were very few iPhone applications available in the App Store for the purposes of tracking runners. This has changed in the past few months, and there are now a number of running applications available. For this reason, I will perform a search and analysis of the most popular existing solutions, ensuring that RunningCoach is not a mere repetition of available software, and that I am able to learn from the existing applications. Where possible, the existing solutions will be tested first-hand, and all testing will take place on the same platform version RunningCoach will be designed for. For each solution, strengths, weaknesses and lessons learned have been identified.
2.3.1 From The App Store
2.3.1.1 iMapMyRun © 2009, MapMyFitness Inc. Version 3.0
iMapMyRun’s is a free iPhone application available through the iTunes App Store. The application’s unique selling point is that uses the iPhone aGPS to track a runner’s route, and log it on a map of the location. The main interface displays an interactive map that tracks your run and shows your current location. The application is supported by a website (http://www. MapMyRun.com), and the application automatically synchronises your run date with the web site upon completing a run. There is also the ability to switch between ‘map’ view (see Fig. 2.3) and ‘data’ view, to display the corresponding information from the existing run. The data screen tracks and displays the overall time and distance of the current run. iMapMyRun also features
the ability to manually enter workout data, so that indoor activities (such as treadmill running) can be easily logged and recorded. The application features the ability to export run data directly from the application to the social networking site ‘Twitter’, allowing you to share your workout data with friends and family.
Fig. 2.3: iMapMyRun Map Interface
10
Strengths
• A novel feature of iMapMyRun is the ability to export run data directly from the application to Twitter: http://www.twitter.com
• The application is well supported by http://www.MapMyRun.com that features an online community with discussion forums, an online training log and the ability to search for local events and races.
• The application is available from the iTunes store free of charge
Weaknesses
• The application has fairly poor latency, and the overall performance of the application is sub-standard. It is prone to crashes and parts of the application logic are flawed since the application occasionally experiences crashes (likely due to memory leaks), or remains stuck in a loop.
• iMapMyRun only gives very selective feedback. For example the application does not display the current or average speed, just the overall run time and distance.
• As the application is free, it is supported by banner advertisements, which impede the functionality of the application as they often pop up over a useful section of the interface.
Regardless of the issues with iMapMyRun, there are a number of features that will have an influence on this project. Firstly, iMapMyRun uses aGPS to track the users location and bearing, and provides feedback (in this case it is visual feedback on the data or map interface). This project will consider the use of maps, and will include feedback of run data (although it may not be purely visual feedback). One of the most interesting aspects of iMapMyRun is the integration of social networking. iMapMyRun allows the user to ‘tweet’ their previous run to Twitter. Social networking inclusion will likely influence the design of RunningCoach, as this will enable the application to communicate data to online communities, without the requirement for a supporting database or web infrastructure.
11
2.3.1.2 MotionX-GPS © 2003-2009 Fullpower Technologies, Inc. Version 7.2
MotionX-GPS is a premium GPS based tracking system available through the App Store. It is a heavily evolved application that is updated with new versions regularly. MotionX-GPS has received 2 million purchases at £1.79 and is very well established online as a successful iPhone GPS application. It advertises itself as a modern GPS application designed for Walking, Hiking, Running, Cycling, Biking, Sailing, Skiing, Flying and Racing. Although the scope of this application is much greater than for this application, there are a number of important features and lessons that can be learned from MotionX-GPS. Fig. 2.4 shows one of the many interface screens available on MotionX-GPS.
Strengths
• MotionX-GPS s an incredibly feature-rich application with many advanced functionalities, and at £1.79 is a great all-round GPS tool for multiple purposes
• The application supports GPX, which is the XML data format for the interchange of GPS data (e.g. waypoints, routes, tracks) from any source. This is particularly useful feature that is well supported by the online community.
• Features magnetic compass integration, meaning that an accurate bearing can be calculated alongside the GPS location
• The application allows the creation of personal waypoints, allowing the user to store favourite locations or routes.
• MotionX-GPS also supports the exporting of run data to social networking sites such as Facebook and Twitter.
Weaknesses
• MotionX-GPS is loaded with features and functionality and as a result it can often be slow to load the application. 3 tests all took ~11s.
Fig. 2.4: MotionX-GPS Interface
12
Furthermore this slowness is also occasionally experienced when switching between interface windows.
• The application sometimes failed to locate a valid GPS signal, even when the GPS receiver itself was successfully receiving one.
• As the phone is designed to be a multi-purpose GPS device, the interfaces are not specifically designed for the use of runners. The necessity of visual interaction with the touch-screen is very high, as the application is not designed specifically for runners.
• Many features are limited to the iPhone 3GS only (e.g. the magnetic compass feature)
In terms of functionality, MotionX-GPS is well developed, and has many useful features. However some of the features are only usable on later versions of the iPhone (e.g. 3GS). In terms of being a multi-purpose GPS device, it is very good and extremely powerful, however it is too ‘heavy’ to be an everyday application for running. The application features a large number of different interface screens, all of which have many interaction points. RunningCoach should ensure that the interface is specifically designed from a runner-oriented perspective.
2.3.1.3 RunKeeper Pro © 2009 FitnessKeeper, Inc. Version 1.6
RunKeeper Pro is the most expensive of the selected applications at £5.99. It is also the closest existing application to that proposed in this project. RunKeeper Pro uses aGPS to track running, with a supporting website http://www.runkeeper.com. RunKeeper integrates maps in a similar way to iMapMyRun. Is the ability to allow you to chose an iTunes playlist to start when you begin running. This application also features audio feedback, informing you of time or distance based metrics throughout the run.
Strengths
• The application features a very intuitive and useful design, supported nicely by the ability to receive audio feedback on your running performance.
Fig. 2.5: RunKeeper Pro Interface
13
• The iPhone's iTunes playlists are nicely supported and can be used directly without having to restart the application.
• Features geo-tagged photos - saving your photos to the map location where you took them.
Weaknesses
• This is a very useful running application, and performs nicely with very good GPS fixation and latency, and a number of helpful and innovative features.
• The only considerable drawback of this application is the price. Although it is good value at £5.99, RunningCoach will be available at zero cost.
2.3.2 Alternative Implementations Rather than focusing entirely on iPhone-based applications, it is essential to include a short evaluation of an alternative implementation with different platforms and hardware.
2.3.2.1 Nike+iPod The Nike+iPod sports kit consists of a small accelerometer that can be embedded into Nike training shoes, and record the distance and pace of
running, in collaboration with an iPod. The run data is then automatically synced with iTunes and a Nike+ online profile. Nike+ have a huge online community of runners, and the community arrange and take part in events and competitions allowing the user to race against another runner elsewhere.
In 2009 Apple introduced the iPhone 3GS, which has built-in Nike+ capabilities allowing the
Nike+ accelerometer to be attached. As the Nike+ technology is not compatible with the iPhone 3G, the necessity for GPS based applications such as RunningCoach is apparent.
Fig. 2.6: Nike+iPod Sports Kit
14
Strengths
• Nike have a highly active and well established community at http://nikeplus.com
Weaknesses
• Nike+iPod does not feature geolocation tracking. The device merely estimates the speed, distance, and overall run data, based on the number of steps taken and the runner’s average stride. This method of tracking attributes towards the inaccuracy of the Nike+iPod sports kit.
• Nike+iPod can only be used with a certain combination of the correct Nike trainers, the correct iPod/iPhone and the Nike+ wireless transmitter. RunningCoach will provide the running services for all iPhone’s (3G and later) and will have no requirement for extra equipment or tracking devices.
2.3.3 Solution Accuracy While all of the tested solutions feature innovative features, arguably the most important feature of a mobile running assistant is its accurate record of run times and distances. The following logs detail accuracy tests performed on the iPhone applications named above. All three applications were tested tracking runs of 1.02km (3 complete laps of an official size Rugby pitch). The results are displayed in Table 2.2.
Table 2.2: Solution Testing
App Load Time GPS Fix Battery Usage
Distance Logged [/1.02km]
iMapMyRun ~4s ~8s 11% 0.92km
Motion-X ~11s ~9s 9% 0.89km
RunKeeper Pro
~6s ~1s 10% 0.88km
2.3.3.1 Test Conclusions These tests raised a number of interesting observations. Firstly, all 3 of the applications were 0.1km+ inaccurate in measuring the distance travelled. Djuknik & Richton (2001) state that GPS is usually accurate up to a radius
15
of ~10m. While this is fairly accurate, the 5-10% under-calculation can be explained by the overall performance of GPS accuracy, which depends on the quality of the pseudo-range and “satellite ephemeris data” (Leva et. al., 1996), which can be affected by weather conditions and other complex environment variables.
All of the tested applications were tested under constant conditions and using the same iPhone OS and the results still varied. This indicates that each application somehow modifies, filters, or changes the iPhone CoreLocation framework to use the location data. This project will aim to enhance the CoreLocation framework so that developers can rely on its data rather than having to modify it within their application.
2.4 Implementation The application framework for the iPhone is called Cocoa Touch, and is fundamentally different from common application frameworks such as those for .Net or Java applications (Mark & LaMarche, 2009). Firstly, the language used for iPhone development is the same language for that of Mac OSX programming: Objective C 2.0.
2.4.1 Objective C 2.0 A prerequisite to iPhone development is to understand the programming language Objective C 2.0 - as this is the language that will interact with the Cocoa Touch layer of the iPhone SDK. In order to become familiar with the syntax and general programming principles of Objective C, we have begun programming the introductory tutorials in ‘Programming in Objective-C 2.0’ (Kochan, 2009). Simultaneously, we will write small applications for use on the iPhone, to familiarise ourselves with some of the key tools and technologies needed.
2.4.2 iPhone Design Patterns There are a few notable design patterns that should be considered when designing and implementing iPhone applications.
2.4.2.1 Delegation & Target/Action Rogers, (2009) identifies 2 notable Cocoa design patterns: Delegation, and Target/Action.
Delegation acts as an alternative to the normal Object Oriented practice of subclassing and overriding. Target/Action is a mechanism specifically used for the UIKit classes. The mechanism causes a control (for example UIButton) to
16
invoke a method in another object. This method is referred to as an action, and the object that contains it, a target.
2.4.2.2 Model-View-Controller
Probably the most fundamental iPhone design pattern not mentioned by Rogers, is the standard MVC (Model-View-Controller) pattern. MVC is used in the standard way with iPhone development, with Xcode and Interface builder supporting this pattern explicitly.
2.4.3 iPhone SDK & Software The iPhone SDK is based on a layered architecture, as illustrated in Fig. 2.8.
From bottom up, the Core OS is the fundamental layer for all low-level processes such as memory allocation and math computation. The core system services that all applications use for security, networking and XML libraries (and much more) form a part of the Core Services layer. The Media layer is responsible for all audio and video incorporated into the iPhone, such as core animation and other graphics technologies. Finally, the Cocoa Touch layer consists of the primary classes for creating all iPhone applications, and is the most important layer to familiarise with for iPhone development.
Fig. 2.7: Model-View-Controller Design Pattern (developer.Apple.com, 2009)
Fig. 2.8: iPhone SDK Architecture
17
2.4.3.1 Cocoa Touch The most important framework in the Cocoa Touch layer is the UIKit framework. UIKit which is a required framework that consists of the classes needed for: application integration, graphics and windowing services, event-handling, standard view and controls, web content and text services, accelerometer data, access to built-in camera and photo library, and more.
The CoreLocation framework will be the second most important framework for the purposes of this project, as it is responsible for the geolocation functionality.
For the above frameworks we will access code samples, best practices, and all documentation from:
http://developer.apple.com/iphone/library/navigation/index.html
2.4.3.2 Tools The iPhone SDK consists of a number of available software tools to assist the development of iPhone applications.
Xcode, Interface Builder & Instruments
The integrated developer environment needed to build native iPhone applications is Xcode 3.1 (Mark & LaMarche, 2009), which is used in association with Interface Builder; the Apple software required for building rich interactive interfaces. Once RunningCoach is built, for the purposes of testing I will need the Instruments application. Instruments offers the ability to profile and sample a compiled application, and provide feedback on memory usage and other performance characteristics in order to benchmark the application’s efficiency and performance.
iPhone Simulator
For application testing purposes, the SDK includes an iPhone simulator, which allows a developer to test the application they have written directly on their desktop. One fundamental limitation of the iPhone simulator exists - RunningCoach will be based on geolocation and aGPS tracking; something that will not be possible to test through the standard iPhone simulator (Apple, 2010a). For this reason, we have proposed a novel solution: iSimulate.
iSimulate
Though iSimulate is not a part of the iPhone SDK, it is an important application to note. iSimulate is an iPhone application available in the App Store aimed specifically at iPhone developers with the intention of syncing an iPhone with iPhone Simulator whilst testing. This application will allow the
18
testing of non-visual interaction (such as GPS location) throughout the development of RunningCoach.
2.4.4 iPhone Development Environment As discussed, the iPhone simulator is unable to test geolocation during development. This issue arises due to the iPhone host-target development environment, which is similar to that of many mobile devices. All of the development takes place in the Host environment and the run-time application can be simulated within this environment. The application can then be compiled and run in the Target environment. This development paradigm is referred to as “host-target development”, and introduces numerous complexities in iPhone development that will have to be considered when creating the RunningCoach application.
2.5 Conclusions & Next Steps With a clear understanding of the literature in the domain, it is clear that RunningCoach will fulfil a requirement, provide developments in the area of creating location-aware iPhone applications and enhance the iPhone SDK. This project will provide an extension of the standard iPhone SDK to improve it’s functionality for both the target and host development environment. The remainder of this document will discuss the challenges experienced and choices made when creating RunningCoach.
2.5.1 Software Development Process To formally begin the software development process, this project will be split into standard phases normally recognised as the Waterfall Model (Fig. 2.9). Initially, time will be spent to decide upon the project Requirements (pg.
19). Building on these requirements, an architectural and user interface Design (pg. 28) will be defined before the project moves into the Implementation (pg. 39) phase. The application will further be tested in the Verification (pg. 47) phase, and Maintenance will be not be explicitly performed.
Fig. 2.9: Software Development Process (Waterfall Model)
19
Since the project requirements and design should remain fairly static for the duration of this project, the waterfall model nicely illustrates the general process in which this project will be performed. However, since there will be a certain amount of “backtracking from one activity to another” (Sommerville 2004, p.73), the development process should be viewed more as Boehm’s (1988) Spiral software
process model ( Fig. 2.10) The spiral process model is
further applicable due to the development environment that will be used to develop the application. The host-target environment requires the application to be developed and tested in iterations between both the host and target environment, a requirement that would not be possible following a linear software process model such as the waterfall.
Fig. 2.10: Spiral Software Process Model
20
3 Requirements 3.1 Introduction While this project is not directly concerned by the functionality of RunningCoach, but rather the effectiveness of the iPhone SDK, it is still important to formalise the application requirements to ensure that thorough attention is paid to the typical implementation required for developing a mobile running assistant with the iPhone SDK. This section of the report outlines the functional and non-functional requirements for all aspects of RunningCoach. These requirements explicitly define how the application should behave in order to formalise the functionality that RunningCoach will and will not include. In addition to this the requirements will outline non-functional requirements relating to the user interface, and application performance requirements.
3.2 Requirements Elicitation
3.2.1 Literature Review Much of the requirements elicitation for RunningCoach has been based on existing solutions, as outlined in Section 2.3 of the Literature Review (Existing Solutions – pg. 9). As many of these running applications are relatively mature, they tend to offer a wide range of functional features, some of which will form a basis for the RunningCoach requirements, and some of which are out of range for the scope of this project.
3.2.2 Google Survey To gather initial high-level requirements, and to set the context of
RunningCoach, a short survey was created (see Appendix A – Survey & Results) and completed by 28 voluntary participants inside a local gymnasium. The results suggest that a surprisingly high number of respondents own an iPhone (Fig. 3.1). This is a potentially important factor for RunningCoach for a number of reasons. Firstly this
Fig. 3.1: iPhone Owners
21
means that a relatively high number of perspective users are both familiar with the iPhone itself and familiar with the expected application interface. For this reason, RunningCoach will attempt to conform as closely as possible to the standard Apple application layout and UI design. Secondly, this high level of ownership confirms that adoption of the iPhone itself is particularly high amongst perspective users. Supporting this notion is Fig. 3.2, which confirms that a high number of participants (93%) use their phone for applications outside of standard phone functionality (phone calls, text messaging etc). These results suggest that RunningCoach has a substantial place in the running domain.
One of the main features of the existing solutions is the integration with social networking sites. Many of the applications allow run data to be posted to
Facebook, Twitter, Bebo and so on. Following on from this, the survey attempted to ascertain which social networking sites our participants used most frequently, by asking which Social Networking Sites (SNS’s) they post content to.
Fig. 3.3 displays the survey results for the participants, and shows that the most popular SNS the participants use and post content to is Facebook. Should RunningCoach be developed to integrate social network status updates, the SNS’s would be considered the in order of the popularity as shown in these results. Although integrating RunningCoach with social networking sites would be a useful form of marketing, our
Fig. 3.2: Application Use
Fig. 3.3: Social Networking Site Usage
22
survey results suggest that users would be less concerned by these extra features, and more interested in the core functionality.
When surveyed, the majority of users agreed that the accuracy of the run data would be the most important feature of RunningCoach. For this reason, RunningCoach will not focus heavily on extra features, rather on providing a stable, useable and accurate tracking tool. Fig. 3.4 shows the results for the most important feature section of the survey.
This primary research has given a good insight into the expectation of potential RunningCoach users. The survey results concluded that RunningCoach should focus on creating an accurate tracking application, that conforms to the typical Apple iPhone application UI.
3.3 Requirements Prioritisation All of the requirements for RunningCoach will be given a priority from the following: Critical, Significant, Non-vital. These levels of priority will define the importance of the requirement to the overall application.
Critical These requirements provide the core functionality of RunningCoach. Without meeting these requirements, the application will be unusable and not fit its intended purpose. These requirements provide the core functionality of RunningCoach and as such, are the most critical requirements to meet.
Significant The significant requirements relate to functionality that is highly important
Fig. 3.4: RunningCoach Important Functionality
23
for the implementation of RunningCoach. The application will perform the basic core functionality without meeting these requirements, however the significant requirements will have a profound effect on the application as a whole. Without these requirements the application will be basic and would be considered a functional prototype only.
Non-vital Non-vital requirements include ‘nice to have’ functionality. The non-vital requirements are not fundamental to the core functionality of RunningCoach, however they will provide a number of extra features and functionality that will enhance the application further from it’s basic core functionality.
3.4 Hardware & Software Requirements The hardware and software requirements relate to the building, compiling, and use of RunningCoach, in terms of the hardware and software used. As iPhone development is a host-target paradigm, the requirements are split into Target (Table 3.1) and Host (Table 3.2) requirements.
Table 3.1: Target Requirements
# Requirement Priority
1 The application should run on Apple iPhone 3g and later (3gs, …)
Critical
2 The application should compile and run on iPhone OS 3.1.2 (device)
Critical
3 The application should utilise the iPhone inbuilt aGPS receiver
Critical
Table 3.2: Host Requirements
# Requirement Priority
4 The application should be built and deployed on Mac OS X 10.5
Critical
5 The application should compile and run on iPhone OS Simulator 3.1.2 (dev environment)
Critical
6 The application should be built using iPhone SDK Critical
24
3.1.2 and Xcode 3.1
7 The application should be compiled using GCC 4.2 compiler
Critical
8 The application should be written in Objective C 2.0 Critical
3.5 Functional Requirements Since RunningCoach will attempt to conform as closely as possible to the expected Apple application layout, the functional requirements will be split into sections for each user interface view; Profile (Table 3.3), RunningCoach (Table 3.4), History (Table 3.5), and Settings (Table 3.6).
Table 3.3: Profile Requirements
# Requirement Priority
9 The application should support multiple user profiles Significant
10 Profile data should be stored in the iPhone persistent data (SQLite database, …)
Significant
11 Profile data should be stored along with:
• Profile ID (UID) • User name • User run data
Significant
12 The application should allow users to add profile data to the iPhone persistent data
Non-vital
13 The application should allow users to delete profile data from the iPhone persistent data
Non-vital
14 The application should allow users to modify profile data in the iPhone persistent data
Non-vital
Table 3.4: RunningCoach Requirements
# Requirement Priority
15 The RunningCoach UI should display the currently selected profile data including:
• User Name
Significant
25
• Number of runs completed • Total run distance
16 The application should utilise the iPhone aGPS (corelocation framework) to determine the device’s current location
Critical
17 The application should calculate the distance travelled between two GPS coordinates
Critical
18 The application should only allow the user to track running data if the GPS accuracy is accurate within 50m.
Significant
19 The RunningCoach UI should display the current GPS accuracy in meters
Significant
20 The application should calculate the users total run distance by logging the distance between GPS coordinates n and n+1
Critical
21 The application should calculate and display to the UI the users current running speed
Significant
22 The application should calculate and display to the UI a timer showing the current run time for the existing run
Significant
23 The application should begin tracking the users running data once the ‘Start’ button is pressed.
Significant
24 The application should stop tracking the users running data once the ‘Stop’ button is pressed.
Significant
25 The application should store run data to the iPhone persistent data once a run is completed
Significant
Table 3.5: History Requirements
# Requirement Priority
26 The application should display the history of the currently selected users run data, including:
• Run time • Average running speed • Total distance covered
Non-vital
27 The application should display a map of the individual run data, showing the route taken,
Non-vital
26
including the start and end points of the run
Table 3.6: Settings Requirements
# Requirement Priority
28 The application should allow switching between kilometres and miles throughout the application
Non-vital
29 The application should allow the user to define the desired GPS accuracy
Non-vital
30 The application should allow the user to turn on and off audio feedback on the run
Non-vital
31 The application should allow the user to select a playlist of music from the iPhone to be played whilst the user run is in progress
Non-vital
32 The application should offer the option to ‘autosave’ runs rather than prompting
Non-vital
Table 3.7: User Interface Requirements
# Requirement Priority
33 The application should contain UI screens for each view:
• Profile • RunningCoach • History • Settings
Significant
34 The application should include a ‘tab’ view in the same style as existing Apple applications
Significant
35 The application User Interface should function entirely using the iPhone touch screen technology
Significant
27
3.6 Non-Functional Requirements Table 3.8: Application Requirements
# Requirement Priority
36 The application should provide as accurate as possible GPS tracking
Significant
37 The application should require no longer than 5 minutes training for a user with no prior experience with an iPhone
Significant
38 The application should require no training at all for a user with prior iPhone experience
Significant
39 The application should conserve the iPhone battery as much as possible
Significant
40 The application should not contain memory leaks, and should exit gracefully in the event of an error
Critical
41 The application should handle incoming calls and text messages in an intuitive way
Significant
Table 3.9: User Interface Requirements
# Requirement Priority
42 The application should conform as closely as possible to the standard Apple application layout
Significant
43 The application should include a ‘loading’ view to inform the user the application is loading
Non-vital
44 The application should have an icon displaying the application logo on the iPhone home screen
Non-vital
45 The application should minimise the user physical interaction with the device User Interface
Significant
28
4 Design 4.1 Introduction Following on from the requirements definition, the design chapter will begin to build upon the requirements in order to define the overall system architecture that will be applied to running coach. In addition to this, this chapter will establish a sound foundation for RunningCoach in terms of the application structure and user interface design.
A number of design techniques have been applied to ensure that a comprehensive and thorough approach has been taken to enhance the design foundation of RunningCoach.
4.2 Architectural Design From a high level, the architectural design of RunningCoach can be illustrated in Fig. 4.1.
Fig. 4.1: High-Level Architectural Design
RunningCoach will receive the aGPS location data using the corelocation framework provided as part of the iPhone OS libraries. The main function class will be RunningCoachViewController, and will interact with two custom classes; Run (encapsulating Run data) and Profile (encapsulating runner information). To store and retreive data from the iPhone persistent memory, an SQLite database will be used, and will maintain a relational database of both the Run and Profile data for each user.
29
4.2.1 Persistent Data RunningCoach aims to store both Profile and Run data in persistent memory in the iPhone, meaning that the data will be available after the application has been restarted. To achieve this, the built-in SQLite functionality of the iPhone OS will be utilised. Fig. 4.2 illustrates the simple database structure that will be used for storing these two objects.
Fig. 4.2: SQLite Database Structure
Since the size and complexity of the datasets to be stored in RunningCoach are very limited, no extensive entity relationship modelling (ERM) has been performed. Should RunningCoach require larger and more complex datasets, a fully relational database design would be established using techniques such as normalisation to preserve data integrity.
pkFirstNameLastNamePicture
Profile
RunIDRunObjectRunnerPK
Run
30
4.3 UML Modelling In order to visualize the architecture of RunningCoach and show how the numerous system functions will interact, UML (Unified Modelling Language) diagrams have been created. Both static (Section 4.3.1 - Class Diagram, pg. 30) and dynamic (Section 4.3.2 - Sequence Diagram, pg. 31) models have been developed, in order to demonstrate the system modules in multiple states.
4.3.1 Class Diagram Fig. 4.3 shows a simplified version of the RunningCoach class diagram. The final implementation will include a large number of classes from various libraries. For this reason, a full class diagram shall not be included and only the core classes are shown in Fig. 4.3. The main class RunningCoachViewController will contain the majority of the functionality for the application. Classes in red are protocols that will be extended from the existing iPhone API. Classes in grey are API classes that will be sub-classed by the custom RunningCoach classes. UIViewController is the superclass for all controller classes, and is used to provide the view management functionality required by all iPhone applications. NSObject is the superclass used when creating a custom class, in this case: Profile and Run.
Fig. 4.3: RunningCoach Class Diagram
31
4.3.2 Sequence Diagram A sequence diagram has been created for the main scenario; Start Run. Fig. 4.4 illustrates how the classes will interact, and which methods will be used to complete the start run scenario, with the user first creating a new profile.
Fig. 4.4: RunningCoach ‘Start Run’ Sequence Diagram
The Start Run scenario is the core functionality of RunningCoach and as shown in Fig. 4.4, the number of methods to be used is minimal. The startUpdatingLocation method is the CoreLocation method to be used to obtain the geolocation data, which will be filtered and manipulated directly.
4.3.3 Proposed Methods With an architectural design established, it is important to provide an overview of the intrinsic functions that will be present in the main classes; Profile, RunningCoachViewController, and Run.
4.3.3.1 Profile Class The profile class will remain relatively simple, and be responsible for inserting and retrieving profiles from the RunningCoach SQLite database. The following methods are proposed:
-(id)initWithPrimaryKey:(NSInteger)pk database:(sqlite3 *)db
initWithPrimaryKey will receive a primary key value (Profile ID) from the user input, retrieve the Profile data from the SQLite database, and insert the profile values into the Profile object. Details on how the user input will be detected are covered in Section 4.4.2 - Profile (pg. 36).
User
RunningCoachViewController
2. startButtonPressed()
Run
3. newRun()
Profile
1. newProfile()
TabBarController
4. startRun()
corelocation
5. startUpdatingLocation()
6. loop()
32
- (void) addProfile
The addProfile method will be responsible for building the following SQL statement and injecting the profile data into the SQLite database when required: “insert into Profiles(FirstName, LastName) Values(?,?)”
4.3.3.2 RunningCoachViewController Class The RunningCoachViewController will be the main class in terms of RunningCoach functionality and will encapsulate (at minimum) the following methods:
- (void)locationManager:(CLLocationManager *)manager didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation *)oldLocation
This method will be the most important for the core functionality of RunningCoach. didUpdateToLocation is a callback method, which is triggered upon receiving a geo-location coordinate from the corelocation framework. This method will be overridden to allow RunningCoach to filter and manipulate the corelocation data.
- (void)didReceiveMemoryWarning
Since memory is scarce in the iPhone, occasionally a memory warning will be issued. To deal with this gracefully, the above method will be implemented from the UIViewController class, and will be called to release any cached images, or files that are not currently being used.
- (void)viewDidLoad
The viewDidLoad method will be called upon the RunningCoach view being loaded on the device. This allows any extra control to be added that is not instantiated by the interface .xib file. For the purposes of RunningCoach, this method will be used to tell the corelocation framework to start updating the location coordinates. This method will also be responsible for setting the desired accuracy of the corelocation framework.
- (void)reset
33
reset will be called when the application is required to set the application to a completely ‘ready’ state. This will involve releasing the previous run data and objects, and current location data and instantiating new objects.
- (void)updateCounter:(NSTimer *)theTimer
As RunningCoach will maintain a run counter for the purposes of the User Interface, the updateCounter method will be passed the timer from the current Run object, and asynchronously update it for display on the User Interface.
- (void)actionSheet:(UIActionSheet *)actionSheet didDismissWithButtonIndex:(NSInteger)buttonIndex didDismissWithButtonIndex will be responsible for handling the action sheets that are displayed to the user for the purposes of confirming saving run data to the iPhone persistent memory. Fig. 4.5 illustrates an Action Sheet example proposed for RunningCoach. - (BOOL)saveRunData
The saveRunData method is responsible for saving a completed run data to the iPhone persistent data. The method will inject the Run object into the Run table inside the SQLite database.
- (IBAction) startButtonPressed
- (IBAction) resetButtonPressed
- (IBAction) stopButtonPressed
- (IBAction) startSpinner
- (IBAction) stopSpinner
The above IBAction methods are directly linked to the buttons and methods included in the main interface window. They will handle the user input and action the required methods, which are all self-explanatory.
Fig. 4.5: RunningCoach Action Sheet Example
34
4.3.3.3 Run Class Much like the Profile class, the Run class will be fairly simple, and will encapsulate minimal data related to the run, including the run time and total distance. The functions below are proposed to support this class: - (void)updateCounter:(NSTimer *)runTimer
A timer will be initialised for each run that is started. The timer will simply provide a record of the run length (in seconds, minutes and hours) at any one time. This method will be responsible for maintaining the run timer.
- (BOOL)isRunStarted
A boolean method; isRunStarted will be required by the RunningCoachViewController class so multiple runs cannot be performed simultaneously. This method will provide an indication as to whether a run is currently in progress or not.
- (void)stopRun
- (void)startRun
The above methods require no further clarification.
4.3.3.4 Common Methods The methods outlined in this section will be applicable to almost all classes within the RunningCoach project. To avoid repetition, these methods have been detailed here. - (void)dealloc
Since memory management is performed manually on the iPhone, it is necessary to have a method that will be called under certain circumstances (e.g. upon application exit) that will be responsible for releasing all of the objects which have been allocated to memory and are no longer required. This functionality is the responsibility of the dealloc method.
35
4.4 User Interface Design The User Interface of any application is highly important, more so when the iPhone display offers just 480x320 pixels (Mark & LaMarche 2009, p.6), far less than many modern computers. For this reason, designing a well-constructed and thoughtful UI is imperative. This section will outline the work to be completed for the User Interface Design.
UIView is the typical superclass from the UIKit framework and for each view a unique UIView will be implemented. Wireframes for the application User Interface will be initially designed to provide a representation of the individual elements for each UIView. This section defines the proposed UIViews for the 4 main views and the application view itself.
4.4.1 Application User Interface To conform as closely as possible to the standard Apple User Interface, RunningCoach will incorporate a ‘tab bar’ controller. The tab bar controller is a User Interface module that allows multiple View windows to be controlled and displayed from within the application. The tab bar (Fig. 4.6) is highly integrated with the iPhone and is used in many Apple applications for
application navigation purposes.
Commonly, the tab bar is displayed at the bottom of the active application, and provides a direct link to the individual Views required for navigating within the application. This type of tab bar will be replicated for RunningCoach and four individual views are proposed:
1. Profile View 2. RunningCoach View 3. History View 4. Settings View
The RunningCoach tab view has been designed as closely as possible to the typical Apple tab bar, and the icons for ‘Contacts’ and ‘Recents’ have been
reused for ‘Profiles’ and ‘History’ respectively. Custom icons were designed and created for the
“RunningCoach” tab and the “Settings” tab. The finalised 4-tab design is shown in Fig. 4.7.
Fig. 4.6: Typical Apple Tab Bar
Fig. 4.7: Custom RunningCoach Tab Bar
36
4.4.2 Profile View As the RunningCoach Profiles have been designed to be stored and retrieved from an SQLite database, a user interface is proposed that utilises the UITableView from the standard UIKit framework. The UITableView
explicitly supports the proposed SQLite database as it “can enter an editing mode where users can insert, delete, and reorder rows of the table” (Apple, 2010b). The proposed view will enable users to scroll a list of profiles that have been retrieved from the SQLite database, and make a selection, based on their interactive touch gesture. Fig. 4.8 displays the proposed view, with the placeholder custom tab bar included. The choice to reuse the UIKit UITableView is based on numerous factors:
1. The typical Apple layout can be used
2. Interactive gestures can be easily recognised (e.g. when a user touches a name, the name can be highlighted)
3. The UITableView integrates well with the SQLite database.
Fig. 4.8: Profile Wireframe Design
37
4.4.3 RunningCoach View Since the aim is to limit the amount of physical interaction the user has with the device once in ‘run’ mode, the RunningCoach view will provide limited information, and 2 simple UIButtons; Start and Stop to control the run
tracking. Fig. 4.9 illustrates the proposed layout of the RunningCoach view. The UI elements will each be linked to their respective objects. The top section will retrieve the selected profile data, and the bottom section will provide the running statistics defined in the requirements: GPS accuracy, Run Time, Speed and Total Distance. While this view does not capitalise heavily on the media rich iPhone frameworks, overall RunningCoach aims to provide a minimal design and to focus on providing accurate run data rather than extra features. The Start and Stop UIButtons will utilise the methods proposed in RunningCoachViewController, the startButtonPressed and stopButtonPressed functions respectively.
4.4.4 History View In a similar way to the Profile view, the History view will utilise a UITableView to retrieve the individual Run objects from the SQLite database. The view will appear almost identical to the Profile view, but displaying Run data rather than profile data.
Fig. 4.9: RunningCoach Wireframe Design
38
4.4.5 Settings View As the Settings Requirements have all been defined as ‘Non-vital’ this project will not be heavily concerned with the Settings user interface or functionality. A proposed layout is shown in Fig. 4.10. The interface features a slider that allow the user to define the level of desired GPS accuracy. This feature is
beneficial as “by carefully specifying the absolute minimum accuracy level you need, you can prevent unnecessary battery drain” (Mark & LaMarche 2009, p.429).
The settings view also meets the requirements by allowing the user to switch between Metric and Imperial measurement, a standard feature for location tracking applications.
4.5 Advancing To Implementation To this point the project has provided a foundation for the implementation of RunningCoach. This extensive requirements and design process allowed us to implement the proposed application using the tools and software documented in the Literature Review. The following sections will document the implemented application and as such some sections will read as a post-implementation reflection.
Fig. 4.10: Settings Wireframe Design
39
5 Implementation & Testing 5.1 Introduction This chapter outlines the implementation phase of the RunningCoach project. Rather than covering each element of the implementation in its entirety, greater attention has been paid to the key areas that were either problematic, or otherwise interesting. The main challenges of implementing RunningCoach are discussed and recommendations are naturally derived, which will be covered in detail in Chapter 6 - Results (pg. 51). The chapter will also cover the challenges experienced when creating applications for the iPhone using the host-target development environment.
5.2 CoreLocation For RunningCoach to establish the device location, the CoreLocation framework must be implemented. Utilising the CoreLocation framework itself is fairly simple, however in practice implementation can become problematic. The host environment offers a simulation iPhone OS environment, which is fairly extensive in its features and similarities with the target iPhone OS environment, however the location “reported by the CoreLocation framework in the simulator is fixed” (Apple, 2010a). During the literature review, a developer application iSimulate was identified to overcome this problem, claiming to support GPS simulation in the host environment. This however is not the case, and the application simply reports a single static location, which does not allow the geolocation to be tested or developed effectively. These shortcomings of the iPhone Simulation Environment make the development of applications using CoreLocation somewhat challenging.
5.2.1 Implementing CoreLocation Utilising the CoreLocation framework itself is fairly straightforward. The classes are included from the CoreLocation.framework and the LocationManager is initialised in RunningCoachViewController as follows:
Fig. 5.1: Initialising LocationManager
locationManager = [[CLLocationManager alloc] init]; locationManager.delegate = self; locationManager.distanceFilter = kCLDistanceFilterNone; locationManager.desiredAccuracy = kCLLocationAccuracyBest; [locationManager startUpdatingLocation];
40
The LocationManager is ‘alloc’ed (allocated) a segment of memory to work in, and is told to start updating the location. This process takes place as soon as the RunningCoach view loads to ensure the location data is available as soon as possible.
Once startUpdatingLocation is called, the LocationManager calls the ‘delegate’ method locationManager:didUpdateToLocation:fromLocation which is defined in the RunningCoachViewController. Each time a new location update is received from the LocationManager this method will be called. Therefore, this method is where RunningCoachViewController will manipulate the location data each time it is received.
The RunningCoachViewController initialises an object of type ‘Run’ called currentRun. Each time a location update is received, the location coordinates are inserted into the mutable array ‘runCoords’ inside the currentRun object: [currentRun.runCoords addObject:currentLocation];
This process is repeated until the user touches the ‘Stop’ button, and then an action sheet is displayed, confirming whether to save or discard the run. The run data is then either injected into the SQLite database, or discarded.
5.2.2 Rapid Target Test Since the implementation took place within the host environment that does not support testing of CoreLocation, this was then compiled and tested on the device (the target environment). Very quickly, a rapid test of the application revealed that the location data being reported by CoreLocation was somehow inaccurate, and constantly reported 0km (Fig. 5.2).
Fig. 5.2: RunningCoach Rapid Test
41
These findings highlighted the need for CoreLocation support within the host development environment simulator.
5.2.3 Host Environment Simulation The lack of CoreLocation support in the simulator led us to develop a novel solution that would overcome this deficiency. It was decided that the CoreLocation framework would be modified to read a file of fake GPS coordinates, and return these as the real values. We modified the CLLocationManager class to include the following:
This workaround allowed the application to read a text file of coordinates, and return the ‘fake’ location when the delegate method polled for location. This provided the simulator with dynamic coordinates rather than a static location normally reported by the simulator environment. This aided the debugging of the application in the simulator, which would then help to remove the incorrect location reporting whilst running on the device. This solution allowed us to overcome the shortcomings of the iPhone Simulator and as such, will form a part of the project results (Section 6.1 - CoreLocation Simulation, pg. 51).
Fig. 5.3: CoreLocation Simulator Workaround
// if the active environment is the iphone simulator #ifdef TARGET_IPHONE_SIMULATOR // read a text file of fake coordinates NSString *fakeLocation = [[NSString alloc] initWithContentsOfFile:COORDINATES_FILE]; NSArray *coords = [fakeLocation componentsSeparatedByString:@","]; CLLocationDegrees x = [[coords objectAtIndex:0] doubleValue]; CLLocationDegrees y = [[coords objectAtIndex:1] doubleValue]; // report the fake coordinates as the new location fake_location = [[CLLocation alloc] initWithLatitude:x longitude:y];
42
5.3 Implementing The User Interface iPhone applications are built by iteratively working between Xcode and Interface Builder. For the purposes of clarity, this section will outline the interface implementation and the key implementation features behind these interfaces.
“Interface Builder” (Fig. 5.4) is the application built into the iPhone SDK for the purposes of creating rich, iPhone user interfaces. Interface builder allows controls to be dragged directly into a view, meaning the majority of the user interface can be designed and built directly by ‘dragging’ the required Cocoa Touch components from the left-most window, and ‘dropping’ the component into the iPhone view (second window from left).
Fig. 5.4: Interface Builder in Mac OS X
Interface builder reduces the amount of code required in the core classes, by storing the interface objects in a .xib file that is loaded directly to the device. Using Interface Builder, it is clear that the application is extremely powerful and greatly reduces the development time for creating rich graphical user interfaces. However, challenges arise due to the fact that the .xib file hides some code from the main application classes, which can make debugging or manipulating User Interface controls complicated. For this reason, prior to implementation, it was decided that controls that would require complex manipulation from within the main classes would be programmed by hand using Xcode, rather than built graphically using Interface Builder.
This section outlines the work required to move from the graphic designs established in Section 4.4 (
43
User Interface Design, pg. 35), to a built and integrated user interface. Each interface built will conform to characteristics identified in the iPhone Human Interface Guidelines (Apple, 2010c).
5.3.1 Profile User Interface As established in the user interface design, the Profile interface will utilise the UITableView from the Cocoa Data View library. In terms of development of the Profile user interface within Interface Builder, there is little implementation besides dropping a UITableView within the UIView and assigning a data source by linking the table view with the tabbar outlet (Fig. 5.5).
The remainder of the work was completed inside Xcode:
The above code loads the Profiles which have been previously initialised from the SQLite database, and appends the Profile First Name and Last Name to a
Fig. 5.5: Linking UITableView to dataSource outlet
Profile *profile = (Profile *)[Profiles objectAtIndex:indexPath.row]; NSString *entry = [NSString stringWithFormat:@"%@ %@", profile.FirstName, profile.LastName];
44
string, and returns it as a UITableView cell in order for it to be output to the UITableView.
5.3.1.1 Final Implemented Interface Fig. 5.6 shows the progression of the wireframe user interface design for the Profile view, to the implemented profile view running in the iPhone simulator.
5.3.2 RunningCoach User Interface The RunningCoach View is the main user interface users will interact with. However to fit with the requirements of this project, the interface will aim to reduce the amount of direct interaction to a minimal level. For this reason the view will contain only two UIButtons that will start and stop the run. All other information displayed in this view will be linked to data calculated in the RunningCoachViewController, such as the speed, run time etc.
5.3.2.1 Mapping Actions & Outlets The UILabel class is used to display information in the RunningCoach view, so a mapping is required between the RunningCoach view and the RunningCoachViewController. To achieve this, in RunningCoachViewController, an IBOutlet (Interface Builder Outlet) is defined:
Fig. 5.6: Profile UI: Wireframe to Implementation
45
@property (nonatomic, retain) IBOutlet UILabel *totalDistanceTravelledLabel;
This IBOutlet tells Interface Builder that we want to connect the totalDistanceTravelledLabel instance variable to an interface object. Back in interface builder, the two items are linked (Fig. 5.7).
Fig. 5.7: Connecting totalDistanceTravelledLabel Outlet
The same process takes place when connecting the UIButton (e.g. the start button). In addition to linking the outlet with interface builder, we also link the UIButton with a user gesture and an action (Fig. 5.8). The startButton is instructed to perform the ‘startButtonPressed’ method upon the ‘touch up inside’ event. This simply means that when the user lifts their finger up from the startButton, the startButtonPressed method is called.
Fig. 5.8: Connecting startButton Action / Outlet
46
5.3.2.2 Final Implemented Interface shows the initial wireframe design for the RunningCoach view and the final implemented interface running in the iPhone simulator.
5.3.3 Settings User Interface Similar techniques to those above were implemented for the Settings user interface, and will not be covered in detail. The final user interface progression is shown in Fig. 5.10.
Fig. 5.9: RunningCoach UI: Wireframe to Implementation
Fig. 5.10: Settings UI: Wireframe to Implementation
https://www.url.com/iphone
Page title
Settings
HistoryProfiles SettingsRunningCoach
GPS Accuracy
Metric (km)Imperial (m)
47
5.4 Testing In order to verify and validate RunningCoach meets the specification and delivers the expected functionality, a number of testing mechanisms have been applied. This chapter outlines the various testing techniques used to ensure that RunningCoach:
1. Meets the initial requirements (Section 5.4.1 - Requirements Verification, pg. 47)
2. Performs efficiently (Section 5.4.3 - Performance Testing, pg. 48)
This suite of tests should ensure that RunningCoach meets the original requirements set out in Chapter 3.
5.4.1 Requirements Verification The requirements verification process aims to ensure that an application conforms to its original specification (Sommerville 2004, p.516). Appendix B – Requirements Verification Testing Log outlines the original requirements, and whether the application ‘passed’ (i.e. met the original requirement) or ‘failed’. Requirements that have been met are highlighted in green and those that fail in red. Requirements that have failed are discussed further in Section 5.4.2.
5.4.2 Failed Requirements Of the 11 requirements that RunningCoach failed to meet, just one requirement (req. 25) is considered a ‘Significant’ requirement, with the remaining 10 being ‘Non-vital’. Requirement 25 states that run data should be saved into the iPhone persistent data once the run is completed. An SQLite database was implemented and functioning correctly, which has the capability of storing both Profile and Run data. The Profile data functions correctly and can be retrieved from the database, in the same way required for the Run data. Simply due to timing constraints within the project, the requirement to save the data after a run was completed extended beyond the scope of RunningCoach.
Since this is not a software development project, but a dissertation, the ‘non-vital’ requirements have been reserved, since they do not add value in terms of this document. The non-vital requirements add extra functionality to the RunningCoach application, which would of course be important should the application be released as a commercial product. Due to both intellectual property rights resting with the University of Bath, and the limited scope of this dissertation, these requirements are unnecessary implementation for this project.
48
5.4.3 Performance Testing Performance testing for iPhone applications is vital, since the iPhone has limited resources in terms of memory and processor power. Memory management in the iPhone is dealt with manually, and therefore it is very easy to forget to de-allocate a segment of memory, or over-allocate memory. For this reason, ensuring the application is durable and does not experience performance related issues is paramount.
The iPhone SDK includes a piece of software called ‘Instruments’ (Fig. 5.11), which enables low level performance testing of applications in both the host and target environment. This section will discuss the performance testing applied to RunningCoach and evaluate the results.
Fig. 5.11: 'Instruments' Performance Testing
5.4.3.1 Testing Memory Leaks In order to test for memory leaks in the RunningCoach code, instruments was simultaneously run alongside the application in the host environment. The ‘Start Run’ scenario was tested and Instruments instructed to search for memory leaks. The application revealed a number of Libraries that contained leaked objects, the most significant being an object from the RunningCoach library. A memory address corresponding to the leaked object was reported alongside a stack trace.
Tracing the stack trace it was visible that RunningCoachViewController was responsible for leaking a 32 byte object;
currentRun = [[Run alloc] init];
49
Since “memory leaks happen when you throw away your pointer to that memory”(MobileOrchard, 2009), it was identified that the currentRun object was allocated memory, but never released. For this reason, the following release call was added to RunningCoachViewController to release the object when it was no longer required:
[currentRun release];
Although the omission of this release call did not cause RunningCoach to crash, the best-case scenario is wasting the limited iPhone memory resources. In the worst-case, if the application ran for long enough and the leak happened every frame, the application would eventually crash completely. To combat this, RunningCoach was tested stringently with Instruments to insure that none of the RunningCoach classes were responsible for memory leaks. Finally, instruments reported no existing memory leaks within the application.
5.4.3.2 CPU Testing The iPhone 3g features a Samsung 600MHz processor (RoughlyDrafted, 2008), and compared to the standards of modern computers, handles a relatively low processing power. Therefore testing RunningCoach’s CPU performance is important, however testing the application inside the Host environment is fairly nonsensical, since the Target environment is the final device where the application will run (and consume processing power). Testing the CPU performance is crucial to understand the overall system workload RunningCoach will have on a typical iPhone 3g. Fig. 5.12 displays a CPU monitor log for a one-minute test of RunningCoach. It should be noted that the blue graph refers to the System Load (iPhone core frameworks, phone functionality etc), the brown graph refers to User Load (RunningCoach and the libraries used within RunningCoach) and the grey graph refers to the Total Load (sum of System and User Load).
Fig. 5.12: RunningCoach CPU Profiling
50
Fig. 5.12 has been labelled with three key events which took place during the duration of the CPU sampling. At event (1) the application was loaded from the iPhone. At this point the application is loading the interface (.xib file), establishing all of the data objects, and initialising the view. Therefore, a spike in CPU usage is expected, since the application is retrieving all of the data required to fully load the application, a Total CPU usage of 96.06% is permissible. At this point RunningCoach is only responsible for 47.24% of the total load. Once the application had loaded, a decrease in the CPU usage is experienced, until event (2) is reached. At (2), the iPhone has loaded all of the required files, and begins to call the CoreLocation framework and begin polling for the device location. Again, this initial spike in CPU performance is expected, and the usage drops once a GPS fix has been established. Fluxuations in the CPU useage between event (2) and (3) are explained by new Location data arriving, and the application handling (either storing or discarding the location). At event (3) the Run is stopped and the application saves the Run data.
The highest peak throughout the CPU profiling (excluding event (1) - application load) was the initial establishment of a GPS fixation. From this point, the application load remained constantly below 50%, and is therefore well within the CPU capabilities of the iPhone 3g.
Newer models of the iPhone (3gs, 4g) feature and will feature more powerful processers than the 3g(Shimpi, 2009). For this reason, RunningCoach will be forward compatible with newer and run (at least) as seamlessly as on the iPhone 3g.
5.4.4 Beta Testing Since the University owns the intellectual property rights to this project, it is not possible to submit the application to the iTunes app store to obtain end-user feedback. Consequently, beta testing is unfortunately out of scope for this project.
51
6 Results & Evaluation This chapter documents the key results that have emerged as a result of this project. The creation and development of RunningCoach has naturally resulted in three main results:
• Improving the CoreLocation framework to support host environment simulation (Section 6.1)
• Improved accuracy of CoreLocation (Section 6.2) • Guidelines for creating CoreLocation applications (Section 6.3)
6.1 CoreLocation Simulation While it is possible to implement CoreLocation applications using the simulator alone, this project concludes that ‘effective’ CoreLocation development is achieved when iterative testing can be performed between both the host and target environment. Fig. 6.1 illustrates the host-target development environment experienced when implementing CoreLocation applications. Without explicit CoreLocation support in the simulator, it is not possible to iteratively test the framework.
This iterative testing was achieved by modifying the host environment simulator to support CoreLocation simulation (Section 5.2.3, pg. 41), which aided the CoreLocation development to a successful level.
6.2 CoreLocation Accuracy When testing RunningCoach in the target environment (Section 5.2.2, pg. 40) it was evident that the data reported by CoreLocation was often inaccurate or incorrect. For this reason, RunningCoach implemented a basic algorithm to improve the accuracy of CoreLocation:
Fig. 6.1: iPhone Development Paradigm
52
1. If the horizontal accuracy of the new location is a negative value, discard the location, since it is an erroneous value
2. If the horizontal accuracy of the new location is less than the desired GPS accuracy, discard the location, since it is inaccurate
3. If the new location is more accurate than the previous location, discard the previous location and use the new location
4. If the new location is older than -0.00, it is a location cached in the iPhone memory, which is no longer valid and should be discarded
These simple error-filtering steps have been applied to RunningCoach and removed much of the erroneous data being reported by the CoreLocation framework.
6.3 CoreLocation Implementation Guidelines Apple provides a CoreLocation framework reference guide (Apple, 2010d), however a number of important aspects are not included. Firstly, Apple provides the iPhone SDK and therefore does not heavily advertise the fact that the iPhone simulator does not support CoreLocation simulation. While this isn’t hugely important for applications that wish to singularly poll for the users location and take action, it is of vital importance for applications that aim to utilise CoreLocation for geolocation tracking.
Developers should aim to have an understanding of these implications regardless of their CoreLocation requirements, as it fundamentally affects the development process. It is recommended that developers modify the CoreLocation framework as described in this document, in order to allow CoreLocation simulation in the iPhone simulator.
In addition to this, developers should realise that CoreLocation does not always provide reliable data. Apple does not document the accuracy and error rates of the CoreLocation framework, however, the development of RunningCoach highlighted (some of) the many erroneous data reports from CoreLocation. Again, it is highly recommended that the simple error-filtering algorithm developed in this project is applied to all CoreLocation applications.
6.4 RunningCoach Evaluation Now that RunningCoach has been developed and tested, it is possible to evaluate the application. The testing phase showed that RunningCoach has been well implemented in terms of its performance. The application features no memory leaks, and uses a very low percentage of the iPhone’s available
53
resources. Given this, the application will be benchmarked against the applications tested in the Literature Review, based on the same criteria. The results are displayed in Table 6.1.
Table 6.1: RunningCoach Benchmarking
App Load Time GPS Fix Battery Usage
Distance Logged [/1.02km]
iMapMyRun ~4s ~8s 11% 0.92km
Motion-X ~11s ~9s 9% 0.89km
RunKeeper Pro
~6s ~1s 10% 0.88km
RunningCoach ~3s ~2s 8% 0.86km
RunningCoach is incredibly lightweight, due to the fact that the majority of the functionality is core only. This lightweight design and implementation means that RunningCoach has the fastest load time when compared to the other three applications. In addition to this, RunningCoach also reserves more of the battery life than the other three applications. This is also attributed to by the lightweight design.
RunningCoach was also very quick to obtain a GPS fix, since the application attempts to obtain a geolocation fixation as soon as the application has started, and took on average up to 2 seconds to obtain a fix; comparable to the highly evolved application ‘RunKeeper Pro’.
On a 1.02km run, in the same location as the originally tested applications, RunningCoach reported a total distance of 0.86 / 1.02km. This illustrates that RunningCoach is slightly less accurate than the previous applications, which may be for a number of reasons:
1. As with the original tests, geolocation data is affected by complex environment conditions, and as RunningCoach was tested on a separate occasion to the primary applications, the environment may have been slightly different (e.g. a larger cloud cover may have affected the accuracy detrimentally.
2. RunningCoach has not been developed with an ‘outdoor’ host environment. It is assumed that the most accurate CoreLocation applications perform iterative testing between the host and target. If
54
the host environment could be located in an area that is in “direct line of sight [of GPS satellites]” (Rao & Minakakis, 2003), the development accuracy could be greatly improved.
3. RunningCoach has been developed with no prior experience of iPhone development, Objective-c 2.0, or CoreLocation. Naturally, experience with the above three items would lead to a more efficient development with fewer inconsistencies.
Still, RunningCoach is a particularly resource efficient application, and is closely comparable to the professionally developed applications, which have had additional time to evolve.
As an application, RunningCoach lacks a number of the features found in a number of the other mobile running assistants. RunningCoach is less feature-rich than the main applications available in the app store. However, in terms of this dissertation, RunningCoach has provided a huge insight into the iPhone SDK and the numerous problems associated with creating iPhone applications, and specifically CoreLocation applications, and we have been able to provide novel solutions to these problems.
55
7 Conclusion In this concluding chapter, we will outline the key findings from each section of this dissertation before reflecting on the entire project (Section 7.1, pg. 55). Since this dissertation is purposely restricted in terms of scope there are a number of areas that have been identified as potential areas of future work and research (Section 7.2, pg. 57).
7.1 Project Overview In order to begin working towards the goals set out in Chapter 1, an initial review of the previous work in the area was conducted (Chapter 2, pg. 3) involving both a thorough review of the academic literature and an evaluation of existing products. One of the key considerations identified throughout the literature review was the iPhone host-target development environment (Section 2.4.4, pg. 18), which further encouraged the pursuit of both evaluating and enhancing the SDK to support this complex environment. The literature highlighted a variety of important aspects, some of which were out of scope for this dissertation itself. For example, research surrounding HCI was initially required to gather an understanding of the domain of ‘mobile running assistants’, but played a smaller part in the development of this dissertation. The literature review identified that the iPhone SDK should thoroughly support development of CoreLocation applications, however it became clear that this was not the case when evaluating the geolocation accuracy of existing iPhone applications (Section 2.3, pg. 9).
To build on the knowledge gained in the literature review, a requirements elicitation and definition process took place (Chapter 3, pg. 20). A large proportion of the requirements were gathered from potential users of RunningCoach to ensure the application was fulfilling user requirements. In addition to this, many requirements were elicited from the existing solutions, since this dissertation aimed to evaluate the iPhone SDK for creating such applications. Naturally, deriving requirements from these existing solutions allowed the ensuing project phases to accurately reflect a ‘real life’ development scenario of a mobile running assistant using the iPhone SDK.
An architectural and UI design phase was undertaken (Chapter 4, pg. 28) to establish a sound foundation for the development of RunningCoach. This design phase allowed the underlying design of RunningCoach to be formalised so that the implementation phase could take place (Chapter 5, pg. 39). The implementation phase was where the key work would be performed to help bridge the gaps identified in the CoreLocation framework (Section 5.2 pg. 39). In addition to improving the CoreLocation framework, RunningCoach was
56
tested (Section 5.4, pg. 47) and the results from the project documented and evaluated (Chapter 6, pg. 51).
This project organically resulted in a number of improvements to the accuracy and development efficiency of the CoreLocation framework. The results section identifies that effective CoreLocation development can be achieved when iterative testing can be performed across both the host and target environments. Modifying the host environment to support CoreLocation simulation was the key enabler for this. In addition to these SDK improvements, a number of guidelines for developing CoreLocation applications have been identified, along with a simple algorithm to remove erroneous geolocation data from the framework. The results from this dissertation will provide value to the iPhone developer community as well as making a conscious move towards improving the quality of applications made available for iPhone users worldwide.
The initial aim of this project was to develop an application for the Apple iPhone that is capable of tracking a user’s run data. In this respect, the project has been a complete success. An intentional by-product of this aim was to evaluate the effectiveness of the iPhone SDK for creating location aware, ‘CoreLocation’ applications. Developing RunningCoach certainly highlighted the effectiveness (or lack thereof) of the CoreLocation framework, and identified a number of areas that require improvement. In addition to highlighting these areas, this project also contributed novel solutions to help solve problems associated with these framework inefficiencies. Modifying the CoreLocation framework enhanced this project in two ways:
1. The modification enabled RunningCoach to be implemented more efficiently, and to provide a more accurate geolocation reading.
2. This modification is applicable to the official Apple iPhone SDK and therefore could be applied to any iPhone development project, thus increasing the effectiveness of the official SDK itself.
Overall, we feel that this project has been a true success and has provided a number of important (and indeed necessary) extensions to the iPhone SDK that we envisage being submitted to Apple for inclusion in new versions of the SDK2.
2 Due to University Intellectual Property Rights the project author is unable to submit these solutions to Apple, however it is
likely that the new version of the iPhone OS (OS4) in mid 2010 will see a similar implementation included.
57
7.2 Future Work
Human Computer Interaction
With a device such as the iPhone, the majority of human communication with the device is interactive. The device supports a wide array of multi-touch gestures and communication channels. This project has only begun to research into the interaction techniques available on the iPhone. Therefore future work should be performed to provide efficient ways to utilise these SDK libraries, with attention being paid to the host environment, which appears to lack many of the features available in the target environment.
Further CoreLocation Enhancement
The solutions established in this dissertation provide a stepping-stone towards harnessing the power of the CoreLocation framework. This dissertation can be built upon by enhancing the support of CoreLocation in the iPhone simulator. Further research should be performed into the feasibility of creating an application in the target environment (on the iPhone device) that can run simultaneously alongside the iPhone simulator and feed live GPS data wirelessly from the target device to the simulator environment.
~
58
8 References
148Apps.biz. 2009. App Store Metrics. [online] Available at: http://148apps.biz/app-store-metrics/?mpage=submission [Accessed 1 November 2009]
Apple. 2009. Apple iPhone Technical Specifications. [online] Available at: http://www.apple.com/iphone/specs-3g.html [Accessed 10 December 2009]
Apple. 2010a. Apple Development Guide: Using iPhone Simulator. [online] Available at: http://developer.apple.com/iphone/library/documentation/Xcode/Conceptual/iphone_development/125-Using_iPhone_Simulator/iphone_simulator_application.html [Accessed 10 February 2010]
Apple. 2010b. UITableView Class Reference. [online] Available at: http://developer.apple.com/iphone/library/documentation/UIKit/Reference/UITableView_Class/Reference/Reference.html [Accessed 14 April 2010]
Apple. 2010c. iPhone Human Interface Guidelines. [online] Available at: http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html [Accessed 25 April 2010]
Apple. 2010d. Core Location Framework Reference. [online] Available at: http://developer.apple.com/iphone/library/documentation/CoreLocation/Reference/CoreLocation_Framework/index.html [Accessed 4 May 2010]
Boehm, B. 1988. A Spiral Model of Software Development and Enhancement, IEEE Computer. 21(5), pp. 61-72.
59
Campbell, T., Ngo, B., & Fogarty, J. 2008. Game design principles in everyday fitness applications. CSCW '08: Proceedings of the ACM 2008 conference on Computer supported cooperative work. California, U.S.A. 8-12 November 2008.
CNet. 2009. Daily Tidbits: iPhone app downloads reach 500 million. [online] Available at: http://news.cnet.com/8301-17939_109-10144326-2.html [Accessed 12 December 2009]
Djuknic, G., & Richton, R. 2001. Geolocation and Assisted GPS, Computer. 34(2), pp.123-125.
Drake, C. 2003. Non-visual user interfaces. BEng. Perth, Australia: Curtin University of Technology.
Durant, N. 2009. Childhood Obesity: Harnessing Technology for Prevention and Treatment. Bariatric Nursing and Surgical Patient Care, 4(3), pp.157-159.
Estilow, T. 2009. Unbelievable iPhone App Store Statistics. [online] Available at: http://www.iphonefaq.org/archives/97682 [Accessed 12 December 2009]
FCC.gov. n.d. Enhanced 9-1-1 - Wireless Services. [online] Available at http://www.fcc.gov/pshs/services/911-services/enhanced911/Welcome.html [Accessed 14 December 2009]
Golding, P. 2004, Next Generation Wireless Applications, Wiley, Chichester.
International Telecommunication Union. 2008. ICT Statistics. [online] Available at: http://www.itu.int/ITU-D/ict/statistics/ict/index.html [Accessed 1 November 2009]
Kochan, S. 2008. Programming in Objective-C 2.0. Addison-Wesley, 2nd edition.
60
Leva, J., Haag, M., & Dyke, K,. 1996 Understanding GPS: principles and applications. Artech House, Boston London, pp. 237–320.
Lumsden, J., & Brewster, S. 2003. A Paradigm Shift: Alternative Interaction Techniques for Use with Mobile & Wearable Devices. Proceedings of the 2003 conference of the Centre for Advanced Studies on Collaborative research, Toronto, Ontario, Canada 6-9 October 2003, pp.197-210.
Mark, D., & LaMarche, J. 2009. Beginning iPhone Development: Exploring the iPhone SDK. USA: Apress.
MobileOrchard. 2009. Finding iPhone Memory Leaks: A “Leaks” Tool Tutorial [online]. Available at: http://www.mobileorchard.com/find-iphone-memory-leaks-a-leaks-tool-tutorial/ [Accessed 28 April 2010]
Rao, B., & Minakakis, L. 2003. Evolution of mobile location-based services, Communications of the ACM. 46(1), pp.61–65.
RoughlyDrafted. 2008. iPhone 2.0 SDK: Video Games to Rival Nintendo DS, Sony PSP [online] Available at: http://www.roughlydrafted.com/2008/03/20/iphone-20-sdk-video-games-to-rival-nintendo-ds-sony-psp/ [Accessed May 4 2010]
Rogers, M. 2009. It’s for you! An iPhone Development Primer For The Busy College Professor. Journal of Computing Sciences in Colleges. 25(1), pp.94-101.
Rowland, D., Flintham, M., Oppermann, L., & Marshall, J. 2009. Ubikequitous Computing: Designing Interactive Experiences for Cyclists. MobileHCI’09. Bonn, Germany 15-18 September 2009.
Saddique, M., & Amir, M. 2005. Literature review of mobile geo-location techniques. The AEESEAP International Conference 2005, Kuala Lumpur, Malaysia 7-8 June 2005, pp.1-10.
61
Search Engine Land. 2008. Cell Phone Triangulation Accuracy Is All Over The Map. [online] Available at: http://searchengineland.com/cell-phone-triangulation-accuracy-is-all-over-the-map-14790 [Accessed 12 November 2009]
Shimpi, A,. 2009. The iPhone 3GS Hardware Exposed & Analyzed [online] Available at: http://www.anandtech.com/show/2782/2 [Accessed May 4 2010]
Silfverberg, M. 2003. Using Mobile Keypads with Limited Visual Feedback. Mobile HCI 2003. Heidelberg, Berlin 8-10 September 2003, pp. 76-90.
Siltanen, S., Woodward, C., Valli, S., Petri, H., & Rauber, A. 2008. User Interaction for Mobile Devices. Multimodal Processing and Interaction, 33(4) pp.1-17.
Sommerville, I. 2004. Software Engineering (7th Edition), Pearson Addison Wesley.
Wylie, C., & Coulton, P. 2008. Mobile exergaming. ACE '08: Proceedings of the 2008 International Conference on Advances in Computer Entertainment Technology. Yokohama, Japan. 1-5 December 2008. !
62
9 Appendices Appendix A – Survey & Results
Do you own an iPhone?
Do you use your phone for applications?
Do you post content to any of the following:
Which of the following would be most important in a running application?
Yes Yes Facebook, Twitter Run data accuracy
Yes Yes Facebook, Twitter, Myspace, Bebo
Social networking integration
Yes Yes Facebook, Twitter Social networking integration
No Yes Facebook, Twitter Real-time feedback on running
63
Yes Yes Facebook, Myspace Real-time feedback on running
Yes Yes Facebook, Twitter, Other Run data accuracy
No Yes Facebook, Myspace, Bebo, Other
Social networking integration
No No Facebook Run data accuracy
No Yes Facebook, Myspace, Bebo, Other
Social networking integration
Yes Yes Facebook Run data accuracy
Yes Yes Facebook, Twitter Real-time feedback on running
Yes Yes Facebook, Twitter Run data accuracy
Yes Yes Facebook, Twitter, Myspace, Bebo
Social networking integration
Yes Yes Facebook, Twitter Social networking integration
No Yes Facebook, Twitter Real-time feedback on running
Yes Yes Facebook, Myspace Real-time feedback on running
Yes Yes Facebook, Twitter, Other Run data accuracy
No Yes Facebook, Myspace, Bebo, Other
Social networking integration
No Yes Facebook, Twitter, Myspace Real-time feedback on running
No Yes Facebook, Myspace, Bebo, Other
Social networking integration
Yes Yes Facebook Run data accuracy
Yes Yes Facebook, Twitter Real-time feedback on running
Yes Yes Facebook Run data accuracy
Yes Yes Facebook, Twitter, Myspace Run data accuracy
Yes Yes Facebook, Twitter, Myspace Run data accuracy
No No Facebook Run data accuracy
Yes Yes Facebook Run data accuracy
No Yes Facebook, Twitter, Myspace Real-time feedback on running
Yes Yes Facebook, Twitter, Other Run data accuracy
64
Appendix B – Requirements Verification Testing Log
9.1.1 Hardware & Software Requirements
9.1.1.1 Target Requirements # Requirement Priority
1 The application should run on Apple iPhone 3g and later (3gs, …)
Critical
2 The application should compile and run on iPhone OS 3.1.2 (device)
Critical
3 The application should utilise the iPhone inbuilt aGPS receiver
Critical
9.1.1.2 Host Requirements # Requirement Priority
4 The application should be built and deployed on Mac OS X 10.5
Critical
5 The application should compile and run on iPhone OS Simulator 3.1.2 (dev environment)
Critical
6 The application should be built using iPhone SDK 3.1.2 and Xcode 3.1
Critical
7 The application should be compiled using GCC 4.2 compiler
Critical
8 The application should be written in Objective C 2.0 Critical
9.1.2 Functional Requirements
9.1.2.1 Profile Requirements # Requirement Priority
9 The application should support multiple user profiles Significant
65
10 Profile data should be stored in the iPhone persistent data (SQLite database, …)
Significant
11 Profile data should be stored along with:
• Profile ID (UID) • User name • User run data
Significant
12 The application should allow users to add profile data to the iPhone persistent data
Non-vital
13 The application should allow users to delete profile data from the iPhone persistent data
Non-vital
14 The application should allow users to modify profile data in the iPhone persistent data
Non-vital
9.1.2.2 RunningCoach Requirements # Requirement Priority
15 The RunningCoach UI should display the currently selected profile data including:
• User Name • Number of runs completed • Total run distance
Significant
16 The application should utilise the iPhone aGPS (corelocation framework) to determine the device’s current location
Critical
17 The application should calculate the distance travelled between two GPS coordinates
Critical
18 The application should only allow the user to track running data if the GPS accuracy is accurate within 50m.
Significant
19 The RunningCoach UI should display the current GPS accuracy in meters
Significant
20 The application should calculate the users total run distance by logging the distance between GPS coordinates n and n+1
Critical
21 The application should calculate and display to the Significant
66
UI the users current running speed
22 The application should calculate and display to the UI a timer showing the current run time for the existing run
Significant
23 The application should begin tracking the users running data once the ‘Start’ button is pressed.
Significant
24 The application should stop tracking the users running data once the ‘Stop’ button is pressed.
Significant
25 The application should store run data to the iPhone persistent data once a run is completed
Significant
9.1.2.3 History Requirements # Requirement Priority
26 The application should display the history of the currently selected users run data, including:
• Run time • Average running speed • Total distance covered
Non-vital
27 The application should display a map of the individual run data, showing the route taken, including the start and end points of the run
Non-vital
9.1.2.4 Settings Requirements # Requirement Priority
28 The application should allow switching between kilometres and miles throughout the application
Non-vital
29 The application should allow the user to define the desired GPS accuracy
Non-vital
30 The application should allow the user to turn on and off audio feedback on the run
Non-vital
31 The application should allow the user to select a playlist of music from the iPhone to be played whilst the user run is in progress
Non-vital
67
32 The application should offer the option to ‘autosave’ runs rather than prompting
Non-vital
9.1.2.5 User Interface Requirements # Requirement Priority
33 The application should contain UI screens for each view:
• Profile • RunningCoach • History • Settings
Significant
34 The application should include a ‘tab’ view in the same style as existing Apple applications
Significant
35 The application User Interface should function entirely using the iPhone touch screen technology
Significant
9.1.3 Non-Functional Requirements
9.1.3.1 Application Requirements # Requirement Priority
36 The application should provide as accurate as possible GPS tracking
Significant
37 The application should require no longer than 5 minutes training for a user with no prior experience with an iPhone
Significant
38 The application should require no training at all for a user with prior iPhone experience
Significant
39 The application should conserve the iPhone battery as much as possible
Significant
40 The application should not contain memory leaks, and should exit gracefully in the event of an error
Critical
41 The application should handle incoming calls and text messages in an intuitive way
Significant
68
9.1.3.2 User Interface Requirements # Requirement Priority
42 The application should conform as closely as possible to the standard Apple application layout
Significant
43 The application should include a ‘loading’ view to inform the user the application is loading
Non-vital
44 The application should have an icon displaying the application logo on the iPhone home screen
Non-vital
45 The application should minimise the user physical interaction with the device User Interface
Significant
69
Appendix C – Source Code // // RunningCoachViewController.h // RunningCoach // // Created by Gareth Talty on 13/02/2010. // Copyright __MyCompanyName__ 2010. All rights reserved. // #import <UIKit/UIKit.h> #import <CoreLocation/CoreLocation.h> #import "Run.h" #import "Profile.h" @interface RunningCoachViewController : UIViewController <CLLocationManagerDelegate, UIActionSheetDelegate> { CLLocationManager *locationManager; CLLocation *currentLocation; CLLocation *startingPoint; Run *currentRun; Profile *currentRunner; IBOutlet UILabel *name; IBOutlet UILabel *runTimerLabel; IBOutlet UILabel *speedLabel; IBOutlet UILabel *totalDistanceTravelledLabel; IBOutlet UILabel *horizontalAccuracyLabel; IBOutlet UIActivityIndicatorView *spinner; IBOutlet UIButton *startSpin; IBOutlet UIButton *stopSpin; IBOutlet UIButton *startButton; IBOutlet UIButton *resetButton; IBOutlet UIButton *stopButton; } @property (nonatomic, retain) IBOutlet UILabel *name; @property (nonatomic, retain) IBOutlet UILabel *totalDistanceTravelledLabel; @property (nonatomic, retain) IBOutlet UILabel *horizontalAccuracyLabel; @property (nonatomic, retain) IBOutlet UILabel *runTimerLabel; @property (nonatomic, retain) IBOutlet UILabel *speedLabel; @property (nonatomic, retain) IBOutlet UIButton *startButton; @property (nonatomic, retain) IBOutlet UIButton *stopButton; @property (nonatomic, retain) IBOutlet UIButton *resetButton; @property (nonatomic, retain) IBOutlet UIActivityIndicatorView *spinner; @property (nonatomic, retain) CLLocationManager *locationManager; @property (nonatomic, retain) CLLocation *startingPoint; @property (nonatomic, retain) CLLocation *currentLocation;
70
@property (nonatomic, retain) Run *currentRun; @property (nonatomic, retain) Profile *currentRunner; -(IBAction)startButtonPressed; -(IBAction)stopButtonPressed; -(IBAction)resetButtonPressed; -(IBAction)startSpinner; -(IBAction)stopSpinner; -(BOOL)saveRunData; @end // // RunningCoachViewController.m // RunningCoach // // Created by Gareth Talty on 13/02/2010. // Copyright __MyCompanyName__ 2010. All rights reserved. // #import "RunningCoachViewController.h" #import "Run.h" #import "Profile.h" #import "tabbarAppDelegate.h" @implementation RunningCoachViewController //UILocationManager + Locations @synthesize locationManager; @synthesize startingPoint; @synthesize currentLocation; //UIButtons @synthesize startButton; @synthesize resetButton; @synthesize stopButton; //UILabels @synthesize name; @synthesize runTimerLabel; @synthesize speedLabel; @synthesize horizontalAccuracyLabel; @synthesize spinner; @synthesize totalDistanceTravelledLabel; @synthesize currentRun; @synthesize currentRunner; static double totalDistanceTravelled; - (void)didReceiveMemoryWarning { // Releases the view if it doesn't have a superview. [super didReceiveMemoryWarning]; // Release any cached data, images, etc that aren't in use. } - (void)viewDidUnload { }
71
- (void)viewDidLoad { // load the location info locationManager = [[CLLocationManager alloc] init]; locationManager.delegate = self; locationManager.distanceFilter = kCLDistanceFilterNone; locationManager.desiredAccuracy = kCLLocationAccuracyBest; [locationManager startUpdatingLocation]; //TODO: /* while(currentLocation.horizontalAccuracy <= 100 ) { // TODO unable to gather decent GPS accuracy, prompt to start non-GPS mode, or continue waiting for gps accuracy UIActionSheet *actionSheet = [[UIActionSheet alloc] initWithTitle:@"Unable to get GPS Fix. Do you want to enter non-GPS mode?" delegate:self cancelButtonTitle:@"No, keep trying!" destructiveButtonTitle:@"Yes please!" otherButtonTitles:nil]; [actionSheet showInView:self.view]; [actionSheet release]; }*/ } -(IBAction)startButtonPressed { currentRun = [[Run alloc] init]; // only start run if not already started if (![currentRun isRunStarted]) { [currentRun startRun]; NSTimer *timer; timer = [NSTimer scheduledTimerWithTimeInterval:1.0f target:self selector:@selector(updateCounter:) userInfo:nil repeats:YES]; //NSMutableArray *runCoords = [[NSMutableArray alloc]init]; [currentRun.runCoords addObject:currentLocation]; //[currentRun.runCoords addObject:[CLLocation currentLocation]]; //hide start buttoni can startButton.hidden = TRUE; stopButton.hidden = FALSE;
72
} } - (IBAction) startSpinner { [spinner startAnimating]; } - (IBAction) stopSpinner { [spinner stopAnimating]; } - (void)locationManager:(CLLocationManager *)manager didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation *)oldLocation { //static double totalDistanceTravelled; NSLog(@"oldLocation : %@", oldLocation); NSLog(@"newLocation : %@", newLocation); //*newLocation = [self.initWithLatitude:+30.000010 longitude:+090.650020]; NSDate* newLocationeventDate = newLocation.timestamp; NSTimeInterval howRecentNewLocation = [newLocationeventDate timeIntervalSinceNow]; //if the horizontalAccuracy is negative, CoreLocation failed, and we want a good reading, so we want at least 100 meter accuracy, show the start buttons, and hide the loading animator if([newLocation horizontalAccuracy] <= 10000 && [newLocation horizontalAccuracy] > 0){ // Needed to filter cached and too old locations if ((!currentLocation || currentLocation.horizontalAccuracy > newLocation.horizontalAccuracy) && (howRecentNewLocation < -0.0 && howRecentNewLocation > -10.0)) { if (currentLocation) [currentLocation release]; currentLocation = [newLocation retain]; NSLog(@"currentLocation : %@", currentLocation); NSString *horizontalAccuracyString = [[NSString alloc] initWithFormat:@"%gm -/+", newLocation.horizontalAccuracy]; horizontalAccuracyLabel.text=horizontalAccuracyString; NSLog(@"horiz ac %@",horizontalAccuracyString); [horizontalAccuracyString release]; startButton.hidden = FALSE; resetButton.hidden = FALSE; spinner.hidden = TRUE; [spinner stopAnimating]; if ([currentRun isRunStarted]) {
73
[currentRun.runCoords addObject:currentLocation]; if (oldLocation != nil) { CLLocationDistance distanceChange = [newLocation getDistanceFrom:oldLocation]; totalDistanceTravelled += distanceChange; NSString *distanceString = [[NSString alloc] initWithFormat:@"%g km", totalDistanceTravelled*1000]; totalDistanceTravelledLabel.text = distanceString; [distanceString release]; CLLocationSpeed speed = newLocation.speed; NSString *speedString = [[NSString alloc] initWithFormat:@"%g km/h", speed*3.6]; speedLabel.text = speedString; [speedString release]; } } } } } - (void)dealloc { [locationManager release]; [startingPoint release]; [currentLocation release]; //UIButtons [startButton release]; [resetButton release]; [stopButton release]; //UILabels [name release]; [runTimerLabel release]; [speedLabel release]; [horizontalAccuracyLabel release]; [spinner release]; [totalDistanceTravelledLabel release]; [currentRun release]; [currentRunner release]; [spinner release]; [super dealloc]; } - (void)actionSheet:(UIActionSheet *)actionSheet didDismissWithButtonIndex:(NSInteger)buttonIndex {
74
if(!(buttonIndex == [actionSheet cancelButtonIndex])) { if([self saveRunData]) { UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Run Saved!" message:@"Your run data has been saved" delegate:self cancelButtonTitle:@"Ok!" otherButtonTitles:nil]; [alert show]; [alert release]; } else { UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"There was a problem!" message:@"Your run data has not been saved" delegate:self cancelButtonTitle:@"Ok!" otherButtonTitles:nil]; [alert show]; [alert release]; } //[self dealloc]; // [msg release]; } } -(void)reset { totalDistanceTravelledLabel.text = @"0.00 km"; speedLabel.text = @"0.00 km/h"; [currentRun release]; self.currentRun = [[Run alloc] init]; runTimerLabel.text = currentRun.runTime; } -(BOOL)saveRunData { //if run saved properly return 1 if (1==1){ /* if(addStatement == nil) { const char *sql = "insert into Runs (time) Values(?,?, ?,?,?,?,?,?)"; if(sqlite3_prepare_v2(db, sql, -1, &addStatement, NULL) != SQLITE_OK) NSAssert1(0, @"Error while creating insert statement. '%s'", sqlite3_errmsg(db)); } sqlite3_bind_double(addStatement, 1, currentRun.runTime);*/
75
return 1; } else { return 0; } } -(IBAction)stopButtonPressed { // prompt to save run or discard UIActionSheet *actionSheet = [[UIActionSheet alloc] initWithTitle:@"Run complete. Do you wish to save this run?" delegate:self cancelButtonTitle:@"No thanks!" destructiveButtonTitle:@"Yes, I'm sure!" otherButtonTitles:nil]; [actionSheet showInView:self.view]; [actionSheet release]; // [timer invalidate]; [currentRun stopRun]; startButton.hidden = FALSE; stopButton.hidden = TRUE; } - (void)updateCounter:(NSTimer *)theTimer { NSLog(@"runTime : %@", currentRun.runTime); NSLog(@"coordinates : %@", currentLocation); self.runTimerLabel.text = currentRun.runTime; //[currentRun.runCoords addObject:[CLLocation currentLocation]]; NSLog(@"RunCoords : %@", currentRun.runCoords); } -(IBAction)resetButtonPressed{ //[self dealloc]; [self viewDidLoad]; } /* // The designated initializer. Override to perform setup that is required before the view is loaded. - (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil { if (self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) { // Custom initialization } return self; } */ /*
76
// Implement loadView to create a view hierarchy programmatically, without using a nib. - (void)loadView { } */ /* // Implement viewDidLoad to do additional setup after loading the view, typically from a nib. - (void)viewDidLoad { [super viewDidLoad]; } */ /* // Override to allow orientations other than the default portrait orientation. - (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation { // Return YES for supported orientations return (interfaceOrientation == UIInterfaceOrientationPortrait); } */ @end // // AddViewController.h // RunningCoach // #import <UIKit/UIKit.h> @class Profile; @interface AddViewController : UIViewController { IBOutlet UITextField *txtFirstName; IBOutlet UITextField *txtLastName; } @end // // AddViewController.h // RunningCoach // // Modified from tutorial at www.iPhoneSDKArticles.com. #import "AddViewController.h" #import "Profile.h" #import "tabbarAppDelegate.h" @implementation AddViewController /*
77
// Override initWithNibName:bundle: to load the view using a nib file then perform additional customization that is not appropriate for viewDidLoad. - (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil { if (self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) { // Custom initialization } return self; } */ /* // Implement loadView to create a view hierarchy programmatically. - (void)loadView { } */ // Implement viewDidLoad to do additional setup after loading the view. - (void)viewDidLoad { [super viewDidLoad]; self.title = @"Add Profile"; self.navigationItem.leftBarButtonItem = [[[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemCancel target:self action:@selector(cancel_Clicked:)] autorelease]; self.navigationItem.rightBarButtonItem = [[[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemSave target:self action:@selector(save_Clicked:)] autorelease]; self.view.backgroundColor = [UIColor groupTableViewBackgroundColor]; } - (void) viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; //Set the textboxes to empty string. txtFirstName.text = @""; txtLastName.text = @""; //Make the coffe name textfield to be the first responder. [txtFirstName becomeFirstResponder]; }
78
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation { // Return YES for supported orientations return (interfaceOrientation == UIInterfaceOrientationPortrait); } - (void)didReceiveMemoryWarning { [super didReceiveMemoryWarning]; // Releases the view if it doesn't have a superview // Release anything that's not essential, such as cached data } - (void) save_Clicked:(id)sender { tabbarAppDelegate *appDelegate = (tabbarAppDelegate *)[[UIApplication sharedApplication] delegate]; //Create a Coffee Object. Profile *profileObj = [[Profile alloc] initWithPrimaryKey:0]; profileObj.FirstName = txtFirstName.text; //NSDecimalNumber *temp = [[NSDecimalNumber alloc] initWithString:txtPrice.text]; profileObj.LastName = txtLastName.text; // [temp release]; //coffeeObj.isDirty = NO; // coffeeObj.isDetailViewHydrated = YES; //Add the object [appDelegate addProfile:profileObj]; //Dismiss the controller. [self.navigationController dismissModalViewControllerAnimated:YES]; } - (void) cancel_Clicked:(id)sender { //Dismiss the controller. [self.navigationController dismissModalViewControllerAnimated:YES]; } - (BOOL)textFieldShouldReturn:(UITextField *)theTextField { [theTextField resignFirstResponder]; return YES; } - (void)dealloc { [txtFirstName release]; [txtLastName release]; [super dealloc]; } @end
79
// // Profile.h // RunningCoach // // Created by Gareth Talty on 13/02/2010. // Copyright 2010 __MyCompanyName__. All rights reserved. // // Modified from tutorial at http://icodeblog.com/2008/08/19/iphone-programming-tutorial-creating-a-todo-list-using-sqlite-part-1/#add-db #import <Foundation/Foundation.h> #import <sqlite3.h> @interface Profile : NSObject { sqlite3 *database; NSInteger primaryKey; NSString *FirstName; NSString *LastName; UIImage *profilePicture; } @property (assign, nonatomic, readonly) NSInteger primaryKey; @property (nonatomic, retain) NSString *FirstName; @property (nonatomic, retain) NSString *LastName; @property (nonatomic, retain) UIImage *profilePicture; -(id)initWithPrimaryKey:(NSInteger)pk database:(sqlite3 *)db; -(void)addProfile; @end // // Profile.m // RunningCoach // // Created by Gareth Talty on 13/02/2010. // Copyright 2010 __MyCompanyName__. All rights reserved. // Adapted source from http://www.iphonesdkarticles.com/2008/10/sqlite-tutorial-adding-data.html // #import "Profile.h" static sqlite3_stmt *init_statement = nil; static sqlite3_stmt *addStmt = nil; @implementation Profile @synthesize primaryKey; @synthesize FirstName; @synthesize LastName; @synthesize profilePicture; -(id)initWithPrimaryKey:(NSInteger)pk database:(sqlite3 *)db { if(self = [super init]) { primaryKey = pk; database = db;
80
//Compile the query for retrieving data. if(init_statement == nil) { const char *sql = "SELECT FirstName, LastName FROM Profiles WHERE pk=?"; if(sqlite3_prepare_v2(database, sql, -1, &init_statement, NULL) != SQLITE_OK){ NSAssert1(0,@"Error: Failed to prepare statement with message '%s'.", sqlite3_errmsg(database)); } } sqlite3_bind_int(init_statement, 1, primaryKey); if(sqlite3_step(init_statement) == SQLITE_ROW){ self.FirstName = [NSString stringWithUTF8String:(char *)sqlite3_column_text(init_statement,0)]; self.LastName = [NSString stringWithUTF8String:(char *)sqlite3_column_text(init_statement, 1)]; } else { self.FirstName= @"(NoFirstName)"; self.LastName= @"(NoLastName)"; } sqlite3_reset(init_statement); } return self; } - (void) addProfile { if(addStmt == nil) { const char *sql = "insert into Profiles(FirstName, LastName) Values(?, ?)"; if(sqlite3_prepare_v2(database, sql, -1, &addStmt, NULL) != SQLITE_OK) NSAssert1(0, @"Error while creating add statement. '%s'", sqlite3_errmsg(database)); } sqlite3_bind_text(addStmt, 1, [FirstName UTF8String], -1, SQLITE_TRANSIENT); sqlite3_bind_text(addStmt, 2, [LastName UTF8String], -1, SQLITE_TRANSIENT); if(SQLITE_DONE != sqlite3_step(addStmt)) NSAssert1(0, @"Error while inserting data. '%s'", sqlite3_errmsg(database)); else //SQLite provides a method to get the last primary key inserted by using sqlite3_last_insert_rowid primaryKey = sqlite3_last_insert_rowid(database); //Reset the add statement. sqlite3_reset(addStmt); } - (void) dealloc { [FirstName release]; [LastName release]; [super dealloc];
81
} @end // // tabbarAppDelegate.h // RunningCoach // // Created by Gareth Talty on 13/02/2010. // Copyright __MyCompanyName__ 2010. All rights reserved. // #import <UIKit/UIKit.h> #import <sqlite3.h> @class Profile; @interface tabbarAppDelegate : NSObject <UIApplicationDelegate, UITabBarControllerDelegate> { IBOutlet UIWindow *window; IBOutlet UITabBarController *tabBarController; //IBOutlet UINavigationController *mainNavController; IBOutlet UINavigationItem *addProfile; sqlite3 *database; NSMutableArray *Profiles; //NSArray *contentArray; } @property (nonatomic, retain) IBOutlet UIWindow *window; @property (nonatomic, retain) IBOutlet UITabBarController *tabBarController; @property (nonatomic, retain) NSMutableArray *Profiles; //@property (nonatomic, retain) IBOutlet UINavigationItem *addProfile; -(void) addProfile:(Profile *)profileObj; @end // // tabbarAppDelegate.m // RunningCoach // // Created by Gareth Talty on 13/02/2010. // Copyright __MyCompanyName__ 2010. All rights reserved. // // Modified source from http://code.google.com/p/sqlite-manager/issues/detail?id=346 // #import "tabbarAppDelegate.h" #import "Profile.h" @implementation tabbarAppDelegate @synthesize window; @synthesize tabBarController; @synthesize Profiles;
82
//@synthesize addProfile; //@synthesize contentArray; - (void)addProfile:(Profile *)profileObj { NSLog ( @"add Profile pressed"); [profileObj addProfile]; } // Creates a writable copy of the bundled default database in the application Documents directory. - (void)createEditableCopyOfDatabaseIfNeeded { // First, test for existence. BOOL success; NSFileManager *fileManager = [NSFileManager defaultManager]; NSError *error; NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); NSString *documentsDirectory = [paths objectAtIndex:0]; NSString *writableDBPath = [documentsDirectory stringByAppendingPathComponent:@"profiledb.sqlite"]; success = [fileManager fileExistsAtPath:writableDBPath]; if (success) return; // The writable database does not exist, so copy the default to the appropriate location. NSString *defaultDBPath = [[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:@"profiledb.sqlite"]; success = [fileManager copyItemAtPath:defaultDBPath toPath:writableDBPath error:&error]; if (!success) { NSAssert1(0, @"Failed to create writable database file with message '%@'.", [error localizedDescription]); } } // Open the database connection and retrieve minimal information for all objects. - (void)initializeDatabase { NSMutableArray *profilesArray = [[NSMutableArray alloc] init]; self.Profiles = profilesArray; [profilesArray release]; // The database is stored in the application bundle. NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES); NSString *documentsDirectory = [paths objectAtIndex:0]; NSString *path = [documentsDirectory stringByAppendingPathComponent:@"profiledb.sqlite"]; // Open the database. The database was prepared outside the application. if (sqlite3_open([path UTF8String], &database) == SQLITE_OK) { // Get the primary key for all books. const char *sql = "SELECT pk FROM Profiles"; sqlite3_stmt *statement; // Preparing a statement compiles the SQL query into a byte-code program in the SQLite library. // The third parameter is either the length of the SQL string or -1 to read up to the first null terminator.
83
if (sqlite3_prepare_v2(database, sql, -1, &statement, NULL) == SQLITE_OK) { // We "step" through the results - once for each row. while (sqlite3_step(statement) == SQLITE_ROW) { // The second parameter indicates the column index into the result set. int primaryKey = sqlite3_column_int(statement, 0); // We avoid the alloc-init-autorelease pattern here because we are in a tight loop and // autorelease is slightly more expensive than release. This design choice has nothing to do with // actual memory management - at the end of this block of code, all the book objects allocated // here will be in memory regardless of whether we use autorelease or release, because they are // retained by the books array. Profile *td = [[Profile alloc] initWithPrimaryKey:primaryKey database:database]; [Profiles addObject:td]; [td release]; } } // "Finalize" the statement - releases the resources associated with the statement. sqlite3_finalize(statement); } else { // Even though the open failed, call close to properly clean up resources. sqlite3_close(database); NSAssert1(0, @"Failed to open database with message '%s'.", sqlite3_errmsg(database)); // Additional error handling, as appropriate... } //NSLog([[NSString alloc] initWithFormat:@"size:%@",[[Profiles objectAtIndex:3] text]]); } /* // Optional UITabBarControllerDelegate method - (void)tabBarController:(UITabBarController *)tabBarController didSelectViewController:(UIViewController *)viewController { } */ /* // Optional UITabBarControllerDelegate method - (void)tabBarController:(UITabBarController *)tabBarController didEndCustomizingViewControllers:(NSArray *)viewControllers changed:(BOOL)changed { } */ - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger )section { return [Profiles count]; }
84
-(UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { static NSString *identity = @"MainCell"; UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identity]; if(cell == nil) { cell = [[[UITableViewCell alloc] initWithFrame:CGRectZero reuseIdentifier:identity] autorelease]; } Profile *profile = (Profile *)[Profiles objectAtIndex:indexPath.row]; NSString *entry = [NSString stringWithFormat:@"%@ %@", profile.FirstName, profile.LastName]; //cell.accessoryType = UITableViewCellAccessoryCheckmark; [cell.textLabel setText: entry]; //[cell.textLabel setText: profile.FirstName & profile.LastName]; //[cell.textLabel setText: [Profiles objectAtIndex:indexPath.row]]; return cell; } - (void)dealloc { [tabBarController release]; [window release]; [Profiles release]; [super dealloc]; } - (void)applicationDidFinishLaunching:(UIApplication *)application { [self createEditableCopyOfDatabaseIfNeeded]; [self initializeDatabase]; [window addSubview:tabBarController.view]; } @end // // Run.h // RunningCoach // // Created by Gareth Talty on 18/02/2010. // Copyright 2010 __MyCompanyName__. All rights reserved. // #import <Foundation/Foundation.h>
85
@interface Run : NSObject { NSString *runTime; NSTimer *runTimer; NSMutableArray *runCoords; double distance; //IBOutlet UILabel *runTimerLabel; } @property (nonatomic, retain) NSString *runTime; //@property (nonatomic, retain) IBOutlet UILabel *runTimerLabel; @property (nonatomic, retain) NSTimer *runTimer; @property (nonatomic, retain) NSMutableArray *runCoords; -(void)setRunTime:(NSString *)runTime; -(void)startRun; -(void)stopRun; -(BOOL)isRunStarted; @end // // Run.m // RunningCoach // // Created by Gareth Talty on 18/02/2010. // Copyright 2010 __MyCompanyName__. All rights reserved. // #import "Run.h" @implementation Run @synthesize runTime; @synthesize runTimer; @synthesize runCoords; //@synthesize runTimerLabel; static int count; -(id)init { count = 0; self.runTime = @"0:00"; runTimer = nil; runCoords = nil; return self; } -(void)startRun { NSLog(@"Run started"); self.runTimer = [NSTimer scheduledTimerWithTimeInterval:1.0f target:self selector:@selector(updateCounter:) userInfo:nil repeats:YES]; self.runCoords = [[NSMutableArray alloc]init]; }
86
-(void)stopRun { NSLog(@"Run stopped"); [self.runTimer invalidate]; } -(BOOL)isRunStarted { if (self.runTime == @"0:00") { return 0; } else { return 1; } } - (void)updateCounter:(NSTimer *)runTimer { //value clock is incremented by count += 1; int secondsPart = count % 60; int minutesPart = (int) floor(count / 60.0); //format runTimer to handle seconds + minutes: 00:00 self.runTime = [NSString stringWithFormat:(secondsPart<10 ? @"%i:0%i" : @"%i:%i"), minutesPart, secondsPart]; //return theTimer; } @end // // main.m // RunningCoach // // Created by Gareth Talty on 21/04/2010. // Copyright __MyCompanyName__ 2010. All rights reserved. // #import <UIKit/UIKit.h> int main(int argc, char *argv[]) { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; int retVal = UIApplicationMain(argc, argv, nil, nil); [pool release]; return retVal; } // // Prefix header for all source files of the 'tabbar' target in the 'tabbar' project // #ifdef __OBJC__ #import <Foundation/Foundation.h> #import <UIKit/UIKit.h> #endif