代写一个运动类的App程序，练习Google Map API的使用方法。
Aim
Your team will develop a location-aware app which allows the user to test
themselves running to random nearby locations and improve their overall
fitness. Your app will determine the user’s initial location and allow them to
request a random location to run to. As they run, the app will track their
location and calculate the time, distance and speed of the run. Users will
then be able to compare runs and reattempt previous ones to improve.
This assignment will require you to demonstrate an understanding of object
orientation, persistent storage, use of external APIs, as well as related of
code style, documentation, and principles of interface design.
Background
Your team, along with 23 others, have been flown to Osnea (a mid sized pacific
nation) on behalf of the Osnean Institute of Sport (OIS), which trains famous
athletes such as “Fast-Terry Van Zanzebolt”, “Riley Quick”, “Fi Targoing” and
“Mani Kays”. As part of a tender process, they have tasked each team with
developing a proof of concept app to help their athletes train using their
phones.
The best proof of concept app will result in further work for that team as
they will be tasked in developing and maintaining a full app that can be
distributed to all those at OIS to help runners and hurdlers prepare for
upcoming events. If it is well received by their athletes, OIS may also
consider asking the winning organisation to make the app accessible as a paid
product via app stores for Android, Apple and Windows Phone.
What you are provided with
We have made available a skeleton version of the app. The skeleton provides
you with several HTML pages and associated JavaScript and CSS files
representing the structure of the app. You will need to implement the logic
and functionality for each of these pages as described below.
The app skeleton contains three web pages that utilise MDL for their
interface:
- Runs List page (main index page)
- New Run page
- View Run page
A “Run” is a series of ordered points representing the path the user runs to
reach their destination.
In the app skeleton, these pages are mostly blank. They include sample entries
only to demonstrate how to navigate and pass information from one page to
another. You may modify these file as you like, however you should not change
the file names.
The app skeleton contains a displayMessage function you can use to display
toast messages.
What you need to do
This assignment consists of multiple tasks, including programming,
documentation, and use of software tools. For the programming tasks, we
suggest you complete each step together as a team before moving onto the next
one. It is strongly recommended that you practice pair programming rather
than trying to split up the coding and attempting parts individually.
You will need to communicate effectively with your team while working on the
assignment. Your use of Git, Asana, and Google Drive will affect your final
marks on this assignment and as with Assignment 1, your final marks will be
scaled by your team contribution as determined by CATME.
Finally, there will be a team “client” presentation as well as an individual
interview on your submitted code, both of which will occur during your week 12
practical class.
Getting started
- One team member should create an “assignment2” directory with the necessary initial directory structure in your team Git repository by committing the provided skeleton code (see the Skeleton code and the “Submission” section below).
- One of your team members should set up an API key for Google Maps attached to a team Google account (if you didn’t do this already as part of the Week 6 prac exercise).
- Your team should read and discuss the list of required functionality below and create Asana tasks for the necessary features. You should discuss these and break them down into necessary subtasks.
Required functionality
Create a Run class
The app should allow the user to track several different runs and calculate
some information for these. It will be necessary for the app to distinguish
runs from one another. You should create a Run class with several private
attributes: the start location (a google.maps.LatLng instance), the
destination location (a google.maps.LatLng instance), an array of locations
(of google.maps.LatLng instances) representing the path taken by the user, the
date (incl. time) the run was started, the date (and time) the run was
completed, and any other information you feel is necessary.
Note:
- The Google Maps (spherical) geometry API provides useful functions and classes including a google.maps.LatLng class for storing a physical position.
- To use the geometry API you should add the “&libraries=geometry” to the query string to the URL used to load the Google Maps script. This is not always necessary but can cause errors in some circumstances if missing.
- The Google Maps JavaScript file must be loaded and ready before you can make use of classes or code from the API. Usually your initMap callback function will be called when the the API is ready to be used. Hence you should not use the Google Maps API until you receive that callback.
Location detection and tracking
When the user launches the New Run page, the app should locate the user and
display their position and location accuracy on an interactive map. This
information should be updated as the user’s location changes or increases in
accuracy.
Note:
- The builtin JavaScript geolocation API can be used to watch the user’s location. Using the watchLocation method, this code will call a callback function for every location change and give the new location as an argument. This is the approach used in the ENG1003 sensor test app we explored in prac classes.
Destination generation and display
There should be a button on the app’s New Run page which can be tapped to
generate a new destination (a random nearby location). This random location
should be based off the current position of the user (between 60m and 150m
away from it). This button should be initially disabled and should become
enabled when the user’s location accuracy first drops below 20 metres for the
first time.
You should ensure that the logic for generating a random destination is
implemented as a function called ‘randomDestination’ which takes as a single
argument, a google.maps.LatLng class instance, representing the current
location, and returns a google.maps.LatLng class instance representing the new
random location.
| Function Name | File | Input | Output |
|---|---|---|---|
| randomDestination | newRunPage.js | LatLng of current location | LatLng |
| of new location | |||
| The destination should be displayed on the map and the app should display an | |||
| estimated distance from the user’s current location to the destination | |||
| (assuming a direct path from one to the other). This distance estimate should | |||
| update as the user’s position changes. | |||
| Note: |
- Random values can be generated in JavaScript with the builtin Math.random function, as we did in the Dice Rolling prac exercise.
- Modifying a latitude and longitude by a random amount up to ±0.001 will result in a change of no more than 150m.
- You should check that your randomly generated location is not less that 60 metres from the user’s current location. If it is, you should silently select a new destination, so the user doesn’t receive destinations too close to their position.
- The Google Maps (spherical) geometry API provides useful functions; please see resources for documentation.
- computeDistanceBetween() - returns the distance between two google.maps.LatLng class instances in metres.
Beginning a run
The New Run page should have a button to begin the run. When this button is
tapped, the user is expected to run to the destination. The app should set
the start location and time for the run and begin recording the route. You
should store this in a new instance of your Run class.
This “begin run” button should be disabled until the user has selected a
destination.
As the user runs, the app should continue tracking and displaying their
position on the map and displaying the estimated distance to the destination.
In addition to this, the app should display the estimated distance from the
starting location (assuming a direct path from one to the other).
Completing a run
When the user is very close to their destination (for example, within 10
meters) the app should end the run, and record the completion time for the
run.
You should add two methods to the Run class which calculate the total distance
travelled by the user and the duration (time taken). The app should display
the time taken for the run and distance traveled.
Persistent storage of Run instances
The New Run page should provide the user the ability to save the new run once
they have completed it (disabling the button before this). This “save” action
should store the new Run instance in local storage and then return the user to
the Past Runs List (index) page.
Note:
- Be sure that you store runs in such a way that you can retrieve all of your runs from local storage later.
- You may choose to allow the user to store a given run with a nickname/short description for easy identification later.
Showing a list of Runs
Once you have one or more Run instances stored in local storage, you should
modify the Past Runs List (index) page so that it displays a list of Runs that
can be viewed. This list should be generated from information in local storage
and should include the date/time when the run was recorded (and any other
information you would like to display). Clicking on an entry in the list
should cause the app to navigate to the View Run page and display that Run.
Viewing a Run
When the user views an existing run via the View Run page, the app should
display the run on an interactive map, including the start location,
destination and intermediate path.
This page should provide the user a method to delete that Run, which should
remove the Run from local storage and return the user to Runs List (index)
page.
This page should display the distance of the run and the duration, along with
the average speed for this run.
Repeating a Run
The app should allow the user to try and improve their time for a given run.
The View Run page should have a “Reattempt” button that takes the user to the
New Run page, but presets the starting location and destination rather than
allowing the users to select these.
When the user reattempts the run, the app should prevent them from starting
the run until they are near the start location of that run. For this the new
Run page will need to respond differently for reattempted runs, i.e., track
the user prior to beginning the run.
The programming tasks together are worth 10% of your unit mark.
Your team can modify or extend your app as you like, provided it has the
required functionality. In particular, ensure you consider usability when
designing the behaviour of the app.
Technical documentation
Your team should produce two short pieces of technical documentation for your
app:
- A basic Project Management Plan. This is internal documentation detailing:
- Project aim and scope
- Team members, and their responsibilities
- How you are going to do the project, e.g., team meetings, minutes, handling communication of changes to the code
- Any other information you would want to give to a new team member
- A User Guide. This is external documentation detailing:
- How to get started using the app, with screenshots
- Any known bugs or limitations
Your team will be assessed based on the quality of these documents. This will
be worth 9% of your final mark for the unit.
Presentation
Your team has now finished (or mostly finished) the prototype running app for
the Osnean Institute of Sport. Their representative, Tony Heelson, has
organised time for each of the prospective teams (yours and your competitors)
to demonstrate their apps. Based on the client’s satisfaction with the
prototypes and presentations, they will decide which team will be awarded the
contract to produce the full app.
While you will be primarily presenting to the client (OIS), your team can
expect both representatives from the client as well as other hopeful software
teams to be in the audience. Ensure that your presentation explains the
features of the app. It should explain how the app works and describe any
specialised hardware required. You should talk at a high-level about
architecture in order to explain how the app might be extended or what
additional features could conceivably be built on top of it, but you should be
careful not to include too much technical detail or jargon.
This presentation will be a formal client presentation delivered in front of
your prac class. It will be based on the app you produced for Assignment 2. As
with any good presentation, it should be prepared well in advance of the due
date (including any visual aides) and it should be well rehearsed as a team.
Format
Each student team will deliver a 15 minute oral presentation (in prac class)
describing and demonstrating their app and detailing any issues. Every member
of the team should present for 3-5 minutes.
- The target audience for this presentation is the client for the project
- This presentation will be delivered in a business setting and so all team members should be dressed appropriately
- This presentation must discuss the design, structure and functionality of the application
This presentation will be worth 6% of your final mark for the unit.
Testing the app
You can upload your code to the ENG1003 server using the Assignment Upload
Page. This will open a tab for the uploaded app giving you the URL of the
uploaded app on the server. You can then open this page on your team phone.
