Skip to content
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

Merged
merged 4 commits into from
Oct 11, 2022

Conversation

crazytonyli
Copy link
Contributor

@crazytonyli crazytonyli commented Oct 10, 2022

It's one of the initiatives to pass CoreDataStack instead of NSManagedContext. This PR updates NotificationSettingsService to do exactly that. With this change, one usage of newDerivedContext(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:

  1. The blog property in NotificationSettings instances created by NotificationSettingsService is now in mainContext, instead of a derived context. This change is caused by the BlogQuery().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 a Blog which blogs to the main context.
  2. context.performAndWait is removed when accessing Blog instance properties. The original code is added in Weekly Roundup Improvements (Core Data + Localization) #17766. But I don't think we need to use context.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

  1. Potential unintended areas of impact
    None.

  2. What I did to test those areas of impact (or what existing automated tests I relied on)
    Covered in the description above.

  3. What automated tests I added (or what prevented me from doing so)
    None.

PR submission checklist:

  • I have completed the Regression Notes.
  • I have considered adding unit tests for my changes.
  • I have considered adding accessibility improvements for my changes.
  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

@crazytonyli crazytonyli added the Core Data Issues related to Core Data label Oct 10, 2022
@crazytonyli crazytonyli added this to the 21.1 milestone Oct 10, 2022
@crazytonyli crazytonyli requested review from frosty and mokagio October 10, 2022 09:10
@crazytonyli crazytonyli self-assigned this Oct 10, 2022
@crazytonyli crazytonyli modified the milestones: 21.1, 21.0 Oct 10, 2022
@wpmobilebot
Copy link
Contributor

wpmobilebot commented Oct 10, 2022

You can test the changes in WordPress from this Pull Request by:
  • Clicking here or scanning the QR code below to access App Center
  • Then installing the build number pr19422-f095331 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

@wpmobilebot
Copy link
Contributor

wpmobilebot commented Oct 10, 2022

You can test the changes in Jetpack from this Pull Request by:
  • Clicking here or scanning the QR code below to access App Center
  • Then installing the build number pr19422-f095331 on your iPhone

If you need access to App Center, please ask a maintainer to add you.


context.performAndWait {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in bd2f325

@crazytonyli crazytonyli requested a review from frosty October 10, 2022 20:54
@@ -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]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Comment on lines -319 to -322
fileprivate var blogService: BlogService {
return BlogService(managedObjectContext: managedObjectContext)
}

Copy link
Contributor

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())
Copy link
Contributor

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.

🤷‍♂️

Copy link
Contributor Author

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.

Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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

guard let dotComID = site.dotComID?.intValue else {
onError(DataRequestError.dotComSiteWithoutDotComID(site))
continue
}

Copy link
Contributor

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.

Comment on lines 551 to 552
// Error
return
Copy link
Contributor

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?

Suggested change
// 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"?

Suggested change
// Error
return
fatalError("Inconsistent State: Non-WordPress.com sites should have been filtered before calling this method.")

Copy link
Contributor

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 😓

image

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.

Copy link
Contributor Author

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

@crazytonyli crazytonyli enabled auto-merge October 11, 2022 04:11
@crazytonyli crazytonyli merged commit 4f3a670 into trunk Oct 11, 2022
@crazytonyli crazytonyli deleted the core-data-stack-in-notification-settings-service branch October 11, 2022 04:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core Data Issues related to Core Data
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants