Updater/Autopatcher for the launcher

[vScherb]

Adding a Updater/Autopatcher will help users get the newer Verisons.

The problem with reseted configs should be handled by the updater.

For the beginning could be a notification (on startup) with a little summary (what has changed, whats fixed, whats new).

[GerRudi]

Had this in mind already as well, should definitely be implemented!

[vScherb]

After a call, @GerRudi and I have decided to add a launcher and an updater to the SimpleR project.

I've made a sequence of the two types, in which the launcher can operate:

• Regular launch, when the play button was pressed
• Autolaunch, when the autolaunch checkbox was selected (the time will be configurable in the settings)
• Update, when the update button was pressed (autolaunch on hold)

Created with Draw.io

Launcher UI

The Updater will be technical and will provide no GUI. For the Launcher will be a GUI, preferred as MetroGUI, the launcher has a few UI controls to begin with.

• Play button for closing it and starting up SimpleR
• Update button, disabled when no update pending, will invoke the procedure as described above
• 'Autostart' a checkbox which will enable/disable the autostart opation
• Countdown timer which will count down the time before the autostart begins
• Optional the Changelog for the current version (maybe the version wich is in progress to download)
• Progressbar which will indicate the update and its download (default hidden)
• Static links or text for the user to help him (or some often used links in general)

Update scenario

The current problem with updates is, that usually the settings files have to be deleted and the settings need to be reapplied.

The downloaded Updater will hold a migration method for each version update, within the major release.

Example scenario: My local SimpleR is on verison 1.2.0 and the updater suggests me to get to version 1.2.4. When the Updater is downloaded, it contains at least the following methods which will be invoked in its chronical order:

• up1_2_0to_1_2_1
• ...
• up1_2_3to1_2_4 Each method will transform the settings and other files to the new format.

As described in the scenario will this have a good impact on the experience for the user. Additionally the Updater format can change and do more in addition to just update the assemblies provided for the user.

Technical findings

To get the latest verison or the assemblies/other packages of the releases will it be necessary to receive the releases from GitHub. For this I've found in my evaluation tests a helpful resource GitHub API Documentation.

[GerRudi]

Very nice work!

Here's a first UI-Mockup of the launcher:

[vScherb]

This looks very nice. Could we move the timer in the top center with a bigger font? This is a feature which would require immediate attention from the user.

[vScherb]

For the displayed changelog, the latest CHANGELOG.md of the repository will be used.

The md file as translated html can be received directly from GitHub with the following request:

GET /repos/GerRudi/SimpleR-RotMG/contents/CHANGELOG.md HTTP/1.1
Host: api.github.com
Accept: application/vnd.github.v3.html

[vScherb]

The design of the launcher has a little flaw in it @GerRudi . I just realised that the Launcher can't be updated by the Updater since the Launcher is opened while the Updater runs and thus the Launcher needs to be closed while the updater runs.

To implement a progres bar in the Launcher when an updates processes was challenging to implement. Especially difficult is the inter process communication in Autoit. I saw no simple way of doing this in a way which allowes every reader to follow easily.

With these aspects in mind I redesigned the solution.

Created with Draw.io

While the Launcher downlaods the binaries from GitHub a progressbar can display the download status. For large updates or when a user has a poor internet connection. (mentioned by @GerRudi )

When the Launcher is closed while the Updater displays a simple GUI which will just hold a progressbar (and maybe an cancel button).

This addresses the two problems described above. Now the Lauchner can updated from inside of the Updater and the progressbar will be displayed with the real progress value of the update.

The other approaches to the solution will follow the origin idea.

A Wiki entry will be created for the technical overview of the launcher. As this concept is further developed this issue will receive updates until it is merged into dev. Beyond that the changes to the technical design will be kept in the Wiki entry.