1. Controller and Model
Acceptance Criterion
WHEN the user clicks show venues, THEN the names of all available venues in our app will be displayed sorted alphabetically. Clicking the name of one of the listed venues will open a menu for that specific venue displaying a picture of the venue along with a short description.
Frontend Code: When users are in the venues scene, they see a list of all venues which is populated by the call to the backend api. The user is able to select if they want to sort venues alphabetically or by distance within the list, which we implemented by restarting the data in the table. The information from the api call to get venue information is then forwarded onto other scenes using segues.
Code to pull all venue information from backend.
Code to control refresh mechanism and store all venues from backend call.
Populate tableView cells with venue information.
Backend Code:
In order to implement the backend functionality for listing venues, we created the /venues/ endpoint and created a database to store the venues. The venues are stored in a table, the schema for which can be found here. Then, our endpoint simply gets the venues from the database and returns them to the user with this function. Finally, in order to serve the static images that are associated with each venue, we wrote a function that returns an image given a URL to that image (code here).
Acceptance Criterion WHEN the user selects a venue, THEN the names of all available destinations that can be routed to within a venue will be displayed sorted in alphabetical order. Clicking the name of one of the listed destinations will open a menu for that specific venue listing more information, including a description and images of the destination (which a venue can optionally provide).
Frontend Code: Similarly to the venue scene, when a user enters the destinations scene, they see a table populated with information from the destinations api call. The api call information is stored in a variable that gets passed to the description scene through a segue when a user selects the destination they want to route to. When entering the Description scene for one specific destination they want to route to, there is an api call to the Description api that retrieves an image and some information about that destination.
Code to pull all destinations within a venue from backend.
Code to control refresh mechanism and store destinations (within a venue) from the backend call.
Populate tableView cells with destination information.
Backend Code:
To complete this feature, the backend team finished the /venues/:id/destinations/ endpoint, which returns a list of destinations corresponding to the venue with matching id in the URL. For each destination in this list, there is a corresponding name, image URL, description, and latitude/longitude pair (link to code).
Acceptance Criterion: WHEN the user tells our ARmaps where to go in a venue (i.e. they select a destination), THEN the user will see an AR beacon marking the destination within the physical environment of the park when the user has pointed their phone in the direction of the destination they selected (assuming the user is close to the destination for the skeletal product, as our step-by-step directions will be implemented within the MVP section).
Frontend Code: To indicate the end destination in a route, we implemented an AR beacon by passing the latitude and longitude information that was segued from the previous scene into an add node functionality in ARCoreLocation. By doing this, the user is able to see a pin at the latitude and longitude of the destination. A route to this destination is also provided so that users approaching from farther away can be directed to the location to view the pin at the end of the route (discussed later).
Code to pass Lat & Longitude for the pin from destination description scene.
Acceptance Criterion: WHEN the user arrives at their destination at the end of the route, THEN ARmaps will display a pop-up that notifies the user that they have arrived at the destination and include an option to choose a new destination and start another route.
Frontend Code: By using location tracking features in Apple's CoreLocation, ARmaps monitors the user's distance to the destination. Once a user gets close to the destination pin, an alert pops up on the screen letting the user know they have arrived. They are then given the option of choosing a new destination or remaining in the AR scene.
Alert User (with a popup) on Location Overlap with Destination.
Acceptance Criterion: WHEN the user clicks see nearby venues, THEN the names of all available venues in our app will be displayed sorted by proximity to the current location. Clicking the name of one of the listed venues will open a menu for that specific venue listing more information.
Frontend Code: When the user opts to sort available venues by distance from the user's location, ARmaps takes their current latitude and longitude (which is found using CoreLocation), sends it to the backend to get a location-sorted list of venues, and updates the order of the venues according to how far away they are.
Code to find the user's current GPS location (latitude and longitude) using CoreLocation.
Store the venues in a dictionary organized by distance from the user.
Navigation Controller that allows user to switch the sorting methods when desired.
Backend Code:
The venues endpoint, supported by our API, now can optional URL parameters: latitude and longitude. If the endpoint is given this lat/lon pair, it will return a list of venues in order of increasing distance to the user (link to code).
Acceptance Criterion: WHEN the user clicks find nearby destinations (after selecting a venue), THEN the names of all available destinations that can be routed to within a venue will be displayed sorted by proximity to current location. Clicking a name of one of the listed destinations will open a menu for that specific venue listing more information, including a description/images of the destination (which a venue can optionally provide), distance to the destination, and average walking time to travel there.
Frontend Code: When the user opts to sort available destinations within a venue by distance from the user's location, ARmaps takes their current latitude and longitude (which is found using CoreLocation), sends it to the backend (alongside the venue that the destinations are part of) to get a location-sorted list of destinations, and updates the order of the displayed destinations according to how far away they are.
Pass the user's current GPS location from the previous scene.
Store the destinations in a dictionary organized by distance from the user.
Backend Code:
For the backend code, we changed the destinations endpoint to now accept two URL parameters: latitude and longitude. From here, the API will sort the destinations by distance according to the user's lat/lon, and return the destinations in order of increasing distance (link to code).
Acceptance Criterion: WHEN the user clicks a specific destination (after selecting a venue), THEN more information about the destination will be displayed. Users will be able to see the estimated time to destination based on average walking speed. Additionally, users will see the walking distance to the destination. A venue can also include optional images, a description of the destination, and a button to start the route.
Frontend Code: When a user selects a destination, open a new view with more details about that selected location.
Code to pull estimated time and distance from backend and update labels.
Acceptance Criterion: WHEN the user selects a route and hits Go to [selected destination] in a venue, THEN ARmaps will guide the user to their selected location with step-by-step directions. This routing process will leverage AR waypoints along the path (such as arrows) to direct the user in the right direction and help them quickly navigate to their location.
Frontend Code: When a user first enters the api scene, the directions data which holds all the waypoints is called. These waypoints (shown as arrows) then populate the ar scene using the latitude and longitude using ARCoreLocation functionality for adding nodes. The destination pin is also displayed in this same way. When a user reaches a waypoint, there is another call to the api to directions and updates the directions variable.
Loop through the array of coordinates to add destinations.
Call destination API to get all pins along the route to the destination.
Backend Code:
For the backend, we first had to set up the schema for waypoints and paths in the database (code). This allowed us to add test data for the directions endpoint we created. This test data included waypoints and paths at the two test venues we included in our project: Michigan's Adventure and The Big House (test data here). Finally, we had to create the endpoint for the directions. The code can be found here, but a more in-depth explanation is here.
Acceptance Criterion: WHEN the user is routing to a destination, THEN ARmaps will display the running time to destination (in minutes) in a small screen overlay.
Frontend Code: Poll directions endpoint on a timer to update the label on the bottom of the AR navigation view.
Send user's longitude and latitude to the backend to get an updated time estimate.
Call backend on a timer to get updated time estimates.
Acceptance Criterion: WHEN the user arrives at their destination at the end of the route, THEN the app will prompt the user to look around at nearby destinations using AR (names of nearby destinations will appear in an AR). ARmaps will have a popup that lists nearby destinations to route to (including time and distance to nearby locations) and a button to select and start routing to them.
Frontend Code: Once the user's location overlaps with the destination, provide an alert that has an option to return to the list of nearby destinations.