COMP 150-MOB: Mobile Development

Fall 2017 Semester Project


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.


That's it? Any more details than that?

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."

Are we only going to build one app in this course?

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.

Fall 2017 Apps

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

Leg 1: Proposal and Requirements


In your engineering notebook:

  1. Briefly explain the need for the app (the "what").
  2. List the target audience (the "to whom").
  3. List the people and stakeholders who will be supporting your app along with a short statement of support from the person. The person cannot be the instructor of the course or another student in this course.
  4. List and briefly describe the core functionality of the app, the most important functions and transactions of the app.
  5. List and briefly describe the secondary functionality of the app, the functions and transactions of the app that are nice to have only if time allows.
  6. List the features on a mobile device that the app will use (e.g., camera, GPS, SMS, flashlight).
  7. Briefly describe any limitations each team member may feel that will hold back progress.

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.

Leg 2: Basic Foundation of Your App



In class on Thursday, October 5th, I will check-in with each team to note progress.

Leg 3: Lightning Tech Talk, Build Minimum Viable Product (MVP) of App


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.

Doing an MVP

Some reads to learn more about the idea of an MVP of a product:


Leg 4: Testing and Basic Security Audit of Your App (MVP)


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:

Instructions and Requirements

  1. Analyze your mobile app code with 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.
  2. Install and use Fabric's Crashlytics for your mobile app: (free). The purposes of Crashlytics: (1) manage and report on app crashes and (2) pinpoint, down to the exact line of code, the issues causing the app crashes. I've been using Crashlytics since 2012 and it has helped immensely. Make sure to share the crash report with me (use my Tufts CS email address).
  3. Choose at least two other methods of testing. Make sure to provide initial test report and report(s) after changes based on initial test report.
  4. Write about your testing experiences and findings in your engineering blog. This is on top of your weekly status entry.

I will be reviewing your tests and evidence of testing on Thursday, November 9th in the evening (after dinner).

Small List of Tools


Leg 5: Launch App to the Google Play Store


This is the stage we have all been waiting for.

Before You Begin

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.


  1. Please read the instructions on How to use the Google Play Developer Console. Someone will need to pay the $25 registration fee. Also read Get Started with Publishing. The Google Play Developer Console is available at
  2. Create a new entry for your app the Google Play Store. Complete all necessary details.
  3. When you are ready or when you have received confirmation, email me the Google Play URL of your app on at mchow AT cs DOT tufts DOT edu. Example Google Play URL: For the fun of it, use an exciting subject for email (e.g., We've Launched Our App!). Soft Deadline: Friday, November 17th.
  4. At long last, push your app code to the master branch of your repository.
  5. I will be posting Google Play URL of each app when I receive them.

Well done for accomplishing this much in a matter of 9 weeks. The real learning experience has only begun.

Leg 6: Get Customer Feedback on Your App; App Review and Code Review of Other Teams' Apps


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.


  1. In your engineering notebook, keep track of the feedback that your team has been receiving from customers and other lessons learned from publishing your app onto the Google Play Store.
  2. Review all the other apps in the class. We will not use Google Play for reviewing the app. The reasons: (1) not everyone has an Android device to download and review apps, and (2) Google Play is not a forgiving environment. Therefore, I have created a form for reviewing other apps in the class: You are not asked to rate the app using (1 to 5) stars. A free-form field is provided for you to provide an overall review of the app. In addition, you are asked to review the app's source code which has been made publicly available. NOTE: please provide constructive comments on apps. Destructive and uninformative comments will be not be tolerated. Your job is to make other team's apps better.
  3. On Tuesday, November 28th and Thursday, November 30th, each team shall give a 2 minute demo of their app in class. No presentation slides allowed --just demo app on a device. We will try to fit as many demos as we can in the two days.

Please review as many apps as you can by Friday, December 1st. Students' feedback and customers' feedback are very important to improve apps.

Leg 7: Update App on Google Play Store and a Reflection


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:

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:

  1. What did you learn technically?
  2. What did you learn professionally? Please note: this is not the same as the above question.
  3. What do you wish I could have done differently?
  4. If you were to do this all over again, what would you do differently?
  5. If you could make one change to this Mobile Development course, what would it be and why?

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.