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

[Question] Notification #15

Closed
mainrs opened this issue Jun 23, 2016 · 18 comments
Closed

[Question] Notification #15

mainrs opened this issue Jun 23, 2016 · 18 comments

Comments

@mainrs
Copy link

mainrs commented Jun 23, 2016

Is it somehow possible to notify the user that a new update is available? Like a small Alert in the main application?

@edvin
Copy link
Owner

edvin commented Jun 23, 2016

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?

@mainrs
Copy link
Author

mainrs commented Jun 23, 2016

would a SHA-256 check be enough?
I hope so 😄
I really like this project, it's simple and efficient. There are just one, two things that I would miss though ;)

@edvin
Copy link
Owner

edvin commented Jun 23, 2016

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 :)

@mainrs
Copy link
Author

mainrs commented Jun 23, 2016

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.

@edvin
Copy link
Owner

edvin commented Jun 23, 2016

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.

@mainrs
Copy link
Author

mainrs commented Jun 23, 2016

If you need help or something, I got about 1-2 hours each evening off, can help you out here 😄
Ye, something along those lines would be great ^_^

@edvin
Copy link
Owner

edvin commented Jun 23, 2016

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 :)

@mainrs
Copy link
Author

mainrs commented Jun 23, 2016

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.

Is it (with the current architecture) somehow possible to update the fxlauncher itself?

@edvin
Copy link
Owner

edvin commented Jun 24, 2016

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

@mainrs
Copy link
Author

mainrs commented Jun 24, 2016

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.

@edvin
Copy link
Owner

edvin commented Jun 24, 2016

I can think of two different ways to update the updater, so it's absolutely doable :)

@mainrs
Copy link
Author

mainrs commented Jun 24, 2016

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

@edvin
Copy link
Owner

edvin commented Jun 24, 2016

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.

@edvin
Copy link
Owner

edvin commented Jun 24, 2016

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.

@mainrs
Copy link
Author

mainrs commented Jun 24, 2016

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.
Not sure if something like this is possible on other platforms that windows. Replacing an exe file is quite easy but on osx you normally would try to provide the application as an application bundle. Not sure if it is possible to just replace at runtime.

@pablovilas
Copy link

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.
Thanks.

@mainrs
Copy link
Author

mainrs commented Jun 24, 2016

Sure, why not. Makes sense to me ^^

@edvin
Copy link
Owner

edvin commented Aug 17, 2016

I think these features also fits better in FXLauncher 2.0, so I'll table them for now :)

@edvin edvin closed this as completed Aug 17, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants