B4J Question External or Internal updater?

[udg]

Hi all,
it's a couple of days that I'm considering pros and cons about two alternate strategies on how to keep a B4J UI app updated.
Please contribute with your experiences and observations. TIA.

External
A different app, let's call it a checker, has as its main task the checking for new versions of one or more of the locally installed apps. It will (could) check for ancillary files too (like images, videos, whatever) specific for each app. I'm considering to auto-launch by a batch file at PC boot just the checker app . On its exit, the same batch file will decide what to do next based on the checker's exit code (ExitApplication2).
If need arises, the checker could be updated to an UI-based app so to interact with the user (a simple use case could be: do you want to update app X now? It's not a mandatory update).

Internal
Each application will sport its own "checker". On boot, the OS will launch the app (or apps) and each one will check its own status against a server (LAN o remote) and update itself (automatically or based on user input). Once updated the app should terminate and start itself again.

A third way could be an app that uses jshell to wait for the execution of an external checker; the app will then operate as for the Internal options above. The advantage could be to separate the checking code from the main app.

Note: all the above is just for updating apps' code. Each app knows how to alter its sqlite db (versioning) , if needed.

udg

 

[stevel05]

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.

 

[udg]

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.

 

[MicroDrie]

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.

 

[udg]

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

 

[MicroDrie]

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 .