4/30/2021 Fortnightly Task 3 – API Fortnightly Task 3 – API
Due May 16 by 23:59 Points 2
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.
https://canvas.sydney.edu.au/courses/31635/assignments/294923 2/4
4/30/2021 Fortnightly Task 3 – API
Server-side checks. These checks occur automatically on the server, and include issues like the purchase error described above. You do not need to pre-empt these errors, but you do need to detect them from the server response and react accordingly – i.e., tell the user what the error was and ensure the UI view does not update incorrectly.
Running the application
Your application should provide a main method access point through a mainClass named SpaceTraderApp, which you should include in your build.gradle file using the application plugin detailed here: https://docs.gradle.org/current/userguide/application_plugin.html (https://docs.gradle.org/current/userguide/application_plugin.html) . This main method should take in a single keyword argument that is either ‘online’ or ‘offline’, indicating whether the true web API is used, or your dummy version. An example command line execution will look like
gradle run –args=”offline”
Marking Guide
2/2 – Your code compiles and runs successfully. Each of the required features is available and works properly. You have successfully dummied the API so it can be run without hitting the real web API. There is sufficient error handling that a user entering incorrect data does not cause the application to break or crash.
1/2 – Your code compiles and runs successfully. A user can make it through to at least purchasing a ship successfully. You have successfully dummied the API so it can be run without hitting the real web API up to at least purchasing a ship successfully. There is sufficient error handling that any breaking behaviour or crashes are rare.
0/2 – Your code does not compile or run. You do not meet either the 2/2 or 1/2 requirements. Submission
Your work should be submitted through https://github.sydney.edu.au (https://github.sydney.edu.au) in a repository named SCD2_2021_T3, with all the usual collaborators. Your submission should be in the form of a gradle project that can be built and run from the command line. Include a readme file indicating to your marker how to access each of the required features your submission provides.
Academic honesty
While the University is aware that the vast majority of students and staff act ethically and honestly, it is opposed to and will not tolerate academic dishonesty or plagiarism and will treat all allegations of dishonesty seriously.
https://canvas.sydney.edu.au/courses/31635/assignments/294923 3/4
4/30/2021 Fortnightly Task 3 – API
Further information on academic honesty, academic dishonesty, and the resources available to all students can be found on the academic integrity pages on the current students website: https://sydney.edu.au/students/academic-integrity.html (https://sydney.edu.au/students/academic- integrity.html) .
Further information for on research integrity and ethics for postgraduate research students and students undertaking research-focussed coursework such as Honours and capstone research projects can be also be found on the current students website: https://sydney.edu.au/students/research-integrity-ethics.html (https://sydney.edu.au/students/research-integrity-ethics.html) .
Compliance statement
In submitting this work, I acknowledge I have understood the following:
I have read and understood the University of Sydney’s Academic Honesty in Coursework Policy2015(https://sydney.edu.au/policies/showdoc.aspx?recnum=PDOC2012/254&RendNum=0) . The work is substantially my own and where any parts of this work are not my own I have indicated this by acknowledging the source of those parts of the work and enclosed any quoted text in quotation marks.
The work has not previously been submitted in part or in full for assessment in another unit unless I have been given permission by my unit of study coordinator to do so.
The work will be submitted to similarity detection software (Turnitin) and a copy of the work will be retained in Turnitin’s paper repository for future similarity checking. Note: work submitted by postgraduate research students for research purposes is not added to Turnitin’s paper repository. Engaging in plagiarism or academic dishonesty in coursework will, if detected, lead to the University commencing proceedings under the Academic Honesty in Coursework Policy 2015 (https://sydney.edu.au/policies/showdoc.aspx?recnum=PDOC2012/254&RendNum=0) and the Academic Honesty Procedures 2016 (http://sydney.edu.au/policies/default.aspx? mode=glossary&word=Academic+honesty) .
Engaging in plagiarism or academic dishonesty in research-focussed work will lead to the University commencing proceedings under the Research Code of Conduct 2013 (https://sydney.edu.au/policies/showdoc.aspx?recnum=PDOC2013/321&RendNum=0) and the Academic Honesty Procedures 2016 (http://sydney.edu.au/policies/default.aspx? mode=glossary&word=Academic+honesty) .
Engaging another person to complete part or all of the submitted work will, if detected, lead to the University commencing proceedings against me for potential student misconduct under the University of Sydney (Student Discipline) Rule 2016 (http://sydney.edu.au/policies/showdoc.aspx?recnum=PDOC2017/441&RendNum=0) .
https://canvas.sydney.edu.au/courses/31635/assignments/294923 4/4