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.
