I have an ios game mostly written in C++ which stores its game data in the standard c++ binary format. I would like to add iCloud support but I'm not sure if i can upload this kind of files to iCloud.
Is it possible? If so, how?
iCloud documents of your app or game can have any internal format you want - you don't have to use the NSDocument class.
Note that iCloud backups are not the same as iCloud Documents. Putting user data into the Documents folder will cause it to be backed up to iCloud as part of the device backup but will NOT cause it to be synced to other devices. For that you need to use the iCloud APIs to correctly coordinate the syncing process.
You can either save non-specific data that will be treated as a single item or "Documents" that users can delete one by one, when, for example, they are running out of space. You can see how this works by clicking "Manage" in the iCloud preferences.
If the data you need to store is not too big (a few kilobytes) I would suggest looking at the key-value store as well, which is MUCH simpler than the documents API. It is possible to store binary data there using NSData. The limit for the key-value storage has been recently raised to 1MB and 1024 keys.
Why not? Any file in the Documents folder of your application will be backed up on iCloud.
If this file cannot be recreated otherwise (for example it is a savegame, not a cache file), then I see no problem.
The documentation states:
Put user data in the /Documents/. User data is any
data that cannot be recreated by your app, such as user documents and
other user-generated content.
...
Every file or file package located in the Documents subdirectory (or
one of its subdirectories) is presented to the user (via the iCloud UI
in OS X and iOS) as a separate document that can be deleted
individually.
(http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html)
Related
I couldn't think of a better way to phrase this question, so let me clarify:
I'm storing many things in Core Data, some of which are images stored as binary data. These images have been set to allow for external storage, meaning, from what I can gather, that Core Data takes care of storing these pictures elsewhere on disk rather than inside the database itself if they are too large (> 1MB?). I am also trying to build a simple backup/restore system for this database using File Sharing - clicking "backup" copies my .sqlite file from my Library folder to my Documents folder (under a different name), allowing the user access through iTunes (to store wherever they please), and clicking "restore" looks for a backup file in the Documents folder, deletes the active .sqlite file in the Library folder and replaces it with the backup.
The problem arises when an image is deleted from Core Data, but then I want to restore my database to a time when that image still existed. When I delete that image using Core Data, I presume both the path to the image that is stored in the database and the image itself stored elsewhere are both deleted. But, when I restore my old database by bringing the .sqlite file back, only the path to the image exists - the image itself was stored externally, so it's nowhere to be found.
First of all, is this a reasonable approach to backing up and restoring a database under Core Data, or is there a clear reason that I shouldn't be going about it by copying the underlying .sqlite file back and forth? Second, can anyone provide advice on how I might go about allowing Core Data to take care of external storage while still having a way to back up those images? I realize that I could probably store images manually, thus allowing me to back up an image folder along with my .sqlite file, but I do like the simplicity of having Core Data manage this for me, so I'm just wondering if there is any better way to do this backup/restore thing.
My app was rejected due to data storage problems.
After googling, I got these ideas. Please confirm my assumptions are correct or not.
Store the SQLite db in the caches folder and set the "donotbackup" flag, which will stop the file being deleted by the cache clean system.
But what will happen to the db if I update the app to a newer version? Any chance to loss the db?
Keep the cache files like images etc. in the Caches folder.
Do we need to clear the cache with our code or the device will clear it automatically?
Then I am storing all the data(including images) in the application's Sqlite db file. So should I implement iCloud in my application?
You must use "do not backup" attribute to files that you would to keep, other files place to cache folder.
Cache folder will be automatically erased when application terminates.
Check this article
Developers forum
Apple documentation
I'm using Core Data to store some sensitive information. So far, I've applied hardware file encryption to the SQLite file used by the Persistent Store Coordinator. I've done this by setting its file Attributes (NSFileProtectionKey to NSFileProtectionComplete).
I'm storing some image data as Binary Data in the Core Database and I've checked off the "Allows External Storage" and "Store in External Record File" to prevent bloating of my SQLite datastore and to improve performance.
I'm presuming that the data files automatically stored outside of the SQLite database by Core Data will NOT be encrypted and that I need to encrypt these files myself. Does anyone know if this is correct?
Thanks
luckman777,
Every version preinstalled of iOS will hardware encrypt every file when the user uses a screen lock. With respect to your question about external Core Data storage, why don't you just look at the files? It is quite straightforward to move the data from the phone to your dev system. Then try to open one of the external files. I expect that it is encrypted. (If not, that is a rather big and obvious hole in Core Data's encryption policy. I doubt that it exists.)
Andrew
Hidden, but not encrypted!
The folder it currently (iOS 11.2) holds the data is under Documents/.SingleViewCoreData_SUPPORT/_EXTERNAL_DATA
There, you can see all the files, without their extension in a token-name. However, the data is all there unchanged. You can view any file by simply adding the file extension or using the right App.
Yes, the device data is encrypted when the screen is locked, but connected to Xcode, you can very easily download the container and access all the data. If your app holds sensitive data, the 'device is encrypted' will simply not hold.
Only the SingleViewCoreData.sqlite file seems to be encrypted.
I have been puzzling about retrofitting my app for iCloud for a few days and hope someone can help. After getting past code signing issues I am not sure I understand the model for incorporating iCloud. I'll tell you the problem I'm trying to solve first since I'm a big believer in telling people what I'm trying to do before having them try to fix the way I'm doing it :-)
My app workflow
User browses the store which lists a series of training plans they can download
User picks a plan and downloads it
I pull the training plan from our webserver customized to their needs
I add the filename for the training plan they downloaded to a plist of plans they own
User opens the training plan and sees the day-to-day schedule
I want the user to be able to do this on their iPhone and then open their iPad and see the exact same training plans synced over there.
My problem
I currently save the files to the Documents directory and that works just fine. How do I retrofit this to work with iCloud such that folks without iCloud enabled can continue to use the app but those who do get the added benefit?
My understanding
I'm confused as to whether I still need to save to Documents folder and then save a copy to the iCloud folder OR whether I just write to the iCloud folder from now on.
If it's the former I believe I just write a copy the Documents folder files to the iCloud area too to push it up but how do I detect a new file in the iCloud folder and copy it back to my Documents folder?
If it's the latter the files should just exist right?
I'm hoping it's the latter and that still supports devices without iCloud turned on...
Thanks for any help clarifying.
Adam
The iCloud API is pretty well documented and there is a specific chapter that deals with what you are after:
Managing the Life Cycle of a Document
A document goes through a typical life cycle. A document-based
application is responsible for managing its progress through that
cycle. As you can see from the following list, most of these
life-cycle events are initiated by the user:
The user first creates a document.
The user opens an existing document and the application displays it in the document’s view or views.
The user edits the document. A user may ask to put a document in iCloud storage or may request the removal of a document from iCloud storage.
During editing, saving, or other actions, errors or conflicts can happen; the application should learn about these errors and conflicts and either attempt to handle them or inform the user.
The user closes a selected document. The user deletes an existing document. The following sections discuss the procedures a document-based application must complete for these life-cycle operations.
In essence, you application is responsible for working out whether iCloud is available for a particular user and then confirm that the user wants to store their data in the cloud. Based on that selection you will need to work out how to move their existing data from the documents directory to a cloud URL.
On other devices that are setup to use iCloud storage, you have the option to discover documents available via a metadata query.
http://developer.apple.com/library/ios/#documentation/DataManagement/Conceptual/DocumentBasedAppPGiOS/ManageDocumentLifeCycle/ManageDocumentLifeCycle.html#//apple_ref/doc/uid/TP40011149-CH4-SW1
If you are looking for a very easy sample which implements iCloud, have a look at this:
iCloud basics and code sample
This gives you a concrete example of how to implement some of the stages Rog has cited in his post above. Hope this helps.
My application will record and store some sounds to play them back later. Right now, I can record the sound which is saved in temporary folder.
Where is the best way to store sounds to play back later?
Do I need database or just store as files?
Files in your Documents directory. Or perhaps a subdirectory within Docs. Using a subdirectory has the advantage that you may want to store other data files somewhere in Docs dir, but keeping all the sound recordings in their own location lets you iterate through the files or delete the entire directory and its contents. I've seen plenty of messages suggesting it's less efficient and/or fast to store a bunch of binary objects in SQLite.