Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: introduce RemoteResource<T> interface #712

Merged
merged 9 commits into from
Jun 22, 2024

Conversation

skaldarnar
Copy link
Member

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 a String with some IOException? 🤔

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.

Outstanding before merging

Nothing.

@skaldarnar skaldarnar added Type: Enhancement New features or noticable improvements. Status: Actionable An issue or task that can immediately be worked on Type: Maintenance Maintenance or chores not adding new features or fixing bugs. labels Nov 26, 2023
/**
* @deprecated Use {@link DownloadUtils#download(RemoteResource, Path, ProgressListener)} instead.
*/
@Deprecated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

am lacking experience here, but the method is private. why deprecating it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure whether it actually has any effect other than your IDE telling you this is deprecated 🤷 I kinda see it as a TODO to replace the call side of this method with what is written in the deprecation note.
That way, I don't change any interfaces now, and can make this change in a follow up PR to keep the PRs smaller.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add a deprecation note to the upper one, too?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was only a single use of that other method, so I just inlined it and removed the method in 482ba65.

@soloturn soloturn merged commit 13f4108 into master Jun 22, 2024
3 checks passed
@soloturn soloturn deleted the topic/interface-for-remote-resource branch June 22, 2024 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Actionable An issue or task that can immediately be worked on Type: Enhancement New features or noticable improvements. Type: Maintenance Maintenance or chores not adding new features or fixing bugs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants