CSCI 448 - Mobile Application Development

For the Final Project, your will create the App you've always dreamed of. The app content is completely open-ended and up to you.

For the Final Project you will form a development team to make an app. Teams will consist of three students (there will be two teams of four, seek instructor approval before assuming you are the team of four. Also note, the project for a team of four should reflect the work of four people). Your team should come up with a company name and an app idea (with a catchy and/or punny name). Try to think of something useful, it could be a game, a kids app, etc. Each team member must submit an app proposal that states the following:

1. Company Name
2. Team Members
3. App Name
4. Description of the App - What does it do? How will a user interact with the app? What service does it provide?
5. Components/Features of the App - What Android features/functionality does the app make use of? (see list below)
6. Anticipated Challenges
7. Sources - if any outside ideas contributed to the app idea, if you are using any 3rd party libraries. Give credit where credit is due.

Your app must meet the following specifications:

• Minimum SDK Version: API 16
• Target SDK Version: API 23
• Proper Permissions checked at runtime

Your app must include at least three (3) of the following components:

• 2D Graphics
• 3D Graphics
• Animation
• ARToolKit
• Background Services
• Camera
• Custom Views
• Maps / Location
• Microphone
• Network
• Notifications
• Sensors
• Sound
• SQLite / Cloud Database
• Touch Events

Lastly, it is OK if there is already an existing app that does what you want to do. Try to improve it, add features you wish it had, etc. However, your app should not be a clone of the existing app. Make yours different and standout (something beyond a new color scheme).

Your team must submit a series of storyboards that demonstrate the intended functionality of your app. The storyboards will provide several useful functions:

1. Each storyboard will show the intended View layout for each activity/fragment/screen.
2. The storyboards will show the interactions between your activities/fragments/screens.
3. The storyboards will create your activity hierarchy.

The storyboards do not need to be high quality. They can be hand drawn (and then scanned for submission), created in Powerpoint, or made as mockups with online editors. The main requirement is that the storyboards clearly demonstrate what the screen will look like, what actions can be performed on the screen, and what the effect of the action is.

The Alpha Release can be considered a prototype or proof of concept app. The focus should be on basic UI and funtionality. It's much more important to make sure your app does something before making it look pretty. A running app that demonstrates your team's app must be submitted so that other students can provide feedback on your app (see next section). Be sure to include a short writeup explaining any usage instructions, known bugs, etc. that will be helpful for someone running your app at this point. If something is not quite working yet, then explain what it should be doing.

Each student will be randomly assigned three apps to review the Alpha Release of. Fill out this form for each app to provide helpful feedback to the development team. As you fill out the form, think about what sort of helpful feedback you would like to receive and let the other teams know. Try to break their app. If you succeed, then let the team know in a gentle manner. Also provide the steps to reproduce what you did. Examples of feedback will include:

• Usage problems - e.g. buttons don't do what is expected, tried to do X but it wasn't supported
• Errors - how to reproduce a nonfatal/fatal error
• Suggestions - it would be cool to add Y

Every development team should receive feedback from 8-10 students.

Take into account the feedback you received and address the errors/concerns that were raised. By this point you should have a polished app that not only accomplishes what you set out to do, but it looks pretty slick as well. In the real world, you'd go through another round of feedback before creating a release version. Unfortunately, this will be your release version. You should have a well polished, responsive, and persistent app. Create a launcher icon that is representative of your app to complete the package.

As with the Alpha Release, include a writeup explaining any usage instructions, known bugs, etc. that will be helpful for someone running your app at this point.

Your final report should include all documents turned in to this point (proposal, storyboards, alpha release notes, beta release notes). In addition, desribe the technical aspects of your app. What is going on behind the scenes? Describe the components you added to your app. Why was each necessary? What do they add to the user experience? Finally, address the challenges your team faced during the development process. How did you overcome these hurdles?

Make a company webpage that advertises your app. If someone was to visit this page, then convince them to download your app. Show off its features, show screenshots, tell them about all the cool stuff it does.

Finally, in lieu of a final project presentation/demonstration make a short video advertisement for your app. While it does not need to be professional in quality, it needs to be professional in content. You can even include it on your webpage.

Below is the timeline of deliverables. If Submission Type is listed as "Individual", then every team member is expected to provide a submission to Blackboard. If Submission Type is listed as "Team", then the full submission only needs to be in one team member's dropbox on Blackboard. For the team members that did not submit the full submission, they need to upload a text file saying who submitted the full submission. There are no late extensions on any of the final project deliverable deadlines. These are hard deadlines, penalties will be applied for late submissions. As we approach each deadline, additional details will be given as needed.

Deliverable ID	Deliverable Item	Due Date	Submission Type
TP	Teams & Proposal	Friday, March 11, 2016 2:59 PM	Individual
SB	Storyboards	Monday, March 28, 2016 2:59 PM	Team
AR	Alpha Release	Monday, April 11, 2016 2:59 PM	Team
FB	Feedback on Alpha Releases	Monday, April 18, 2016 2:59 PM	Individual
BR	Beta Release	Friday, May 06, 2016 11:59 PM	Team
RWV	Report, Website, Promo Video	Thursday, May 12, 2016 10:15 AM	Team

With this and all future assignments, you are expeced to appropriately document your code. This includes writing comments in your source code - remember that your comments should explain what a piece of code is supposed to do and why; don't just re-write what the code says in plain English. Comments serve the dual purpose of explaining your code to someone unfamiliar with it and assisting in debugging. If you know what a piece of code is supposed to be doing, you can figure out where it's going awry more easily.

Proper documentation also means including a README.txt file with your submission. In your submission folder, always include a file called README.txt that lists:

• Your Name / email
• Assignment Number / Project Title
• A brief, high level description of what the program is / does
• A usage section, explaining how to run the program, which keys perform which actions, etc.
• Instructions on compiling your code
• Notes about bugs, implementation details, etc. if necessary

Your submission will be graded according to the following rubric.

When you are completed with each deliverably, zip together the needed files. Name the zip file, userName_FP_<DELIVERABLE_ID>.zip where DELIVERABLE_ID is the ID of the current deliverable. Upload this file to Blackboard under the appropriate deliverable section of the Final Project.