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.
Related
do we have any command line from where i can query the sqlite database, which is created by coding, and stored in the application's default Documents folder?
Turn on file sharing for the app, copy the database file to your Mac, and use the command line tools (sqlite3) that are there.
(Note to the previous editor: I appreciate editing of answers for accuracy, format improvements, and fixing typos...but, if you want to provide completely different information, I suggest providing your own answer instead of changing the meaning of another user's response.)
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.
i am working on an application that displays read-only data i am shipping.
it is more of a book.
It is easy with SQLite but i am not satisfied with the performance and trying to use Core Data.
The issue is with pre-filling Core Data is that it is a hard process.
My question is:
Is it possible to build an assistant iphone application (for me to use) which uses the same data model for pre-filling.
and then take the populated .xcdatamodel file and use it in my original application?
I hope this makes sense :)
Adham
I believe what you're asking is whether you can create a CoreData database upfront and copy it to the iPhone. Is that correct?
This article will help. Here's a quote:
I thus suggest the following five-step process:
Create your data in a comma-separated file, typically placing each row of data (an entity) in a row of the file and separating different columns (its attributes) by commas.
Write a standalone program and copy in your .xcdatamodel file from your main project.
Write code in your new program that parses your comma-separated file and inserts the information into a Core Data persistent store that should be identical to the persistent store in your main project.
Run the program in the Simulator
Copy your data from the Simulator's documents directory into your actual project's bundle.
It's possible, I've done it. I made a desktop application to read from a CSV file using the code here:
http://www.mac-developer-network.com/columns/coredata/may2009/
I just had to alter the way the CSV part worked, and change the model.
I copied and pasted my model from the model builder into the iPhone model. (Clicked on the "grid" area, selected all, copied)
Then I took the sqlite database the desktop app produced (found it in Application Support, in the folder for this application) and put it into the resources folder
I made some code to copy the sqlite into the documents folder on the iPhone (if it wasn't already there) at startup, in the applicationDidLaunch method. It's possible that having it in the resources folder is no good. Even though you're using the database as read only, Core Data may want to write something to it. Not sure about this though..
I used the sqlite file in the documents folder in my Core Data set up.
The desktop and iPhone Core Data sqlite file seem to be exactly the same format. You can transfer one sqlite file to another application (iPhone to iPhone too) as long as they have the same data model. In another application, I used NSXMLParser to create the Core Data sqlite file, then transferred it to another app, both on iPhone using the Simulator.
Yeah, your data source can be whatever you want it to be. The other suggestions are good ones. Create a managed object model (.xcdatamodel) identical to what you want to use in your app. Read in the data from your file, create a new instance of your managed object and populate it from the file. Then save, and dive into the bundle in the iPhone Simulator and copy it over. This has the added bonus of being in exactly the format you need, with all the helpful metadata. Copy your object model and your managed object classes and you're good to go.
Note, though, if you really intend for it to be read-only, and you're using it at install, it will be installed in your finished app's bundle (under Applications/{SIGNATURE}/Myapp.app). If you intend to edit this database or allow a user to save to it, it's a better idea to copy it to the Applications/{SIGNATURE}/Documents directory where your user database lives.