CSE 216: Software Engineering Programming Assignment #2
Instructor: Prof. Liang Cheng and Prof. Mark Erle Assigned: 2/29/2020
Project Assistants/Mentors: Jack Cunningham, Andrew Johnson, Kyle Moon, Buckley Ross,
Dominick Rubino, Maxim Vezenov, Matthew West
Due: 3/23/2020

Problem Statement

Well, that escalated quickly. The CTO saw your web app and said “I want that.” He insisted that you
launch it immediately, but you managed to buy enough time to go from “prototype” to “barely adequate.”
On the bright side, while he said you only had two weeks before you went live, he accepted your advice
to add features incrementally. But at the very least, it’s going to be important to add authentication and a
comment system.
It’s going to be important to move quickly. But more importantly, you need to make sure that each step is
done right... this project is going to get bigger and bigger, and any technical debt you accrue now is going
to cost a lot to pay off later on down the road.
You talk with the folks in IT, who talk about the company’s switch to Google Apps for Business, and
how Google’s implementation of OAuth 2.0 [1] has made password resets a thing of the past for almost
every system in the company. But the password resets are just too big of a problem, and you’ve got to do
something quick. You take a look at the Google API Console [2], and it looks tantalizingly easy...

Reminder

Each student should be in a different role than the one during Phase 1. The design for this phase (Phase 2)
will be an in-class exercise. The class will discuss, and coalesce around, a single design.


Deliverables

The Back End

Your job is to implement an OAuth flow in the back end, so that clients can authenticate with Google. We
have discussed how to do this in class, to help you get started. It will be a good idea to do this as early as
possible, since your teammates are depending on this code.
One aspect of this task that can be confusing is that your back-end server will get a token from Google,
and that token will have an expiration date. We do not need to worry about the expiration, though: once
the user has authenticated, that’s good enough for us... we won’t be making subsequent requests to
Google APIs using that token. Once the user is authenticated, you can save the user ID and a random
session key into a local hash table.
You will probably want to read the Google documentation on Backend OAuth implementation [3]. Note
that for the purposes of this assignment, you should only allow use from the lehigh.edu domain. You do
not need to implement a “registration” phase anymore: anyone at lehigh.edu should immediately have
access to The Buzz.
We will no longer have anonymous browsing of the messages on “The Buzz.” Users must be logged in to
view posts, up-vote, down-vote, and have the ability to leave comments. Note that comments won’t be
nested.
Regarding votes, we will provide votes as a state machine. Initially, a user has a neutral vote. Clicking up-
vote or down-vote will act as expected. However, up-voting a post that the user has already up-voted, or
down-voting a post that the user has already down-voted, will result in no change. Down-voting a
previously up-voted post, or up-voting a previously down-voted post, will replace the previous vote. You
must think carefully about how to do this in SQL.
Votes must be secure. It should not be possible for a user to dissect the JSON and see who has up-voted
or down-voted a post. However, you might choose to allow a user to see which posts she up- or down-
voted.

The Android App

Your app should support all of the above features of the server, to include displaying comments for
messages, handling login/logout via OAuth, and registering up/down votes. A user should be able to edit
the comment(s) posted by the user (which means more REST routes... be sure to coordinate with the
back-end developer). Clicking on the name of a person who posts a message, or who makes a comment,
should take you to their profile page. You should use multiple activities, as appropriate.
Note that you will be modifying and adapting code that your team member wrote in a previous phase. If
your team member adhered to good standards, you should follow suit. If not, you should refactor the older
code to match the quality of the code you write.
You should use the GoogleApiClient and activity overlay to sign in [4]. Note that this can get
complicated for your teammates, because this method requires a client ID that is specific to one team
member’s Android Studio instance. There are tutorials online to help you to get this right.
If you haven’t yet, you should also add a profile activity. The user should be able to visit profile of the
author of any message or comment. It should also be possible to visit one’s own profile page. On any
profile page, a user should be able to see all of the posts that the given profile has posted.
You should be mindful of duplication of code in this phase. You will be using a RecyclerView.Adapter,
just like in the main list of messages. Don’t copy and paste code. Instead, consider using an observer
pattern. Depending on how your teammate wrote the code, this may mean implementing any listeners in
the observer class and having all ”reactions” that occur on the UI thread occur there. If done correctly,
you can use one class (the observer) in many activities to respond to things like Up/Down/Neutral votes.
Note: To keep a user logged in, you should use SharedPreferences to store session state. Also, be sure to
continue to use Espresso to test the Android app. If you keep any references to the activity/adapter in the
observer, make sure you nullify those in the activity’s onDestroy or else there may be a memory leak.

