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.
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 planning on building an app whose main content are images. Basically, it is going to have multiple menus using UITableViews, whose cells are going to have only an image. When you click the cell, you'll be pushed to a simple view with that image and another one, wich has the rest of the detailed content.
This is all quite easy to do, my questions is about optimization. It's gonna have LOTs of content (Maybe 1k rows) and It's gonna display images in the UITableView, so Core Data is a must (given it's lazy loading and several other optimizations)
My question is: What's best, to store the image in the Core Data db (as NSData) or to just store the name of the image? What I'm imagining is if I store the name of the resource, For each row in the UITableView the device must go fetch that image, process it finally display it. When scrolling trough them (wich is expected to happen A LOT) we would have lots of fetching images. If I store them in Core Data, it would be as simple as taking that info and using it as if it where an image.
The benefits of storing the images in Core Data comes with the normal withdraws of storing blobs in a db. I don't know how much of a problem this would be in Core Data (My experience in dbs comes mainly from MySQL)
On the other hand, tough my "common sense" dictates saving just the name and fetching the images as they're needed its gonna take more time if they're requested more, I'm not sure how much of a performance hit would this be. Is there a "best way" to store them? Just the name and then call pathForResourse:ofType:or (if it's faster) pathForResourse:ofType:inDirectory: on the mainBundle, store the URI, or other form of pointing to it.
edit: The application will have static content shipped with the application and the user won't be able to modify this content in any way. (at least in version 1.0)
From the Core Data Release Notes for iOS v5.0:
Small data values like image thumbnails may be efficiently stored in a database, but large photos or other media are best handled directly by the file system. You can now specify that the value of a managed object attribute may be stored as an external record—see setAllowsExternalBinaryDataStorage:. When enabled, Core Data heuristically decides on a per-value basis if it should save the data directly in the database or store a URI to a separate file which it manages for you. You cannot query based on the contents of a binary data property if you use this option.
The setAllowsExternalBinaryDataStorage: essentially does what you described "...just store the name of the image..."
Also refer to these other questions:
CoreData : store images to DB or not?
Core data images from desktop to iphone
Provide example for why it is not advisable to store images in CoreData?
you will get a great optimization from just using the name of the file...
if you re-use a file ... you wont have to store it in the database twice, or alternately have a model object just to represent that file as a relationship.
You could do some profiling and check... but I assume that just a name would be ideal.
also you could do a little work to make something similar to -imageNamed that caches the images for you, and you will only have to make one UIImage for each file, wherever it exists in your program.
Don't save the images in core data. You can save the information pertaining the images in an organized matter in core data, but keep the images ordered in a supporting files section in your project. Or if you are downloading the images, you can cache them in your images section of the app and simply update the information for the images in core data.
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.
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 am fairly new to Objective C and iOS programming but am constantly trying to learn as much as I can.
I am about to start an iPad project which will involve storing large amounts of data which will need to be exported to one extremely large excel spreadsheet.(it's for a friend....they currently enter massive amounts of data into excel by hand so that they can analyze it).
This database contains over 400 names(this number is constantly growing) and the app will be very functionally similar to to built in contacts app, except that for each name there will be approximately 2,000 attributes. These attributes will be entered across tens, if not over a hundred views.
The excel file will be located on a local server and the database will be synced with it over wifi. If I have to write a server side application to handle this, I happily will.
My question is this:
What data storage method would serve best for my purpose accounting for the sheer size of the database and the need to export to excel? (i.e. CoreData?, SQLLite?, XML?)
I sincerely appreciate any help you might offer.
James
It'll be harder to create a CoreData store on the server end. I'd suggest using and SQLite DB. FMDB is decent frontend for using SQLite on the iPhone, but there are many others.
A framework for relational data such as Core Data or SQlite would work well for selecting and working with subsets of data. There's no innate export-to-Excel functionality but you could export a csv (comma-separated-value) file that Excel can import.