Gmail recently supported CONDSTORE CAPABILITY and which gives the feasibility of getting the flag changes since last sync.
Command for fetching changes:
. FETCH 1:* FLAGS (CHANGEDSINCE modseq)
Above command works nice if there are only few changes since last sync but it is not going to work in case of more number of changes since last sync. suppose client is not synced to Gmail server for long time. Here when I request for the changes since last sync then Gmail throws the huge response which my IMAP c-client is unable to process it.
Is there any page wise request for changes with CHANGEDSINCE. I know that there is one solution to fetch chunk wise like below, but it introduces lot of other manipulations which I don't want to do.
. FETCH 1:1000 FLAGS (CHANGEDSINCE modseq)
Can any one help me to solve this issue.
Related
It seems that all examples from Firebase suggest reloading the Remote Config in didFinishLaunching. It looks like a great idea, BUT I see an issue with it. When I run this setup in the simulator, the first fetch arrives with the default values set in the console. Seems reasonable, but the problem is that I have a running A/B testing experiment — actually, several of them. And I do see that on the second launch, I receive new values coming from those experiments.
The experiments target all users of my app, and it worries me that from the first launch, I do not receive those values. In a real-world, Firebase will cache the obtained values for 12 hours. However, as the docs do not mention when a user is counted towards a particular variant in my experiment, I worry that for these 12 hours some of my users will be attributed to non-default modification even though their app does not know that they should receive a non-default experience.
Another issue which I have is the fact that for Remote Config fetch to execute in didFinishLaunching, the app needs to be terminated. What if my users use it regularly and the system doesn't kill it? It means that they may never receive updated config values.
My question boils down to these:
Isn't it better to reload the Remote Config in didBecomeActive?
When does Firebase attribute a user to a particular variant in my A/B test? Does it happen silently at some point in app lifecycle, or do they make sure that it only happens when my user received corresponding Remote Config values? It may be a silly question as it SHOULD be obvious that a user should only be counted if they received new values, but the docs do not mention this.
Is there a way to reload Remote Config and be confident that I
receive the latest values, taking all ongoing A/B testing
experiments into account? Imagine if I want to run a test to determine the ideal price point for my in-app purchase. I would want to reload the Remote Config and load all the latest values before I fetch my in-app products. I wouldn't want to receive default values on the first launch, present my store screen with low price level to user, only to load a more expensive version on the second launch when new values arrive from Remote Config.
It alls comes down to the criteria of your A/B test. A user will not be able to receive A/B variants UNTIL it satisfies all the test requirements. You can refetch these values at a point in your app that you know the user will have satisfied these requirements.
You can use the DebugView to see whether a specific A/B test has been activate for a user.
I'm getting the following error when calling /delta:
resyncApplyDifferences: Resync required. Replace any local items with the server's version (including deletes) if you're sure that the service was up to date with your local changes when you last sync'd. Upload any local changes that the server doesn't know about.
What it's asking is for seems quite extreme, do I need to wipe out all the items I have and replace them with the server version? I know that the current sync state is fine so is there any way to bypass this error?
Also what's triggering this message? Is there any way to avoid it in the future?
The error content here sounds a bit more severe that it really is. Basically it's saying there is an issue with the delta token and the service can no longer determine the changes to the Drive since your last poll.
If you're 100% sure there are no changes, you can simply reset by requesting a /delta without a token and starting over. If you're not 100% sure, you can compare that fresh /delta with your local files and re-apply any changes required (upload local files missing from the drive, delete files removed from the drive, etc).
I wanted to ask for the best solution in synchronizing large amounts of data between the local data storage and a database. (Offline and Online synchronization)
let's say i have two tables and these tables have customers.
Now if i change some data e.g name for the customer, i have to send this to the server before i can pull the server side update, otherwise there would be a conflict.
Let's image the app is offline and has no internet connection so all the changes are made locally.
What i have been doing up till now is save the initial data pull locally and set queue states for the changes. If i change the name for the customer i would set the customer queue state to AWAITING and once the application gets internet and is back online, i would run a query and get all customers that have queue state AWAITING and send that to the database for synchronization, before i can do a data pull.
I believe this model is called Eventual consistency which i think is not very good, and wonder if there is a better way to do this.
I had a different idea where i would create some Queue where every change is stored in JSON and once the app gets internet the queue would be run and all of these API calls would be sent, but this would work weirdly if let's say i change the customers name from John to Matt, then back from Matt to John, and at this point 2 new api calls would be added to the queue. First where i change to Matt and next where i change back to John, which is what we started with and is therefor not needed, but these changes would be very hard to keep track of, and as it is already now it feels like the synchronization is very unstable.
Do you guys know any better approaches for synchronization between (Offline and Online) local changes and the serverside database?
I build an app that is able to store OData offline by using SAP Kapsel Plugins.
More or less it's the same as generated by WEB ID or similer to the apps in this example: https://blogs.sap.com/2017/01/24/getting-started-with-kapsel-part-10-offline-odatasp13/
Now I am at the point to check the error resolution potential. I created a sync conflict (chaning data on the server after the offline database was stored and changed something on the app and started a flush).
As mentioned in the documentation I can see the error in ErrorArchive and could also see some details. But what I am missing is the information of the "current" data on the database.
In the error details I can just see the data on the device but not the data changed on the server.
For example:
Device is loading some names into offline store
Device is offline
User A is changing some names
User B is changing one of this names directly online
User A is online again and starts a sync
User A is now informend about the entity that was changed BUT:
not the content user B entered
I just see the "offline" data.
Is there a solution to see the "current" and the "offline" one in a kind of compare view?
Please also note that the server communication is done by the Kapsel Plugin and not with normal AJAX calls. This could be an alternative but I am wondering if there is no smarter way supported by the API?
Meanwhile I figured out how to load the online data (manually).
This could be done by switching http handler back to normal one.
sap.OData.removeHttpClient();
sap.OData.applyHttpClient();
Anyhow this does not look like a proper solution and I also have the issue with the conflict log itself. It must be deleted before any refresh could be applied.
I could not find any proper documentation for that. Also ETag handling is hardly described in SAPUI5 and SAP Kapsel documentation.
This question is a really tricky one, due to its implications. I understand that you are simulating a synchronization error due to concurrent modification, and want to know if there is a way for the client to obtain the "current" server state in order to give the user a means to compare the local and server state.
First, let me give you the short answer: No, there is no way for the client to see the current server state "for reference" via the Offline APIs when there are synchronization errors. Doing an online query as outlined above might work, but it certainly is a bad idea.
Now for the longer answer, which explains why this is not necessarily a defect and why I said there are quite some implications to the answer.
Types of Synchronization Errors
We distinguish a number of synchronization errors, and in this context, we are clearly dealing with business-related issues. There are two subtypes here: Those that the user can correct, e.g. validation errors, and those that are issues in the business process itself.
If the user violates the input range, e.g. by putting a negative price for a product, the server would reply with the corresponding message: "-1 is not a valid input value for 'Price'". You, as a developer, can display such messages to the user from the error archive, and the ensuing fix is indeed a very easy one.
Now when we talk about concurrent modification, things get really, really nasty. In fact, I like to say that in this case there is an issue with the business process, because on one hand, we allow data to get out of sync. On the other hand, the process allows multiple users to manipulate the same piece of information. How all relevant users should now be notified and synchronize, is no longer just a technical detail, but in fact a new business process. There just is no way to generically device how to handle this case. In most cases, it would involve back-office experts who need to decide how the changes should be merged.
A Better Solution
Angstrom pointed out that there is no way to manipulate ETags on the client side, and you should in fact not even think about it. ETags work like version numbers in optimistic locking scenarios, and changing the ETag basically means "Just overwrite what's on the server". This is a no-go in serious scenarios.
An acceptable workaround would be the following:
Make sure the server returns verbose error messages so that the user can see what happened and what caused the conflict.
If that does not help, refresh the data. This will get you an updated ETag, and merge the local changes into the "current" server state, but only locally. "Merging" really means that local changes always overwrite remote changes.
The user now has another opportunity to review the data and can submit it again.
A Good Solution
Better is not necessarily good, so here is what you should really do: Never let concurrent modification happen because it is really expensive to handle. This implies that not the developer should address this issue, but the business needs to change the process.
The right question to ask is, "When you replicate data in a distributed system, why do you allow it to be modified concurrently at all?" Typically stakeholders will not like this kind of question, and the appropriate reaction is to work out a conflict resolution process together with them. Only then they will realize how expensive fixing that kind of desynchronization is, and more often than not they will see that adjusting the process is way cheaper than insisting in yet another back-office process to fix the issues it causes. Even if they insist that there is a need for this concurrent modification, they will now understand that it is not your task to sort this out and that they need to invest in a conflict resolution process.
TL;DR
There is no way to compare the server and client state to the server state on the client, but you can do a refresh to retain the local changes and get an updated ETag. The real solution, however, is to rework the business process, because this no longer is a purely technical issue.
The default solution is that SMP or HCPms is detecting errors by ETags. At client side there is no API to manipulate ETags in case of conflicts. A potential solution to implement a kind of diff view on the device would work like this:
Show errors
Cache errors (maybe only in memory?)
delete the errors
do a refresh of the database
build a diff view with current data and cached errors
The idea with
sap.OData.removeHttpClient();
sap.OData.applyHttpClient();
could also work but could be very tricky and may introduce side effects.
Maybe some requests are triggered against the "wrong" backend.
I implemented real time sync following Realm's tasks demo app.
There a dummy container is used, to hold a List with the models.
The demo app doesn't seem to support offline usage.
I wondered what happens when, given this setup, I start the app on an online as well as an offline device and then go online with the offline device.
My initial expectation was that I'd end with 2 containers (which would be an invalid state), but when I tested surprisingly there was only 1 container at the end.
But sometimes I get 2 containers and haven't been able to identify what causes this.
The question then is, how does this exactly work? I assume the reason that the container is normally not duplicated when I sync the offline device for the first time is that it's handled as the same object, maybe because it doesn't have a primary key or something? But then why is it sometimes duplicated? And what would be the best practice here? Do I maybe have to use a primary key or check after connecting if there's duplication and if yes do a manual merge of the containers?
At the moment, Realm Tasks merely checks if the default Realm is empty before it tries to add a new base list container object. If the synchronization process hasn't completed by the time this check occurs, it's reasonable that a second container would be created. When testing the app on a local network, this usually isn't a problem since the download speeds are so fast, but we definitely should test this a bit more thoroughly.
Adding a primary key will definitely help since it means that if a second list is created locally, it will get merged with the version that comes down from the server.
We've recently been focusing on the 'on-boarding' process when a second device connects to a user's Realm Mobile Platform account via the new progress notification system. A more logical approach would be to wait for the synchronization to complete the initial download after logging in, and then checking for the presence of the objects. Once the documentation is complete, we'll most likely be revamping how Realm Tasks handles this.
The demo app (as well as the Realm Mobile Platform) does support offline, but only after the user has logged in for the first time (which is when these container objects are initially generated). After that time, the apps can be used offline, and any changes done in that interim are synchronized the next time it comes online.
We're planning on building 'anonymous user' feature where a user can start using the app straight away (even offline) and then any changes they made before they log in (due to them being offline) are then transferred to the user account after they do so.