[Is This Correct Offline Exception Handling?] Offline Mobile App Exception Handling

[Is This Correct Offline Exception Handling?] Offline Mobile App Exception Handling

  
Forge Component
(0)
Published on 11 Mar by Adrian
0 votes
Published on 11 Mar by Adrian

Please take a look at the scenarios I listed in this app and confirm this is correct behavior:


  1. When using an aggregate to get data, if the app is offline, the aggregate will generate a CommunicationException. It seems it is not possible to catch this exception in the screen in order to show an alternate content, instead the Exception propagates to the Flow where the screen is contained.
  2. Using a DataAction with an aggregate inside to get data and an Exception handler next to the aggregate. If the app is offline, the aggregate will generate a CommunicationException and I expect the Exception Handler to catch it so I can show an alternate content. Instead the Exception propagates to the Flow where the screen is contained. Is this normal? 

  3. Using a DataAction with a ServerAction inside to get data and an Exception handler next to the ServerAction. If the app is offline, the ServerAction will generate a CommunicationException and I expect the Exception Handler to catch it so I can show an alternate content. Instead the Exception propagates to the Flow where the screen is contained. Is this normal?

  4. Using a Button calling a ClientAction with a ServerAction inside to get data and an Exception handler next to the ServerAction. If the app is offline, the ServerAction will generate a CommunicationException and the Exception Handler will catch it so I can show an alternate content. The Exception does not propagate to the Flow where the screen is contained.

Hello Adrian,

There is a built-in detection of exceptions. First, you initiate sync in one of the screens and create an action (handler) for the layout of the same screen, an action that reacts to the trigger from the OnSynError event. The handlers are defined on the app level in Common\Layout, but it makes more sense to listen for the events on the individual screens rather than globally (one of the gotchas).

If you don't start sync automatically, as defined in offline sync configuration, make sure you call the sync by TriggerOfflineDataSync. This ensures the layout events fire off when needed.

You can also detect the network change independently from sync, by using NetworkStatusChanged.

The above info if from the Sync Framework Reference. More details we give in Implementing Offline Sync, which covers some of the questions from your post.

I hope this helps.

Hi Romeo,


Thanks for your answer, but I'm afraid my question was not clear enough: I am referring to exception handling scenarios when app loses connectivity and errors are triggered as result of user actions (navigating to a screen clicking on a button), not exceptions caused by the built-in offline sync. Maybe it helps if you see the code https://www.outsystems.com/forge/component/3407/is-this-correct-offline-exception-handling/ , I would appreciate your opinion.


Kind regards,


Adrian

Hi Adrian,

Apologies for the late reply. I'll have a look and get back to you.

Romeo Mlinar wrote:

Hi Adrian,

Apologies for the late reply. I'll have a look and get back to you.

No problem, let me know what you think!


Solution

Hi again. The best way to handle exceptions depends on the use case (it's not the same whether it's database transaction or data fetching), maybe some other users can chime in...? However, you can add exceptions just like you did. Better even, prevent the action by first checking connectivity status by using the GetNetworkStatus() function. NetworkStatusChanged "listens" for the change of the network, but it is not designed to help in cases where the action you want to perform is bound to a button that user has to press and the button is always enabled.

Here are more generic pages about about exceptions and how to handle exceptions. Checking for online and offline status, and adapting to the outcomes, is introduced in this tutorial.

You mobile app does not seem to have any local entities and fetches data directly from the server. That is a serious performance issue. I assume this is intentional for the purpose of testing, since the apps are designed to work with their local storage - which is then synced in the background, and for which you can use exceptions listed above.

I hope this helps.

Solution