Xcode Project with shared CoreData for iOS & MacOS Targets
A few months ago I started to work on a MacOS Application which required CoreData implementation. Today I am beginning to work on a related iOS application that is based on the same Api, and though relies on the same model. I added my iOS target on my project and I mutualised some classes (by adding them to both targets), including the CoreData Stack:
I added my
app.xcdatamodeldon both targetsI added my
Object+CoreDataClass.swift&Object+CoreDataProperties.swifton both targets
- I modified my
ManagedObjectsControllerto support both iOS and MacOS implementation
by defining the appDelegate for both iOS and OSX, I can access it the same way to get my context let context = appDelegate.persistentContainer.viewContext
It works fine but I was wondering if I am doing this right. Is this the correct way to mutualise access to appDelegate instances between two targets?
Should I use some kind of Protocole & Generic Typing?
Or should I simply build a ManagedObjectController for each target?
Thanks
swift xcode core-data
asked Nov 13 '18 at 19:15
OlympiloutreOlympiloutre
352314
add a comment |
A few months ago I started to work on a MacOS Application which required CoreData implementation. Today I am beginning to work on a related iOS application that is based on the same Api, and though relies on the same model. I added my iOS target on my project and I mutualised some classes (by adding them to both targets), including the CoreData Stack:
I added my
app.xcdatamodeldon both targetsI added my
Object+CoreDataClass.swift&Object+CoreDataProperties.swifton both targets
- I modified my
ManagedObjectsControllerto support both iOS and MacOS implementation
by defining the appDelegate for both iOS and OSX, I can access it the same way to get my context let context = appDelegate.persistentContainer.viewContext
It works fine but I was wondering if I am doing this right. Is this the correct way to mutualise access to appDelegate instances between two targets?
Should I use some kind of Protocole & Generic Typing?
Or should I simply build a ManagedObjectController for each target?
Thanks
swift xcode core-data
asked Nov 13 '18 at 19:15
OlympiloutreOlympiloutre
352314
add a comment |
A few months ago I started to work on a MacOS Application which required CoreData implementation. Today I am beginning to work on a related iOS application that is based on the same Api, and though relies on the same model. I added my iOS target on my project and I mutualised some classes (by adding them to both targets), including the CoreData Stack:
I added my
app.xcdatamodeldon both targetsI added my
Object+CoreDataClass.swift&Object+CoreDataProperties.swifton both targets
- I modified my
ManagedObjectsControllerto support both iOS and MacOS implementation
by defining the appDelegate for both iOS and OSX, I can access it the same way to get my context let context = appDelegate.persistentContainer.viewContext
It works fine but I was wondering if I am doing this right. Is this the correct way to mutualise access to appDelegate instances between two targets?
Should I use some kind of Protocole & Generic Typing?
Or should I simply build a ManagedObjectController for each target?
Thanks
swift xcode core-data
asked Nov 13 '18 at 19:15
OlympiloutreOlympiloutre
352314
A few months ago I started to work on a MacOS Application which required CoreData implementation. Today I am beginning to work on a related iOS application that is based on the same Api, and though relies on the same model. I added my iOS target on my project and I mutualised some classes (by adding them to both targets), including the CoreData Stack:
I added my
app.xcdatamodeldon both targetsI added my
Object+CoreDataClass.swift&Object+CoreDataProperties.swifton both targets
- I modified my
ManagedObjectsControllerto support both iOS and MacOS implementation
by defining the appDelegate for both iOS and OSX, I can access it the same way to get my context let context = appDelegate.persistentContainer.viewContext
It works fine but I was wondering if I am doing this right. Is this the correct way to mutualise access to appDelegate instances between two targets?
Should I use some kind of Protocole & Generic Typing?
Or should I simply build a ManagedObjectController for each target?
Thanks
swift xcode core-data
swift xcode core-data
asked Nov 13 '18 at 19:15
OlympiloutreOlympiloutre
352314
asked Nov 13 '18 at 19:15
OlympiloutreOlympiloutre
352314
asked Nov 13 '18 at 19:15
OlympiloutreOlympiloutre
352314
asked Nov 13 '18 at 19:15
OlympiloutreOlympiloutre
352314
asked Nov 13 '18 at 19:15
OlympiloutreOlympiloutre
352314
352314
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Declaring a protocol helps if you have multiple classes which you want to both support common functions. But in this case, UIApplication and NSApplication already support the common functions you need! The problem is that you need access two different global symbols.
One alternative worth considering is: Instead of declaring two classes IosAppDelegate and MacAppDelegate, declare a single class AppDelegate, and move that dirty #if code out of your ManagedObjectsController class and into AppDelegate. Then, this AppDelegate could be used wherever you need a reference to the shared app delegate. This is more than a few places in most projects.
But if you want to get your product out the door asap, and this ManagedObjectsController is the only place you need the shared app delegate, your code is fine.
answered Nov 13 '18 at 23:37
Jerry KrinockJerry Krinock
1,7171720
Alright thanks for the clarification. When you say "ove that dirty #if into AppDelegate", do you mean anAppdelegate.swiftfile with a big#ifdefining aclass AppDelegate: UIResponder, UIApplicationDelegateand an#elseifdefiningclass MacAppDelegate: NSObject, NSApplicationDelegate? Won't that be more confusing?
– Olympiloutre
Nov 14 '18 at 8:54
Or do you mean that I should keep MacAppDelegate and IosAppDelegate, but create a third singleton classAppDelegate, and put theifarround asharedvariable?
– Olympiloutre
Nov 14 '18 at 8:56
1
I meant what you said in your first comment, but what you said in your second comment would also work, as will your original code. Getting back to your original question, there is no right way to do this. Keep in mind what economist Thomas Sowell has said about public policy options: There are no solutions. There are only trade-offs. That also applies to engineering design decisions. In this case, all of the three options we discussed will work. Maybe there is not much difference among their (benefits minus costs). If that is the case, just move on with what you've already got.
– Jerry Krinock
Nov 14 '18 at 19:16
Understood, That clearly answer my question thanks
– Olympiloutre
Nov 15 '18 at 10:10
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53288029%2fxcode-project-with-shared-coredata-for-ios-macos-targets%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Declaring a protocol helps if you have multiple classes which you want to both support common functions. But in this case, UIApplication and NSApplication already support the common functions you need! The problem is that you need access two different global symbols.
One alternative worth considering is: Instead of declaring two classes IosAppDelegate and MacAppDelegate, declare a single class AppDelegate, and move that dirty #if code out of your ManagedObjectsController class and into AppDelegate. Then, this AppDelegate could be used wherever you need a reference to the shared app delegate. This is more than a few places in most projects.
But if you want to get your product out the door asap, and this ManagedObjectsController is the only place you need the shared app delegate, your code is fine.
answered Nov 13 '18 at 23:37
Jerry KrinockJerry Krinock
1,7171720
Alright thanks for the clarification. When you say "ove that dirty #if into AppDelegate", do you mean anAppdelegate.swiftfile with a big#ifdefining aclass AppDelegate: UIResponder, UIApplicationDelegateand an#elseifdefiningclass MacAppDelegate: NSObject, NSApplicationDelegate? Won't that be more confusing?
– Olympiloutre
Nov 14 '18 at 8:54
Or do you mean that I should keep MacAppDelegate and IosAppDelegate, but create a third singleton classAppDelegate, and put theifarround asharedvariable?
– Olympiloutre
Nov 14 '18 at 8:56
1
I meant what you said in your first comment, but what you said in your second comment would also work, as will your original code. Getting back to your original question, there is no right way to do this. Keep in mind what economist Thomas Sowell has said about public policy options: There are no solutions. There are only trade-offs. That also applies to engineering design decisions. In this case, all of the three options we discussed will work. Maybe there is not much difference among their (benefits minus costs). If that is the case, just move on with what you've already got.
– Jerry Krinock
Nov 14 '18 at 19:16
Understood, That clearly answer my question thanks
– Olympiloutre
Nov 15 '18 at 10:10
add a comment |
Declaring a protocol helps if you have multiple classes which you want to both support common functions. But in this case, UIApplication and NSApplication already support the common functions you need! The problem is that you need access two different global symbols.
One alternative worth considering is: Instead of declaring two classes IosAppDelegate and MacAppDelegate, declare a single class AppDelegate, and move that dirty #if code out of your ManagedObjectsController class and into AppDelegate. Then, this AppDelegate could be used wherever you need a reference to the shared app delegate. This is more than a few places in most projects.
But if you want to get your product out the door asap, and this ManagedObjectsController is the only place you need the shared app delegate, your code is fine.
answered Nov 13 '18 at 23:37
Jerry KrinockJerry Krinock
1,7171720
Alright thanks for the clarification. When you say "ove that dirty #if into AppDelegate", do you mean anAppdelegate.swiftfile with a big#ifdefining aclass AppDelegate: UIResponder, UIApplicationDelegateand an#elseifdefiningclass MacAppDelegate: NSObject, NSApplicationDelegate? Won't that be more confusing?
– Olympiloutre
Nov 14 '18 at 8:54
Or do you mean that I should keep MacAppDelegate and IosAppDelegate, but create a third singleton classAppDelegate, and put theifarround asharedvariable?
– Olympiloutre
Nov 14 '18 at 8:56
1
I meant what you said in your first comment, but what you said in your second comment would also work, as will your original code. Getting back to your original question, there is no right way to do this. Keep in mind what economist Thomas Sowell has said about public policy options: There are no solutions. There are only trade-offs. That also applies to engineering design decisions. In this case, all of the three options we discussed will work. Maybe there is not much difference among their (benefits minus costs). If that is the case, just move on with what you've already got.
– Jerry Krinock
Nov 14 '18 at 19:16
Understood, That clearly answer my question thanks
– Olympiloutre
Nov 15 '18 at 10:10
add a comment |
Declaring a protocol helps if you have multiple classes which you want to both support common functions. But in this case, UIApplication and NSApplication already support the common functions you need! The problem is that you need access two different global symbols.
One alternative worth considering is: Instead of declaring two classes IosAppDelegate and MacAppDelegate, declare a single class AppDelegate, and move that dirty #if code out of your ManagedObjectsController class and into AppDelegate. Then, this AppDelegate could be used wherever you need a reference to the shared app delegate. This is more than a few places in most projects.
But if you want to get your product out the door asap, and this ManagedObjectsController is the only place you need the shared app delegate, your code is fine.
answered Nov 13 '18 at 23:37
Jerry KrinockJerry Krinock
1,7171720
Declaring a protocol helps if you have multiple classes which you want to both support common functions. But in this case, UIApplication and NSApplication already support the common functions you need! The problem is that you need access two different global symbols.
One alternative worth considering is: Instead of declaring two classes IosAppDelegate and MacAppDelegate, declare a single class AppDelegate, and move that dirty #if code out of your ManagedObjectsController class and into AppDelegate. Then, this AppDelegate could be used wherever you need a reference to the shared app delegate. This is more than a few places in most projects.
But if you want to get your product out the door asap, and this ManagedObjectsController is the only place you need the shared app delegate, your code is fine.
answered Nov 13 '18 at 23:37
Jerry KrinockJerry Krinock
1,7171720
answered Nov 13 '18 at 23:37
Jerry KrinockJerry Krinock
1,7171720
answered Nov 13 '18 at 23:37
Jerry KrinockJerry Krinock
1,7171720
answered Nov 13 '18 at 23:37
Jerry KrinockJerry Krinock
1,7171720
1,7171720
Alright thanks for the clarification. When you say "ove that dirty #if into AppDelegate", do you mean anAppdelegate.swiftfile with a big#ifdefining aclass AppDelegate: UIResponder, UIApplicationDelegateand an#elseifdefiningclass MacAppDelegate: NSObject, NSApplicationDelegate? Won't that be more confusing?
– Olympiloutre
Nov 14 '18 at 8:54
Or do you mean that I should keep MacAppDelegate and IosAppDelegate, but create a third singleton classAppDelegate, and put theifarround asharedvariable?
– Olympiloutre
Nov 14 '18 at 8:56
1
I meant what you said in your first comment, but what you said in your second comment would also work, as will your original code. Getting back to your original question, there is no right way to do this. Keep in mind what economist Thomas Sowell has said about public policy options: There are no solutions. There are only trade-offs. That also applies to engineering design decisions. In this case, all of the three options we discussed will work. Maybe there is not much difference among their (benefits minus costs). If that is the case, just move on with what you've already got.
– Jerry Krinock
Nov 14 '18 at 19:16
Understood, That clearly answer my question thanks
– Olympiloutre
Nov 15 '18 at 10:10
add a comment |
Alright thanks for the clarification. When you say "ove that dirty #if into AppDelegate", do you mean anAppdelegate.swiftfile with a big#ifdefining aclass AppDelegate: UIResponder, UIApplicationDelegateand an#elseifdefiningclass MacAppDelegate: NSObject, NSApplicationDelegate? Won't that be more confusing?
– Olympiloutre
Nov 14 '18 at 8:54
Or do you mean that I should keep MacAppDelegate and IosAppDelegate, but create a third singleton classAppDelegate, and put theifarround asharedvariable?
– Olympiloutre
Nov 14 '18 at 8:56
1
I meant what you said in your first comment, but what you said in your second comment would also work, as will your original code. Getting back to your original question, there is no right way to do this. Keep in mind what economist Thomas Sowell has said about public policy options: There are no solutions. There are only trade-offs. That also applies to engineering design decisions. In this case, all of the three options we discussed will work. Maybe there is not much difference among their (benefits minus costs). If that is the case, just move on with what you've already got.
– Jerry Krinock
Nov 14 '18 at 19:16
Understood, That clearly answer my question thanks
– Olympiloutre
Nov 15 '18 at 10:10
Alright thanks for the clarification. When you say "ove that dirty #if into AppDelegate", do you mean an
Appdelegate.swift file with a big #if defining a class AppDelegate: UIResponder, UIApplicationDelegate and an #elseif defining class MacAppDelegate: NSObject, NSApplicationDelegate ? Won't that be more confusing?– Olympiloutre
Nov 14 '18 at 8:54
Alright thanks for the clarification. When you say "ove that dirty #if into AppDelegate", do you mean an
Appdelegate.swift file with a big #if defining a class AppDelegate: UIResponder, UIApplicationDelegate and an #elseif defining class MacAppDelegate: NSObject, NSApplicationDelegate ? Won't that be more confusing?– Olympiloutre
Nov 14 '18 at 8:54
Or do you mean that I should keep MacAppDelegate and IosAppDelegate, but create a third singleton class
AppDelegate, and put the if arround a shared variable?– Olympiloutre
Nov 14 '18 at 8:56
Or do you mean that I should keep MacAppDelegate and IosAppDelegate, but create a third singleton class
AppDelegate, and put the if arround a shared variable?– Olympiloutre
Nov 14 '18 at 8:56
1
1
I meant what you said in your first comment, but what you said in your second comment would also work, as will your original code. Getting back to your original question, there is no right way to do this. Keep in mind what economist Thomas Sowell has said about public policy options: There are no solutions. There are only trade-offs. That also applies to engineering design decisions. In this case, all of the three options we discussed will work. Maybe there is not much difference among their (benefits minus costs). If that is the case, just move on with what you've already got.
– Jerry Krinock
Nov 14 '18 at 19:16
I meant what you said in your first comment, but what you said in your second comment would also work, as will your original code. Getting back to your original question, there is no right way to do this. Keep in mind what economist Thomas Sowell has said about public policy options: There are no solutions. There are only trade-offs. That also applies to engineering design decisions. In this case, all of the three options we discussed will work. Maybe there is not much difference among their (benefits minus costs). If that is the case, just move on with what you've already got.
– Jerry Krinock
Nov 14 '18 at 19:16
Understood, That clearly answer my question thanks
– Olympiloutre
Nov 15 '18 at 10:10
Understood, That clearly answer my question thanks
– Olympiloutre
Nov 15 '18 at 10:10
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53288029%2fxcode-project-with-shared-coredata-for-ios-macos-targets%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
