Description
Play Application: “Reactive TweetAnalytics”.
Your goal is to modify your Play application from Assignment #1 to make it reactive, i.e., stream live updates to the user interface.
Thus, instead of having a static
list of Tweets for a search keyword, your application will now dynamically show any new incoming tweets.
You only have to make the search page reactive; the profile page can stay static (but you are free to make it
reactive as well).
You must implement this reactive behavior as an asynchronous server push solution, using WebSockets and
Akka Actors.1 You can base your implementation on the Play ‘Reactive Stocks’ example application shown
in the lecture (note: you can, but do not have to, use Akka Streams in your solution).
Coding guidelines. Your submission must satisfy the following requirements:
a) Your application must be based on the Play framework and it must be possible to build and run it using
the standard sbt run command. Any required third-party libraries must be automatically resolved through
sbt.
b) Document all your classes and methods with Javadoc (including private methods).
c) Your controller actions must be asynchronous, using Java 8’s CompletionStage/CompletableFuture. Do
not use .get()/.join() to block for the future’s results anywhere in your code (only exception are unit
tests, see below).
d) Create JUnit tests for all your classes. You must have tests for every method in your controller and every
controller action, as well as any additional classes you wrote. Compute your test coverage with JaCoCo.
Notes: (i) within a test, you can use .get()/.join() to wait for a result; (ii) do not call the life Twitter
API from a unit test, use a mock class for testing instead.
d) You must include a README.txt file with: (i) Group member information (names, IDs); (ii) Contributions
of each group member (classes, methods – also include the names in the relevant Javadoc @author tags);
(iii) any technical notes about your app (compiling, running, etc.).
e) For testing your Twitter API, you must use dependency injection with Google Guice (if you are already
using a mocking framework, like Mockito, this is also acceptable for A2).
f ) You must create one actor for each user (WebSocket connection). Create separate actors for managing
the Tweets and Twitter Users (profiles). Define appropriate message classes. You must have JUnit tests for
your ActorSystem, using the Java Akka Testkit shown in the lectures.
Submission. You must submit your code electronically on Moodle by the due date (late submission will
incur a penalty, see Moodle for details). You must also demo your code to the marker during your lab session.
Note that all group members must be present for the demo and ready to answer questions about the code.
In particular, a solution where you simply refresh (parts of) a page using, e.g., AJAX on the client side will not be accepted.
