Is This Correct Offline Exception Handling?
Stable Version 1.0.0
Published on 11 Mar by 
Created on 11 Mar
Details
I am listing a series of scenarios with what I think is rather unexpected behavior when a mobile app loses connectivity. Please let me know what you think, is this all normal or reflects a Platform issue?
Read More

Listing a few scenarios where exception handling works different that I expected:

  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.

Reviews (0)
Category
Samples & How-tos
Support Options
This component is not supported by OutSystems. You may use the discussion forums to leave suggestions or obtain best-effort support from the community, including from Adrian who created this component.
Dependencies
See all 1 dependencies
Requirements
Platform
10.0.0.402
Database
All
Stack
All
Team
Component Consumers
Is This Correct Offline Exception Handling? has no consumers.
Weekly Downloads 
Related Components
OutSystems UI Mobile
OutSystems R&D
Create amazing native mobile applications using this fully integrated UI framework for OutSystems, with dozens of UI patterns ready to use.
7306
Field Services Mobile
Field Services Team
Sample mobile app to support telecom technicians in performing field services.It’s specially designed for iPads, with an iOS10-like look and feel. Works completely offline, as it allows the technician to perform all tasks offline and synchronizes all data when connected. Uses mobile plugins to integrate location and barcode scanning with the device. This sample app can be integrated with your existing systems and be fully customized to your specific company needs in a matter of days or weeks.
1449
Silk UI Responsive Sample App
Labs
Functional fully-responsive application built with the Dublin template and Silk UI patterns, visit silkui.outsystems.com for more information.
1719
More from Adrian
OneClickCleanup
Adrian
This application provides a simple yet aggressive removal of the massive amounts of useless data on your Cloud Personal Environment. It may work on non cloud environments but has not been tested outside a Cloud Personal Environment. I used LogsManagement and DBCleaner for inspiration, many thanks to Carlos Alfaro the author of LogsManagement (http://www.outsystems.com/forge/component/1195/logs-management/) and to Acácio Porta Nova the author of DBCleaner (http://www.outsystems.com/forge/423/)
330
Glossary Guru
Adrian
An Enterprise Glossary Application with Specifications Management capabilities, advanced import/export capabilities and synchronization to/from Enterprise Architect and JIRA. 
RESTCacheHowTo
Adrian
A mobile app with offline cache using REST services. Local app cache is used when: - there is no connection to the server; - there is an error retrieving information from the server; Server-side cache is used when: - there is a timeout retrieving information via REST - there is an error retrieving information via REST - call throttling dictates cache should be used instead of the REST api. Server cache throttling allows one call every 15 seconds. Example on how to send error codes via REST and handle REST errors.