@cmadeo I tinkered with this a bit and here are my findings on notification receipt while the app is foregrounded:

1. If the user has enabled push notifications in their settings, and allowed permissions, it's very easy to display the standard (with rich deep press) system notification view on top of the foregrounded app. We can also suppress this easily too.
2. If the user has at one time enabled push in their settings, but allowed permissions and later revoked them, we are unable to display the standard system notification view on top of the foregrounded app. We do however, still get a callback when that push is received, so we can hook into that and display a custom banner if needed.
3. If the user has never enabled push in their settings, and never allowed permissions, this means the device did not get registered with the service and we won't get that callback. In this case we may need to poll the notifications API regularly to determine if there are new notifications, and display a custom banner if we find anything.

@cmadeo We have a request from engineering sync:

Case 3 from my comment above gets gross technically for us, because we would need to poll regularly to see when new data arrives in order to display custom banner on top of their foregrounded app if the user has never registered or given permissions for push notifications. Can we scrap handling this situation?

Case 2 is halfway gross but we at least wouldn't have to poll. I also want to float the idea of scrapping it too just so we don't have to consider a custom notification banner design. I think it can be argued that if a user denies push permissions, they also don't want to be interrupted while reading an article. But this case is still easier to implement than case 3 above if it's a must.

Case 1 is easy - users will get a notification (classic OS-style push UI) on top of their foregrounded app if they have enabled permissions.

Thanks!

@Tsevener just out of curiosity would it be easier to always show the in-app banner if the app is foregrounded?

@cmadeo unfortunately no - depending on how their permissions and registration is set, we may need to take extra steps to ensure we get the data to populate an in-app banner in certain cases. If they've never registered for push notifications or allowed permissions, we'll need to continually poll for new notifications. If theyve registered for push notifications but since disallowed their permissions, we'll need to design the custom UI for an in-app banner. Both are technically possible, just looking for areas that might not be a must for v1 to simplify. Happy to discuss or negotiate further!

@Tsevener certainly for v1, I'm happy to work with whatever is technically easier or more feasible!

Engineering sync notes:

I think the bell icon view and state will be handled in separate tasks, so the bell-related piece of this task description can be considered something for QA only.

Engineering can confirm the in-app notification view appears while foregrounded as a part of this task, and add the notification tap > deep link to Notifications Center routing to finish up this task as well.

@cmadeo one good point brought up in Engineering sync is how the user will route to Notification Center when tapping on the notification banner. Do we programmatically dismiss/pop all screens, select the first tab, then push on the Notification Center? They could lose their place which could be a lot of movement and annoying. But the alternative is pushing the notification center on top or from the right of wherever they are, which could be some really weird contexts (like the editing flow).

Great question @Tsevener could we try pushing from the right and having the back arrow lead back to where they were instead of the Explore feed?

Here are our options from task sync. This is what we could do when a user tap a notification that is happening on a foregrounded app, a backgrounded app that is navigated to a particular area, or a terminated app that has a particular navigation state restoration ready to be restored:

1. No matter where in the flow things are, notification center is pushed on from the right and back button will be updated to reflect where it was pushed from. It is understood that this could interrupt flows like editing.
2. No matter where in the flow things are, notification center is presented on top of wherever the user currently is, and will instead have a close modal button. It is understood that this could lead to presentations on top of presentations (settings is already a modal, editing flow is already a modal, media and link wizards within editing flow are already modals on top of modals).
3. We do a hybrid of 1 and 2, where we dismiss any modals the user has presenting (i.e. editing flow, settings), but then push on notification center from the right on top of whatever navigation stack is underneath. Back button will be updated to reflect where it was pushed from.
4. We go nuclear and dismiss all modals and pop any navigation stack underneath to root. We programmatically select the Explore tab, then push on the notification center from the right. It is understood that the user would lose their place.

I think the priority of things to try is 2, 3, 4, then 1. We aren't sure what will work best right now so we'll just have to explore how these go when we pick this ticket up.

@JMinor @Dmantena @cmadeo please let me know if I'm misremembering anything here, thanks!

Looks accurate to our sync. thanks for the writeup!

@JMinor @cmadeo @OTichonova I pushed a new Experimental build (black icon) with some prototype options on this.

1. Fresh install build
2. Log in if necessary
3. Go to Settings > Notifications > Enable push permissions
4. Go to Settings > Push notifications tap debug

These are the different options we have set up. Hopefully the cell descriptions are explanatory enough, but let me know if you have any questions. The gray background color indicates which option is selected.

To trigger a fake push notification, shake the device from anywhere in the app. You should see a notification appear on the foreground (unless you chose one of the options that suppresses it in the Editor flow), tap to navigate to Notifications Center.

Note: sometimes when you shake, the Apple OS will pop up a "Undo Typing" alert when you're editing text. This is just an unfortunate side effect of hooking into the shake gesture. I suggest tapping cancel to get rid of it before tapping the local notification.

Thanks @Tsevener! This is SO HELPFUL! I'm really curious about the technical complexities of each of these, specifically curious about Option 1 with the editor opened, would we be able to detect if the editor was already open in the stack and then show the alert? I'm just a bit curious about what might happen if someone goes to answer a notification and then sort of forgets that they're already in an editing flow -- otherwise the simplicity of tapping 'back' to get to where you were before the notification 'interruption' seems intuitive and easy to use.

(Extra comment for more thank you's! This is really helpful and I appreciate your making it so easy to play around with!)

@cmadeo yep, we could detect if the editor is already open and show an alert for Option 1 before pushing, like how we did for options 3 & 4. I didn't demo that because, since we're pushing it on from the right, they wouldn't actually lose their editing changes. They should be able to tap back and get back to the Editor, so this particular alert with how it's worded isn't necessary. But preserving the editing flow (as we do in Options 1 & 2) can get them into some wacky setups (for example, they're in Editor > Media Wizard, are pushed to Notifications Center, that pushes them to an article, then they tap Edit again and another Editor is presented, etc).

I think the most technically stable options would be to dismiss any modals that are currently presenting to avoid that situation, which is why I tried to offer the most variations on 3 & 4 - to give users a heads up that their editing changes will be lost because we're dismissing.

Per the sync meeting, we'll pursue option 5, have Anthony test some of the "messier" paths and see if that is sufficient.

@Tsevener could we use the following alert text:

Header: Dismiss the editing mode?
Body: Are you sure you want to leave editing mode without publishing first?
Button (cancel): Cancel
Button (destructive): Discard edits

Also thinking we might want to show this if a contributor has entered new text in the editor and then taps on the 'x' to dismiss the editor! < @JMinor

@cmadeo that looks good! I forgot to mention, I'm also going to use this alert on the article description editor screen - is it okay if I use the same copy there?

Perfect to use it there too! Thank you!

https://github.com/wikimedia/wikipedia-ios/pull/4143

@cmadeo since y'all already saw an example of this in action via a prototype build, I'm moving this straight to QA. I added a screenshot of the new alert view in the Testing Notes for QA section of the task description. Feel free to move this to Needs Design Review if you want another look though.

Perfect, thanks so much @Tsevener !

Looks good to me on 6.9.0 (1904)