In Task 3 your work will mirror many of the things you will need to do for your exam in SOFT3202. You
will be creating a GUI application that targets a web API to provide certain features.
Your task is to create a GUI application that provides users access to the API provided by SpaceTraders. You should read up on the SpaceTraders server and its API through the following links:
https://spacetraders.io/ (https://spacetraders.io/) https://api.spacetraders.io/ (https://api.spacetraders.io/)
You are being given significant freedom to decide exactly what your application will look like and how it will deliver on the requirements. Unlike other assessments you have control over the build.gradle file that is used and (within some specific limits) can add in libraries to assist in your work. Your first library decision will likely be the GUI framework you use. JavaFX and Swing/AWT are likely to be the most common, but you are not limited to these.
The key limitation on what libraries you can include (which you will experience in your exam work as well) is that you cannot include any API specific libraries. This means none of the libraries included here https://github.com/SpaceTradersAPI/awesome-spacetraders (https://github.com/SpaceTradersAPI/awesome-spacetraders) or anything that does something similar, you must code the way your application accesses the API yourself. You can use the native java.net method described in the Week 7 tutorial, but you will probably find it easier to bring in a higher abstraction library such as Apache HttpClient https://hc.apache.org/httpcomponents-client-5.0.x/
(https://hc.apache.org/httpcomponents-client-5.0.x/) .
An issue with targeting a web API is that you have introduced an external dependency into your work, which will make testing in isolation more difficult (note that you do not need to do programmatic testing in this task, but running it on your own to see if it works, and your marker doing the same, are all forms of system testing). This has 3 main issues – first, the API could be down, whether due to a bug or maintenance. Second, the API has built in rate limit protections, which your marker may reach when marking leading to subsequent students’ applications failing to work. Third, the API has timers included that will make testing difficult. To resolve this, you will need to abstract access to the API – I would strongly suggest applying the façade pattern here.
You will then need to create a ‘dummy’ version of the SpaceTraders API behind this abstraction that acts locally, and yields enough data/dynamic responses to successfully demonstrate the features of your application, selectable through the command line parameters to be detailed later. This does not need to be fully featured (consider it similar to a mock) – it is just there to show your UI lists, dialogues, etc display with information in them correctly.
In order for your application to be considered a success it must allow the following: https://canvas.sydney.edu.au/courses/31635/assignments/294923 1/4
4/30/2021 Fortnightly Task 3 – API
The user can see whether the server is currently active
A new user can obtain and store credentials (these can just be stored in RAM, no need for saving to disk)
An existing user can enter and store their existing credentials
The user can see their info
The user can list available loans and their details
The user can obtain a loan
The user can list active loans
The user can pay off a loan
The user can list available ships and their details
The user can purchase a ship
The user can list their ships and their details
The user can purchase ship fuel
The user can view the marketplace details for a given location
The user can purchase goods from the marketplace
The user can list nearby locations and their details
The user can create a flight plan and journey to a nearby location
The user can view their current flight plan (this does not need to automatically refresh, manual is ok)
The user can sell goods to the marketplace
These features should be available ‘half-way’ – that is, if a user closes the application and re- opens it, they should be able to pick up where they left off. This must be based on the server state, not any locally saved data.
Note that this feature set maps closely to the initial tutorial outlined at https://spacetraders.io/docs/guide (https://spacetraders.io/docs/guide) and each one maps to a specific API end point (purchasing fuel and other goods are the same endpoint).
At first glance this list of features may seem daunting – remember however, the code to handle these features already exists on the web server. All you are doing is providing a front-end to these commands. It is possible to re-use significant amounts of code between features. This also applies to your exam work – it is anticipated that significant amounts of your code from this Task will be re- usable in your exam work, even though it will target different APIs. For this reason, while your design is only assessed through its effect on the user, it will be useful to you to consider your design as you go to ensure maximum reusability (remember the Modularity design goal).
You should include some protections for user input. These come in 2 categories:
Client-side checks. These checks should be limited to the very obvious problems – if numeric input is required, your code should refuse to accept strings that do not parse to numbers. If the user has to select from a list (and you require them to do so by manually entering a value, which is itself not recommended) you should refuse input not present in that list.
You do not need to mirror the API logic in these defensive checks – for example, if the user attempts to buy more than they can afford, you should let them try, do not anticipate these errors.