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.
Related
In my iPhone / iPad application, I show a person's medical reports in the form of a PDF. I have saved the reports in the documents directory and am reading them from there.
I want the user to be able to add or edit comments on these PDFs, as well as be able to highlight certain sections in the PDF. After editing, the application should be able to save the PDF back into the documents directory.
Is this possible within an iOS application? If so, how? Is this a task for Core Graphics?
Editing PDF directly on iPad/iPhone is a rather big job because the standard API only supports showing it (and only a bit more.) If you want to do anything more, you need to invest a huge amount of time to implement generic pdf handling code.
There is an open-source library handling these, e.g. this one. I don't know if it fits your needs, though.
A better idea, in my opinion, is to create a native UI showing the data contained in the PDF file using the standard Cocoa-Touch UIKit and create the PDF once the user is done with it so that the user can export it back. That way, you don't have to write a complicated PDF handling code.
In any case, it's not a good idea to show generic PDF on iPhone, because the screen size is so small (iPad is a different question, especially if you expect the user to be familiar with the particular format of your pdf.). A dedicated UI would be much better.
I'm currently developing a simple text editor for iPad, and only save/load data parts are left. As a novice programmer, I don't have any experience with data managements in other languages and development environments. I researched on Core Data for a week and implemented a basic auto save/load feature in my app. But I have questions about better design of a text editor's data management such as saving text to *.txt files.
Which way is better? How do other text editors
1) Saving/Loading text as *.txt files
I found that in iOS 3.2 and later, the app can save and load (sync) texts as *.txt files into its local folder, so the users can load files in iTunes easily.
My question is that to implement save/load features, can I just save each text as *.txt file in my local folder and load them when launching my app? Specifically, can I just load titles of each *.txt file and load the entire NSString content only if the user clicks the specific file in UITableView??
So it doesn't use Core Data (or maybe Core Data is just used for a current text for auto save).
2) Core Data
Or using only Core Data is better approach? So when only the users want to save text to a *.txt file, the app saves a Core Data object or NSString content to *.txt file. In other words, unless the users manually save text as *.txt files, the users can't see any *.txt file in iTunes because Core Data internally saves them.
3) Both 1) + 2)
Would it better to save text as *.txt files and also using Core Data? I think it's just wasteful though.
Sorry for long questions. Thank you!
Apple strongly suggests in their Human Interface Guidelines that your users must not have "press save" to save, but rather saves should be automatic. At this point, iOS users do indeed expect that behavior. Core Data and autosave work really well together. (Core Data is also great for implementing Undo/Redo functionality as well.)
Therefore, I would suggest using Core Data as the app's internal format but offering the ability to export to other formats, like .txt. They are really not mutually exclusive methods. To export .txt files, you would create the .txt file in memory and then write it to your app's documents directory, which is what iTunes reads from. It's not very complicated.
Good luck!
I think you should use text files. So you can save space and sync into iTunes.
I'm using an NSXMLParser to read data out of a XML, but how can I make my iPhone App storing data into this specific XML.
The case is that I want to create an app to display available dates and one that administrates this dates, whether they are available or not (I'm using an UISwitch to handle this).
Thanks for your answers,
btype.
If you have small amount of data, you can save them in a plist.
See Property List Programming Guide
There's a github project that let's you create XML DOM objects. You can save your XML to your documents folder on the phone.
https://github.com/arashpayan/apxml/
Is it possible to create a page with formatted text that is stored in core data. The text would need to be displayed with paragraphs and a few images. I have already written the code to create a PDF with one line of text, but I am unsure of the pattern needed to layout the PDF in a nice document way. One of reasons is I had to write the code in C. The data that will be in the document is of course In core data. And I do not know what the best practice is for what I am trying to do.
Unless you have a particular need for PDF, the best practice is to use HTML and UIWebView. WebView is the primary formatted-text displayer for iPhone. iPhoneOS 3.2 added CoreText, which is another option if you have serious layout needs, but it generally isn't needed for simple formatted text and data.
The Text and Web Programming Guide includes a good discussion of your formatting and layout options. Generally UIWebView is still your best bet.
I am quite sure NSData (your c bytes) could be stored in NSManagedObject.
Even if not. Why don't store only metadata in CoreData? Is much more simpler for example: info needed to render the page wanted, etc.
I am not sure archiving the hole PDF in CoreData is a good approach.
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