New Feature - Device Connectivity and Offline Cache


#1

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. :confetti_ball: :partying_face: :tada:

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! :pray: :mega:


#2

My mood. THANK YOU guys

awesome


#3

Hi @sue quick question about the Network Connection Changed event.
By the name it sounds like this is triggered when the network connection changes.
Does this mean it won’t be fired if on application launch the network status is offline?

I’m thinking of a way to detect when the network is offline when the application is launched to show a toast.


#4

Haha I am with you on that lol. :dancer: :fireworks: :boom:


#5

I’m glad you are as enthusiastic about this feature as we are, @seanhoots!

The Network Connection Changed event will fire on the Page Loaded event on the landing page only, as well as any time the network status changes from offline to online or vice versa on any page. Note that it will not trigger on the Page Loaded event of all pages, just the landing page.

The reason it is a page level event rather than a Lifecycle event is so that you can trigger actions to occur in the page context such as changing the color of an icon to represent the network status.

In practice, I have found it useful to have a boolean device variable that I set in the Network Connection Changed event of each page. That way, I can retain the status of the network globally even when I switch pages.

The way I would recommend using it is to set up an if statement in the Network Connection Changed event like this:

Then in the True and False sections of the if, you can set your boolean device variable to true or false plus perform any page level actions you desire (like setting an indicator).

With regard to showing a toast when the network is offline when the application is launched, you can absolutely do that. Just do it in the Network Connection Changed event on the landing page and it will work as you describe.


#6

I just tested it and it works perfectly as expected. Thanks a lot.

This update is one of my favorite :joy:


#7

Some few questions about the Cache.

  1. Is there any limit to the amount of data that can be stored in the cache? Or there is no limit and it depends on the users memory availability?
  2. What is the security policy for the data stored in Cache? Is the data private to the app only? Is it accessible by other apps or the user using some file viewer app?
  3. Can you set the Expiration to a very large number as a way of making your app always use local data for data that may hardly change. For example if i have a list of countries, instead of always fetching it from the database i could fetch it once when the application is first installed and set the expiration date to like 1year (31556952 seconds).

#8

Hi @sue, some minor thing i just obverved.
Was the event data for the Network Connection Changed event changed from isConnectedToNetwork to connected?
From your snapshot above it shows isConnectedToNetwork while in my app (see below ) i see connected.


#9

Can you guys give more details on how the Cache and Fetch option works?
Sue posted above the below

use cache and also fetch new data from the API

I’m not sure i understand the main difference between the Cache and Fetch and Force options.


#10

@seanhoots I got that screen capture from my test environment which has a slightly different set of builds on it. Sorry about that. What you are seeing is correct.


#11

Hey @seanhoots

For technical details about our offline implementation, we use the mobile data Realm behind the scenes to handle all of our offline caching and data storage.

  1. We currently do not cap this, it is handled by the devices storage.
  2. The data is stored to an internal database inside of the app’s sandbox, therefore is subject to the security provided to apps by the device. We do not recommend storing sensitive data like user credentials in the database, use the keychain for that. For data that is sensitive, use ‘None’ for request mode.
  3. You can, however if you do not provide any expiration, the data will live in the database for as long as the app is on the device. Another tip - every time a request is run that utilizes caching, when data is returned from the server and updates the cache, the expiration is reset to always preserve the cache’s freshness.

Hope this helps!


#12

@seanhoots here is a more detailed look at how offline works in Dropsource:

Caching is done at the request level. As a result of that, we utilize caching keys in the following format “requestId + request.path”. So each request with a unique path will be stored in a separate cache. We DO NOT count query parameters as part of the path because in REST, query parameters do not define an endpoint as unique. So for API requests like GET /users/{userId} there will be a separate cache object for each user that has a different userId. With that being said, here is how each mode works:

None - When running a request, the app will always make an API request to the server and will not store any data locally. For API endpoints like authentication, or POSTing data, this is the mode to use.

Cache - When running a request, the app will look in the cache for an individual request. If a cache object exists, it will send the result directly to the view, forgoing running an API request. This behavior will be true for as long as there is a non-expired object in the cache. For data that does not need to always be fresh, this is a great mode to run a request in.

Cache and Fetch - When running a request, the app will look in the cache for an individual request. If a cache object exists, it will send the result directly to the view and asynchronously execute the API request in the background to refresh the cache data. This is different from cache in that it will always run and API request to try and refresh the cached data, regardless if a cache object already exists.

Forced - When running a request, the app will forgo checking the cache for existing data, and will go straight to the server to force a refresh of the cached data. This is primarily used for uses cases like a refresh button to reload a list of data. This is different than Cache and Fetch in that it will not read data from the Cache, it will instead read from the server and refresh the cache.

I hope this helps! We look forward to seeing how everyone utilizes offline in the coming months.

Thanks!


"Add cell" action to dynamic/static table
#13

@Nate, for the Cache and Fetch option, will there be a rebinding event in the view for the updated object (when it comes back from the server)?


"Add cell" action to dynamic/static table
#14

Yes all data bindings will rebind if data successfully returns from the server


"Add cell" action to dynamic/static table
#15

Thanks Nate for the detailed explanation of each option. I get it now. I think you should add this to your documentation somewhere.
I was going to ask the same question Mark asked but you’ve already answered it.


#17

Cheers guys, I’m going to add some of this detail to the info in the help center.