Homework Assignment 11

Making Our Social App Persistent

CS 2530
Intermediate Computing

Due: Saturday, December 8, at 6:00 PM

Introduction

Note the same unusual due date and time for Homework 10!

Fast forward to early 2015. Your homegrown replacement for Twitter is in its second iteration and drawing raves from everyone in the company. It is not a full-featured social media app yet, but it is theirs: open source, written in the company's primary programming language, and extendible in ways that your users find most useful.

Why limit yourself to someone else's program when you can make what you want?

Feature requests are rolling in with regularity now. You decide to address them in small releases, as the application started, so that you can get user feedback quickly and build on the real needs and wants of your users. That is almost always better than guessing.

Tasks

Your tasks are to extend your simple messaging system with a few new features:

• Each message has a unique message ID, so that the system and its users can identify individual messages both inside and outside the system. This can be something as simple as <global_count> or <user>:<count> or <user>:<timestamp> .


• A user can forward a message from another user to all her followers. When her followers see the forwarded message, it will have (via <user>) appended to the end. Those characters do not count against the character limit placed on messages.


• A user can delete a message. Deleted messages do not disappear from open views, but they will not appear in any view opened after the message has been deleted.


• The system administrator can shutdown the application by sending the main object a quit() message. When the system shuts down, all application data is written to one or more text files. Application data include the users, their messages, and all follow sets. When the system is started, it reads all application data from one or more text files to restore the state of the app to what it was when last shut down.

NOTE. You must implement the last bullet -- persistence to data files -- either before implementing the other three or after implementing the other three. If you have time to implement only a subset of features, we want to have fully-functional features.

~~~

Your tasks is also to extend your simple interface with a few new features:

• The user can forward or delete a message by sending a message of the form ^forward message ID or ^delete message ID respectively. Like follow and unfollow messages, forward and delete messages are not broadcast to the user's followers.


• Within a single window, the user can toggle among a feed panel, a mentions panel, and a user page panel. The user page panel displays the most recently requested page for another user, or the user's own user page if no other user's page has been requested.

Your system is growing but incomplete. Consider it still to be a prototype, subject to changes based on feedback from users and your employer. As a result, you should continue to use the design principles and design patterns you have learned to create a program that is as easy to extend and modify as possible.

Feel free to add your own style to the app -- as long as your solution provides the features outlined above. If you add too many features beyond the initial mock-up, though, be prepared that future changes in the spec may conflict with your additions. So design your program in a way that makes your additions -- and even the assigned features -- as easy to modify or replace as you can.

Extra Credit

As many features as you have implemented, there is so much left to do! For extra credit, implement one or more of these new features:

• A user's window contains button panel containing at least a follow button, an unfollow button, a forward button, and an delete button. This panel is perhaps coupled with a text field in which the user can specify a username (for the first two buttons) or message ID (for the last two buttons).


• Any URLs that appear in a message are replaced with short links. Such short links enable the user to include more meaningful text in their length-constrained messages. A map between URLs and short links is stored in the app so that the same short link is used for the same URL in different messages, and so that users can access the full URL if they are interested in following it.


• When the user opens a window to view his various pages, he must enter a password. The password is stored with the rest ofthe user's data. For extra extra credit, encrypt the password somehow!


• The application keeps track of an access marker that indicates posts the user has already seen in a view. With such a marker, the next time she opens a view, she can be shown messages beginning with the oldest message she has not already seen.

NOTE. You may submit work for extra credit only if you have completed all the required features listed above. The only exception is persistence. You may attempt extra credit tasks een if you do not attempt to read and write user data to and from files.

Your readme.txt must state explicitly and clearly that you have attempted extra credit and, if so, which features are included in the submission.

Deliverables

By the due date and time, submit a zipped file containing:

• any file necessary to compile and run your application


• a detailed readme.txt file that includes
  
  
  • specific instructions for compiling and running your app -- in particular the class with main()
  
  
  • a statement of whether you did the persistence feature first, last, or not at all -- and why
  
  
  • a statement of whether you attempted extra credit and, if so, which features are included
  
  
  • an explanation of the design of your program, including the various objects you create and how they relate to one another

For your hardcopy, submit only your readme.txt file.

Be sure that your submission follows all homework submission requirements.