ecse321-fall2018/t07

t07's Issues

Bottom of the ListView in TripSearchResult doesn't gets hidden by the "back/home/multitasking" bar

Backend returning non-standard JSON

Should somehow make it JSON using plugin or PostgreSQL features.

App does not successfully show the ALL list of trips

ListView in PassengerApp's activity Profile_page doesn't scroll

Probably an issue in layout

Android: Driver: Destinations ListView thing crashes when keep pressing "-" after all rows are gone

and i'm too sleepy to look at sorry

Sorting function for TripSearchResult

Fails to add to the database

both users and trips

User Table Management (Creation and Deletion)

Users need to be able to sign up with the app, creating a user profile in the database's user table. Their profile should include a variety of information, such as first name, last name, email and phone number. The system should assign the user a unique user ID to act as a key for the database record. There should be the option to flag a user specifically as an admin, so that they can later have admin permissions for Sprint 3. In addition, there should be a means of storing a rating for the user from their experiences as a passenger, as well as a driver. This rating should be kept separate as passenger rating and driver rating, and averaged appropriately after a new rating is provided.

Functionality should also be present to delete a user from the system. This could come in the form of a user deleting their own profile, or an admin deleting another user. The unique user ID should be user to delete the user from the database.

Passenger User Story: Selecting and Joining a Trip

As a passenger, I would like a way to select the trip that works best for me from the list of search results and be added to it, that way I can confirm my space in the vehicle.

Selecting, Joining and Dropping features:

• Ability to select a trip from the trip's ad
• Available seating on the trip should be updated
• If the available seating drops to zero, the trip should become delisted
• Ability to remove oneself from a trip that has been joined
• If the available seating increases from zero, the trip should become listed again

Passenger App Design Mockup

Create sketches of what the varying views/interfaces of the app look like from the passenger's point of view.
Views should be present for:

• login page
• Sign Up page
• user profile page
• trip search page
• trip results page
• specific trip details page
• My trips page (shows history as well)

Check Email For Uniqueness On Sign Up

Currently the Sign Up page creates a new user in the database, but since we are using email and password on login to look for a unique row in the table, then the user email must be unique. This is of course more user-friendly than using the user ID for login (which is currently already unique).

Therefore, a back end REST call either needs to be added to look for emails in the table that match the user-entered one during sign up, or this functionality needs to be added to the start of the 'create user' back end functionality.

Test Automation

As an extra-functional requirement, the app should have a series of built in unit tests using JUnit. These tests should run automatically, testing each API endpoint for behaviour when valid and invalid inputs/states are provided/present.

User Creation Tests:

• Maximum number of characters for name entry
• No special characters used in name entry
• Email is in a valid email format
• Email is not already in the system
• Phone number only includes number characters

Trip Creation Tests:

• Dates and Times entered are valid
• Available Seats is within a proper range (1 to 5 for example)

searching trip fails when leaving 'sortBy' parameter blank

Backend: Partial Search Function

The website will require partial matching with searching for users (such as drivers or passengers) as well as trips. The current trip function uses WHERE to search for exact copies, a new REST endpoint should be created that uses LIKE for partial matching. This should be a new endpoint rather than changing the existing one so that the Android frontend doesn't break. If no search term is input then it will return all of the rows for the database.

In addition, this endpoint should also have the ability to take a sorting input that will only search for active drivers/passengers/trips. See Issue #45 for trip progress markers. Of course if this search term is empty it will return all.

Three separate partial matching trip search endpoints will be required, for passengers, drivers and trips. This is because how the search actually functions will differ (joining with passenger_ID array, joining with driverID or simply searching the trip table).

Driver App Design Mockup

Similarly, there need to be sketches done for the varying views/interfaces for the driver side of the app.
Pages such as:

• driver login
• driver user creation
• driver profile
• trip creation page
• trip details page
• modify trip page

Passenger User Story

Set up Driver and Passenger Android Project

An Android Studio project/app needs to be created for the Driver app and the Passenger app. The basic dependencies and permissions need to be incorporated to work with the internet and access the database.

Android: Driver: Trip_Create doesn't work

Backend: Display Unique Table Results With Count

In order to display 'top' drivers, passengers and routes by their total number of trips, we need a backend rest endpoint that will return only unique entries (in order to group routes) as well as the count of how many occur in the database. This can be accomplished by using the Group By and Count clauses in SQL. The Group By clause will allow searching for specific column values and returning only unique entries of those, while the Count clause will help return the number of occurrences in order to properly gauge a rating. This endpoint will also have to take start and end dates as inputs so that the admin can bound their search. If dates are not entered then it will search for all.

A REST endpoint will be required for both the user table and the trip table.

See the following link: http://www.postgresqltutorial.com/postgresql-count-function/

Passenger App Page Layouts Implemented

Now that the mockups have been created for all of the pages in the passenger android app, the layouts need to be put together in Android Studio. This process is helped along by Android Studio's ability to drag and drop items such as text boxes and buttons. All aspects from the mockups seen in Issue #18 should be incorporated into different .xml layout files. All default values shown on buttons and in text fields should be set up with the associated string variables. There is a fair amount of overlap with shared pages for the driver and passenger apps (such as login, etc) that can be implemented identically in both apps.

Note: a separate issue exists for hooking up all connectivity of the layout: Issue #27

Backend: Add Trip Progress Markers

