adi00026 / cs2340-52 Goto Github PK

In this milestone, we implement the ability to read in shelter data. You should have some kind of input screen for selecting the option to read in the data. Optionally, you can automatically read in the shelter data on program startup. The data should be stored somewhere in the model. You should provide a list view of the data (this is a conceptual list, not a requirement to use any particular widget).
The shelter data is in a text .csv (comma separated) file in the Files section of Canvas.

Opening the file in a spreadsheet will allow you to see the order of the data elements. The following fields should be handled by your app (the other fields can be ignored)
• Shelter Name
• Capacity
• Gender
• Longitude
• Latitude
• Address
• Phone Number

What fields you show in the main list view is up to you, but should at least include the shelter’s name.

1. Install and setup Android Studio
2. Import the existing project
3. Make required code changes
4. Test completed application

Implement Firebase in M4 so we don't have to worry about it later.

Alternative platform implementations: for example, Native iOS or a web app

Once in the application, there should be a way to logout. After logging out, the application should return to the welcome / opening page.

After the user has claimed a bed, they may not claim any for another shelter before releasing the one(s) their account currently holds. This option should be available to users. Your team may decide if they must release all of their beds at once or specify a number; either way, the number of vacancies for a shelter should accurately reflect how many have been claimed or released by the user.

Canceling the login (pressing Cancel or going back a screen for example) will close out the login attempt. No information is recorded, and the application does not start up. Note: here you are not explicitly required to have a cancel button, just a way to back out of the login attempt.

Once the user has done so, that shelter’s number of vacancies (originally the same as its capacity) should decrease by however many spots the user has claimed (perhaps for a friend or family member). Logically, no user should be able to claim more beds than the shelter has vacancies.

If someone requests login, you should check for the correct user name and password. For this first milestone, you may have a hard-coded user with name "user" and password "pass" to check against.

Add the registration screen to your app. A new user should be able to register by entering their information (like name, email, and password). If accepted, the new user should be added to the system. If cancelled, the user should not be added.

During registration, the new user’s account type (User, Admin, or Shelter Employee) should be specified. In a real application, we would have controls for determining this, but for this class project, we will have registration designate accounts as basic Users. You may implement creation of the other two account types for extra credit.

Email-based password recovery (in lieu of or in addition to Admin unlock after 3 unsuccessful attempts)

Extra credit for app.

Ask what this is?

You may implement an extra option at the login/register stage of your application. The third option is to proceed without logging in. This would allow the user to search the shelters but not report about vacancies or otherwise change the system’s data. Essentially, this create a fourth user type who has less privileges than any of the other three in return for being completely anonymous.

Extra credit for app.

Use Google Maps to show directions to a selected shelter

Team and Project Management

• Team page
• Team contract
• Project planning

User must at least be able to search by gender, age range, and shelter name (independently).

Note that the .csv data reports shelters as for females, for males, or unspecified, so if a user searches for a shelter for females, the resulting list should include both the female-only shelters and those that do not differentiate. Currently, the age ranges specified by shelters include: families with newborns, Children, Young Adults, and Anyone.

We will now add the ability to show on a Google map the locations of shelters. You should allow the user at a minimum to select which restrictions to show. For example, show only shelters for women or only shelters for families.

Push notifications (for vacancies, only works if there is some way of marking which shelters are of interest to that particular user)

The app crashes when ViewDetails is pressed on an empty spinner.

Extra Credit feature for the app. Only has to be done in M13 but we should keep it in mind.

Implement and integrate with rest of app.

Various tests have been made to ensure certain methods within the app are not susceptibile to crash and thier branchses have full coverage

Creating a team page on Canvas, the team charter, and then setting up Zenhub and entering some initial data

Pins should appear on the map for each shelter that meets the requirements. Clicking on a pin should give some basic information about the shelter. Information must include the shelter’s name and their phone number, but feel free to include more.

Each person has to pick one user story and elaborate on it as part of M4.

In addition to vacancies and claims, you must now be able to persist (save and load) data for the application. This includes the registered users, shelter data, and reported vacancies/claims. Your team will need to decide how you handle the new data in addition to the .csv loaded earlier (for example, just persist the new data and always read and parse the file or read and parse the file once, and afterwards just load and save everything).