Hi, When exactly should a SyncableDeveloperString resolve? I have some basic test code in place to see the behavior of cloud syncs and conflicts. In my code I get a SyncableDeveloperString and check for conflicts. If I find conflicts I just print the local and cloud values out. Then I always set the value of the SyncableDeveloperString without calling markAsResolved() since I didn't resolve the conflict but I want it to just write the data to local storage. I also have a call to AmazonGamesClient.getWhispersyncClient().synchronize(); right after to just force a save of the data. The issue is that after I do this, the SyncableDeveloperString seems to get resolved. The next time I ask for it and check its conflict status it is no longer in conflict and both the cloud and local data are now the new value I set it to. The result I was expecting was that only the local data would show the changed values and the cloud data would be the value that I never resolved. Is this how resolving SyncableDeveloperString's should work? If so, how can I delay resolving a conflict and still write data out to local storage?
Hi Gamedever, Actually, Synchronize makes a full sync with the cloud; calling WhispersyncClient.flush() instead of synchronize will commit the data to disk but will not resolve the conflict until you call synchronize. Thanks.
Hi Sujoy, Thanks for clearing that up! One other question, Do the passive sync events that occur respect the markAsResolved setting for developer strings? If I avoid calls to manually sync and continue to set new data will that data only get written out locally if a conflict exists that has not been resolved. Message was edited by: gamedever
My intent was originally to read only the local data from a conflicted string and only write to the local data if a conflict has yet to be resolved. This would allow us to delay when we might prompt a user to resolve the conflict such as waiting until after finishing a level if they got a conflict in the middle of the level. However after speaking with our designers it seems that we intend to always push to the cloud and will only handle resolving conflicts on launch of the title. This means that our expected behavior for any conflicts in the middle of game-play will be to just push to the cloud so the way things work currently will work for us. To answer your question: "Did you mean to set new data in a conflicted string without making a call to flush()?" I was asking if I just set new data in a conflicted string and let the automatic sync take over without making any manual calls to sync. Then would the new data get pushed to the cloud if I never called markAsResolved on the data. I just wanted to confirm if the automatic sync works the same as the manual sync with respect to conflicts. Either way this is something that I can test once I'm diving into this more and I'm sure I have ways to get things to work as I expect.