B4J Question External or Internal updater?

I think it depends on the nature of the app and the update.

If the app can still function without the update (it is using only local data or can safely ignore new functions / online data) my personal preference would be for the app itself to check if it needs updating when it is started and indicate to the user that a new version is available with an obvious but unobtrusive message. i.e. a status bar message or at most a notification that can be dismissed and the update ignored for now. I have often opened an app to do a quick last minute change to something and have been forced to update it to a new version that was released overnight, this is very frustrating.

If the app uses online data and/or will provide incorrect results without the update then the update obviously needs to be enforced.

I think that running an additional service can be counter productive as the user can turn off the service and not allow it to start automatically.

Hi, thank you for your reply.

I share your idiosyncracy about code that forces you in a given way, assuming it knows your business better than you!

As for the mandatory vs. optional update I'll manage that by the to-do list set on the server. So, being it the checker or the final app, they will know beforehand whether the proposed update is really needed or not.
Generally speaking, my apps contact a remote server to receive updated data and to upload local data (i.e. a form of sync) but if the connection is not available they work off-line using last received config data and gathering and storing any new input.
The external model could be useful, if for any reason, the current version of the app should be not allowed to run.

BTW, I now believe that special ancillary files should be downloaded by their intented app rather than by a global checker, even in the (possible) case where the same file is intended for more than one app. Each one will download its copy; more data traffic, but it sounds cleaner.

I would like to give the following considerations:
From the user's point of view, you have "nice-to-have" updates with new functionalities and updates that you might not be waiting for.

From a security perspective, you do want a bug fix to be replaced immediately by a safe version.

SCRUM can be an effective, flexible way to develop software with which you can roll out a software update several times a day if necessary. Only as a user of software that is developed in this way, you will not be happy with endless series new updates.

With a user with the slogan "busy, busy, busy", there may be a tendency to postpone an update indefinitely and nobody is waiting for work that is lost as a result of an updated update. This very “democratic” approach can of course lead to all sorts of different versions on different devices, which can cause confusion at flex workstations and how you ensure that a bug fix version is running smoothly and does not lead to confusion among users who suddenly have a few skip updates?

In my Windows NT administrator time I tested during startup whether there was a certain file in a certain place. If that was missing, I made an update and placed that particular file at that particular location. The user see a little longer time to start up, but all machines had the same software versions after they were started. And with a hot-fix I could always ask if the user wanted to restart their device before entering a meeting, have lunch or would like to restart their device at another convenient moment. But that was a rarity, because I think that a user should not notice anything about management activities. That is why I ran a large "update" round outside working hours.

Hi, thank you for your reply.
If I understand it correctly, you prefer an always mandatory upgrade (being it external or internal doesn't matter) provided it takes just a few seconds more on start up.
The benefit of a common release between all the machines involved takes precedence over any hurry by the customer.

Unfortunately I have to cope with machines not always able to access the Internet, so at leat two releases of the same app are currently running somewhere.
No problem for those that receives an update. My users can easily wait a few seconds more since they already wait for the sync of data to happen (and a nice video is played meanwhile..ehehe).

Simply the best method is in practice often simply the simplest and clearest method. There is nothing wrong with well-considered offline work. I don't know if security is a big issue for an update, but you could create a background routine that detects going online. You have to think about whether you choose to build in the distinction between a fine-to-detect or mandatory update. When working Off-line you should actually teach the user that restarting a device means that in addition to synchronizing his off-line produced data, his other security software such as anti-virus and various software versions also must be updated in his interest .