In my app an NSArray is created to store various results from a library search. The idea is that each NSArray of results should also be stored locally so that if the search is made again in the future the local results are retrieved.
Now, I've been thinking about two different approaches. The first is to simply make an array in the second view controller that stores the different results arrays. The second is to instead make a class called Search (for example) that has an NSArray attribute to store the results. This object would be initiated in the second view controller (which would then add it to its own array).
Does this make sense? In terms of memory management is one better than the other? Also, I'll need to use the delegate function to get the data across to the second view controller, right?
Thanks
I personally don't see a big difference. To clarify on the second option, create a singleton object that your Search class makes available to any client class (the view controllers). That singleton provides a store function and a retrieve last result function.
You can make this even simpler by just using the class itself - class methods to store and retrieve, and the class then uses a static NSMutableArray (or NSArray) to keep save the objects.
If you want to make this array available across restarts, then use NSUserDefaults. If things in your array cannot be saved in defaults (some objects cannot) you can possibly turn the array into a NSData object and store that (if all objects comply with NSCoding you are in good shape.
Related
There are different levels I'm asking this question at.
Case 1: Let's think about the typical drill-down design. Say a table view controller has an array of custom objects, and tapping a cell will push a view controller that allows the user to modify the object represented by the cell. In this case, should the pushed view controller have the custom object as a property of its own, or use a data source/delegate protocol to edit the custom object but not own it.
Case 2: A similar but slightly different situation is this. I'm using a singleton store to handle an array of bank accounts in my app. A view controller will show a list of the accounts, and I'm wondering if I should have the array of accounts as a property in my view controller or get the array via the store. (The array of accounts is accessed quite often.) I guess the only difference is a single object vs. an array of objects. I'm curious about how heavy these arrays can be, so whether it's faster to load the array from the store each time or have it as a property in the view controller.
Case 3: When should the local file system be used? In my app's example, bank accounts are accessed quite often, so I have them unarchived and set as properties upon launching the app, but for much bigger data, I only load them from the file system when they should be displayed or edited. I'm still not sure what the right way is.
I am learning a bit on NSCoreData and before introducing it some existing projects I have, I would like to validate my good understanding of the core principles.
From what I have understood, NSCoreData make it easier to manage local storage of object (+retrieval after that) by subclassing our Model class from NSManagedObject rather than from NSObject.
Right ?
I have a few questions then. Let's consider I am building a real estate application with as core model object the class Property that can represent an appartment, a house, and all related information. Currently it is managed in my app as a subclass of NSObject.
1) I retrieve the properties from the server through a search query, and have written a initWithJson : method to populate each instance.
Now if I subclass Property from NSManagedObject, I will create my instances by using
+(id)insertNewObjectForEntityForName:(NSString *)entityName
inManagedObjectContext:(NSManagedObjectContext *)context
and I will be still be able to add a populateWithJson: to my class to fill in the properties.
Then I will create a lot of Property instances in the current managedObjectContext, and if I do a save, they will be stored at the physical layer.
If I call again the same webservice, and retrieve the same JSON content, I will recreate the identical managed objects.
How to avoid redundancy with the [managedObjectContext save:&error] call and not to store physically several time the representation of a single real life property ?
2) Let's say I want to store physically only some properties, for instance only the one the user want to have as favorites.
[managedObjectContext save:&error] will save all created / modified / deleted managed objects from the context to the physical layer, and not only the one I want.
How to achieve that ?
Am I supposed to declare another context (managedObjectContext2), move the instance I want to store in that context, and do the save in that one ?
(I mean, I will have a context just to manipulate the object, create instances from the JSON and represents them in UI ... and a second one to actually do the storage)
Or am I supposed to stores all the objects, and add a isFavorite BOOL property , and then fetching using a predicate on that property ?
3) The app has a common navigation pattern : the UITableView lists Properties instance with the minimum information required, and going on a detail view call a webservice to request more information on a specific Property instance (images, full text description).
Is it a good practice for instance to call the webservice only if the property.fullDescription is nil, and then update the object and store it locally with all detailed information, and the next time only to fetch it locally with a predicate on the property.id ?
What about object that might be updated server-side after they have been created?
Thanks for your lights
1) Retrieve the server data into a temporary form (array of dictionaries?), then for each possible property in the array, check to see if you already have an object in Core Data that matches. If you do, either ignore it or update any changed attributes; if not, create a Property object.
2) Decide which things you want to persist in order to support your app's functions. There's no point in creating a managed object for something you don't want to save. Note, though, that Core Data supports sub-classes if you want both Property and FavoriteProperty.
3) Entirely up to your "business rules"…. How often do you need local data to be updated? The only technical consideration might be the guideline to not keep large files locally that can be re-created on demand.
I'm trying to have multiple copies of a single product objects in different view controllers (i.e. you have a product in a shopping list and when you search queries web-service and returns searched products). There is a symbol on search tableviewCell if that product is in the shopping list.
I thought of two ways to do this:
Have an array in a singleton class that caches the products in a NSMutableDictionary by their id numbers and every time a products is created it check to see if there is one in its place. If so it just uses the product already there. I can have a setting in the product that states if it is on the shopping list or not.
Use core data. I tried to implement it but not sure how I can exactly do this. I was thinking of using core data so that when i update a product object it is also updated in other parts of the app using NSFetchedResultsController.
What is "standard practice" for this situation?
Let me know what you think and how you would approach this. Thanks!
You can use singleton pattern for your data manager class, which will hold your data in an array of Models (For e.g.: Product)
If you use singleton data manager (for e.g.: ProductManager) then your data (for e.g.: Product entities) would be persistent for all your class files in application life cycle mode.
Here you can find more information:
Objective C Singleton Class
http://www.galloway.me.uk/tutorials/singleton-classes/
Hope this is what you are looking for.
if the shopping list doesnt need to be written to disk, option 1 is fine. if it does need to be written to disk, you can use core data.. or use sqlite, or NSArchiver. there are a few ways of storing data.
I have a data controller class used within my app that handles parsing xml and a few other operations vital to my app. What I want to be able to do is have the data that it parses store in an array that can be accessed in multiple views of my app. Right now, each view creates its own instance of the data controller class and so the array that the data is stored in is specific to that view controller. Is there a way to still create individual instances of the data controller class for each view controller, but the data is stored in the array where all views can access it? I have tried to store in NSUserDefaults but that doesn't seem the most effective way. Each view controller needs to have its own instance of the data controller class because I utilize delegate methods that are used in each of the view controllers. I hope this makes sense.
You have two ways to implement this (ok, maybe more than two but those are most common):
Store array in application delegate and acces it as property.
Create singleton object who gonna hold array (and other possible data/methods).
I built a Core data model with different entities for my database, on my iPad app. I do want to access these attributes (and fill the dBase) from different viewControllers. For instance, there are UITextFields in viewController A, and another UITextField in viewController. I'd like the seized information to fill different attributes from my Core Data entity...
Is that possible? What is the best practice to do so?
My problems :
I declare the objects with type "entity" in viewController A
I fill different attributes of this entity with the seized text, also in viewController A
I store the objects (same type as my entity) in a NSMutableArray in viewController A
I use different methods to save and retrieve this NSMutableArray in viewController A
Any help or advice would be appreciated! :-)
Here comes the power of MVC. Make a class (model as of M of MVC) which is responsible for you data manipulation - fetching, updating, deleting, etc... Make this class either singleton or add a property in the AppDelegate and take in every UIViewController you need it. Collect all the data from the view controllers somewhere else - eg. some dictionary or something, then call a method of your data class that will insert the data, when ready... Good design always leads to less problems and difficulties with implementation and also makes further changes to the UI easy and fast...