My iPhone (actually, iPad) app creates documents that consist of several images, plus a bit of metadata. What's the best practice for storing these sorts of documents on disk? I see two main options:
Create a folder for each document, and store my images as separate PNG files within the folder (plus another little file for the metadata).
Create a single file which contains all images and metadata.
But I'm not sure how to easily do option 2. I think I can convert my images in PNG format to/from NSData, but then what? I'm still a newbie at Cocoa, but I believe I saw something about stuffing mixed data into some NSSomethingOrOther and having this write itself out to disk, and read itself back in later. Does this ring a bell with anyone? And, will it work with large binary blobs of data like my images?
Or would you recommend I simply go with option 1?
Simply go with option1. It's clean, elegant, and simple to implement. You could even use (a subset of) HTML.
TIFFs and PDFs can have multiple pages.
Creating a document centric iPhone/iPad application with own file format using ZipArchive
Related
I find many similar question but i didn't get solution for this.
Is it possible to upload some file like image, document, zip file to upload on iCloud programmatically?
See table 4-1 in the documentation:
How do you manage the data? Manage files and directores using the
NSFileManager class. Open, close, read, and write files using standard
file system routines.
So if you can create a file, you can store it in iCloud. But remember there's a finite, relatively small amount of space available.
iCloud can handle all kinds of files. So if you want rot use an obscure file format or invent your own, go for it. It only can to be converted into a byte stream/NSData, but then again, what isn't?
Check this tutorial walkthrough app. It shows how to create, modify and delete files for iCloud.
http://github.com/lichtschlag/iCloudPlayground
any recommendations for saving four strings into an own file format that is read by the application and can be shared?
In my app, you will be able to enter some text in some boxes and the app shows a view with an background image and those strings. Now, I am already able to save this as a picture, but I actually want to save it to an own file format so that you can save different files that can be modified afterwards as well or even exchanged via email and opened from another iphone with the app.
Now, I wrote the code for accessing the documents folder of the app, as well as saving and deleting. Thing is, i dont know how to store those strings in a file (perhaps in a xml?) and read them easily afterwards from my application.
For the exchanging part, I found that link which would be a nice feature indeed: http://iosdevelopertips.com/cocoa/launching-your-own-application-via-a-custom-url-scheme.html
Parsing xml seems not that difficult (never done it before): http://ipad.about.com/od/iPad-App-Dev/a/How-To-Parse-Xml-Files-In-Xcode-Objective-C.htm
If it's only a small bit of infomation then the easiest way to store your data in a file would be using a plist - there's a good tutorial here - http://www.icodeblog.com/2009/02/14/loading-data-from-plist-files/
In addition to the plist, you could also do the following approaches:
1) simplest - open a file in your documents directory, write the 4 strings (using whatever delimiter/end of string marker is useful - carriage return?) and overwrite them each time through. (i.e. it's your file, you can format it how you like)
2) mildly harder - use Apple's NSArchive to pack and unpack the strings.
3) possible overkill - store them directly in a SQLite database
4) major overkill - store them in CoreData.
Of course, the "overkill" options also provide you with extra features which may be of use if your app functionality extends beyond what you've outlined.
By sharing, I would think that simple copy and paste might be enough, but there's also sending it via email, or tripping another app's URL scheme to make it open it and sending the strings as part of the URL. You'd have to know that the other app would be able to interpret your strings as part of the URL, so you might have to write it yourself.
Okay guys I found that very nice method in the NSString documentation:
–writeToFile:atomically:encoding:error:
I think I am gonna separate my strings by /n and save them to a .txt. When I am gonna read the file afterwards, i am getting the string, divide it to substrings. That will do it, I guess.
One last question: Is it possible to replace the content of my file so that I won't need to create a new file every time i want to change something?
Thanks!
I'm making my first iOS App, and I'm facing my first (little) issue.
The App will be a very classical iOS UI Experience : I mean, table views, tab bar, push controllers etc. displaying documents (from RTF files already existing), audio and video files.
My RTFs have mixed languages, all supported by iOS, I think it's important isn't it ?
Considering audio and video will obviously stored in the sandbox documents directory, I'm not so sure for the RTF.
I want it to be very reactive, on every devices, so my idea was to store my RTFs in a Core Data entity (using the binary type) and getting it in my application with NSAttributedString which can respond to the initWithRtf message.
I guess that after that I'll have to load it into a UIWebView ? Or simply displaying this NSAttributedString into a textview will preserve it's formatting ?
But I don't know how to ship my application with a Core Data pre-filled database.
So here are my questions :
Is it a good idea to store those RTFs in Core Data ? Is it really faster than a simple UIWebView where I would load the RTF file from documents folder directly ? Maybe SQLite is better for my case ?
How to pre-fill a database into my application ?
Any specific consideration about the multiple languages into my RTFs ? (Latin AND non latin languages into a same file for exemple).
Thanks a lot ! Bye.
getting it in my application with NSAttributedString which can respond to the initWithRtf message.
That won't work. -initWithRTF:documentAttributes: is currently only available on OS X. To convert an RTF file into an NSAttributedString on iOS requires manual parsing of the file at the moment (let's hope that changes with iOS 5).
I guess that after that I'll have to load it into a UIWebView ? Or simply displaying this NSAttributedString into a textview will preserve it's formatting ?
UIWebView can't display NSAttributedStrings. Neither can UITextView. You would have to use the Core Text functions to draw the text yourself. Or use HTML from the beginning and display the text in a web view.
Is it a good idea to store those RTFs in Core Data ? Is it really faster than a simple UIWebView where I would load the RTF file from documents folder directly ? Maybe SQLite is better for my case ?
What's wrong with plain files? That would be my first option because it seems to be the simplest. You shouldn't worry about optimizing something if you don't know if it needs optimizing at all. But since you can store arbitrary binary data with Core Data or plain SQLite, it's definitely possible.
How to pre-fill a database into my application ?
Just include the Core Data datastore file in your app's bundle. If this database needs to be written to, your code needs to copy the file from the bundle to your app's Documents directory on first launch.
Right, this is the problem I have a container (rar,zip) which contains images png's tiffs bmps or jpegs in an order.
The file extension isnt zip or rar though but uses the same compression.
I want to pull out a list of images contained within the file in the numerical order, then depending on the user decision go to the image selected.
I'm not after any code just the high level thought process/logic of how this can be achieved and how it could be achieved on iphone OS.
From what i know of iphone OS it uses a kind of sandbox environment so how would this effect the process as well.
Thanks
You can include the libz framework in your project and write some C to manage zipped data. Or you can use Objective-C wrapper classes others have written.
Your application resides in its own sandbox. You can include zip files in the "bundle", i.e. add them to your project, and copy them to the application's Documents folder to work with them. Or you can copy archived data over the network to the application's Documents folder if you don't want to include files in your project.
I don't think the extension matters so much as the data being in the format you expect it to be.
Everything I wrote above is for zip-ped files. If you're working with rar-formatted archives, you'll need to look at making a static library for the iPhone, perhaps from the UnRAR source code.
I have to link a date and a name to some jpegs that I am including in my bundle, or possibly downloading from my own server to the Documents folder. Is there a way to extract EXIF data easily?
If so, then I will use EXIF to store this info. If not, then I will have to create a database or flat file that maps my extra data to the image file.
Keep in mind, these are not photos the iPhone has taken and is providing via UIImagePicker or from outside the sandbox. These are photos that I am including with the app or downloadig to the Docs folder myself. The important point here is ease:
Is it easier to
read EXIF file from my image files
have another file that keeps track of
the image file and the associated
data (could be sqlite)
Thanks!
You can try using iphone-exif toolkit to extract the data. However, it's licensed GPL and if your app is commercial you'll need to negotiate a license deal. If that's not viable then you may want to go the external meta-data route.
The actual EXIF data is stored in the form of a small TIFF file with EXIF-specific TIFF tags for information that doesn't have a home in the TIFF specification. When placed in a JPEG file (really a JFIF bitstream), it is stored in a JPEG APP1 marker which limits the total size of the EXIF data to just a bit less than 64KB.
It shouldn't be that difficult to locate the APP1 marker, confirm it contains EXIF data, and then parse out a specific collection of EXIF tags with fairly brute force coding.
One example you can look at is exiftool which does just that, and is written in Perl and open source under the same terms as Perl itself.
If these files are purely for use in your own application and will not be reused in other tools by the user, then there is some mileage in storing your data as XML/JSON in the comment segment 0xFFFE. As mentioned before you get just short of 64k to play with.
The beauty of using the comment segment is that it should be preserved by image editing tools, is quick to access (because you do not need to traverse the IFD blocks that store EXIF data, you just read/write a text string with 4 byte type/length header) and is human readable/writable in a graphics app.
I would avoid storing the associated data in a db if practical, so that you don't risk the db becoming out of sync with the available files.
I use ExifTool
embedded in my app. Works a treat.