The goal of this final project is to utilize the technical and product skills you’ve been gathering over the last 5 months to build a custom app with your teammates and showcase your abilities.
You’ll be asked to form teams and propose a product of your own design. We will review all project proposals to ensure that each app meets the guidelines outlined below. We want to ensure that products are:
- Solving a relevant problem that serves an existing market
- Technically complex and ambitious enough to highlight the skills you have gained
- Fully functional and polished for presentation at Demo Day
With that in mind, things to think about when ideating projects are the technical complexity, design, and product..
- Team Size: 3-4
- Team Formation:
1. Research
2. Pitch
3. Mingle
4. Form Teams - Support: * Weekly technical office hours * Weekly product office hours
- Process:
* 6-Week Release Cycle
- Week 0: Planning + Proposal
- Week 1-3: Building
- Week 4-5: Testing + Modifications * Daily Standup @Class * Weekly Retro @Sunday Class
- Overall product requirements
- Technically complex
- Compelling use case
- Polished implementation (UI/UX)
- Original product
- Proper release to Play
- An engaging pitch that connects with the audience
- Basic technical requirements
- Does not crash
- Does not hang (little or no delay visible to the user)
- Does not fail when internet connection is slow/unavaialable
- Have a consistent look and feel visually across the app
- Consistent with Material Design guidelines
- Look great in both landscape and portrait
- Have well-organized, high-quality code
- Clean coding style (see this sample style guide and the Android project’s official guide)
- Well-commented source code some tips
- Clearly named files, classes, and methods (can I tell what each thing does?)
- Object-Orientation (think back to your OOP lessons and exercise)
- Separation of Concerns (Wikipedia description, Reasons for Doing that)
- Proper Access Modifiers on Objects (see the official Java docs)
- Drawables, Raw Media, Layouts, Activities, Fragments, etc are all in the proper places (read Android’s descriptions of app structure)
| Week | Date | Milestone | Deliverables |
|---|---|---|---|
| Week 1 | Tue Aug 3, 7pm | Final Project Kickoff! | |
| Week 1 | Sun Aug 9, 10pm | Project Proposals Due | Proposal Submission |
| Week 2 | Tue Aug 11, 10pm | Project Revisions Due | Proposal Submission |
| Week 2 | Sun Aug 16, 6pm | Weekly Retro Due | Weekly Retro Format |
| Week 3 | Thu Aug 20, 7pm | Midway Demo to Class | Demo Guidelines |
| Week 3 | Sun Aug 23, 6pm | Weekly Retro Due | Weekly Retro Format |
| Week 4 | Sun Aug 30, 6pm | Weekly Retro Due | Weekly Retro Format |
| Week 5 | Tue Sep 1, 7pm | First Release + Demo | Demo Schedule |
| Week 5 | Sun Sep 6, 7pm | Weekly Retro Due | Weekly Retro Format |
| Week 6 | Tue Sep 8, 7pm | Second Release + Demo | Demo Schedule |
| Week 6 | Sun Sep 13, 7pm | Weekly Retro Due | Weekly Retro Format |
| Week 7 | Tue Sep 15, 7pm | Final Demo Day | Demo Schedule |
| Members | Team Name | Link to Repo |
|---|---|---|
- Things that would impress:
- Super cool library that other devs could use
- Integration of complex APIs (e.g video, web services, etc...)
- Awesome UI
- Work with the OS in a more intimate way (ie Twilight App)
- Advanced Separation of Concerns (MVP/MVC-style architecture)
- Things to Avoid:
- Unusable: Good technical implementation, but does not consider the end user's interaction
- Non-function: Good UI, but does not actually incorporate the tools needed to be feature complete.
- Obvious: Solution can easily be found in tutorials or examples, copies an existing system tool, or simply strings together APIs.
- Not Useful: This app doesn’t have a clear purpose or solve a problem.
- Some sample project ideas:
- Weather + Calendar
- Poll app / trivia app
- Really good photo journal app
- Really good note taking app