I have huge array with NSobjects. While storing to file iPad is getting memory issues.
I want to store each object in file one by one and again read it back. Any suggestions?
I would recommend Core Data. It handles all the heavy lifting in regards to memory.
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/cdProgrammingGuide.html
http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreData/CoreData.pdf
Alternatively if Core Data feels a little heavy you could implement the NSCoding protocol.
Apple provide a code example here
Related
I'm about to implement caching on my app, I imagine there are already good patterns on how to do that.
I think I'm going to use Core Data but I was wondering the best way to do that.
Most of the doc I found are just for Core Data tutorial.
What I do is to generate the NSManagedObject but then I also use a similar class with my additional methods, this to be decoupled from future fields addition keeping the generated one independent.
Is there some tutorial on the best way to handle object caching with Core Data?
Thanks in advance.
For keeping the hand-written code separate from the machine-generated code when using Core Data, have a look at mogenerator. Very useful.
As far as caching goes, Core Data's pretty decent, and with judicious use of batch faulting and pre-fetching, you can fairly easily manage the number of trips to the persistent store. The faulting mechanism works well in my experience, so be wary of premature optimisation when it comes to Core Data.
The advice Apple gives here is good, in particular use the profiling tools to see the part of your app that isn't working efficiently, and then address that specifically, rather than spending time writing code for a problem that doesn't exist.
Caching to file system is discouraged on iOS. Use Core Data for permanent storage, not temporary caching when possible.
There are however two in memory caching facilities provided by Apple.
NSURLCache for caching responses using the URL loading system (NSURLConnection and friends.). Simply create a new instance, and set it using +[NSURLCache setSharedURLCache:].
NSCache for caching any object. Just create an instance, add and fetch cached object using keys like form a normal dictionary collection. Supports both count and cost limits, as well as locking cached objects using the NSDiscardableContent protocol.
You could also use a in-memory NSPersistentStore for Core Data if you like to work with managed objects, that are only to live for one execution of the app.
I am relatively new to iOS and programming, and I made an app before, but it used a plist for storage, which I saved to the documents folder. Now, I am thinking about switching over to Core Data, but it looks a little complicated, and I'm not sure if it will work for what I want. I am going to have a bunch of data which I need to graph, so I'm not sure if Core Data is best for this, as it seems that I cannot create an array type in the .xcdatamodeld file. What are some other advantages of Core Data? Is it faster? Easier to use (once you set it up)?
Update: For anyone wondering, I finished the app, and it was totally worth it to learn how to use Core Data, and it was a lot less complicated that I originally thought. Doing it with plists would have been hell. The way they go about doing it seemed a little cryptic at first but if you just start using it you will get it. The relationships are really what is awesome about it.
A few advantages off the top of my head:
Much better memory management. With a plist you must load the entire thing into memory; with Core Data only the objects you're currently using need to be loaded. Also, once objects are loaded, they're normally placeholder "fault" objects whose property data doesn't load until you need it.
Related to the above, when you have changes, you can save only the changed objects, not the entire data set.
You can read/write your model objects directly instead of converting them to/from something like an NSDictionary.
Built-in sorting of objects when you fetch them from the data store.
Rich system of predicates for searching your data set for objects of interest.
Relationships between entities are handled directly, as properties on the related objects. With a plist you would need to do something like store an object ID for a relationship, and then look up the related object.
Optional automatic validation of property values.
Data models don't use arrays, but "to-many" relationships are modeled as sets.
It's a matter of what you're saving. For simple strings, arrays, dictionaries, it's fine to use a plist. For something more complicated (data, images, non-object information) or something with to-many relationships (think relationship between song to album, or photo to photographer), then something like a more robust solution might work better like SQLite.
CoreData is an objective-c-based wrapper around SQLite. If you think you might want to something more complicated, CoreData might be the way to go.
If you need a quick tutorial, I'd check out: http://www.raywenderlich.com/934/core-data-tutorial-getting-started
This got me going and allowed me to learn the basics the workings of CoreData.
Good luck!
I would simply like to create a file that stays around after the program quits. I would like it to contain objects that I have initiated, is that possible? Or does it just have to have text in it? How can I access that file later? Also, is this done the same way on the Mac and the iPhone?
Take a look at Core Data or SQLite. Apple has some sample code for them, not sure about SQLite because they prefer you tou use core data.
I will direct you to this question. Adding core data to my iPhone app
Or use NSUserDefaults: Best way to save data on the iPhone
Yes! It's possible.
Derive your objects that you want to persist from NSCoding. On those objects, implement the initWithCoder and encodeWithCoder functions on those objects. In these functions, write all of your primitive types to the coder (or read them) using the functions here http://developer.apple.com/library/ios/#documentation/cocoa/reference/foundation/Classes/NSCoder_Class/Reference/NSCoder.html
When you want to save your file, use an NSKeyedArchiver and pass in the object you want to archive along w/ the file name.
[NSKeyedArchiver archiveRootObject:root toFile:string];
More examples here https://stackoverflow.com/questions/2805026/iphone-problem-in-saving-file-using-nscoding
I have used SQLitePersistentObjects in the past to give my Objective-C class objects an ORM-esque feel and behaviour. The objects itself translate into corresponding tables in the database, which in this case is a simple SQLite database file.
Archives and Serializations Programming Guide might be interesting as well.
I'm currently writing a Twitter client for iPhone and need a way to cache the public timeline. The data fetched is stored as 'Status' objects in an NSMutableArray.
The NSMutableArray stores 20 objects at a time.
What is the best way to do this?
You will probably want to use Core Data. You'll need to create an entity for each tweet, and then store that in your database. There is quite a lot of documentation and sample code on Core Data out there; start at Apple's Samples page.
If you don't want to play with one of the frameworks already mentioned (SQLitePersistentObjects and CoreData), you could implement your own using the NSCoding protocol on your status objects. The array should already implement NSCoding for archiving/unarchiving.
If you want to start quickly try SQLitePersistentObjects.
If you never plan to go over 20 objects you could (slightly) violate some rules from the gods of apple, and use NSUserDefaults - likely the easiest one to implement, but as the name implies, made for things like user settings, so don't use for big piles of info.
Disclaimer: If you know how to use the others, use them, this one is kinda the lazy way if you don't want to learn something better but more difficult.
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.