I would like to know if anyone knows if it is possible to subclass a Core Data Model.
In my case I am developing a library that I would like to use in 2 projects. Both projects have nearly the same Data Objects that i would like to outsource into the library, because there are some classes and methods in this library which requires to know about the existence of these Entities.
Some ideas on that?
It would probably be more stable through future releases to add a Category on NSManagedObjectModel, instead of subclassing it.
Related
I was talking to several developers which approach is best in objective C according to latest trends?
For example: if i am populating data from server in json form, which approach should i use?
I have seen my friends populating data into json objects in past as well as fewer of them in NSdictiory,NSMututable Dictionary, what apple recommends data structure wise?
any help would be appreciated.
I personally greatly prefer custom objects (or Structs for Swift) because it lets me more easily tell what properties the objects have. If you are just passing around dictionaries it makes it much harder (in my opinion) to remember what object you have, what keys it has, and maybe what nested objects it has too. Whereas if you have named classes (again, these ought to be Structs in Swift), then you (and the compiler) can easily know what properties they have. Plus you can easily create instance methods for your objects.
And if you don't want the pain of parsing them yourself there are frameworks that will manage parsing the server response into objects (e.g. RestKit https://github.com/RestKit/RestKit).
If you consider example code from Apple as a "recommendation" from Apple, you can see the way they make a data model in their "Start Developing iOS Apps" here: https://developer.apple.com/library/ios/referencelibrary/GettingStarted/DevelopiOSAppsSwift/Lesson6.html. Yes the example is for Swift but most concepts are comparable.
Apple also has "Cocoa Core Competencies" (https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/ModelObject.html) where they define a modal object as "typically a subclass of NSObject or...a subclass of NSManagedObject."
just started iOS 7 development. I'm building an app which stores a user profile. Certain data, like photos and reviews, need is related to multiple users.
From researching, I found that Core Data essentially provides this type of relational DB. But super n00bie question - is a Core Data the same as a Singleton? Which should I use for accessing user data across multiple viewControllers?
If I go the Core Data route, it seems that I'll have instantiate a Core Data object in every ViewController. Doesn't that seem excessive??
With Singletons, I won't have to do that, but I'll need to have proper thread management.
Sound right?
CoreData is an object model framework, and a singleton is a design pattern. This isn't even comparing apples to oranges, because apples and oranges are both fruits.
But your question makes it seem like you want to know how to access your data throughout your app. There are a few common patterns for this.
You typically use one or more instances of NSManagedObjectContext. You can pass this instance along to each view controller. Or you can have some singleton object which has a reference to the NSManagedObjectContext. This singleton is often the App Delegate, especially since the built in Xcode templates already come with a reference to your NSManagedObjectContext in the App Delegate.
it's not the same thing at all.
Core Data allows you to create subclass of NSMamagedObject which are object representing table in a sql data base stored on disk.
singleton are unique instance of any class (usually if not never an NSManagedObject).
read on wikipedia about singleton it's a good article.
both have nothing to do with iOS7
I've been dealing with Core Data for the first time and I wanted to know what the best practices are for extending the classes that Xcode generates for my NSManagedObject entities.
I saw mogenerator and I've been also using a similar approach to that as suggested in SUPER HAPPY EASY FETCHING IN CORE DATA.
So I had three kinds of classes:
The EasyFetching category (only one class);
A generated NSManagedObject subclass (i.e.: _Entity);
A custom subclass with some custom methods like finding all the inactive objects, clearing the cache for an object, etc. (i.e.: Entity).
This approach let me do some custom code while I could refactor my Core Data entity and generate it as many times as I needed. But I've also run into some problems like not being able to declare object level methods for my entities (because the NSManagedObjectContext only knew my _Entity classes).
Now I'm using categories to extend my entities functionalities. And this works a lot better because I can have custom object level methods. I now have three kinds of classes:
The EasyFetching category (as it has a lot of methods that all my custom code uses);
A generated NSManagedObject subclass (i.e.: Entity);
A custom category for my NSManagedObject entity (i.e.: Entity+Custom.h).
My question is: what would you recommend?
Thanks in advance for your answers
Now that you have posted your question as an answer on my question,
I thought I should answer your question :)
Mogenerator doesn't look bad, give it a try.
Also the way you suggested with categories is also a fine option.
Infact here is a link that exactly explains How to do so.
I have a new project, kind of a board game, and I'm using a storyboard which has multiple view controllers in it - the game simply moves from one view to the next with the player making various decisions and then loops back.
I have an object which holds information about the player (along with a couple of methods) - the score etc. I obviously only need one instance of this object and as I want each View Controller to access the same instance, should it be a singleton? I've never used them before and I've read they're often over-used, so I just want to check if this is the correct way to do this from the start. Many thanks.
What you have described is the Model for your application, holding the game data and core logic. Is there any reason to make this a singleton rather than passing it between your controllers?!
I would assume one controller calls the next and so can pass this information across?! We use singletons for services and the like but not for model data, it's not really the point of them in our experience.
I personally have nothing against singletons, as long as you don't use too many of them in one project. While other people might recommend you use some other mediation for this project, I say go for it—this is exactly what you'd use a singleton for.
Singleton's can be be bad if you are developing a library component, a large server project, or for unit testing. But since you are doing an iphone game don't fret about it, it'll will be easier and faster just to use a singleton.
If you are worried about unit testing, since objetive-c is latebound and singletons are made with factory methods instead of constructors it's not hard to changeout the singleton for your unit test anyway.
When do you recommend integrating a custom view into Interface Builder with a plug-in? When skimming through Apple's Interface Builder Plug-In Programming Guide I found:
Are your custom objects going to be used by only one application?
Do your custom objects rely on state information found only in your application?
Would it be problematic to encapsulate your custom views in a standalone library or framework?
If you answered yes to any of the preceding questions, your objects may not be good candidates for a plug-in.
That answers some of my questions, but I would still like your thoughts on when it's a good idea. What are the benefits and how big of a time investment is it?
It's perfectly reasonable to push the view and controller classes that your application uses out into a separate framework — embedded in your application wrapper — for which you also produce an Interface Builder plug-in.
Among other reasons, classes that are commonly used in your application can then be configured at their point of use in Interface Builder, rather than in scattered -awakeFromNib implementations. It's also the only way you can have your objects expose bindings that can be set up in Interface Builder.
It's a bit of coding, but for view and controller classes that are used in more than one place, and which require additional set-up before they're actually used, you'll probably save a bunch of time overall. And your experience developing with your own controller and view classes will be like developing with Cocoa's.
I think the Apple guidelines sum it up nicely.
If you're writing a control that will be used in multiple applications and is completely generic, then creating a custom object is a good idea. You'll be able to visualize the look and set properties directly from Interface Builder.
If your control is limited to one application, or is tightly coupled with your data, then moving it into a custom object really won't buy you much.
It's not difficult to create a custom view, there are a lot of easy to follow guides out there.