-
Notifications
You must be signed in to change notification settings - Fork 109
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
[Question] Notification #15
Comments
This can be done quite easily, but it's not a built in feature of FXLauncher right now. Basically what you'd have to do, is to run a Thread on a Timer that checks if the app.xml manifest you have locally is different from the remote file. If it differs you can pop up a dialog. Do you know how to write this yourself? |
would a SHA-256 check be enough? |
Yeah, that would probably do, but you could also just read the whole string into memory, since it's not big at all. I'll probably add something like this to the project later :) |
Did you ever thought about a rollback function? Like, if there is some huge bug in the application, a user can just download the older version of it till the developer gets the bugs fixed. |
No, not really. Absolutely possible to do, and at some point I would like to create a better architecture and make it trivial to support something like that, maybe even with an UI to keep certain versions and choose what version to use at startup etc. |
If you need help or something, I got about 1-2 hours each evening off, can help you out here 😄 |
That's very interesting. Right now I'm focusing on finishing the documentation for TornadoFX. After that I might take you up on that offer :) |
Is it (with the current architecture) somehow possible to update the fxlauncher itself? |
No, that requires some custom code now. This is another thing that should be fixed :) You have touched almost all the pain points I'm aware of with the current architecture :) hehe |
Haha 😂 wasn't my attention. Looks like the "update the updater" problem is mine of those problems that every update framework is facing. Can't really think of a solution for this. |
I can think of two different ways to update the updater, so it's absolutely doable :) |
Mind sharing them? The only one that came into my mind would be a patcher class that looks if the launcher has been changed in the repi |
Theory number one: A thin wrapper who's only mission is to check if a new version of the launcher is available. If it is, the new version is downloaded and then loaded into the same JVM, where it performs the launcher tasks that fxlauncher.jar performs today. |
Theory number two: The launcher detects a new version of itself, downloads it to a separate location and then moves the new file in place over itself, possibly using a shutdown hook. This might be problematic on Windows, where the file can't be overwritten while in use. In a native installer however, the native part can handle this before the app launches. That's also possible for theory number one - a native launcher does that part. I would like to create native stumps for each major platform to handle this, and even possibly download the selected JDK, so you can distribute a very small binary that handles everything. |
Native launchers would be nice to have, so your calling chain would be (from a clean installation): native launcher - > Jre - > launcher jar - > program. Meaning that the native launcher could get updated by the jar launcher. |
Hello, I'm interested too about the autoupdate of the updater. May I open a new issue only for that and copy relevant comments?, so we leave this only for notification topic. |
Sure, why not. Makes sense to me ^^ |
I think these features also fits better in FXLauncher 2.0, so I'll table them for now :) |
Is it somehow possible to notify the user that a new update is available? Like a small Alert in the main application?
The text was updated successfully, but these errors were encountered: