We have to write a directory application in Objective-C , we now use plist xml file to read data and write data , and store some data in it .
The plist xml file generated from mysql database , to avoid scaling problems , we have to decide weather to stay with xml plist files or move every thing to SQLLite ? as we estimated the maximum file size of xml is 10MB .
Any Suggestion ?
Another option would be to move to CoreData, which I'd prefer over SQLite.
I would go for a sqllite dbs, with the right wrappers it's very easy to get data and write data without parsing everything and sqllite is very fast...
Heres the issue with switching to SQLite, the file size of the database will be at least 3x the size of the plist. SQLite databases store a significant amount of information besides what the app generates from the user interaction.
As for using a plist over 10MB's, if the user is consistently writing to that file, there will be some noticeable delay unless you place the writing on a new thread.
You can always try CoreData as well. Even with this option, you will need to restructure and move your data. This will also require a ton of new code to your application.
You should also look into NSCoding and NSKeyedArchiver, which is almost exactly the same as an XML Plist, only it's a binary format (so much more compact) and it's faster, and it supports pointers (so if the same object is in multiple places when you write the file, it will still be the same object when you read it).
Generating an NSCoding file from a MySQL database could be a challenge (I've never tried), but you could always generate a plist, and then immediately convert it to the binary format once it's on the device.
My rule of thumb is if it fits in RAM you should use NSCoding, if it doesn't fit in RAM you should use SQLite or Core Data.
I would always avoid XML on an iOS device, disk space is at a high premium. Obviously sometimes you need XML though, especially if you're going to allow the user to import/export files in and out of your app and they expect something XML based.
Related
Is storing NSAttributedText including NSTextAttachment for images, or NSTextStorage into Core Data as binary data a good solution performance-wise?
Do I need to store it as Binary Dataor is there a better alternative? Maybe Transformable? Consider that I need to save it while typing, and this should sync in iCloud with a test editor on iOS.
If not, what would be the best practice to store rich text documents in my app?
thanks
In most cases it is no good practice to store large binary objects in a database. Especially if you write such objects very often (while typing) you stress the database more than necessary. Why not store the data in a file and use the database just for metadata?
With a CloudKit container you can share the files between devices like you already do with the database. Maybe you can the store the NSAttributedText in HTML format, so the files can even be read without your app.
I am writing an iPhone app which would download articles (UTF8 text files) from my server. The app is then supposed to produce a listing of the filenames. Upon clicking the filename, the file contents would be displayed. It is very similar to an email program or RSS reader.
My question is, what is the best way of saving / retrieving the content on the device? One option is to put it all into a sqlite db. The other option could be to download the contents and save it in a new file. Any other solutions?
Any advantages/disadvantages for these approaches?
Thanks in advance
For some rather small amount of data in a simple structure you could store it in an NSMutableDictionary and use its methods for writing the content to file and for reading from a file.
Your data structure seems to be simple enough for that. If the amount of data is small enough I cannot say. If your list may grow endless then you shoud go for sqlite or for core data rather than a simple dictionay. A dictionary will be stored completely in RAM. With sqlite ore core data you can utilize RAM more efficiently by loading not much more records as are curently displayed.
I hope all of you have had a good Christmas :-)
In my app i have a database, using Core Data, that requires a lot of data, at least 1.500 records consisting of 6 fields. That means at least 9.000 lines of data. All data is pure text.
During the development phase i have 250 records to test on.
The way i do populate the DB at this point is that i have a text (.txt) file, which i edit in Word and then reads into my database. This is very inconvenient for many reasons such as if i save it, by mistake, in the wrong format it all screws up (i have Swedish characters that changes).
Given the amount of records i will need i would like to ask for advice how people do these things and what to use? Is there some sort of (free) database available that i could use etc.
Cheers
For editing use notepad, notepad++, or gedit. You won't have issues with MS Word specific characters.
I am not too familiar with Core Data, but I believe it uses SQlite on the backend.
I have implemented SQLite directly into a few developments that I have worked on. It might be worth your time to take a look.
Can you give more details about your app? Platform, how often data is accessed, how often it is modified, etc.
Hmm, one way to get started on this might be to fill the Core Data store a single time, and then, whenever you need to run your tests, just copy this store file out of your application bundle into your documents directory. I maintain a "Reset All" function in a game I've worked on using this method, and it works great for very quickly populating Core Data.
Hej,
currently I am developing an app with very similar requirements - a prepopulated Core Data database with 1200+ entries with more or less the same amount of fields.
The data I receive is in xml format. I've written a small mac app which features the same core data model as the iphone app does - it will read the xml and create core data entries accordingly. I then take the database file my mac app created and add it to my iphone apps bundle, from where it will be copied to the documents folder on the first launch (or whenever a reset to the factory data is required).
This is working perfectly, I think you could do something very similar. The only difference would be that, instead of parsing xml, you'd need to write something that reads your textfile. Fear not, it's easy to do!
I've taken the approach to add a unit test that determines if the database exists. If the database doesn't exist, the test creates it from a text file (usually a plist or csv).
This approach enables me to: alter the underlying data via text, "clean" the database by simply deleting it, and run tests against the data. Since you're using CoreData, there might be some additional benefits by ensuring your schema matches the dataset; I once found I'd accidentally set an attribute to not allow nil.
I want to create and manage a database with images and or audio clips. I know it's not the best idea and I know there are better options, but it's the easiest way to have the data separate from the programming and I'm not the one writing the code. So I need an application that will allow me to edit the database that the application is calling, and the application needs to call random audio or image file. I JUST NEED TO KNOW OF AN SQL EDITOR.
Super bad idea to put large files in a database, it will kill performance and could well blow away the memory limits an application has. You also cannot stream them out of the database the way you can from the file system.
Instead, consider this approach - as Alex suggested, work with separate files and strings that represent file names. You could put both the database and the files into a single directory, that your coder keeps as a folder reference in XCode - so all content in the folder you change is added to the coding project automatically. Note that if you change any existing file, due to a bug in XCode he'll be required to do a Clean BUild before building again or it will not copy changed assets (mostly a problem for the DB).
Then you can easily use any SQLLite client to maintain the database of filenames and other data. "Base" is a nice standalone app.
I would highly recommend you use some source control system like Git so that you could check in changes and the programmer could get his project updated right away without the confusion of emailing files around.
You could use Core Data instead. It uses a SQLite backend, by default. Instead of using BLOBs, you can simply store an NSString* that is a path to the object in the application's Documents folder. When you want to retrieve a stored image or other large binary data object, you can load an NSData* instance from the path value directly. Keeping large files outside the database will give you much better performance.
Lets say I make an App that enables users to make short notes and write things down.
Is there Core Data on iPhone OS too?
Or how else would you save that data in iPhone?
No. Core Data, and Cocoa Bindings, as well as Objective-C Garbage Collection are all missing from the iPhone.
Update: As mentioned below, Core Data is available with iPhone OS 3.0.
If you can wait for iPhone OS 3.0, Apple's preview movie lists Core Data as one of the new features in 3.0.
SQLite is generally the preferred storage method if you have a lot of data. You can code the SQL classes by hand, or there are a number of nice third-party solutions.
For smaller amounts of information, you can easily store data in a file using NSCoding and NSArchiver.
I'll reiterate the above, but you could have a look at OmniDataObjects which provides Core Data-esque functionality and runs on the iPhone.
If you have to do some ordering or querying on the saved data, the best solution is SQLite.
Otherwise you can use serialized data. NSDictionary and NSArray provides -writeToFile methods to write serialized (in xml format) data to file.
Marco
depending upon the complexity, you can save your data on sqlite database, plist files, or even create your own xml files and save them on iphone file system (usually in the documents directory)
if you dont anticipate too many reads / writes / complex lookups then stick to plist files or xml files
however anything more complex, go ahead with sqlite.
if you do go ahead with sqlite then i would suggest you to use FMDB - a cocoa wrapper for sqlite, this saves you tons of repetitive code
Data saving on the iPhone is not much different - write the data to a file (like a plist). As far as I know, there's no iPhone Core Data.