I have a Mac and iOS application that is sharing data using iCloud, via a single "shoebox" file.
Most of the time, changes are properly synchronized in an efficient and prompt manner. However, every once in a while (particularly, right now) changes that I make on one device simply sit there.
I have made changes on my Mac to the shared data file, and the data has been saved to disk. However, I don't know whether it's the system's failure to upload the data to iCloud, or the iOS device's failure to check for the new data, but I'm twiddling my thumbs.
The 5KB file below is the one that should be changing. No matter how many changes I make in the Mac app, every once in a while during testing, iCloud will just stop syncing changes. If I walk away for 20 minutes and come back, it might start up again.
Further: If I run the Mac application in Xcode and keep an eye on the same file, even though I make changes to the file and can confirm that the file on disk (in the Finder/Terminal) is actually changing, the iCloud panel in Xcode does not pick up these changes very quickly either:
Note the same 5KB file has changed on my local filesystem on my Mac (at 9:01), but iCloud just isn't picking it up. There are actual content changes in this file, not just a modification date change.
So, I would like to find a way to either:
Trigger the sync programmatically, or even using Xcode. I know that the iCloud sync can be triggered using the simulator, but this only works when testing on iOS, and I much prefer to do my testing on the actual hardware anyway. Or,
Determine who (or what) is "at fault" for the data not being shared. I have followed the iCloud documents from the beginning, ensuring that I'm using coordinated writes to save changes, etc. It's just a very intermittent thing where iCloud will doze off, and makes testing very frustrating.
I don't think you can trigger synchronization of selected files, but you can use this tool "brctl" to see what is going on under the hood (or diagnose) (on OSX), to diagnose what it might be about.
commant line command:
$ brctl
for example use it like this
brctl log --wait --shorten
or
brctl diagnose
I realized when you migrate any store to your existing iCloud store, the iCloud store adds those data and forces sync to the version in the iCloud. So I migrate an empty store to my existing iCloud store, and I forced the sync!
Related
Use this directory to write temporary files that do not need to persist between launches of your app. Your app should remove files from this directory when they are no longer needed; however, the system may purge this directory when your app is not running.
https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html
There are conflicting answers about the need to manually clear the tmp folder. There is no API for clearing it, it must be performed manually file by file (which says something). More importantly, we should always avoid unnecessarily overworking the disk because it will wear out the SSD (Apple's Data Storage Guidelines mentions this also), and purging a folder file by file that's designed to be purged by the OS routinely seems counterintuitive.
Would it not be best practice then to delete what we know for certain isn't needed anymore as it comes our way (on-the-spot cleaning) and let the rest be purged by the OS and avoid manual purging altogether?
And should we not apply this strategy to the Library/Caches folder as well, since that folder's cleaning policy is the same as the tmp folder's?
You said:
Would it not be best practice then to delete what we know for certain isn't needed anymore as it comes our way (on-the-spot cleaning) and let the rest be purged by the OS and avoid manual purging altogether?
Yes, the documentation is telling you that when you create a temporary file, that you should just remove it as soon as you’re done with it. There’s no “manual purging” or sweeping of this folder needed. Just delete the individual files when you’re done with them.
And should we not apply this strategy to the Library/Caches folder as well, since that folder's cleaning policy is the same as the tmp folder’s?
If you know for certainty that you don’t need a particular cached file anymore, then absolutely delete it.
But often with caches, you don’t know when a particular file isn’t needed anymore, so we often resort to LRU-style logic based up the quantity, size, or cost of the assets.
But in both cases, you want to clean up as appropriate, to prevent unbridled growth in storage. You want to avoid using persistent storage for assets that are no longer needed
I accidentally ran rm -rf on my terminal on my mac and lost everything, including an app project I was working on. Is it possible to somehow transfer the app project that I had deployed on my iPhone back to my computer in any way? Just so I can see what I can salvage?
You can't get the Xcode app project back from the app that was installed on your phone.
If you're using source control (such as with git), you may be able to go back to a prior version. To check, go to the command-line and do
% git log
See if it shows any history.
Otherwise, if you stored your project in your Documents or Desktop folders and have those folders synchronized with iCloud, you might be able to get it back by going to iCloud.com and checking if you can download it. However, because these folders are synchronized, doing this right away is important, because it will synchronize the deletion. This is why a cloud-sync'd folder isn't considered a backup.
If you have Time Machine configured on your Mac, you can check if there is a version available there. Open Time Machine from Launchpad -> Other -> Time Machine, or click the Time Machine icon in the upper right corner of your Mac screen (looks like a clock with an arrow/circle around it), then click "Enter Time Machine". If you're able to do this, you can go to the folder and browse previous versions by time.
Lastly, check any other backup solution you may have, such as Backblaze, for example. Backblaze is a cloud backup solution. It also has an icon up top on your Mac desktop -- it looks like a flame.
If none of these work, you're out of luck (sorry!). Learn about git, and use Bitbucket or Github with it. Set up time machine. Also set up a cloud backup, like Backblaze. I use all of those. Hopefully one of these works for you!
I would like to leverage the benefits of a server workspace (seeing who has checked out which file) together with the ability of the Team Explorer - Pending Changes to detect local changes (which with my current configuration works only when using a local workspace).
Is there a possibility to configure such behavior? I do not understand which technical limitation makes my server workspace incapable of sensing that I added, removed or changed files without checking them out first. It should at least be capable of showing these and then prompting me to check them out before I can include them for commit.
Is there a possibility to configure such behavior?
Nothing is built in. If you take locks on the server, you need to explicitly notify the server, but that would mean having something running all the time to check for file changes and see if a lock could be taken (and how would arbitrary tools handle that failing?)
You could create something yourself to do this (the TFS-VC API is available).
Meanwhile most developers find the local model works better (don't require exclusive access, in the cases where there is a conflict it is resolved at checkin).
I am using File.applicationStorageDirectory to store user data, specifically purchased items from iOS store.
I noticed that when users upgrade their version the data is lost and users need to restore their purchases (on ios items) , is it a bug on my side or is the File.applicationStorageDirectory not the correct place to store that kind of data.
Thanks!
applicationStorageDirectory is also known as the "temporary files" of the system. Regardless of the platform (desktop or mobile) or OS, when something drastic is done (such as installing a new version of the system), those temporary files are (generally) wiped out in the process.
Furthermore, uninstalling your application and reinstalling it (or, indeed, updating it) may (in some cases, dunno about iOS) delete those temporary files, or simply create a NEW directory for them, ignoring the old one.
Third, some cache-cleaning apps will also wipe out this data.
So, to answer your question, yes, you're going to want to store things you want to persist despite major changes, such as in-app purchases, in a new, dedicated folder in the userDirectory or the documentsDirectory.
I'd like to implement a backup and restore feature in a sql-backed Core Data app. I can successfully backup and restore .sqlite file via dropbox, but I have one question about this approach.
If, in the future, my data model changed there are 2 possibles case that will happen.
User backup in newer version and restore it in the older version of my app. From my understanding that will cause some schema error.
User backup in older version and restore it in the newer one. I think this one will work just fine because it should migrate as normal case.
If this assumption are right, what should I do to handle the problem that may occur from the first case?
When I make backup I create it as zip file containing plist file with stored version of backup in it. When I do restore I check that version and if backup is newer than current version I deny restore. It doesn't make sense to restore backup in older app version.
As long as You have necessary models it will work properly.