Both games and JREs will be "installed" and managed by the launcher in the future.
I believe that both can have a shared interface for the remote resource, that is, the download URL.
I'm not sure about other properties yet, like a checksum for the file. For managed JREs, the checksum will be statically known. For game releases, we can fetch the checksum separately from remote. Probably should also be a Future<String> to express the async nature, or just a String with some IOException? :thinking:
Also start turning the static utility class DownloadUtils into a class that can be instantiated. This should help long-term with testability of the different manager classes, and make it easier to make the timeouts configurable and testable.
How to test
The changes should be a refactoring from the user's point of view.
Ensure that the launcher is working as before.
I've tested this on Windows by downloading a release and starting it.
Contains
Both games and JREs will be "installed" and managed by the launcher in the future.
I believe that both can have a shared interface for the remote resource, that is, the download URL.
I'm not sure about other properties yet, like a checksum for the file. For managed JREs, the checksum will be statically known. For game releases, we can fetch the checksum separately from remote. Probably should also be a
Future<String>to express the async nature, or just aStringwith someIOException? :thinking:Also start turning the static utility class
DownloadUtilsinto a class that can be instantiated. This should help long-term with testability of the different manager classes, and make it easier to make the timeouts configurable and testable.How to test
The changes should be a refactoring from the user's point of view. Ensure that the launcher is working as before.
I've tested this on Windows by downloading a release and starting it.
Outstanding before merging
Nothing.