Skip to content

App status: improvements maintenance and forced update

Choose a tag to compare

@uatisdeproblem uatisdeproblem released this 02 Oct 12:04
· 38 commits to main since this release

The app status is how we put an app in maintenance, force an update or announce something without a release. This release makes it more dependable. It doesn't change the format of status.json: it only adds to it.

Updated with 8.14.1, which makes it lighter: the status is no longer read every 5 minutes, only when something happens; ideaAppStatusGuard is only for a native app that may force an update; leaving the status page loads the app again on native too; the status file has 10 seconds to answer. The notes below describe 8.14.1.

New features

  • Common. Maintenance and forced update reach whoever is already inside, and let them go. After the first check(), the status is read again when the app becomes visible and when a request to the back-end fails: never on a timer while the user works (until 8.14.0, also every 5 minutes). During a maintenance the page offers "Try again", checks again every 30 seconds, and takes the user back where they were going once it's over, loading the app again (on native too, from 8.14.1).

  • Common. A message for the maintenance, an announcement for every version. Two new keys in status.json, each a string or a map of language to string:

    "maintenanceMessage": { "en": "We'll be back by **15:00 CEST**.", "it": "Torniamo entro le **15:00**." },
    "announcement": "Papaya will be **under maintenance on Saturday**, 14:00–15:00 CEST."

    maintenanceMessage is shown only during a maintenance, to every version. announcement is a notice for every version; a version's own message wins over it.

  • Common. ideaAppStatusGuard, for a native app that may force an update. On the routes, it keeps users on the status page even when they press back or follow a link. A web app doesn't need it: it always runs its latest version, and during a maintenance whoever gets around the status page goes back there when the API refuses their requests.

Behaviour changes for older versions

No code change is required, but two things now happen that didn't before:

  • Every app reads status.json again while it's open, on the events above. It's a small file, so the cost is negligible; check({ watch: false }) turns it off.
  • A status.json without latestVersion now means "the installed version is the latest", instead of undefined.

How to adopt the improved version

  1. Update @idea-ionic/common to 8.13.10 (better: 8.14.1), making sure to update the i18n translations. That's all it takes, with no change to the code: the status reaches the sessions already open, and the page lets users go.

  2. If the back-end closes the API during a maintenance (idea-aws 4.8.0, APP_STATUS_URL): the auth guard, when its requests are refused while the status blocks, must leave the user on the status page instead of sending them to sign in.

    } catch (error) {
      // during a maintenance (the API answers 503) or a forced update, the user stays on the status page
      if (_appStatus.isBlocking(await _appStatus.load())) return false;
      return navigateAndResolve(['auth']);
    }
  3. Only for a native app that may force an update. Add ideaAppStatusGuard to every route except app-status, right after the init guard, so that neither the app's own navigation at start-up nor the back button takes an old version out of the update page. It reads the status already known: no request per navigation.

    import { ideaAppStatusGuard } from '@idea-ionic/common';
    
    { path: 'dashboard', loadChildren: ..., canActivate: [initGuard, ideaAppStatusGuard, authGuard] },
    { path: 'app-status', loadChildren: ..., canActivate: [initGuard] } // the status page keeps only the init guard
  4. If your app adds its own keys to status.json, read them from IDEAAppStatusService.statusFile instead of fetching the file again.

Notes

  • The status page must be registered at app-status, as it has always been.
  • Apps still on the API method (check({ viaApi: true })) shouldn't add the guard: it may run before check(), and it would read the asset instead of the API.
  • An invalid status file, or one that doesn't answer within 10 seconds (from 8.14.1), blocks nobody: it's reported in the console as [IDEA app status] ….
  • See the App status how-to.