JavaScript代写:ENG1003 Run Challenge App

代写一个运动类的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

  1. 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).
  2. 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).
  3. 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.