-
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
Replace context object with CoreDataStack
in NotificationSettingsService
#19422
Replace context object with CoreDataStack
in NotificationSettingsService
#19422
Conversation
You can test the changes in WordPress from this Pull Request by:
|
You can test the changes in Jetpack from this Pull Request by:
|
|
||
context.performAndWait { |
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.
I'm pretty sure it's safest to ensure that these operations accessing the object happen on the same queue as its context. This change was added because originally we were setting crashes here when accessing siteTitle
. If I recall we didn't ever really get to the bottom of what was causing the issue but I think this change improved things (can't say for certain though). I'd personally be hesitant to change it. Can we just call perform on the site's context
if we don't want to pass one in?
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.
👍 I was thinking the same thing, probably safer to use site.context than the one in arguments. I'll make the change.
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.
Addressed in bd2f325
@@ -6,6 +6,7 @@ | |||
* [**] [Jetpack-only] Added a "Save as Draft" extension. Now users can save content to Jetpack through iOS's share sheet. This was previously only available on the WordPress app. [#19414] | |||
* [**] [Jetpack-only] Enables Rich Notifications for the Jetpack app. Now we display more details on most of the push notifications. This was previously only available on the WordPress app. [#19415] | |||
* [*] Reader: Comment Details have been redesigned. [#19387] | |||
* [*] [internal] A refactor in weekly roundup notification scheduler. [#19422] |
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.
👍
fileprivate var blogService: BlogService { | ||
return BlogService(managedObjectContext: managedObjectContext) | ||
} | ||
|
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.
Well done finding this unused var
👍
@@ -101,7 +101,7 @@ final public class PushNotificationsManager: NSObject { | |||
deviceToken = newToken | |||
|
|||
// Register against WordPress.com | |||
let noteService = NotificationSettingsService(managedObjectContext: ContextManager.sharedInstance().mainContext) | |||
let noteService = NotificationSettingsService(coreDataStack: ContextManager.sharedInstance()) |
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.
Did you consider adding an instance property to store ContextManager.sharedInstance()
?
I don't think it would make much difference at runtime, given it would still access the shared instance. It might be useful in the future when/if we'll remove all the shared instances accesses in favor of Dependency Injection.
🤷♂️
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.
I don't want to think too far ahead, even though we know DI is going to happen at some point, but we don't know how it's going to look like, which can affect how the code should be written.
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.
Fair enough. 👌
} | ||
guard let dotComID = dotComID else { | ||
// Error | ||
return |
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.
Would it be useful to call the completion and pass an error about this to it?
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.
I don't think this "else case" can actually happen, not in the current code at least. The non-WP.com sites have been filtered out beforehand in
WordPress-iOS/WordPress/Classes/Utility/BackgroundTasks/WeeklyRoundupBackgroundTask.swift
Lines 82 to 85 in e3c3e41
guard let dotComID = site.dotComID?.intValue else { | |
onError(DataRequestError.dotComSiteWithoutDotComID(site)) | |
continue | |
} |
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.
Gotcha.
🤔 😞 It's disappointing the domain modeling evolved to leave the door open for this inconsistent state path, but I'd say tackling it is out scope for this PR.
// Error | ||
return |
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.
Given this code should be impossible to reach, what do you think of leaving a note about it?
// Error | |
return | |
// This code path should be impossible to reach. | |
// At the time of writing, there is code to filter non-WordPress.com sites before calling this method. | |
return |
Alternatively, would this count as "developer error"?
// Error | |
return | |
fatalError("Inconsistent State: Non-WordPress.com sites should have been filtered before calling this method.") |
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.
🤔 this is how I see the comment I just posted 😓
If that's how you see it, too, you should be able to see my suggestions by looking at the comment source via the edit button. But I hope that's just a temporary hiccup.
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.
The suggestion blocks look normal on my side 😸
I've added a fatalError
in f095331
It's one of the initiatives to pass
CoreDataStack
instead ofNSManagedContext
. This PR updatesNotificationSettingsService
to do exactly that. With this change, one usage ofnewDerivedContext
(another thing that we'd like to move away from) is also removed.I've tested the Weekly round up feature(My site -> Stats -> Weeks) and the notification scheduler(see "To test" section in #17766). I couldn't find any issue with this change.
But there are two changes that I can spot in the code:
blog
property inNotificationSettings
instances created byNotificationSettingsService
is now inmainContext
, instead of a derived context. This change is caused by theBlogQuery().blogs(in: ...)
line in the diff.I don't see this change causing any issue though: if the current code is okay with using a
Blog
which blogs to a discarded derived context, I don't see how it can break using aBlog
which blogs to the main context.context.performAndWait
is removed when accessingBlog
instance properties. The original code is added in Weekly Roundup Improvements (Core Data + Localization) #17766. But I don't think we need to usecontext.perform
to guard access to a Core Data model's properties? @frosty I know it's been a while since you created PR#17766. but do you mind reviewing this change if you have some time? Thanks.Regression Notes
Potential unintended areas of impact
None.
What I did to test those areas of impact (or what existing automated tests I relied on)
Covered in the description above.
What automated tests I added (or what prevented me from doing so)
None.
PR submission checklist:
RELEASE-NOTES.txt
if necessary.