I'm trying to push a file to iCloud from one of my apps but sometimes there is no way to track if the file is already on iCloud or not. After marking the file as ubiquitous I have a method that periodically checks the status of the files via a NSMetadataQuery. When I get the results back I use these keys for the status of the file:
NSNumber *isUploaded = [file valueForAttribute:NSMetadataUbiquitousItemIsUploadedKey];
NSNumber *isUploading = [file valueForAttribute:NSMetadataUbiquitousItemIsUploadingKey];
NSNumber *uploadPercent = [file valueForAttribute:NSMetadataUbiquitousItemPercentUploadedKey];
This seems to work sometimes but in other times the isUploaded value is 0 and the isUploading value is also 0! The uploadPercent value is actually always 0. When I go into the 'Settings' app of my device and check the files for my app the files are already listed there so I'm not sure why the 'NSMetadataUbiquitousItemIsUploadedKey' key would return 0?
Any help is appreciated! Thanks!
I'm trying to do the same thing. Per the iCloud guide, try NSURLUbiquitousItemIsUploadedKey instead of NSMetadataUbiquitousItemIsUploadedKey. Let me know if that works for you. I still haven't been able to get this working. Here's the section from the guide:
Determining the Transfer Status of a File or DirectoryItems you write to an iCloud container directory are transferred automatically to the iCloud server as quickly as possible. However, depending on the network and the type of device, a file might not be uploaded to the server or downloaded to a device immediately. In cases where you need to know the state of a file, you can use the getResourceValue:forKey:error: method of NSURL to retrieve the value for one of the following attributes:NSURLIsUbiquitousItemKey—Indicates whether or not the item is stored in iCloud. NSURLUbiquitousItemIsDownloadedKey—Indicates whether the current version of the item is downloaded and accessible.NSURLUbiquitousItemIsDownloadingKey—Indicates whether the current version of the item is being downloaded and is not yet available.NSURLUbiquitousItemPercentDownloadedKey—For an item being downloaded, indicates what percentage of the changes have already been downloaded. You can use this value to update progress bars.NSURLUbiquitousItemIsUploadedKey—Indicates that locally made changes were successfully uploaded to the iCloud server.NSURLUbiquitousItemIsUploadingKey—Indicates that locally made changes are being uploaded to the iCloud server now.NSURLUbiquitousItemPercentUploadedKey—For an item being uploaded, indicates what percentage of the changes have already been uploaded to the server.Although the iCloud server aggressively pulls changes your app makes locally, iOS devices typically do not pull changes from the server until you try to access the file. If you try to open a file that is currently being downloaded, iOS blocks the thread that issued the open request until the file is downloaded and available for use. Thus, if you are concerned about potential delays, check the file’s current state as needed and possibly update your user interface to reflect that the file is not yet available or is currently downloading.For more information about the attributes you can request for URLs, see NSURL Class Reference.
Related
I need some clarification and Microsoft documentation is only confusing me more.
I want to save a txt file in iCloud so the user doesn't loose some data that belongs to them.
This db document is some information I am retrieving from a local database and storing in a text file. I have seen two ways of doing this.. however all the posts on this topic are very outdated and I don't know which way might be best or if they are even doing what I trying to do.
All I would like is to be able to have the user backup this particular file to their iCloud account, so they can still keep this info even if they change phones or delete the app and want to restore from iCloud.
Microsoft's documentation points me to this page https://learn.microsoft.com/en-us/xamarin/ios/data-cloud/introduction-to-icloud
I began setting up the provisioning profiles and setting the iCloud options on the entitlements page etc. However the documentation when sideways for me when they began creating a monkey page UI Document and having the user manager the ubiquity documents (which I don't want) I actually don't want the user even seeing this Txt file. However this option shows how to check if the iCloud is even turned on on this user's phone.
Now this other option I think is more straight forward and I read the documentation on it here https://learn.microsoft.com/en-us/xamarin/ios/app-fundamentals/file-system using something like this to store and retrieve a document:
var libraryPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Personal), "..", "Library");
However what if iCloud is turned off? Is this an automatic backup option?
Any type of explanation is helpful.
The iCloud storage API in iOS 5 allows applications to save user documents and application-specific data to a central location and access those items from all the user's devices.
About the definition of iCloud, you will know that it will save your data to cloud server. And it can be used in all the user's device if turn on the iCloud.
However what if iCloud is turned off?Is this an automatic backup option?
Therefore, if iCloud is turned off, you could backup the data in device although it will not be used for other user's devices. You could save it in Application directories. This should be a good chooice to backup your data. And you also can get the data when you need them.
In addition, you also can use other cloud server APIs to backup your data. Such as Azure Storage, Firebase Storage etc.
When i submit my iOS app i got following rejection issues from apple.
On launch and content download, your app stores 13.14MB on the user's iCloud, which does not comply with the iOS Data Storage Guidelines.
Next Steps
Please verify that only the content that the user creates using your app, e.g., documents, new files, edits, etc. is backed up by iCloud as required by the iOS Data Storage Guidelines. Also, check that any temporary files used by your app are only stored in the /tmp directory; please remember to remove or delete the files stored in this location when it is determined they are no longer needed.
Data that can be recreated but must persist for proper functioning of your app - or because users expect it to be available for offline use - should be marked with the "do not back up" attribute. For NSURL objects, add the NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from being backed up. For CFURLRef objects, use the corresponding kCRUFLIsExcludedFromBackupKey attribute.
Your App stores data in the users iCloud. This is only alowed to a certain degree.
The 13,14 MB your app stores to the cloud is just too much.
I never submitted an app to Apple, but the error message is clear and defined.
Take a look on your app and what it does store in the iCloud. Reduce the size or just dont write to iCloud.
Hope it helps...
*edit
Why would one write to the iCloud anyways? Just write on the phone memory.
Do you call a web service on App launch which stores data in the App's documents directory? Or do you store some other data in the App's documents directory?
By default all the data in the App's documents directory is synced to iCloud. So any data that can be recreated later (unlike session data) must not be stored on the documents directory.
So instead save data in the App's Temp directory.
To do that have a look at this- How to save images and recoded files in temp directory?
Another option is you have is How to use addSkipBackupAttributeToItemAtURL API?
Scenario:
After downloading the file from Server, we have to store it in device’s local and fetch from their for later use.
This is for reducing unnecessary hits to DB to get the same file again and again. And accessing file offline too (when user don’t have internet access, he can able to fetch file from local).
How can we implement the above scenario in iOS devices for videos?
This solution will work only if files have unique names.
You can create a local db in which you have to store all file names which you have already downloaded from server.
Whenever user want to see a file you have to first check thes local db.
If file is already downloaded you can take the file and play it.
Right now we are designing an app in Swift that fetches HTML applications from a server in form of zip files and then run it in the iOS app as an web view. Each zip files is of approx 4-5 mb in size. We have 30+ HTML applications in our app as of now. But we may reach to 150-200 apps soon enough. I would like to know the maximum amount of data that an iOS app can handle. If excess amount of data gets deleted, where will it go? Will it be stored in iCloud before the data gets deleted? Please help me. P.S. The HTML applications will be downloaded from the servers in form of zip files , it'll be extracted and then will be stored as a folder. When the user first installs the app in his system , he won't have any html applications installed. He'll have to fetch the apps one by one according to his requirements.
Since you're saving the content to disk, the limitation is the disk size of the user's device. It also depends on where you're saving the data: If you save to the tmp directories, the data may get deleted, but if you're saving to the application's normal directory it will also be backed up to iCloud (assuming the user backs up).
I would advise against filling up the user's phone with hundreds of MB of data automatically, they will get very annoyed at you. So you will want to offer them a UI to actually select which content they want to keep and which should be removed.
No limit as far as I know.
But be aware that all files you download and store in the app have to be marked as "do not backup in iCloud" - otherwise Apple will reject your binary when you submit it to the store.
See
Apple Documentation and
Excluding files from iCloud Backup
My advice,
Don't download all the applications at once, instead provide user a UI from which he can able to select any application (only one at a time, because at any point he'll be able to run single app only, I guess), then download that particular application (also removed if any previous installed app found).
But wait, there's one more option, you can keep 3 apps at a time, and I believe they wouldn't cost you more than 20Mbs (as you said, 4-5Mbs / app). If so user may have feel of switching between (last used) three apps. If he want any other application then he can select any app, here you need to delete (a app from last three) and add newly downloaded app, this means at any point you'll have 3 apps in your directory.
Now the problem of preserving user information (for individual apps), here you can use any local db (or your server or any third party servers) to store (preserve) user information for particular app. At any point he'll delete the app (you should keep backup of it before deletion will be made).
Later, when he changed his mind, and download the app (previously deleted), then you can restore the information (which was preserved before).
Good luck! Don't wash your hands :)
in the message of the resolution center (App Store) I received the following message:
"The iOS Data Storage Guidelines indicate that only content that the user creates using your app, e.g., documents, new files, edits, etc., may be stored in the /Documents directory - and backed up by iCloud.".
In my iOS application I store the "Settings" in a SQLite file. That I create just one time and gets modified by the user when he requires to do those changes. The size of this file is about 20kb and I'm storing it in Documents (as Critical Data). It is correct to do this?.
Yes this is correct. If you reply to them and tell them what you've said above, they'll probably allow you to pass the review. Just make it clear that it's user created/modified and needs to be backed up.
Source: This happened to us as well and we challenged and got accepted.
Note: You could save settings in the NSUserDefaults instead if you don't want to have to challenge them.