Shawn Long SID: 862154223 James Liem SID: 862212126
Phase 3 of the project was implemented in Java mainly using the code that was provided in the project files. Shawn worked on the Command Line Interface and backend with the database and James worked on the GUI and documentation with both of us occasionally helping each other out with various bugs and fixes.
One of the design changes that we implemented was to move the command line driver into its own class and file, and created a separate file for the ProfNetwork class which we used to handle all database interaction. Most of the database functionality is pretty straight forward, but adding friends required another major design decision. One of the design constraints was that to add a friend, they must have a connection of at least three levels. To implement this, we decided to create a friends table and a request table. The friends table serves as an edge list with custom constraints to enforce a unique record for each edge (no duplicates for (a,b), (b,a). Requests for friends then live in the requests table, and when a request is set in both directions, the records are deleted. This optimizes data storage by eliminating records when no longer needed.
We also made a few assumptions with the provided data. For instance, the original data types in create_tables.sql were not sufficient to import the provided data. Because Postgres implements char, varchar and text in the same way under the hood, we opted to use text types instead of varchar’s so that we could accept unlimited size input. Because we enforce that a valid usr must exist for foreign key references in other tables, we removed records form input data without user references.We didn’t see the announcement about deleting messages for one user only, instead of both so instead we assumed that an approach like Slack or Discord was better, where edits/deletes to a message for one user affect both users.
Most of the core features are pretty self explanatory, and require only simple SQL queries, such as querying friends or messages, or creating users. We included input validation to avoid duplicate or invalid data. The most difficult implementations were friends and updating profiles. Friends was difficult because of the connection constraint, but we fixed this by creating the Friends table as an edge list, adding custom constraints for uniqueness, and indexes for optimization. As a result, it wasn’t difficult to write an optimized BFS algorithm to check if friends can connect. The second difficult implementation was updating a profile. We had to make sure that an updated username didn’t break other functions from being mismatched. We solved this by passing the updated username back to the top-level in the main loop.
Some problems that occurred with the GUI was organizing how the layout of the GUI worked and making sure it stayed consistent with each menu. Additionally, it was difficult to make sure all the buttons regularly worked. There were also problems with the buttons in that it would only work once and so some work needed to be done in order to make sure that the buttons always worked.
We made a few changes outside of the given specifications. For one, we added a feature to search users based on partial match to username and name, so users could find people they aren’t yet friends with. We also set up the system so that two apps could run simultaneously. Lastly, we added a notification and option to view all unread messages when viewing messages, and split a thread between users to separate messages that were already read from new messages, like in Slack.