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

Edit Notifications #2663

Merged
merged 207 commits into from
Oct 15, 2018
Merged

Edit Notifications #2663

merged 207 commits into from
Oct 15, 2018

Conversation

natharateh
Copy link
Contributor

@natharateh natharateh commented Sep 26, 2018

Things to look out for:

  • Thread safety
  • Handling Core Data failures

Doing

  • Fetch and save notifications that appeared in the account after first authorized wikidata description edit
  • Stop polling after 24h
  • UI
  • Localizations

Merge after #2676

Testing:

Prerequisites:

  1. You have to make at least one authorized (logged in) Wikidata description edit

If you have any old reverted notifications in your account:

  1. Open the affected article on the device
  2. Comment out age validation on line 163-165 in RemoteNotificationsModelController

I if you don't have any old reverted notifications, you can use the test account in 1P

Natalia Harateh added 30 commits September 18, 2018 12:35
# Conflicts:
#	Wikipedia/Code/MWKDataStore.m
@@ -122,3 +81,91 @@ class RemoteNotificationsOperationsController {
}
}
}

final class RemoteNotificationsOperationsTimeController {
weak var viewContext: NSManagedObjectContext?
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is it better to keep this value on the viewContext or add WMFKeyValue to RemoteNotifications.xcdatamodeld (like in EventLogging.xcdatamodeld) and use the private context created by RemoteNotificationsModelController?

Copy link
Contributor

Choose a reason for hiding this comment

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

It'd be better to use the private context

@@ -15,6 +15,18 @@ import CoreData
}
}

public struct RemoteNotificationState: OptionSet {
Copy link
Contributor

@joewalsh joewalsh Oct 12, 2018

Choose a reason for hiding this comment

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

could these be modeled as discrete states? it seems like if a notification is excluded, it'll never be seen or read. also, it seems like read implies that it was seen. The states I'm imagining are ignored -> presented -> read nevermind this was just changed


private func request<T: Decodable>(_ queryParameters: Query.Parameters?, method: Session.Request.Method = .get, completion: @escaping (T?, URLResponse?, Bool?, Error?) -> Void) {
if method == .get {
let _ = Session.shared.jsonDecodableTask(host: NotificationsAPI.host, scheme: NotificationsAPI.scheme, method: .get, path: NotificationsAPI.path, queryParameters: queryParameters, completionHandler: completion)
Copy link
Contributor

Choose a reason for hiding this comment

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

Long term, it'd be good to have this take a session on init instead of relying on Session.shared. Short term could just be private let session = Session.shared

let modelBundle = Bundle.wmf
guard let modelURL = modelBundle.url(forResource: modelName, withExtension: modelExtension) else {
assertionFailure("Couldn't find url for resource named \(modelName) with extension \(modelExtension) in bundle \(modelBundle); make sure you're providing the right name, extension and bundle")
abort()
Copy link
Contributor

Choose a reason for hiding this comment

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

Could this fallback on not creating the controller instead of crashing the app?

}
guard let model = NSManagedObjectModel(contentsOf: modelURL) else {
assertionFailure("Couldn't create model with contents of \(modelURL); make sure \(modelURL) is the correct url for \(modelName)")
abort()
Copy link
Contributor

Choose a reason for hiding this comment

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

same question as above

class RemoteNotificationsFetchOperation: RemoteNotificationsOperation {
override func execute() {
self.managedObjectContext.perform {
self.apiController.getAllUnreadNotifications(from: ["wikidata", "en"]) { fetchedNotifications, error in
Copy link
Contributor

Choose a reason for hiding this comment

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

should this be the list of app languages instead of "en"?

private let modelController: RemoteNotificationsModelController?
private let deadlineController: RemoteNotificationsOperationsDeadlineController?

private let syncRepeatingTime: Int = 15
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this mean it's still checking every 15 seconds? Oh, related, should this polling be reachability aware?

Copy link
Contributor

Choose a reason for hiding this comment

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

(on both counts can be follow-ups as needed)

Copy link
Contributor

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 needs to be shut off based on reachability as long as it handles network failures gracefully. There's also waitsForConnectivity on URLSession that we might be able to set for this and the saved articles fetcher.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

right now it's checking every 15 seconds, just like WMFReadingListsController. good point with reachability, I'm looking at solutions that don't involve AFNetworkReachabilityManager since we want to move away from AFNetworking

Copy link
Contributor

@montehurd montehurd left a comment

Choose a reason for hiding this comment

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

nice! (added note for potential follow-ups)

@natharateh natharateh merged commit d37f592 into develop Oct 15, 2018
@natharateh natharateh deleted the feature/T203167 branch October 15, 2018 21:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants