In a pair (with another student in the class or in some situations no more than three people), design and build an app that someone needs.
No, that's it.
I am appalled by how students are generally uncomfortable with working on unstructured and open-ended problems. The problem becomes glaring during students' first internships as I constantly see comments in CPT reports such as "I wish my supervisors had described the overall structure in a little more detail" or "I was simply freaking out with the fact that I did not have an assignment with a roadmap." That's normal and reality. Generally speaking in the real world, you will not be given detailed specifications as you have been in most classes. You will also not be given details on how you will be graded on a project because there is no such thing as grades in the real world. The professional world "is unstructured, with competing priorities and decisions that need to be made on the fly. College is very task-based: take an exam, finish a paper, attend a club meeting, go to practice. The workplace is more of a mash-up of activities with no scheduled end."
The open-ended nature of the project in this course will make you care more about the project and ultimately enjoy the course more. The ultimate goal for me is to see you all "set your own schedules and let your curiosity shape the project with little involvement from me."
Tough call. Last year, students asked to have a lab to build a simple app. I understand the reasoning for that: to serve as a simple exercise, training wheels, because many have never dabbled with mobile development before. This year, there will be a simple app lab to be done individually that will take no more than two weeks to do. However, the focus of this semester will be on one app. Having taught a course with an emphasis on mobile development each year since 2012, there isn't enough time. There are thirteen weeks in a semester. If we spend a month writing the same app, that about only nine weeks to design and develop a "final project." The big problem with that model is that each app becomes a "one off," a throwaway, not meaningful.
Blocking Tracker by Selena Groh and Ben Fuglini
Crowder by Conner Erickson, Berkay Unlu, and Phil Wang
Favor! by Catherine Cowell, Iris Oliver, and Leah Stern
FlashVocab by Gyan Tatiya and Huixian Zhang
Hearound by Jianjie Liu, Rui Qin, and Max Turpin
House by John Fairfield-Sonn, Claudia Mihm, and Sara Goldstein-Weiss
LifeTrack by Remmy Chan
Neural News by Brendan Voelz and Charles Winston
Over The Mystic by Rebecca Alpert, Anna Kasagawa, Monsurat Olaosebikan
Palette Paintbox by Rachel Hogue and Melissa Iori
Scanventures by Meet Patel and Jeremy Su
Speaky Jumbo by Tong Dong and Yedi Wang
Time Steward by Xiaozheng Guo and Keyue Wang
ThriftEZ by Harper Hopkins and Sam Oakley
TripSharing by Wanqing Chen, Lu Meng, Taining Zhang
Walker Pal by Kiki Chan and Will Mairs
You In? by Frank Hattler and Frances Hughes
In your engineering notebook:
It goes without saying that the point of this leg is to plan accordingly: "have a plan, write it down." This leg is due on Friday, September 22nd. This should give you enough time to come up with a great idea. Teams will be giving a two minute pitch on their respective idea on Tuesday, September 26th.
master branch on Git repository. Create and work off of a different branch (e.g., alpha, experimental).In class on Thursday, October 5th, I will check-in with each team to note progress.
The idea of a minimum viable product (MVP) is to get something to market as soon as possible, get real people using it, and then iterate or add features based on user feedback instead of assumptions.
Some reads to learn more about the idea of an MVP of a product:
master branch on Git repository. Create and work off of a different branch (e.g., alpha, experimental).Let's face it: generally speaking, we talk a good game about testing but have little to show for it (read: testing is not done).
The goal of this leg is to prove that you have done some testing and even have considered basic security in your app and app infrastructure. There are many methods to go about testing and basic security auditing, including:
lint. Lint is a code scanning tool that can help you to easily identify and correct problems with the structural quality of your code, without having to execute the app or write any test cases. Provide the initial lint report inside a folder named tests at the top level of your mobile app repository. Make any necessary changes. After making any necessary changes, rerun lint scan and also provide that report in your repository. There should be no errors on second lint scan.I will be reviewing your tests and evidence of testing on Thursday, November 9th in the evening (after dinner).
This is the stage we have all been waiting for.
Please read the official documentation Launch Checklist first. Make sure you have all the required assets before adding your app to the Google Play Store. This also includes an icon for your app.
mchow AT cs DOT tufts DOT edu. Example Google Play URL: https://play.google.com/store/apps/details?id=com.instagram.android&hl=en. For the fun of it, use an exciting subject for email (e.g., We've Launched Our App!). Soft Deadline: Friday, November 17th.master branch of your repository.Well done for accomplishing this much in a matter of 9 weeks. The real learning experience has only begun.
Now that your app is on the Google Play Store, it is time for your team to market and advertise your app, and to review the other apps developed in the class. With your apps now in the public eye, there are non-monetary cost including spam and increased public scrutiny of each team's work. For the next two weeks, we will step a little back from development and have fun.
Please review as many apps as you can by Friday, December 1st. Students' feedback and customers' feedback are very important to improve apps.
For each team with published apps, I provided feedback from other students in the class. For this final leg of the project, your team shall provide at least one update of the app on the Google Play Store. Your team shall also provide two entries into you engineering notebook: an entry on the changes made, and a reflection piece.
1. Provide an update of your app on the Google Play Store. Please make sure that your update release notes are thorough enough.
2. Write about the update of your app in your engineering blog. If you want a stellar example of an app update blog post, see Blizzard's updates for the game Hearthstone: https://playhearthstone.com/en-us/blog/21098848/hearthstone-update-october-17-happy-hallow-s-end
3. Write a reflection piece on your work this semester in your engineering blog. Ideally, each person in team shall provide an entry. In your reflective piece, address the following questions:
We will discuss more about this on the last day of class. Please note, and very important: this is not a substitute for the course evaluations.