Hi Junaid, 

D you mean screens that are meant to be used only offline? You can use the OnInitialize and OnReady for those. 

If you mean processing something when a data action fails, you can use the OnAfterFetch of the data action itself.

If you give more details about your use case, I can try to help you more.

You can call a Client Action from a javascript block. 

So you could make an asynchrounous call to the action that executes the processing in either of those event handlers without blocking the screen rendering.

EDIT: 

Actually following my own advice, I'm trying to implement an asynchronous call in the platform, but the screen rendering always gets hanged by the execution of the function I'm trying to execute asynchronously. Maybe someone else can help out with this.

Junaid Ahmed Syed wrote:

For purely offline screens, I think developer shouldn't be implementing Data Actions at all, because as you said - server data is not available. Your workaround in these situations is perfectly valid and something I'm using to overcome these situations as well.

There are other workarounds, but they approach the problem from different angle and may or may not suit your needs:

1. Client function could be used as widget data source, but this imposes some serious limits to data sources, as server actions, client actions which are not functions and local storage aggregates cannot be called from client functions. 
2. Basically this leaves you an option to safeguard your app against communication exceptions on screens where Data Actions are needed. By checking network status at (screen/layout) OnInitialize event action and doing some redirect logic or screen state setup in there is another way to handle these situations. If Data action "Fetch" property is set to "Only on demand" and screen does not try to read any info from DataAction results, I recall there will be no problems. Extra care is of course needed, as any attempt to read will trigger a fetch and communication exception will happen.
3. Another thing you could consider is handling network related errors (CommunicationExceptions) by adding OnException action to your flow and managing the application/screen status (based on network status) from there.