Homework Assignment 11
Making Our Social App Persistent
Due: Saturday, December 8, at 6:00 PM
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
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
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
- 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
^delete message ID
respectively. Like follow and unfollow messages, forward
and delete messages are not broadcast to the user's
- 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.
As many features as you have implemented, there is so much left to
do! For extra credit, implement one or more of these new
- 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.
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
- 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
For your hardcopy, submit only your
Be sure that your submission follows all
homework submission requirements.
Eugene Wallingford .....
December 1, 2012