The Web Developer

Your task is pretty much the same as the Android developer, except that the OAuth flow is a little bit
simpler to implement for the web. As with the Android app, the web developer needs to start by getting
the web front end caught up with the new design. You’ll need to have a login page via OAuth, up-votes,
down-votes, and comments using the new JSON formats and new REST routes. In addition, you are
going to add a profile page, which will show the user name, user email, and a comment about the user.
The comment should be editable (which means more REST routes... be sure to coordinate with the back-
end developer). Clicking on the name of a person who posts a message, or who makes a comment, should
take you to their profile page. And, of course, you should be able to get to your profile page from the
Bootstrap navbar at the top of the page.
The Admin App

Of course, you will also need to have a way to manage the new tables and new columns in the existing
tables in your database. Once you have those tasks done, it will be your responsibility to help the project
manager to keep everything on track, by pair programming with your teammates.

The Project Manager

The project manager should create a new Google account that can be used to ”host” the project. Using
this account, the project manager should set the authorized JavaScript origins, authorized redirect URIs,
and Android Studio instances. You will have multiple client IDs to set as the ”audience” but only the
server’s client ID/secret will be used for the redirect URL and Open ID Connect code redemption.
With the app running on Heroku and following the principles of 12-factor app design, you’re starting to
have a lot of configuration variables to maintain. That’s just a fact of life, but you should document the
configuration carefully.
In addition, the Project Manager is still responsible for integrating each member’s code into the main
branch, performing code reviews and documentation, and submitting the team’s work. Remember: tests
are important, and should not be delayed. Finding bugs early is much better than finding them late!
Code reviews are going to be extremely important for this step. In particular, you should study OAuth on
your own, so that you can be sure that your developers are using it correctly. Are the keys from Google
being used correctly? Are secrets being kept secret? Can the user fake her credentials? Can the server
spoof a user? Once a program uses external APIs, code reviews become harder, because you need to
review API usage (and you need to test for correct usage too). The programmers write less code, since
they aren’t implementing things themselves. But as the project manager, your job gets a little harder.
In addition to the database and routes, you should also create documentation for the user interface for
your app. The UI should be as similar as possible for the web and Android versions. Be sure to document
the flows related to authentication.
The project manager (also the code reviewer “czar”) continues to explore ideas to extend the project for a
potential start-up and researches on what the target users/markets are. Brainstorm with team members so
that the team has a storyboard. Fill in the template provided for Design-oriented Thinking for this phase;
the template is available in the CourseSite.
Lastly, note that this is an opportunity to refactor. The next phase will have many more deliverables than
this phase, so the more resilient your code is, the easier that phase will be. You should make a plan for
how your team will get rid of technical debt and be in a good place moving on to the next phase.
Mentorship

Each team has already had one Project Assistant (PA) assigned as a mentor, and that PA will meet with
students at least once per week, both to mentor the team and to assess its performance. Teams should take
advantage of this opportunity, especially when it comes to teamwork, priorities, and technical obstacles.

Turn-in Instructions
We will make a copy of your team’s repository at some point on or after the due date. Be sure to commit
and push your solution prior to the due date by branching from master into a new branch called
“phase2”. If your team completes all the tasks, your last commit to the Phase2 branch should contain the
message “All tasks complete, ready to be graded”. This will be viewed as a submission, and any future
commits will not be included in your grade.
Late Submission Policy

If you do not push a commit with the message “All tasks complete, ready to grade” then a snapshot of
your repo will be taken by the 4th day after the deadline and used for grading. The following policy will be
used for grading late submissions.

Submission late for 1 day: 15% penalty;
Submission late for 2 days: 30% penalty;
Submission late for 3 days: 45% penalty;
Submission late for 4 days: 60% penalty;

A submission late for more than 4 days will not be graded thus receiving 0 point.

Acknowledgments

The creation and updates of this project were funded in part by the Kern Entrepreneurial Engineering
Network [5]. We thank Professor Michael Spear and the Kern Family Foundation for making this project
possible, and we encourage our students to emphasize the “Three C’s” in all aspects of this project.

References

[1] OAuth2.0. OAuth Community Site, 2019. https://oauth.net/.
[2] Google, Inc. Google API Console, 2019. https://console.developers.google.com/.
[3] Google, Inc. Authenticate with a Backend Server, 2019. https://developers.google.com/identity/sign-
in/web/backend-auth.
[4] Google, Inc. Integrating Google Sign-In into Your Android App, 2019.
https://developers.google.com/identity/sign-in/android/sign-in.
[5] The Kern Family Foundation. KEEN-Engineering Unleashed, 2019. http://engineeringunleashed.com.