In order to check that a trip is currently in progress, we need to add to the backend trip table a means of marking which destinations the driver has hit. This can be easily implemented by an array that is the same size of the destinations array, and will consist of 0's and 1's. A 0 indicates that the driver has yet to hit that destination and a 1 means that they have reached it. Therefore trips that have a 0 in the array are still in progress.

Passenger App JUnit Tests

A host of unit tests should be implemented in the Passenger Android App to check various functionalities and input states from the user. Any major functions used within the app by various actors or at a high frequency should have tests to ensure that they are still working. Aside from the JUnit tests, there should also be checks and balances (such as try/catch blocks) within the code to ensure users aren't entering data into the fields in improper formats or as content that makes no sense. It should also return errors for example when users do not fill in all of the mandatory fields (such as in user creation).

Heroku and Travis CI Integration

As an extra-functional requirement, the application must work in conjunction with both Travis CI and Heroku. Every push to the Git repository should trigger a build job with Travis, which uses the Maven build system to compile, link, and test the push for regression. Heroku should wait for Travis to finish building the job before running.

Update trip_table structure to include arrays as column data types

Currently there are a number of columns in the trip_table that are set as singular values, but need to be of the array data type instead so that we can store multiple possible values within. The following columns need to be changed:

• destination should be Text[ ]
• duration should be Double[]
• prices should be Double[]
• passengerIDs should be integer[]

Additional BackEnd Functionality: Modify Trips

In order to meet the front end user functionality for Sprint 2, drivers must be able to modify their trips. Currently functionality is present for creating and deleting trips, but not altering destinations or other key information. There should be consideration for drivers changing trip details within a short window from departure, or changing critical information that isn't relayed to the passengers.

Driver App Page Functionality

As the various layouts are created for the pages required in the Driver Android App (seen in Issue #24) the functionality that connects them should be implemented as well. This will involve hooking up the functions/activities that are run when various buttons are clicked on the screen. This also requires sending the proper REST HTTP requests to the heroku-hosted database in order to read/write data.

Keeping current logged-in user's userid somewhere for common use

JUnit Tests

• JUnit test class created
• Able to run junit test
• Failed to initialize

Driver User Story

As a driver, I would like a way to easily post my trip details/itinerary, so that interested passengers can easily find me in a secure way.

Desired Trip Details:

• Departure location
• Trip destination(s)
• Date
• Time (of departure/estimated arrival)
• Number of passengers
• Contact information
• Price (per destination)
• Luggage space
• Vehicle information
• Other preferences
• List of available passengers

Android: Driver: Datepicker crashes for Trip_Edit

It crashes because onTimeSet() in the timepicker fragment attempts to return value to (Trip_Create) while it is called from Trip_Edit

Additional BackEnd Functionality: Sorting Trips By Other Criteria

Presently, when passengers search for trips, they can include a variety of different criteria and the results automatically sort by soonest to latest trip. Functionality should be present to allow passengers to also sort by other criteria such as price or available seats or trip duration, etc.

Driver App Page Layouts Implemented

Now that the mockups have been created for all of the pages in the driver android app, the layouts need to be put together in Android Studio. This process is helped along by Android Studio's ability to drag and drop items such as text boxes and buttons. All aspects from the mockups seen in Issue #19 should be incorporated into different .xml layout files. All default values shown on buttons and in text fields should be set up with the associated string variables. There is a fair amount of overlap with shared pages for the driver and passenger apps (such as login, etc) that can be implemented identically in both apps.

Note: a separate issue exists for hooking up all connectivity of the layout: Issue #26

Admin User Story

As a system administrator, I would like a way to easily check the status of all active drivers and passengers in the network, as well as list the top drivers and passengers based on historical data. This way I can monitor the system as a whole and ensure smooth operation of the app.

System Administrator abilities:

• View the list of users (driver, passenger)
• Ability to ban the user when necessary
• Ability to send users notifications
• View the list of trip details
• View historical data of drivers and passengers

Driver App JUnit Tests

A host of unit tests should be implemented in the Driver Android App to check various functionalities and input states from the user. Any major functions used within the app by various actors or at a high frequency should have tests to ensure that they are still working. Aside from the JUnit tests, there should also be checks and balances (such as try/catch blocks) within the code to ensure users aren't entering data into the fields in improper formats or as content that makes no sense. It should also return errors for example when users do not fill in all of the mandatory fields (such as in user creation or trip creation).

Minor design issues

like keyboard covers textbox.

Passenger App Page Functionality

As the various layouts are created for the pages required in the Passenger Android App (seen in Issue #25 ) the functionality that connects them should be implemented as well. This will involve hooking up the functions/activities that are run when various buttons are clicked on the screen. This also requires sending the proper REST HTTP requests to the heroku-hosted database in order to read/write data.

Persistence Layer

As an extra-functional (non-functional) requirement, the app must have a working persistence layer. This means that data created through interactions with the RESTful web service must persist when the server shuts down, whether gracefully (through the user ending the application) or ungracefully (through crashes). A PostgreSQL DBMS instance will be used to store this info.

Passenger User Story: Searching and Sorting

As a passenger, I would like a way to search for different trips, using various sorting methods, to allow me to find the trip that best matches my needs as quickly and easily as possible.

Desired Searching/Sorting Methods:

• Searching for departure location and destination(s)
• Sorting by departure or estimated arrival time/date
• Sorting by total trip duration
• Sorting by number of available seats/passengers
• Sorting by price
• Easily viewing auxiliary information like: contact information, luggage space, driver preferences

Note: all sorting methods should be able to flip sorting directions (ex: shortest at the top or longest at the top)