This document should be read in conjunction with the original Major Project specification and your assigned APIs. It contains information about the tiers above Pass, as well as marking information for your Milestone 2 submission.

•      See original release

•      See original release – Milestone 2 is a Test Checkpoint

CORE REQUIREMENT: Your application must have caching enabled. What is to be cached is listed in your input API instructions. Cache exactly this – no more, no less. This caching must follow certain rules:

•     The cache should be stored in a sqlite database

•      Caching is only enabled when the Input API configuration is online. Output API configuration is not relevant.

•      Caching must be retained across application runs – that is the caching database file must be retained on disk and used after the application has been closed and reopened

•     The caching must be performed entirely through the use of SQL. In-memory caching does not count for this requirement, and selecting the appropriate cached data should be performed using a SQL     query, not pulling more data than is needed and filtering using Java code.

•      Whenever a cache hit occurs, the user should be informed in the GUI in some way, and be given the   choice of whether to use this cached data or request fresh data. For example (this is not the only way to do this), a dialog box saying, “cache hit for this data – use cache, or request fresh data from the       API?”

•     There should be a user-accessible function to clear the cache

You must also implement 2 of the following features:

•      Add a ‘splash’ image (seehttps://en.wikipedia.org/wiki/Splash_screen) when your application starts. This splash image should be something relevant to your application (no need to draw something, but cite your source). Display a loading bar under the splash image that takes 15 seconds to load. After     this time the splash image disappears, and your application runs as normal.

•      Allow the user to interact with your application solely by keyboard shortcuts and tabbing (if they choose to – mouse alternatives can stay available).

•      Add a help feature to your application. When the user holds a keyboard modifier (default being CTRL, other modifier may be negotiated if your design already makes use of CTRL) any button click or other  click interaction does not execute, but instead pops up an alert telling the user what that element in   the UI is for and how to use it.

•      Allow the user to save a screenshot of the main window scene to disk. This should make use of a FileChooser or equivalent.

•       Implement logging, with a user-configurable log level. You may use a logging library to assist with this. You should at a minimum implement the INFO and DEBUG log levels, where INFO gives at a    minimum 1 log output for every human user action, and where DEBUG gives at a minimum a log    output for all data mutations.

•     Theme song. The application should play a music track on a loop . The user should have the ability to turn this feature on and off. The music track is your choice (cite your source – please exercise good   judgement when selecting a music track and avoid anything inappropriate – radio acceptable only).

•      Add an ‘About’ feature. This feature should display the name of the application, your name, and        references used. This feature must be in conjunction with a MenuBar, and be accessible through an  ‘About’ MenuItem. It may optionally be available through some other access point(s), e.g., a button.

•      Include a light mode and dark mode for the application, which can be toggled by the user. Light mode being light background, dark text. Dark mode being dark background, light text. You should be careful to test your software on multiple operating systems if you choose this feature, as the Look & Feel         behaviour may be different.

•      Sendgrid/Mailgun only: use HTML email contents for your report. Style your email in a visually impressive way, with colour, headings, and a banner image (cite your source).

•     This requirement specification remains as described (you must determine the appropriate way to achieve this on your own): You must use concurrency such that your UI remains responsive            throughout slow network calls

You must additionally complete 1 of the following features:

•      Personalisation and user accounts. Implement a user account feature. This feature will ask the user to log on with a username (stored in plaintext) and password (hashed using SHA1, no need for salt).          When starting the application, the user should be asked if they will log in to an existing account, or       create a new account. Guest access should not be implemented. There is no need to allow the user      account to change mid-execution. This user account setup must allow for a preference configuration   setup that is saved to that user:

o  Any colours involved in the UI function must be selectable by the user (use a ColorPicker or  similar convenient method, not typing colour codes), which are then stored under that user account and retrieved the next time the user logs in.

o  Any lists, favourites, history, or retrieved data that your input API uses must be stored in the user account and loaded upon that user logging in .

o  Note if you have implemented the light mode dark mode standard feature this should be tied in together.

•      Queued commands. The user should be able to queue commands intended for the Input API, to load   multiple requests. Days, currencies, Ips, words, ingredients, characters, teams, tags, cities, searches.    These parallel requests should be entered into a visible queue that the user can continue to add to,      remove from, and execute. Upon execution the GUI should display multiple views – either separate      windows or a tabbed display, that shows the outcome of each query when it arrives. These views          should be immediately visible but not populated with data until their query executes. These queries     should be executed in order, automatically on a timed schedule every 30 seconds (longer may be          negotiated if your API has rate limit issues even at that slow speed). Your GUI must remain responsive throughout, and critically the user must be able to interact with each window/tab including adding       new requests while this queue is executing.

•      Allow string localisation, and translate all displayed text strings (aside from those coming from your  APIs) into French. Use Google translate or similar to handle the translation (stored statically on disk,