Is there a way to enable an app to use the CoreData framework if the box "use CoreData" was not checked?
I know it could be done by altering AppDelegate.swift but I am trying to find a way to do it automatically
Checking the box "use CoreData" just causes Xcode to generate some boilerplate CoreData code for you (a persistentContainer property and a saveContext() method) and dump it into your AppDelegate. It doesn't need to go in AppDelegate, however, and you can certainly write or import your own persistent container into your app (and frankly, you should).
Checking the box also creates an empty CoreData .xcdatamodeld file to get you started with adding your own entities. Something you can just add yourself at any time.
So if by "automatically" you mean can you add couple files to your app to give you the equivalent code of checking the "use CoreData" box, then the answer is yes.
And you should hunt around for good CoreData swift boilerplate code that fits with the needs of your app. Apple's is just to get you started, and they rudely dump it into your AppDelegate rather than isolating it into a separate singleton, just to simplify for people just getting started with it.
Related
I started new project without core data checked and then I tried to put it in manually. So everything is fine but I have a question concerning Codegen in Data Model Inspector.
When I put class definition in Codegen field my class was redefined in appropriate to core data way so I deleted my old one. And after I saw extension of this new class where I could find all the properties.
So after I closed I couldn't find it in my project but I want to see it again.
How can I make it appear again?
When an NSManagedObjectModel is configured to generate code, it doesn't add that code to your project. Rather, it generates that code into your Derived Data, in the DerivedSources directory for the target the model is a part of.
In Objective-C, you can just use #import "ModelName+ManagedObjectModel.h" in your other code to gain access any of the entities for which code has been generated. In Swift, you don't even need to do that, you can just use the classes that were generated.
If you want to see the code for those classes, you can use Open Quickly (command-shift-O) and type in one of the class names. Xcode should take you right to the generated source code for it.
I will start developing a new project for iOS. I am unsure for now if I should use core data in this project, or not. I will find out along the way, while developing (most likely with some coaching help).
Now my noob question is: Should I, while creating my new project, already check the option 'use core data'? Or shouldnt I?
Basically my question is: What is more difficult, removing core data when I checked the option and I will not been using it after all? Or adding core data when I did not check the option and I will be using it after all?
I have found it is not super difficult to add after:Implement CoreData into an existing project using Swift
But still, it seems like alot of hassle, so I now ask u!
Thanks for the answer in advance
It doesn't matter. Starting with Core Data just prepares the core data code in the app delegate and makes an empty model file, both of which are
1) easy to create yourself, or
2) copy from a new empty project started with core data later when you need it.
And if you already have it in your project, but you don't use it, it is also no problem. I found that almost all projects need core data after a while, so I usually just let it create it from the start.
Xcode just allows you to check using coredata to prepare already a coredata for you project.
BUt it is very simple to add or remove it later.JUst simple as File>create or File delete.
In a words don't worry about creating in the begining or later.
My question, how can I properly remove a realm file? Currently I'm doing so using the file manager, which is fine for me since the Realm file is mostly here for offline caching.
My app logs in to a web-platform, and creates a realm for this platform so you can log in to multiple. When you remove it with the filemanager however, there can still be lock files and such so I guess this dirty way of removing is the wrong way!
in Android you have the deleteRealmFile call on the RealmClass, which works fine when all references are closed. It seems there is not much security on iOS as I can just remove it like this.
So what is the proper way of handling this?
I'm not sure if realm is intended to be used like this but it's ideal for us and makes the developers happy.
I'm working in swift and have an iOS7+ requirement.
That is the proper way of deleting it. You can check the Migration example in the RealmExample project that come with the SDK and see that that's exactly how they do it, so I assume the recommended way.
let defaultPath = Realm.defaultPath
NSFileManager.defaultManager().removeItemAtPath(defaultPath, error: nil)
ers,
I recently integrated CoreData into my existing iOS application. I have previously existing tests written around some domain and network functionality; that now needs to be retrofitted to use CoreData (instead of storing in userDefaults).
I have GHUnitIOS.framework included in my project. However, all my tests are failing because the TestAppDelegate knows nothing about CoreData's managedObjectContext. For reference as to what I'm seeing:
[GHUnitIOSAppDelegate managedObjectContext]: unrecognized selector sent to instance
This makes sense - the test app delegate doesn't have managedObjectContext as a property. I'd love to add it, but since I only have access to the header files when using the framework, I can't really modify it for my needs. I could download the GHUnit source and modify the implementation files, but I'd rather not do that if there's another option.
How have others solved this problem? IE, how can I fix my tests to support CoreData using GHUnit?
Much thanks.
I had this issue before. GHUnit testing framework uses its own app delegate. So calling the delegate does not call the code you wrote within the app delegate, and its behavior can be erratic.
Generally speaking you should always handle calling your managedObjectContext(s) in a singleton that is not your app delegate. Recently I switched to GHUnit from OCunit and had to abstract all the of that functionality into a different class. It was a pain, but worth it.
When designing the core data model in XCode, you can automatically generate NSManagedObject subclass definitions (.m and .h files) by
Selecting the Entities
Choosing "Create NSManagedObject Subclasses" from EDITOR menu
After that, you may add a lot of code in these classes, what if you have to modify the data model setting a lot for some reason after that? To reflect these changes on the data model, is there any automatic way to do that? or you have to do everything manually.
Currently if I try to recreate these class definition from EDIT menu again(automatically), it will replace all the current files. All added code will disappear.
I really hope future version of Xcode can add a smart feature: automatically updating the default class definition without losing the added work. Maybe I am too lazy. :)
You're running into a common problem. You're pretty much stuck with that way of creating managed object subclasses with Xcode for the time being. Knowing that, you can either:
Design around it
For simple cases, you can use Categories to add functionality (though not state) to your NSManagedObject subclasses. Code in the category's file is obviously safe from being overwritten every time your data model changes.
Don't use Xcode
Mogenerator is a nifty tool designed to solve exactly that problem. It creates two classes for each entity instead of one, allowing Xcode to manage one while you manage the other.
It seems Apple has addressed the issue with XCode 7 : now it automatically creates the entity and a category of the entity with its core data properties. When you regenerate, it only updates the category, leaving your custom code in the entity class unharmed. See this link
You can create a class with different name and paste the generated fields into the old class