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.
Related
I have an iPhone app that allows users to create content (mainly things that are stored as binary data) while recording video. So the output of the app are multiple files, the recording and the user generated content. Because between the two there is a relationship, I though of archiving them and present them to the user as a single file, a bundle. But since the video can be huge, archiving is becoming less of an option because of the time needed to archive/unarchive the file. What other options do I have? When I record I write buffers to disk, so I'm not loading the file in memory. Would be nice to be able to write into an archive, but I'm almost sure it's not possible.
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.
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)
I want to store some photos that I take from a web service to my phone for the case when I don't have internet connectivity. I am storing data to a database but i have a question: should I store in the database the URL of the photo and the photo in a folder, or store the image in the database? The volume of photos shouldn't be great; something like 200-300 small pics, at approx 30-40kB each.
If you already have a database, i would organize my photos in database with only the path to the photo. And the photos can be stored on memorycard or on local disk.
The basic rule of thumb is to put big data objects like images right onto the disk and only reference the URLs. This might come in handy for loading/processing the images anyway.
30-40 kB per image is not that much, but then I'd consider 6-12 MB for the database quite extensive, especially it's probably the majority of your database volume.
I'm not real familiar with iOS. But my understanding is that it supports XML files. If the database is just being used to store the paths (instead of images), why not use an xml file to store the paths?
If you need the db, with small images, I don't see it being a problem if the phone is just using it. Either way, I don't think it'll be an issue. Someone else can probably give you a better answer as far as efficiency. That's outside my jurisdiction.
Store all the pics in document folder, and when there is no internet connection get them from document folder of your iPhone.
I'm currently working on an application that users a number of different views to obtain user information and I have just hit a snag.
My current method saves each user detail against a key value in a plist file, the problem is that when the user switches to another view and saves their data again, the old keys and data are overwritten.
So my question is what is more efficient, to a) have a different plist for each different view or b) read all the existing data from the file first then save the data back to the file along with the new details.
Bearing in mind eventually I will want to export all of this information as XML, though it shouldn't be too difficult to read form multiple files.
thanks in advance!
It would probably be more efficient to use multiple files. The most scarce resource on the iPhone is memory, and loading a huge plist could potentially use up a lot. Using multiple files means you don't have to load all of the plists into memory at once. If you have a lot of data, I'd also suggest taking a look at Core Data eventually.