Part 1: Final App Distribution:

Video Link
.AIA file
.APK file
Barcode:

Part 2: Introduction to our App:
Developers:
Hunter Moore and Felix Cavan
Title of app: People’s Resource
Programming Language Used: App Inventor

Screenshots from final app:

Main Menu Screen:

Item Registration Screen (Click on Donate button from Main Menu to access):

Item Claim Screen (Click on Claim button from Main Menu to access):

Elevator Pitch:

The name of our app is People’s Resource. It is a charity app which falls under the lifestyle category of the Play Store. Just about everyone should use our app because every household in America has things they don’t use anymore and every household needs stuff that they either can’t afford, or can’t find in retail stores nearby. However, adults would benefit because they understand what they really need in the house. There are apps that help users sell items, but there are no apps that link people to each other for a free exchange of items. Our app is innovative and unique.

Our original design for the app looked like this:

It has evolved as we expected. It consists of three screens. A main menu, which links you to the two other screens, which are the Item Registration screen and Item Claim screen. The Item Registration screen has textboxes for the user to submit their information. The item claim registration now has a category list picker, but originally we designed it for the user to type anything in, and any possible hits would appear.

Our app is socially useful because it directly gives back to the community by making donation an easy and convenient process. People who are more fortunate can give their items up for donation, while poorer communities benefit directly. It eliminates the middle man charities who might profit or misuse funds. It is a revolutionary app that is unlike anything else on the market, so it doesn’t really improve on any competitors. Everyone should be interested in using our app because you are either helping your community and getting rid of things you don’t need anymore or benefiting from someone else’s generosity.

 

Section 3: Design:
Storyboard:
1. User initiates app.
2. User clicks Donate Button.
3. Complete fields.
4. Click submit button.
5. Go back to main menu.
6. Go to Claim screen.
7. Select category of desired item.
8. Pick Item you want.
9. Look at contact information and use it to get in touch with them.
10. Return to main menu.
11. Repeat steps 2-9 as necessary.

  1. Difficulties while DevelopingThe first problem that we came across while developing our app was figuring out how to store the data on to the database instead of locally on the device. Initially we had the valueToStore under a list of a variable. We later realized that storing data in the device disappears whenever the app disconnects. But after bouncing ideas off of each other and meeting with Ms. Lake, we determined we needed to change the valuetoStore in the Firebase StoreValue block to the entire variable. We were also able to cut code of the storeValues procedure by 75% by using 4 parameters.The second problem we ran into was the DataChanged block. We wanted any update to the database to be automatically pushed through to all active users. To achieve this, we originally just called the getValue procedure. We thought this would work because it called the data from the firebase. We then discovered that we needed to add code from the GotValue event handler. This code interprets the changes, and the getValue procedure calls it and pushes it out to the active users.This was a very collaborative project. Working alone proved inefficient because we were unable to work off of each other’s ideas.2. Algorithms:

    ^This block of code stores the data that the user has provided into the correct tag based on the selected category into the device. Then it takes the data stored in the device and stores it into ourĀ online database. It also puts comma in between pieces of information so that it is easier for the user to read. It is an algorithm because it consists of a linear sequence of actions.
    The smaller block calls for two procedures. The first one makes sure all fields are filled in, and the second one stores the item data in the device and firebase. We have decided to use parameters to condense the code and easier to read.
    ^This block of code retrieves the data from the firebase. If no results are under the tag, an empty list is created. It is an algorithm because it is an integral component of our code. The app would not function without it.


    ^This block of code ensures that all the fields contains text. If the user clicks submit while one of the fields is empty, a notifier appears that informs that user that he/she must complete all of the fields. It is an algorithm because the app would not function if a field was left empty.

3. Abstractions:

^This block of code ensures that when the user uploads or deletes data, all active users automatically get updated on the change in the database. It is an abstraction because it determines which tag is affected by the change through using a series of logic statements.


^This block of code stores the data that has been retrieved from the firebase into the device. It also puts the selected item text into the textbox. It is an abstraction because it simplifies the storing process by only allowing the four available tags.


^This block of code sets the elements of the list picker with the data stored under the variables. Following the initial selection of the category, it opens a second list picker screen that shows all of the data under the selected tag. Finally, it resets the elements of the list picker back to the four main categories. It is an abstraction because it toggles between the two list pickers based on the user’s actions, but the user is unaware that logic statements are behind the app’s functionality.

4. We used a firebase tutorial to help us set it up.
Ms. Lake also helped us set up the lists of the resulting items found in the list picker, instead of all the hits coming up as one item.
Selina helped us set up a procedure.

Market Testing:
Round 1:
Ms. Lake
Recommendations: Add hints to textboxes, change the category label to a list picker.
Thoughts on UI: Looks great.
Error messages: None

Round 2:
Timothy Lee
Recommendations: Work on return value. (Search function)
Thoughts on UI: Very clean and the background is very lively.
Error messages: None

Round 3:
Thierno Barry
Recommendations: Work on separating items in list. All old data was chunking up into the first item.
Thoughts on UI: He liked how bright and colorful it is. Fits theme of app.
Error messages: None