Differences
This shows you the differences between two versions of the page.
|
osp:project:assignment [2016/10/25 14:39] vlad.traista [Tasks] |
osp:project:assignment [2017/01/10 17:36] (current) vlad.traista [Server revisions] |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| ====== Assignment ====== | ====== Assignment ====== | ||
| * **Deadline: January 15th, 2017** | * **Deadline: January 15th, 2017** | ||
| - | * Upload the assignment at the following location: TODO. | + | * Upload the assignment at the following [[http://cs.curs.pub.ro/2016/mod/assign/view.php?id=3433|location]]. |
| * You should upload a zip archive containing: | * You should upload a zip archive containing: | ||
| * the sources of the application | * the sources of the application | ||
| Line 10: | Line 10: | ||
| * Make sure that your team is registered [[http://ocw.cs.pub.ro/courses/osp/project/team-choice|here]]. | * Make sure that your team is registered [[http://ocw.cs.pub.ro/courses/osp/project/team-choice|here]]. | ||
| * A single team member must upload the assignment. The team members should be mentioned in the README file. | * A single team member must upload the assignment. The team members should be mentioned in the README file. | ||
| + | * The assignment has to be presented to the OSP team on **January 16th, 2017**, at **19:00**, in **PRECIS 703**. An assignment that is not presented will have a penalty of 1 point (out of 10). | ||
| ==== General description ==== | ==== General description ==== | ||
| Line 22: | Line 23: | ||
| If the Android client application is developed using an Android mobile device, a WiFi connection is required in order for the client to be able to communicate with the server. | If the Android client application is developed using an Android mobile device, a WiFi connection is required in order for the client to be able to communicate with the server. | ||
| - | If the Android client application is developed on an emulator, there is no need for a WiFi connection since the communication will be done using local sockets (localhost/127.0.0.1). | + | If the Android client application is developed on an emulator, there is no need for a WiFi connection since the communication will be done on the local host. For the Android application to be able to access the server on the host machine, you will have to use the following IP address 10.0.2.2 (magic). This IP address is the address of a virtual router that isolates the emulator network interfaces from the host's network interfaces. When accessing this IP from the emulator, it will be translated to the IP of the host. |
| + | |||
| + | ==== Server revisions ==== | ||
| + | |||
| + | This section will contain all the changes and bug fixes applied to the Python server code: | ||
| + | |||
| + | * **07.01.2017** | ||
| + | * changed the address on which the server listens from the localhost address (127.0.0.1) to any address (0.0.0.0 or "") in order to allow a mobile device to connect through WiFi to the server. | ||
| + | <spoiler Diff><code> | ||
| + | 265c265 | ||
| + | < server.bind(("127.0.0.1", 4000)) | ||
| + | --- | ||
| + | > server.bind(("", 4000)) | ||
| + | </code></spoiler> | ||
| + | * **09.01.2017** | ||
| + | * fixed an issue that did not close the sockets when the remote end gracefully or forcefully closes the connection (e.g WiFi interface goes down). These changes are reflected in the server_experimental.py file which was added in the archive with the server code. | ||
| + | <spoiler Diff><code> | ||
| + | @@ -160,12 +160,26 @@ | ||
| + | buf = b'' | ||
| + | running = True | ||
| + | while running: | ||
| + | - aux_buf = self.socket.recv(4096) | ||
| + | + try: | ||
| + | + aux_buf = self.socket.recv(4096) | ||
| + | + except Exception as e: | ||
| + | + running = False | ||
| + | + print("Client disconnected...") | ||
| + | + try: | ||
| + | + clients.remove(self) | ||
| + | + self.socket.close() | ||
| + | + except Exception as e: | ||
| + | + print("Server encountered following error: %s" % str(e)) | ||
| + | |||
| + | if len(aux_buf) == 0: | ||
| + | buf += b'\0' | ||
| + | running = False | ||
| + | print("Client exiting...") | ||
| + | + try: | ||
| + | + clients.remove(self) | ||
| + | + self.socket.close() | ||
| + | + except Exception as e: | ||
| + | + print("Server encountered following error: %s" % str(e)) | ||
| + | else: | ||
| + | buf += aux_buf | ||
| + | </code></spoiler> | ||
| ==== Tasks ==== | ==== Tasks ==== | ||
| Line 75: | Line 120: | ||
| After login, the user should be redirected to an activity that displays a list of all existing users from the server. | After login, the user should be redirected to an activity that displays a list of all existing users from the server. | ||
| - | This activity should also have a menu from which you can easily navigate to the favorite users activity or to the chat activity. | + | This activity should also have a menu with two options: |
| + | * one that allows the user to navigate to the favorite users activity | ||
| + | * one that allows the user to logout of the application by redirecting the user to the login activity | ||
| === Task 3: Favorite users (1.5p) === | === Task 3: Favorite users (1.5p) === | ||
| Line 96: | Line 143: | ||
| "message": "Message" | "message": "Message" | ||
| } </code> | } </code> | ||
| + | |||
| + | The list of users from the outgoing message represents the users who should receive this message (it is similar to a broadcast message). | ||
| + | |||
| + | <note warning> | ||
| + | The outgoing message does not contain information about the author of the message. The Python server will "guess" the author of the message using the information provided by the login message. Therefore, only one user can be logged in at a time in the application. | ||
| + | </note> | ||
| Format of incoming message: | Format of incoming message: | ||
| Line 108: | Line 161: | ||
| === Task 5: Communication with the server (3p) === | === Task 5: Communication with the server (3p) === | ||
| - | Communication with the server should be implemented through a service which stays alive after login and dies once the socket is closed or the user decides to logout (Add a button to the applications for this). | + | Communication with the server should be implemented through a service which stays alive after login and dies once the socket is closed or the user decides to logout. |
| The service should display new message notifications which open the correct Activity for reading the message. | The service should display new message notifications which open the correct Activity for reading the message. | ||
| Line 114: | Line 167: | ||
| === Task 6: Service reconnect (1p) === | === Task 6: Service reconnect (1p) === | ||
| - | Add a broadcast receiver component which reconnects the service when the internet comes back online (if previous state was logged in). | + | Add a broadcast receiver component which reconnects the service when the internet comes back online (if previous state was logged in). If the user was previously logged in, the reconnect procedure should restart the login procedure (the JSON messages). |
| + | |||
| + | <note warning> | ||
| + | When implementing this receiver, it will most likely listen to events caused by the change of network connectivity state (WiFi interface goes down or up). However, when a WiFi interface goes up it transitions multiple times into the CONNECTED state which means that the receiver will receive that event multiple times. **The reconnect procedure needs to be done only one time once the WiFi interface is up.** | ||
| + | </note> | ||
| + | |||
