i have a more or less general question about using coredata the most efficient way.
i have attempted two different approaches of managing data that is shown in a view of my project.
Approach 1: when the view gets loaded i perform all coredata fetches and store the results in an array, the view then retrieves the displayed objects from the array. (ie: objectAtIndex:...)
Approach 2: the viewcontroller itself lets my data handling class perform fetches on the go, whenever a specific coredata object is needed it gets fetched.
on my current project this involes about 200-500 objects that need to be sorted and displayed in a tableview according to their attributes.
the fetch methods are the same wether i load all objects first or when i load them in batches (of correct attributes).
the difference is mainly in the cellForRow method where i have to decide if i want to pick the objects out of an array or directly from coredata.
both methods work just fine, i dont really see any performance differences just now, but i fear that with scaling of the project & more data one or the other way might be slower.
what do you think is the better way to do this?
With larger data sets there may be an advantage in terms of peak memory footprint to using NSFetchedResultsController controller that is, presumably optimized to fetch just the right amount of data from the persistent store based on the table size.
With NSFetchedResultsController you have control over the fetch batch size which you can tune for performance based on the size and number of the managed objects being fetched, etc.
Related
This is similar to a question I asked before, but now that I've come much further along I still have a question about "proper" subclassing of NSManagedObject as I was told last night that it's a "bad idea" to put lots of non-persisted properties and ivars inside one. Currently I have TONS of code inside my NSManagedObject, and Apple's docs don't really address the "rightness" of that. FYI: the code works, but I'm asking if there are pitfalls ahead, or if there are obvious improvements to doing it another way.
My "object" is a continuously growing array of incoming data, the properties/ivars that track the progress of the analysis of that data, and the processed data (output). All of this is stored in memory because it grows huge, very quickly, and would not be possible to re-generate/re-analyze continuously. The NSManagedObject properties that are actually persisted are just the raw data (regularly saved, as Core Data doesn't support NSMutableData), a few basic properties and 2 relationships to other NSManagedObjects (1 being a user, the other being a set of snapshots of the data). Only one object is being recorded to at any one time, although dozens can be opened for viewing (which may involve further processing at any time).
It's not possible to have the object that inserts the entity (data manager that manages Core Data) have all of the processing logic/variables inside it, as each object necessitates at least a handful of arrays/properties that are used as intermediaries and tracking values for the analysis. And I, personally, think that it sounds silly to create two objects for each object that is being used (the NSManagedObject that is the store, and another object that is the processing/temp store).
Basically, all of the examples I can find using NSManagedObjects have super simple objects that are things like coordinates, address book entries, pictures: stuff that is basically static. In that case I can see having all of the logic that creates/modifies them outside the object. However, my case is not that simple and I have yet to come up with an alternative that doesn't involve duplication.
Any suggestions would be appreciated.
You might use a 'wrapper', that is to say a class with a reference to one of your managed object instances, this wrapper would contain your algorithms and your non persisted algorithms.
My program should save, retrieve and manipulate a large load of data. (Around 200,000 entries, which all have around 20 entries.)
I'm wondering how I should implement the data: create my own class, use a struct or use NSDictionary.
The whole data would be saved in an array (for going through the whole data). But since performance matters (particularly the searching part) I would like to chose the fastest and savest way.
Any suggestions?
CoreData with sqlite store type is the way. You'd be able to fetch portions of data without reading the whole thing to the memory at once. This way you'd be able to generate custom NSManagedObject subclasses if you'd need custom behavior for each instance of an object.
I'm fairly new to iOS programming and am struggling to decide on what is the best way to encode memory intensive objects using the NSCoding protocol.
I have a large number of Item objects. Each Item has numerous hi-res images associated with it. Additionally, each Item belongs to an ItemCategory, which may contain 100 Items.
As far as I can tell, I have a couple different encoding options:
Encode the entire ItemCategory object
Eliminate the ItemCategory class, create just an itemCategory property for each Item, and just encode the individual Item objects.
It seems to me that #1 would be wastefully expensive. In order to add a new Item to the ItemCategory, I'd have to decode the entire ItemCategory (which means decoding those hundreds of images tied to the Items it contains as well), add the Item, and then re-encode the whole thing (again, along with all those images).
But, #1 does seem to be the correct way to do it from a code-structure point of view. #2 forces me to come up with a less intuitive way for storing Items and associating them with their respective ItemCategories.
If I were to go with #1, is there a way to decode only certain parts of objects, so that I don't end up with all those images getting initialized when I don't actually need to display them? One thought that occurred to me is to not actually encode the Item's UIImages along with the Item itself, but rather just the image name. That way, the image would only get initialized when necessary, and could be released without releasing the entire Item if so desired. I suppose this is kind of a relational database type of approach.
I feel like there must be a standard way for handling a situation like this, no?
Or is my fear over memory consumption unfounded? Perhaps this could be seen as an example of "premature optimization", but the decision I make now will deeply affect the data structure of the application. Changing from option #1 to #2 down the road wouldnt be pretty :)
Perhaps you can use CoreData, and a persistentStore. CoreData makes it easy to manage relationships. You can create entities that have relationships that are managed by the system. So in your case, perhaps you can have an 3 entities: Category, Item, and Images, and a one to many relationship between Category and items, and a one to many relationship between Item and images, meaning that each category can have multiple items, and each item has multiple images, then when you need yo you can create new images and add them to a particular item, or search for all the images within an item.
I hope that this was clear, but CoreData is great for managing relationships and the data model is very easy to work with.
I have a UITableViewController, I have 4 types of tabular data to present in the same format. Is it better to use one UITableViewController and reload data each time I need to present data, or should I create four UITableViewController instances with its own data source?
Points I considered (which I'm not sure if true):
I could save resources by reusing one instance of UITableViewController.
However, always calling UITableView's reloadData before presenting the grid might have impact on performance.
What is the best approach in terms of performance / memory consumption / best practice? Or is there no difference? Hope I am clear.
Update: To be exact, I have popover controllers with a table. I use it to as a "Selection Screen" for various fields in my screens.
The number of fields needing the popover are dynamic, so there can be 4 in one screen or upto 10 in another screen. The dilemma is should I create multiple instances of selection popover (one per field), or should I just use one selection screen and reload the data per field?
Short answer :
It doesn't really matter unless your data sets are massive (thousands of rows). Whatever is easiest for you is fine!
Long answer :
I would have a different one per data type - it's probably going to be a slightly more responsive ui if you do (as you pointed out, this comes at the cost of more memory usage).
However, I would use delayed instantiation i.e. only create them the first time they are asked for.
I would also release them if I received a low memory warning notification and they weren't visible.
Sorry if this seems like a silly question - I am an amateur when it comes to Objective-C and Cocoa and even less knowledgable when it comes to Core Data usage.
So here's the situation: I have an NSOutlineView that I've already populated with a few items manually with an NSTreeController. What I need to do now is take the items in one of my Core Data entities and append them to the NSOutlineView's current contents.
Obviously this is beyond the abilities of bindings, so it will need to be done programmatically. What should I do? I assume that I need to do a fetch and then iterate through the returned items, adding each to the outline view. Is this correct? If so, would anybody be able to show an example of how this is done?
Thanks!
Create an NSFetchRequest with an NSPredicate that gets only those whose "parent" is nil (the root/top-level objects). Sort them by some attribute that makes sense (as the fetch results will be an unordered collection - an NSSet). Then implement the NSOutlineViewDataSource to mix/mingle the information as you see fit as it's provided to the outline.
Caution: It's best to cache your results, observing the context for changes and refreshing the cache on each change.