COMP 150-MOB: Mobile Development

Fall 2016 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.


The app cannot be a game. Game development is another subject of its own.

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? Why not more than one app?

We will build only one app in this course. 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.

Teams and Apps

BigGameHunter by Derek Benson and Walton Lee

CompFoodie by Nga Pham and Charles Wan

EasyStream by Chris Anderson and Melanie Belkin

Flipper by Ivan Chen and Nik Patel

Jumbo Eats by Kate Harwood and Zach Zager

Music Mafia by Kevin Dorosh, Matt Yaspan, and Samantha Welch

MusTrip by David Bernstein and Matt Carrington-Fair

MyDea by Joe Campbell and Tommy Tang

Pocket Critic by Eric Hochwald, Alex Jackson, and Jun Wang

PoorMansHomeStereo by Elena Cokova and Kevin Liu

Project Student Housing (psh) by Chris Fitzpatrick and Will Luna

QueueR by Alex Nguyen and Tianyu Zhu

Student Bridge by Nick Carlino and Georgios Papakostas

SueChef by Chase Crumbaugh, Alex Ravan, and Vincent Tran

Suh by Rowan Krishnan and Katya Malison

Treble by Olivia MacDougal and David McConnell

Tufts Bluelight Mobile by Tafari Duncan and Zabir Islam

TwoCents by Toby Glover and John Westwig

socialgraffiti by Alena Borisenko and Cornell Patrick

yummie by Elif Kinli and Marcus Mok

Leg 1: Design and Requirements


In your engineering notebook:

  1. Briefly explain the need for the app (the "what")
  2. List the stakeholders and customers of the apps (the "who")
  3. Using wireframes, sketch the most important views of the app.
  4. Diagram or sketch the architecture of the platform. The platform is what that powers the app. It is very difficult to build an app without any dependencies. An example is Instagram. Read about what powers Instagram:
  5. List and briefly describe the core functionality of the app, the most important functions and transactions of the app.
  6. 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.
  7. List the features on a mobile device that the app will use (e.g., camera, GPS, SMS, flashlight).
  8. Briefly describe any limitations each team member may feel that will hold back progress.
  9. Briefly describe how your team plans to market or advertise the app.

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 16th. This should give you enough time to come up with a great idea. Teams will not be presenting their ideas.

Leg 2: Basic Foundation of Your App


Looking Ahead

If you did not do so in your Design and Requirements, it is urged that you start compiling a list of third-party APIs that you will need for the app. While you are allowed to use third-party APIs, packages, or libraries for development, I will not help you with any questions or issues that you have with them.


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

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


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 Tuesday, November 1st 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!). Deadline: Thursday, November 10th.
  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, write about how your team has been marketing your app to customers and how you are engaging with them. Keep track of the feedback that your team has been receiving from customers.
  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 Thursday the 17th and on Tuesday the 22nd, each team shall give a 2 minute demo of their app in class. No presentation slides allowed --just demo app on a device (I will bring the device loaded with your app). We will try to fit as many demos as we can in the two days. If needed, we will use Tuesday the 29th.

Please review as many apps as you can before Thanksgiving. 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 at least 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 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.