Assignment Overview
In this assignment, you will create a web application called Wassup, which allows users to send a “sup?” message to their friends. “sup?” is short-hand for “what’s up?”, which is an common alternative way to say “hello!”
Specifically, users should be able to
- log in and log out of the application
- add/remove friends to/from the contact list
- view a list of the friends in their contact list
- select 1 or more friends in the contact list, and send a “sup?” message to them
- view “sup?” messages from friends
- clear a particular “sup?” message from the deck
- switch between a private versus public server
Implementation Requirements
User Interface
The wireframe for this application is shown here:
Login / Logout
We assume the user ID is set in a cookie. If it is not set, users will be redirected to a login page (views/wassup_login.html). The login functionality is provided and is fully functional. However, you should provide additional styling of the login page such that it is consistent with the look of your application. The logout function is provided in the server. You need to implement a logout link/button in the user interace, which will issue a form POST to the server to handle logout.
Contact List
The contact list should display a list of friends a user has. The user should be able to add a new friend (using a unique alias) or remove a friend from the contact list.
Sending and Receiving “Sup?” Messages
The “sup?” message should be drawn on the HTML canvas by randomly manipulating the graphic context before calling fillText() on the HTML canvas. That is, each time the user receives a “sup?” message from a friend, that message should have a different look, color and size from the previous message.
The system should periodically poll the server to check if there are “sup?” messages. The “sup?” messages should be displayed one at a time, with the most recent message displayed first. Each “Sup?” message should be accompanied by information about who sent it and at what time. Users should be able to click on a “next” and “previous” button to see the next or previous “sup?” message.
The frontend implementation will involve modifications to the following files:
- views/wassup_app.html
- views/wassup_login.html
- static/css/wassup.css
- static/js/wassup.js
Switching between Private and Public Server
There are two server locations — the public server is at http://104.197.3.113, the private server is at http://localhost, i.e., on your own machine. The public server is accessible by all CS349 students, and so you can use the server to send/receive “sup?” messages to/from your classmates, as long as you know their user ID. Your application needs to provide a way for users to switch between using the private and public server. The ability to switch to a private (i.e., local) server is useful when the public server is down or if the response is slow. Your application needs to be able to deal gracefully with errors and latency issues. When appropriate, you should also incorporate into the user interface components (e.g., progress bar, busy indicators) to help the application maintain responsiveness, by providing feedback to the users about the status/progress of their requests.
Responsive Design
Your frontend designs need to be responsive and display well both on the desktop and mobile devices. When the width is <= 450, the application should switch to mobile mode. In the mobile mode, the layout should change to fit the smaller screen size, which may require resizing some of the user interface components and disabling some of the functionalities. Below is a screenshot of an example of a mobile version of the “Wassup!” application.
Client-Server Communication
The backend server (wassup.py) is written using a web framework called Python-Bottle (http://bottlepy.org/docs/dev/index.html). You should use the provided backend system as is, without having to make any modifications.
To run the backend server privately on your local machine, type “python wassup.py” in the terminal, then go to “http://localhost:8080” using a web browser. You can run print_db.py to print out the content of the database. This is maybe useful for debugging purposes. Alternatively, your application can communicate with the public server directly at http://104.197.3.113.
Each “sup?” message has a unique sup_id. This ID is used to uniquely identify each “sup?” message so that users can clear a particular “sup?” message from their deck.
Your application can call the backend with the following commands and associated data:
- create_user
- input: user_id, full_name
- output: a string (upon the successful execution of the command)
- add_friend
- input: user_id
- output: a string (upon the successful execution of the command)
- remove_friend
- input: user_id
- output: a string (upon the successful execution of the command)
- get_friends
- input: user_id
- output: a list of key-value pairs listing the user_id and full_name of each friend.
- send_sup
- input: user_id, sup_id, date
- output: a string (upon the successful execution of the command)
- remove_sup
- input: sup_id
- output: a string (upon the successful execution of the command)
- clear_sups
- input: sup_id
- output: a string (upon the successful execution of the command)
Some sample code for making an AJAX call to the server is provided in static/js/wassup.js. Essentially, to issue a request to the server, you need to pass in a JSON object inside the handleAjaxRequest() method with the following properties (all required):
- protocol_version: A number indicating the version of the server implementation. It is in general good practice to include the protocol version number in case the server implementation changes. For the purpose of this assignment, you can send “1.0” as the protocol version number.
- message_id: The ID of the message being sent. This is an unique identifier generated by the client to distinguish one message from another.
- command: The actual command to execute (as shown above)
- command_data: Command-specific data (as shown above, null if there is none)
In response to the request, the server will return a JSON object with the following key-value pairs (all fields will be present in every response):
- protocol_version: The protocol version the server is using
- error: string representing the error encountered, or empty string if no error
- command: The command this object is a response to
- message_id: The ID of the original request/message
- reply_data: The return data for executing the command. Undefined if an error. The type of data returned is command-specific.
