-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Abstract ContextManager
usages behind CoreDataStack
#24191
base: trunk
Are you sure you want to change the base?
Conversation
Generated by 🚫 Danger |
c4bae80
to
963f98e
Compare
@objc init(contextManager: ContextManager) { | ||
self.coreDataStack = contextManager | ||
@objc init(contextManager: CoreDataStack) { | ||
guard let typeCastStack = contextManager as? CoreDataStackSwift else { | ||
fatalError("Expected a CoreDataStackSwift-conforming type even though this initializer is marked @objc.") | ||
} | ||
self.coreDataStack = typeCastStack |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not proud of this one. I don't know if there's a neater way to go about it because if CoreDataStackSwift
could be defined in Objective-C, then we wouldn't have needed it in the first place.
Luckily, this hack has to be used only twice, so I think we can live with it...?
Of course, one possible solution would be to convert the Objective-C consumers to Swift... But I think we ought to focus on moving forward with the Core Data migration at the moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, it'd be okay to remove the argument and use the shared instance internally.
ContextManager.shared.resetEverything() | ||
// | ||
// We can afford to force cast here because we are in a test-specific code | ||
(ContextManager.shared as! ContextManager).resetEverything() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In particular, this code will run only in the UI tests and only if a certain launch argument is given
@@ -17,7 +18,7 @@ extension Blog { | |||
|
|||
static func createRestApiBlog( | |||
with details: WpApiApplicationPasswordDetails, | |||
in contextManager: ContextManager, | |||
in contextManager: CoreDataStackSwift, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this PR, I decided not to rename the contextManager
variable that now have CoreDataStackSwift
to keep the diff smaller.
We might want to do it later on, but it does not seem urgent.
ContextManager
usages behind CoreDataStack
|
App Name | ![]() |
|
Configuration | Release-Alpha | |
Build Number | pr24191-cb9162d | |
Version | 25.8 | |
Bundle ID | org.wordpress.alpha | |
Commit | cb9162d | |
App Center Build | WPiOS - One-Offs #11635 |
|
App Name | ![]() |
|
Configuration | Release-Alpha | |
Build Number | pr24191-cb9162d | |
Version | 25.8 | |
Bundle ID | com.jetpack.alpha | |
Commit | cb9162d | |
App Center Build | jetpack-installable-builds #10666 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry if I missed the discussion, but any reason not moving ContextManager into WordPressData too?
@objc init(contextManager: ContextManager) { | ||
self.coreDataStack = contextManager | ||
@objc init(contextManager: CoreDataStack) { | ||
guard let typeCastStack = contextManager as? CoreDataStackSwift else { | ||
fatalError("Expected a CoreDataStackSwift-conforming type even though this initializer is marked @objc.") | ||
} | ||
self.coreDataStack = typeCastStack |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, it'd be okay to remove the argument and use the shared instance internally.
|
I wonder whether moving ContextManager first would be easier for moving the managed objects. Like, this decoupling refactor would not be necessary if ContextManager is already in WordPressData. |
I think it would still be necessary if we have WordPressData the Swift package + WordPressDataObjC the Swift package with only Objective-C files. Because WordPressData depends on WordPressDataObjC, and therefore WordPressDataObjC cannot depend on WordPressData. But |
@crazytonyli your question actually made me realize that some of the models are Objective-C and others are Swift. I'll need to quickly verify whether they can work sparse between the two packages, or if I should just call it quits on the package and use a framework instead :/ |
This is to decouple the Objective-C implementation from knowing about components (i.e. `ContextManager`) in the Swift layer.
963f98e
to
cb9162d
Compare
Part of #24165
Problem I can't move
AbstractPost
and other Objective-C models in WordPressDataObj because they accessContextManager
which is defined in the Swift WordPressData.Solution Decouple from knowing about a specific type (
ContextManager
) and use aprotocol
instead (CoreDataStack
). This came with a few compromises (see inline comments) but I think it got the job done relatively clean.I tested this by running Jetpack on my iPhone and doing a smoke test checking the various tabs.
An alternative solution if we run into more Swift leakages into Objective-C would be to backtrack and create a framework target where we can have mixed languages. I might set aside some time today to search for
#import "WordPress-Swift.h"
usages and see how much extra steps like this would be needed if we kept the packages setup.