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...
Related
I would like to know how can we manage our domain Model and NSManagedObject Model. My scenario is I have to show last 5 comments from coredata which I fetch from coredata manager class, and it returns 5 objects of Comments (:NSManagedObject) object. now I want to to fetch next n number of comments from our server API and will parse them into my domain model object Comments( inherited from NSObject).
Now I have two types of object which logically represents the same object. I want to know best practice/design pattern, how we should handle/implement this.
One obvious solution is to loop through NSManagedObject Model and populate 5 new models of my domain object derived from NSObject and then continue to fetch these objects from my APIManager class. But I want to know the best way if there it is any.
First of all, CoreData is not thread safe, so don’t use those comments objects into the controllers or the views. Isolate core data in a separate layer and transform these objects into a view model or some other form of immutable struct for the view.
Second, you can use a nsfetched result controller in a “provider” class to keep you informed automatically of what are the last 5 comments. A delegate can inform your view of when this provider data change.
You can refresh your server data in background with your api ma manager and when you get the data back, store them in coredata. If you used a nsfetched result controller, you won’t need to do anything else as coredata will automatically notify the object you setup to return you comments
I wonder 4 questions about the data model when creating iOS apps:
Do you create a class called DataModel and inside there we find arrays and objects that belong to the data model that is instantiated by every model? Or do you create a data model that is a singleton and has the app state? I guess singleton is not a good idea because is difficult to test.
Where do you write your networking code and mapping code (converting json files into data model objects)? I guess it should be an object inside the data model.
I understand the model encapsulates app state, for that reasonI I guess if we have a table in controller A and the detail in controller B (using a navigation controller), maybe we have to create an instance of the data model that holds ‘selectedStudent’ and then once the B controller is pushed, it uses the model to know what student was selected.
That’s what I understand from this image:
http://naikom.ru/img/2012/ios2/8.jpg
However from this image;
https://littlehales.files.wordpress.com/2012/01/mvc2.jpg
I see that there are several models and controllers communicate each other, so in my example, using prepareForSegue I could pass the selectedStudent to the other controller. If we do that, then the controller is encapsulating state, rather than the model.
Can you explain to me how I should do that? Or how do large apps do this?
According to this diagram:
http://i.stack.imgur.com/Psi8i.png
In order to send information from the data model to the controller we have to use NSNotificationCenter or KVO.
I know the problem of delegates is that they are just a 1-to-1 relationship, so probably not good idea. What about blocks or creating your own observer using a protocol and addObserver/removeObserver (using an array or a set)? Do you really use for this NSNotificationCenter or KVO in the data model?
I have the following datamodel to manage measurements (heart rate and skin response)
When I'm acquiring a new measurement it's going to be an entity of "MinuteStress"
Now I want to programmatically check if a corresponding day and month entity exist and if not create one automatically and add my measurement to their average.
My first question would be: Where is the right place to check for the super entities? Is it a good idea to do this in the NSManagedObjectSubclass of "MinuteStress" or is it better to do so after I create the entity in my viewcontroller?
My second question would be if there is a smart way to create super entities from a sub entity?
In theory you can do that in the awakeFromInsert method of your NSManagedObject subclass, but that's a Bad Idea (tm) because you can trigger other Core Data events... see the "special considerations" section under awakeFromInsert in the Apple Docs for more info.
You'd be better off to query for the superclasses in the view controller and create them if needed, then create the MinuteStress instance.
You might also want to write some convenience methods for creating related child objects (like -(DayStress *) createDayStress] on MonthStress for example) where you create a child object and automatically set its parent reference (and any initialization values) before returning it. It makes the code flow in the view controller much nicer IMO.
I'm fairly new to iOS development, so I need some advise.
I'm working on a project (creating a character sheet app for an upcoming table top RPG), and I seem to have put the cart a bit before the horse.
I've already created a subclass of NSObject called characterClass that holds everything I need for a single instance of the character sheet. It also has methods to calculate derived information. I have 2 more classes storing abilities, and have them in NSArrays in the characterClass. Now that it's working, I need to work on data persistance, and storing/retrieving multiple characters.
I'm thinking, of using Core Data, creating a separate entity that matches my characterClass, and having a characterClass init method that pulls the data out of Core Data and puts it into the current instance of characterClass. That seems a bit obtuse to me, (implementing a class separate from the entity) but maybe it's a good way to do it.
I would eventually like to set up dropbox syncing for this information, so whatever I do I would like to have compatible with that. (Core Data with XML files as the backend?)
What would be the best method for something like this?
Rather than just pull the data out of Core Data and use it to create your character class, you could just tweak your character class so that it is an NSManagedObject subclass. That way you are storing your objects directly in Core Data
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.