Bar App

Skip to end of metadata
Go to start of metadata

The Bar App

CAMPUSBARAPP Meeting Agendas

CAMPUSBARAPP Meeting Minutes

CAMPUSBARAPP Standup Meetings

CAMPUSBARAPP Reference Materials

CAMPUSBARAPP Bug Tracker

CAMPUSBARAPP Download Link

User Stories and Iterations:

A user wants to see a list of the bars on campus when they open the application. After opening our application, she will be required to log in to our app using her Facebook account. After logging in, she will want basic information about her name and friends to appear in the app. Additionally, she will want to be able to select a bar from the bar list and view details about this bar. Finally, she wants to be able to select which friends are able to ask for their location in a bar.

Next, A user wants to be able to indicate that they have arrived at a bar. Then, he wants to be able to enter details about the bar he is at, such as the length of the line or the amount being charged for cover. Next, he will want to be able to be able to say that a bar is being raided. Other users want to be informed of the raid. Lastly, a user wants to be able to view the real information about a bar.

Iteration 1 (February 6 - February 12)

Iteration 2 (February 13 - February 24)

actual estimated story description
2 units 2 units CAMPUSBARAPP0 S05 Check In to Bar
5 units 4 units CAMPUSBARAPP0 S06 Enter Bar Details
2 units 2 units CAMPUSBARAPP0 S08 View Bar Details (Real Data)
3 units 1 unit CAMPUSBARAPP0 S04 Change Privacy Settings (Continued)
4 units 3 units CAMPUSBARAPP0 S01 View Bar List (Continued)
3 units 3 units CAMPUSBARAPP0 S02 Log In with Facebook Account (Continued)
3 units 3 units CAMPUSBARAPP0 S15 Improve Usability

Iteration 3 (February 27 - March 9)

actual estimated story description
1 unit 4 units CAMPUSBARAPP0 S16 Enter User Details on First Use (Discontinued)
3 units 3 units CAMPUSBARAPP0 S17 Invite Friends on FB  (Discontinued)
14 units 17 units CAMPUSBARAPP0 S18 Refactoring (Not User Story)

Iteration 4 (March 12 - April 1)

actual estimated story description
  6 units CAMPUSBARAPP0 S08 View Bar Details (Real Data) (Continued)
  6 units CAMPUSBARAPP0 S18 Refactoring (Not User Story)

Iteration 5 (April 2 - April 18)

Members:

Member
Email
Caroline Schafer
schafer4@illinois.edu
Jared Lambert
lambert6@illinois.edu
Jay Riggins
riggins1@illinois.edu
Sean Adams
adams10@illinois.edu
Kay Ventura
ventura1@illinois.edu
Marcin Kleczynski
kleczyn1@illinois.edu
Aayush Jain
ajain10@illinois.edu
Bernardo Herdan
herdan1@illinois.edu

Meeting Times and Team Contract:

Sundays from 1pm to 4pm

Wednesdays from 6pm to 9pm

Bar App Team Contract

Description:

We want to create an Android app that enhances the experience of U of I campus bar patrons. The app will have a check-in feature that will inform anyone using the app about the length of bar lines, the bar cover, drink specials, if the bar is being raided, and more. In addition, you will be able to find your friends once you arrive at a bar. The bar scene in Champaign will never be the same!

Development Process:

We will be utilizing a variation on Scrum. Instead of daily stand-ups, we will have biweekly (Sunday and Wednesday) "virtual standups". This will comprise of each group member providing a one or two sentence update on the status of their work and what their upcoming plans are on each check-in day.

Our group will be communicating mostly through a Facebook group. This will allow us to quickly inform everyone about the project, and will provide an artifact of our team's communication throughout the semester. In addition, we will keep this wiki up to date with official user stories and iteration details.

Languages:

Java, MySQL

Style Guide:

We will use this style guide .

Because this is fairly lengthy, we want to point out the most important advice to follow from this guide:

  • Order Import Statements
  • Use Javadoc Comments
  • Write Short Methods
  • Follow Field Naming Conventions
  • Use Standard Brace Style/Indentation (but we don't care if indents are spaces or tabs!)
  • Use TODO comments

Libraries, Platforms, Frameworks:

This will be an Android app, so we will be using the Android platform.

Eclipse: Indigo

Android SDK: 2.3 and up

Emulator: 2.3

Testing Framework

Android Testing

Motivation:

A user wants to see a list of the bars on campus when they open the application. A user wants to be able to log in to our app using their Facebook account. They want basic information about their name and friends to appear in the app. A user wants to be able to select a bar from the bar list and view details about this bar. A user wants to be able to select which friends are able to ask for their location in a bar.

At night when getting ready to go out, it is always a discussion of what bar to go to. More times than not, once you finally agree upon a bar, you show up there only to realize that the line is too long, the cover is too high, the drink specials are bad, or the bar is getting raided! All that could be avoided with an app that instantly connects everyone interested in going to the bars. Another issue our app would solve is this: once you arrive at a bar you know your friends are at, it still can be very difficult to find them! Bars are crowded, it is too loud to make a telephone call, and there is no guarantee on the texting abilities of your potentially inebriated friends. A feature to locate friends in the same bar as you would ensure that you can still meet up despite all that. Let’s face it: the number one thing for students to do on this campus is go to the bars...let’s make it a more enjoyable experience for everyone!

Risks and Challenges:

1. Android emulator can be frustrating and difficult to debug
Potential solution: Ensure that one or more team members have had sufficient Android experience, so that they will be able to offer other less experienced team members guidance.

2. GPS integration could be difficult for several reasons. One, we want to have some indication of if user input is accurate, which may be hard to determine. Two, we want to be able to know someones location inside a bar, but we may not have accurate enough GPS information to use and we may have to determine an alternate solution.
Potential solution: Brainstorm as a team to come up with ways to solve these problems beyond the obvious (and clearly flawed) initial solutions.

3. Potentially complex database: The backend for this app could potentially be very complex, because there is a lot of information to keep track of including all bar information by all users, as well as information specific to each user.
Potential solution: Ensure that those in charge of the backend are familiar with databases, carefully consider this problem and plan a smart database schema before jumping into implementation

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.