Hello everyone!
We’re delighted today to release a significant new feature for Dropsource - the option to save API request data to the local cache, and to detect changes in device connectivity. This will provide the ability to manage gaps in the user device network connection and to control the frequency with which your app makes requests to your backend. 
When you add a Run API Request action to your projects, you’ll now see two additional settings:
- Request Mode - there are four options here, you can opt not to use cache at all, use cache if any is available, use cache and also fetch new data from the API, or force the cache to update with new data.
- Cache Expiration Seconds - this is the number of seconds until your cached request data expires and is considered invalid, you only need to enter a value here if you’re using a cached mode.
When your Run API Request actions execute, if valid cache is available and you have a cache mode selected, your bindings (any displayed response fields or actions using response fields in API events) will initially update from the cached data. A key advantage here is that if the API response is not received straight away, your app still has data to show the user in the meantime.
More detail in our help center:
Your existing actions will default to not using a cache option, with (none) selected for the mode, but you can of course edit that any time you like.
A good way to gain an intuitive sense of when these modes fetch new data vs when they use cached data is to open the network log and trigger your requests while watching what’s happening in the network traffic.
You’ll also find a new event at the page level of your apps - this lets you detect and respond to changes in network connectivity.
You can use the Event Data in actions added here to detect whether or not the device is currently connected and tailor your processing to that status.
Although today’s release is a huge improvement in the available options for managing your dynamic data, we are not quite finished with this area of functionality and will be adding more control over network connectivity management in the next few weeks.
Hopefully this is welcome news to those of you who have struggled with connectivity challenges in your apps in the past. This was a complex feature to implement but we’ve tried to keep it as low barrier as possible from the user perspective. I’d love to hear any potential uses of this you’re thinking of, or feedback on how you find it when you try it out in your projects! 
