Desktop: Seamless-Updates - fixing bugs

[AliceHincu]

This PR fixes multiple issues:

• locking/unlocking mechanism
  • While the new version silently downloads in the background, I locked the update process so that the user can't trigger manually another check. If the temporary new version is downloaded and then the user triggers a manual check, the temporary file is already locked by the OS so the app throws an error and closes (the user won't have permission to write to it two times at the same time). This mechanism handles this situation.
• managing the remote process in the update service
  • The app threw an error if I set the flags to true from Options, closed the app (but not quit from the system tray), and then triggered manual checks. By making the initialization of the service not dependent on the flag, and only periodically checking for updates based on the flag, I solved this issue
• notify if the update check is already in progress
  • If the user triggers a manual check while the periodical check downloads the update in the background, the user will now be informed that this operation is already in progress
• notification message triggered multiple times
  • Before, if I manually checked multiple times for updates, only the first time the notification was shown. Now it can be shown multiple times. This happened because apparently the notification doesn't trigger "Dismiss" event when closing after 5 seconds.

[laurent22]

We talked about this before - we can't have this enabled by default

[AliceHincu]

This flag is not the flag for my service.

https://github.com/laurent22/joplin/pull/11079/files

I set it to false in the last PR, and I switched it back to true here (like how it was before). I also hid it.

Would you like to have both flags set to false ? In this case, when the user triggers a manual check, what should happen ?

[laurent22]

Ok I missed you switched that off - but why did you do this? That's exactly what we did not want to happen, we talked about it and the whole reason why we have an extra feature flag for you. Now everybody who got this version will no longer be notified of new versions. I'm going to turn that back on and create another prerelease.

[laurent22]

Likewise we can't have this running if the user didn't enable the feature. That's the purpose of this flag, to enable it in a controlled way. I don't really understand the logic here, why we need to run this if the flag is not on? If the user needs to restart the app after enabling the flag, we just document it. The flag is a temporary, advanced feature anyway

[AliceHincu]

In the explanation below, by saying "default flag" I refer to the flag previously used for auto updates, together with the existing logic from before. By saying "implemented flag", I refer to the flag I added for my service.

Explanation: let's say the user has the default flag set to true and the implemented flag set to false. If he/she goes to Options to set the implemented flag to true, and then goes back into the application to manually check for an update without closing or quitting the app, the above error will be shown, because the service was never initialized in the first place (since the implemented flag was initially false).

I even tried to add this check so we could avoid this situation:
if (typeof this.updaterService_ != 'undefined' && this.updaterService_ && this.updaterService_?.checkForUpdates)
Unfortunately it still throws the error.

[laurent22]

Not sure about the technical details, but it should be possible to turn on your feature flag and it only uses your new updater service, or turn it off and it only uses the old method. The fact that something is not working when one of the flag is on or off means some logic is missing somewhere