I run into a problem with Xcode8 and automatic CoreData NSMangedObject creation.
The toolversion is already downgraded to Xcode7.3 and the entities are in codegen mode manual/none.
I added a new attribute to an entity and created the NSManagedObject subclass over the Editor->Create NSManagedObject Subclass.
XCode now generates the Entity+CoreDataClass.h/m and the Entity+CoreDataProperties.h/m Files.
Does this mean that I have to change any #import (no Problem by search and replace) or is there an other way to get the old Entity.h and Entity.m Files?
What about my existing code in the Entity.m files, do I have to copy & paste it to the new Entity+CoreDataClass.m file?
In my opinion the code generation is buggy. If there is a relation to other classes the import in the Entity+CoreDataClass.m file is wrong.
The class imports the old Entity.h files...
Perhaps anyone has an idea. If there isn't any other possibility this could only be a joke by Apple....
Related
I have an old Objective-C project, which has multiple targets, and some of the targets share a framework (let's call it CJDataKit) that's also written in Objective-C. I'm trying to add some Swift code to my project, at least to the main app target, and have some limited implementation of it working, but I'm running into some issues whenever the Swift code needs to use or import the CJDataKit framework, or any header file that itself imports the CJDataKit framework.
What's Working
I wrote a basic UIView subclass in Swift (which didn't need any other code from my app), and I can use this in my Objective-C target, using #objc keyword and by importing "MyApp-Swift.h" in my Objective-C code.
I then wrote a new UIViewController subclass in Swift, and used a couple of simple Objective-C objects from both CJDataKit framework and non-framework classes. I did this by creating a bridging header file, and added the Objective-C headers there.
So far so good, and everything compiles fine.
What's Not Working
The problem happens if I try to import into Swift other Objective-C
files that might be importing the CJDataKit framework inside it. For
e.g. I wanted to write a Swift extension of an existing
UIViewController subclass (call is PageAViewController). This
subclass has imported multiple other header files. If I add it to the
bridging header file, I start getting build errors:
Include of non-modular header inside framework module 'CJDataKit':
'.../CJDataKit/Person.h'
Commenting out the #import CJDataKit makes it work for this particular file, but it still gets compile errors from a different header file (that was imported by PageAViewController). It'll only work if all the files imported don't have a #import CJDataKit, which is difficult and cumbersome. BTW, these files all belong to the app target, not the framework. So something about Swift doesn't like interacting with the CJDataKit framework directly, even though it works fine if it's built independently in the same app target along with the CJDataKit framework.
I've also tried importing the CJDataKit.h header file into the Swift
bridging header file, figuring this way I don't have to individually
import each file from the framework, but that doesn't work either.
That results in a different error:
Could not build module 'CJDataKit.h'
I've tried using #import <CJDataKit/CJDataKit.h> as well but same result.
From my settings:
- "Allow Non-modular Includes In Framework Modules" is Yes on the target, and framework. It is No at the project-level.
- "Defines Module" is also set to Yes, on both the app target and framework, and No at project-level.
Would love some help in getting this setup correctly. I've been searching for a solution, but haven't really found anything.
We can create a new Xcode project using Objective-C or Swift.
I want to detect, which language was selected when a project was created?
Projects can be a mix of Objective-C and Swift, but I am concerned about the language, selected during project creation.
May be it can be through pbxproj file or other better way.
Thanks.
ObjC project always contains the entry point that is main function.
Usually it is inside main.m file but it is not necessary. Developer can replace it to any name.
I tried 2 simple projects. One is in ObjC and second one is in Swift.
When I was tried to add new file the Xcode offered Swift language for Swift project and Obj-C for Obj-C project file.
Next I removed in Swift project AppDelegate.swift file and added AppDelegate.h and AppDelegate.m and (sic!) main.m files. of course I had to create bridging file for obj-c.
Which contains
#import "AppDelegate.h"
I was able to compile this project but when I tried to add new file Xcode offered me to add Objective-C file. But initially the project was created as Swift project.
I did similar manipulation for Obj-C project.
I removed AppDelegate.h and .m file as well as main.m and added AppDelegate.swift
I was asked to create bridge file and did empty file.
Next I went to «Build Settings» and switched Define Module parameter to YES value. (Without this I got linker error).
After it I was able to build and run this initially obj-c project which has AppDelegate in Swift now.
When I tried to add a new file the Xcode offered me to add new Obj-C file too.
So. It looks like you cannot detect initial language based on a parameter in Xcode because project can be always corrected. I think that rarely the developer will try to replace AppDelegate in a project and add\remove main entry point.
Hope this helps you.
I took a break from coding for a few months and came back and discovered the changes in CoreData with Xcode8/iOS10/macOS Sierra.
I have been trying to get my head around the new NSManagedObject subclass generation in Objective C but there is very little out there on the web. I have a few things I need clarifying before I start butchering my project and messing things up completely but first, some things I have discovered from poking around that might be useful to others out there...
Where things are
Automatically generated files live buried deep in the DerivedData folder. Look in USER->Library->Developer->Xcode->DerivedData->ProjectName-lotsOfRandomLetters->Build then keep opening folders until you find DerivedSources->CoreDataGenerated.
Automatically generated files do not appear in your project folder or navigator, although if there is an error in one Xcode will display the source for you.
Things Xcode generates
There are three codegen settings - manual/none, Class Definition, and Category/Extension.
When an entities codegen is set to manual/none (which was the old behaviour) creating the NSmanagedObject subclass using Editor-> Create NSManagedObject Subclass generates 4 files inside your project...
Entity+CoreDataClass.h and Entity+CoreDataClass.m and
Entity+CoreDataProperties.h and Entity+CoreDataProperties.m
(previous version Xcode 7 generated Entity.h, Entity.m,
Entity+CoreDataProperties.h and Entity+CoreDataProperties.m files)
If the entity's codegen is set to Class Definition, Xcode generates these same 4 files automatically in the derived data folder - not the project, These files are then marked with a comment telling you not to alter them.
Xcode generates 2 files if the entities codegen is set to Category/Extension. These files are marked with a comment telling you not to alter them. These are...
Entity+CoreDataProperties.h and Entity+CoreDataProperties.m
These 2 file are expecting a Entity.h file to be in the project and will show an error in Xcode if absent. This is the one time that you will be able to see the source for one of these files within Xcode.
Whats in these files
The + CoreDataProperties files appear to be the same as those generated previous version of Xcode generated files except for one addition. They contain all the attributes / properties for the entity / NSmanagedObject and the methods to handle entities that have a one to many or many to many relationship. The new addition is a method for fetchRequest subclassing NSmanageObject's new fetchRequest method.
Questions
1) Is Class Definition now the obvious and best choice for codegen when you don't have any extra properties/functionality to add to a NSManagedObject subclass, as it automatically updates the files for you (when you save the project with cmd-s)?
2) The naming of the files with +CoreDataClass follows the convention for a category on a class, which would imply there should be a class for this to be an extension on.
Am I right in assuming that the Entity+CoreDateClass .h/m files are a straight replacement for the old Entity.h/m files? and that its not actually a category, despite the file name?
3) For new NSManagedObject subclasses should I be importing Entity+CoreDataClass.h rather than Entity.h?
4) If I want to uncluttered my project by removing most of my NSManagedObject subclass files, do i just delete the files in Xcode and set the entities codegen to Class Definition or ...
is there magic under the hood that looks for the entity+CoreDataClass when you try to #import entity.h or will I have to go through and find every reference to #import entity.h and change them to #import entity+CoreDataClass.h ?
5) Am I right in assuming that if I want a NSManagedObject subclass where I want to add a property and a method that i should set codegen to Category/Extension?
6) If I choose Category/Extension I have to create my own NSmanagedObject subclass file, its just entity.h not entity+CoreDataClass.h?
7) If entity+CoreDataClass.h is the new accepted naming format for the entity.h file why does the generated Category/Extension file look for a plain entity.h name file instead of a entity+CoreDataClass.h file? Is this just an inconsistency on Apples part and something I should just accept or am I missing something that I should know about?
Thank you.
Okay - quite a few people looked and no answers so i'll try and answer myself.
1) Yes - if you don't need to add extra properties/functionality to a CoreData entity, go with Class Definition. This creates 4 files:
Entity+CoreDataClass.h and Entity+CoreDataClass.m and Entity+CoreDataProperties.h and Entity+CoreDataProperties.m but you'll never see them as they are hidden away from sight deep inside the derived data folder. If you need to check on a attribute name you can look in the core data editor as you won't have access to these files.
2) Entity+CoreDateClass .h/m files are a straight replacement for the old Entity.h/m files. Despite using the file naming convention for a category, they are not categories, don't let Apple's naming system confuse you. Look inside the file and the class is defined as Entity not Entity+CoreDataClass.
3) For new NSManagedObject subclasses (autogenerated with the 'Class Definition' option) import Entity+CoreDataClass.h rather than Entity.h. After all' it's the file you are importing not the class defined inside. When using the class its just Entity not Entity+...
4) If you decided to declutter your project, by deleting your NSManagedObject subclass files then switching entities codegen to 'Class Definition', you will need to go through the project and change all the import statements that refer to them by adding +CoreDataClass to the file name. Fortunately its not that big a deal as Xcode will have flagged them all up as errors anyway so they are easy to find.
5) Yes - if you wish to add properties or functionality to a NSManagedObject subclass use the codegen "Category/Extension" option.
6) If you choose Category/Extension you have to create my own NSmanagedObject subclass file, name it Entity.h. Do NOT name it Entity+CoreDataClass.h because the autogenerated Entity+CoreDataProperty.h is looking to import an Entity.h file.
7) Yes, this is just a naming inconsistency on Apple's part. Don't let it throw you, like it did me.
And finally , don't forget...
if you go down the route of using codegen ->Category/Extension, if you add an additional relationship to the entity, you will need to update your Entity.h file. For example if you added a relationship to a NSManagedObject subclass called Car you would need to add the #Class Car; to Entity.h.
I am confused when working with Xamarin obj-c bindings, Lets say if I am having a single .h file then its just an happy path when creating binding. But when a .h file is referenced with another .h in it as an import statement. How to deal with the bindings.
If I am having AB.h file which has A.h referred in it, what is the way to generate bindings for this. And If I am having a .xib file in obj-c project then how to deal with that.
Example Sake I am using this project for conversion.
https://github.com/hightower/HTHorizontalSelectionList/tree/master/Source
Have you looked at the Objective Sharpie, it will automatically identify the dependency and help you get started with creating iOS bindings
As the title says, I wanna be able to import a custom class of mine from any new project. So for example, if I have a class called LAView, I wanna be able to type #import "LAView.h" from any new project without actually having to copy LAView.h and LAView.m into the project itself. Is that possible? :)
Create a framework, copy the finished product into /Applications/Xcode.app/Contents/Developer/Library/Frameworks and /Library/Frameworks/
This way your framework will be visible and available in any Xcode project and you can access it like any other framework from the Xcode frameworks list.
NOTE: When you edit your framework you will have to copy the new version into both these locations again. You can automate this using BASH scripts run from the Terminal (if you do this be careful!).