As of April 12th, you must go to Progress SupportLink to create new support cases or to access existing cases. Please, bookmark the SupportLink URL and use the new portal to contact the support team.
a) Don't want to use too much data (for a mobile user) - and latency is better - when pulls from offline rather than Kinvey data center
b) Data on the server end changes every so often, and this needs to go onto the mobile app, maybe on a 2 week cache (and the sync functions seem to only sync mobile changes to server..... not server changes to mobile
PERFECT SOLUTION
To be able to have a setting, on the query, extending "offline" to something like, pull from offline if the data is less than 2 weeks old, otherwise fallback to online (2 weeks to be configurable per query, perhaps)
CURRENT HACKED SOLUTIONS
Three approaches (none of which quite works!)
a) To add to the query an additional notEqualTo - that updates only once every 2 weeks (on a rolling basis) - so that the query would be exactly repeated if requested multiple times, with the repeats coming from cache but the first one coming from Kinvey data centre, during a certain time frame. Problem - when pulling from local cache, seems you are running the query locally against a local data cache, NOT caching the query and the reply....... so by controlling the similarity of the query, this isn't solving the problem
b) Destroy the cache every 2 weeks - problem - with offline:true, fallback:true, refresh:true - when the cache is destroyed, if the queries are set to offline, they don't seem to reply. There has to be an offline:false query first...... to instigate the cache. So this isn't quite it!
c) Run primarily in offline:true, fallback:true, refresh:true...... BUT (while user is doing other things) run a offline:false, fallback:true refresh:true that is the same, so the local cache is updated
Sequence
1) offline: true, fallback:true, refresh: true .... cache saved to local
2) Data changes on server
3) offline: false, fallback:true, refresh: true .... changed data DOES show in app
4) offline: true, fallback:true, refresh: true .... data from 1 actually shows (when I would expect data from 3)
My expectation is that an offline:false, with refresh:true should set the local cache just like an offline:true, refresh:true does
Phonegap library 1.1.3
SUMMARY
a) Would love my perfect solution! (or any other way of doing this)
b) Or any of my 3 hacked approaches to actually work (!). 2nd and 3rd hacked solutions look like bugs (or at least where my expectation doesn't match yours)
The sequence you explained - is that all in one session (no closing the app)? I assume you are going between offline status via Kinvey.Sync.online/offline.
We found the best way to control and ensure the Sync is done properly is to always initialize the app with a sync config set to enabled, but in offline mode. Then (before querying any data collections) manually trigger online mode via Kinvey.Sync.online, depending on network status or however you want to determine this. This ensures that any user changed data is synced and used, as opposed to grabbing remote version on initialize.
Also, make sure you are setting your conflict resolutions methods accordingly. For example, when you manually go online (and sync), pass the online method the conflict resolution method. I think this might be the factor you are missing and why it does not appear to be syncing (in reality, it's throwing away the changes and defaulting to the wrong conflict resolution). For example:
```
var promise = Kinvey.Sync.online({
conflict: Kinvey.Sync.clientAlwaysWins
});
```
You can always implement your #1 perfect solution yourself I believe. Simply keep a manual localstore (not necessarily via Kinvey services at all) that includes collection names and "last updated" date. Check the timestamps on this before running a query, if it's past two weeks set an option in that specific query to offline=false.
M
Mark
said
over 9 years ago
First, I tried the 4 sequence steps you mentioned, and step 4) does return data retrieved in 3) for me. If you have a short snippet which reproduces the behavior you are seeing, I’d be happy to see if there’s anything going wrong.
We are adding a TTL mechanism to the offline database, which will be part of the next library release. This should enable your "perfect solution".
A
A B
said
over 9 years ago
Thank you! I shall await the next release and then have a proper play then.
M
Mark
said
over 9 years ago
The [1.1.5 release](http://devcenter.kinvey.com/downloads) contains a [maxAge](http://devcenter.kinvey.com/guides/caching-offline#CacheControl) feature. Let me know any feedback you might have.
A
A B
said
over 9 years ago
The new update in 1.1.5 is great. Thank you.
However, I am not quite sure if I am using it right
a) For individual entities - I have to request
offline:true,
maxAge:3600
This then will pull from offline and refresh if older than 3600. (But this is where I am confused, as your documents, in the examples, don't have the offline:true usage as well)
b) For queries with multiple results...... I can't work out whether this is even applicable. I (now) know that if you do offline:true it will just search the objects that are held locally. Hence if you don't happen to have any, you don't get any data.
So this is a great step forward - but also I am wondering about multi-entity results.... and if anything can be done for them.
M
Mark
said
over 9 years ago
The offline flag indeed needs to be present - I updated the docs.
The maxAge is verified on a per-object basis, so for multi-object results, if one object is out-of-date, the entire query will go over the network. The consequence of this approach is that, if the query yields 0 objects locally, it will not go over the network.
One solution would be to always execute the network request if the local request resulted in 0 objects, but I’m not sure if that’s the best approach.
A B
a) Don't want to use too much data (for a mobile user) - and latency is better - when pulls from offline rather than Kinvey data center
b) Data on the server end changes every so often, and this needs to go onto the mobile app, maybe on a 2 week cache (and the sync functions seem to only sync mobile changes to server..... not server changes to mobile
PERFECT SOLUTION
To be able to have a setting, on the query, extending "offline" to something like, pull from offline if the data is less than 2 weeks old, otherwise fallback to online (2 weeks to be configurable per query, perhaps)
CURRENT HACKED SOLUTIONS
Three approaches (none of which quite works!)
a) To add to the query an additional notEqualTo - that updates only once every 2 weeks (on a rolling basis) - so that the query would be exactly repeated if requested multiple times, with the repeats coming from cache but the first one coming from Kinvey data centre, during a certain time frame. Problem - when pulling from local cache, seems you are running the query locally against a local data cache, NOT caching the query and the reply....... so by controlling the similarity of the query, this isn't solving the problem
b) Destroy the cache every 2 weeks - problem - with offline:true, fallback:true, refresh:true - when the cache is destroyed, if the queries are set to offline, they don't seem to reply. There has to be an offline:false query first...... to instigate the cache. So this isn't quite it!
c) Run primarily in offline:true, fallback:true, refresh:true...... BUT (while user is doing other things) run a offline:false, fallback:true refresh:true that is the same, so the local cache is updated
Sequence
1) offline: true, fallback:true, refresh: true .... cache saved to local
2) Data changes on server
3) offline: false, fallback:true, refresh: true .... changed data DOES show in app
4) offline: true, fallback:true, refresh: true .... data from 1 actually shows (when I would expect data from 3)
My expectation is that an offline:false, with refresh:true should set the local cache just like an offline:true, refresh:true does
Phonegap library 1.1.3
SUMMARY
a) Would love my perfect solution! (or any other way of doing this)
b) Or any of my 3 hacked approaches to actually work (!). 2nd and 3rd hacked solutions look like bugs (or at least where my expectation doesn't match yours)
Thanks!