I have a working implementation of iCloud. Now I want to improve conflict handling by adding some merge functionality. I've been trying to come up with a consistent way of forcing a conflict for testing purposes but I haven't had luck so far, conflicts don't occur consistently when I expect them to occur. This might indicate that I'm doing something wrong, or maybe that I just misunderstood something about how iCloud works (yet another thing, I mean).
I'm using UIDocument and yes, I'm listening to the UIDocumentStateChangedNotification. In fact, I do get some occasional conflict notifications. Also, I only have one file in iCloud.
Having two devices using the same iCloud accout, here is the flow of events I was expecting to always cause a conflict:
Open the file on both devices (both devices are now correctly seeing the same content). Note: Here is the only time openWithCompletionHandler is called, after this it's never called again.
Make some change on device A and call saveToURL.
Wait some time to allow the change to propagate.
Make some other change on device B and call saveToURL.
Wait some time to allow the change to propagate.
EXPECTED: The app should be getting a conflict notification from iCloud. OBSERVED: A conflict does occur very occasionally, but most of the time what happens is simply that the UIDocument gets its UIDocumentStateEditingDisabled flag set and then cleared back after half a second or so (I'd guess editing is being disabled while the iCloud daemon is pulling the version from the other device and saving it in the local ubiquitous directory).
Much like a version control system like SVN, I was expecting the version from device B to cause a conflict because an "update" was required in order to get the version uploaded by device A.
Am I wrong expecting a conflict in the scenario I just described? Why? Is there any other way to consistently force a conflict?
Thanks!
I would have thought a better way to cause a conflict would be to:
Make sure both devices have an up-to-date copy of the data
Put both devices into Airplane Mode to prevent any iCloud updates
Change the data in the same place on both devices, each with different new data
Turn the network back on
Wait for the changes to propagate
From the docs:
Conflicts occur when two instances of an app change a file locally and both changes are then transferred to iCloud. For example, this can happen when the changes are made while the device is in Airplane mode and cannot transmit changes to iCloud right away. When it does happen, iCloud stores both versions of the file and notifies the apps’ file presenters that a conflict has occurred and needs to be resolved.
The way you are doing it (allowing time for sync, altering the documents differently) seems like it shouldn't cause a conflict.
iCloud works basically the same as version control system - except that you can only access the conflict versions (when conflict happens).
When a device pulled ver_1 from iCloud, edit, save, and find the server has a different version (ver_2 or newer) than it expected, a conflicted version will be created.
After the initial sync, you can:
turn off wifi on device B, edit & save.
edit on device A, save.
turn on wifi on device B.
A conflict will come soon.
Related
Playing on a linux hosted AzerothCore rev. be423a91b535 master branch.
Whenever as a paladin I hit a target with my abilities and then someone else swings at it the entire server crashes. The only error that shows up in log is this.
We've tested this with multiple characters on multiple accounts and and in all instances after casting either of my judgement of light, or judgement of mana causes the server to crash completely when another character swings at said target.
It does not happen if I do not use these abilities and just attach the target at the same time with another player.
This is a clean server recently set up, no additional modules or changes beyond lowering guild signing size.
error image
I've also gotten a snapshot of the server config if that has useful information.
Server config
Apparently there was a module added QAston Proc, and this causes world crashes. If anyone else has this issue updating should clear it up as the commit was removed.
I am using saveEventually in Parse iOS SDK instead of SaveInBackground, just in case there is no network available. Most of the time the save happens immediately. However, sometimes (presumably if there's a bad network connection) I'm having multiple items just getting stuck and nothing is being saved even though some time has passed and a network has clearly been available. The only way to push up all stored items and save them is by closing the app completely and then reopening it, and usually this will immediately save all!
I have found this mentioned from Parse:
"Objects saved with saveEventually will be stored locally in an on-disk
cache until they can be saved. They will be sent
immediately if possible. Otherwise, they will be sent the next time a
network connection is available."
That is clearly not the case in my experience.
I am wondering why the SDK is not realizing the network is available and if I can do anything to force it to try more often. I am also wondering how many times SaveInBackground would try to find a network and save, as I believe it will try a few times at least and if so I could possibly switch to trying that method.
Any ideas?
When I update my system with a new NK.bin file, I want to keep same language configuration I had before.
A suggestion was made that I read the information from the registry, then copy my new NK.bin file, replacing the current NK.bin (yes, you can do this while windows is running using that NK.bin file).
When this is done I write the values back to the registry.
My understanding is that this will affect the NK.bin after restart. This mean that the system shouldn't notice here that it is a new NK.bin file during restart.
And it works fine, the registry changes its value. HOWEVER, when I'm doing the update, it ends with a restart of the system.
When I login after that restart, the regsitry is changed to correct/loaded value, but it shows wrong language. Then after another restart the language is correct.
I want to handle this directly, making the system start with correct language from the start.
The code below shows last step of my update before restart. The new NK.bin file is just copyied and replaced the old one.
Should also say that following register is changed but wont take effect until the second restart:
cSysLang = #"MUI";
cDefaultLCID = #"nls";
cTouchCalibrationData = #"HARDWARE\DEVICEMAP\TOUCH";
cKeyboardDefaultSubKeyStr = #"keyboard layout\Preload";
cLangSubKeyStrCurrUsr = #"MUI";
cLangSubKeyStr = #"nls\overrides";
private void LoadDataAfterInstallation()
{
//langauge
Microsoft.Win32.RegistryKey regLanguage = Microsoft.Win32.Registry.CurrentUser.OpenSubKey(cLangSubKeyStrCurrUsr, true);
if (!(languageRegInfo==0))
regLanguage.SetValue("CurLang", languageRegInfo);
First let's discuss how a persistent registry works. I'm going to assume this is a newer device and it's using a hive-based registry (there was an older mechanism for persistence that worked in a completely different manner, but I've not seen much of it since the 4.x days).
The device has a baseline registry hive that the OS loads up when it's first booted (system.hv). It then applies your changes (user.hv) to that baseline registry. Now before either of these is loaded, the OS should be doing a checksum of the NK.BIN, and if it's different, it should toss out both and recreate them. A registry from an old OS is not guaranteed to be valid for a new OS, and for sanity's sake they should never be used.
So the order should be something like this:
Read registry
Update NK.BIN
Restart
OS deletes the old registry
OS loads the default language in the default registry
Write your registry values for the new language
Restart
OS loads new registry changes
OS loads new language
This, I think is where you are, yes?
The second restart is necessary for the OS to be able to see the registry changes you made. You may be able to avoid the second restart (I'm not sure - it's been years since I tested this and don't recall) by broadcasting a WM_SETTINGS_CHANGE after restoring the value. As a definitive resource, look at the Control Panel source code to see what it's doing when the user changes the OS language with the UI.
If you are using MUI I think you can't avoid the restart. Some settings may be refreshed dinamically, but language isn't. But you can programmatically restart your device as soon as you re-imported the registry. Isn't that an option? You can include a key in the reg inside the image and change it when boot is completed. If you have the image value it means that the registry need to be restored. You restore it, setting the new value, and then automatically restart the machine. This should be a minor inconvenience for your users.
Why isn't it standard behavior for Accurev to automatically run an "Update" upon opening the program? "Update" updates a user's local sandbox with the latest files from the building/promoted area.
It seems like expected functionality that the most recent files should be synchronized first.
I'm not claiming that it should always update, but curious as to why an auto-Update wouldn't be correct.
Auto-updating could produce some very unwanted results.
Take this scenario: you're in the middle of a development task, but you've made a mistake and need to revert a file that you just modified. So you open AccuRev, but before you have a chance to "revert to most recent version", you are bombarded with 100 files that have been changed upstream including the one you want to revert. You are now forced into the position of resolving all the merge conflicts before your solution will build, including the merge of your (possibly unstable) code in progress.
Requiring the user to manually update keeps a protective 'bubble' around the developer, allowing them to commit (keep) changes within their own workspace without bringing down code changes that could destabilise the work in their sandbox. When the developer gets to a point where his code is ready to share with others, that is the appropriate time to do an update and subsequently build/retest the merged codebase before promoting.
However there is one scenario that I do believe auto-updating could be useful: after a workspace is reparented. i.e. when a developer's workspace is moved from one part of the stream hierarchy to another. Every time we reparent we have to do a little dance:
Accept the confirmation dialog that reminds us (rather verbosely) that we need to update our workspace before we can promote any changes.
Double-click the workspace to view its files.
Wait for AccuRev to do a "Pending" search, to determine whether any file changes are waiting to be committed.
And finally, perform the Update.
Instead of just giving us a confirmation dialog, it would be nice if AccuRev could just ask us if we want to Update immediately.
I guess it depends on preference. I for one wouldn't like the auto-update feature.
Imagine you have a huge project and you don't want to build it every time you start Accurev. But you also can't debug because the source files and debugging info no longer correspond.
It would be useful for many people to know how to completely remove an application from your device when testing.
I have downloaded my app many times now, and likewise have deleted it many times. The problem is when deleting the app, it does not remove things like the persistent object related to my app, or the images downloaded through the app. So, when I download the next build, I have no idea if something broke that is related to building the persistent object or fetching the images since those elements already exist from the last build.
I don't know if this is a cache thing. I don't know if this is expected and I have to use some utility to wipe this data after deleting the app. I can't really find much info through basic web searches.
Any information would be appreciated.
Blackberry Bold 9000. 4.6 OS. tested with both SD card and no SD card.
Objects stored in the PersistentStore are automatically deleted on uninstall if their interfaces were defined in your project. If they are from the standard BlackBerry API then they will stick around until they're deleted. E.G if you save a String in the PersistentStore it will stay in the PersistentStore but if you save a class you created it will be deleted on an uninstall. So if you want to have those objects be deleted automatically just create a wrapper class and save that.
Images stored on the filesystem will not be deleted until you or some application deletes them. However, it should be easy for you to write an app that clears everything out.
Another solution you could implement is making your app somewhat self-aware of its data.
Create a simple String value that you persist (or optionally, persist it in a Hashtable so you can store many properties this way) that includes "Version".
At startup of the GUI app, compare the stored "Version" against the application's current version. If the stored version doesn't exist, or if it exists and matches, take no action.
If it exists and does not match, automatically clean up old persisted data; or alternatively prompt the user to see if they want that data to be deleted (which one is better will depend on your implementation)
You can also use CodeModuleListener to listen for an uninstall event -- when that happens, you can clean up at that time as well or instead.
(As an aside and a bit of shameless self promotion, I am actually currently working on a shareable library for Blackberry that makes managing persistence much easier, as well as desktop data backup/restore. I'm doing this as part of the BBSSH project, but I'll be splitting it off into a separate library of core components and publishing it under a dual GPL/optional commercial license. It will contain hooks for data cleanup and data versioning. )