[Notification Refresh] Likes and follows notifications header redesign

[justtwago]

Fixes https://github.com/Automattic/wordpress-mobile/issues/16

This PR contains only the brand-new header UI and UX.

Post like	Comment like	Followers

To test:

• Login to the account that contains likes for posts and comments, and also followers.
• Navigate to the Notifications screen
• Find notifications for comment likes, post likes and a new follower
• The header's UI is the same as on the designs: the original content panel and navigation arrows are brand-new
• Click on the header to navigate to the like content or the followed blog as usual

Regression Notes

1. Potential unintended areas of impact
   Header navigation buttons and the original content panel actions.

2. What I did to test those areas of impact (or what existing automated tests I relied on)
   Manual tests.

3. What automated tests I added (or what prevented me from doing so)
   There have been no tests since the legacy code was changed only.

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.

Testing checklist:

• WordPress.com sites and self-hosted Jetpack sites.
• Portrait and landscape orientations.
• Light and dark modes.
• Fonts: Larger, smaller and bold text.
• High contrast.
• VoiceOver.
• Languages with large words or with letters/accents not frequently used in English.
• Right-to-left languages. (Even if translation isn’t complete, formatting should still respect the right-to-left layout)
• iPhone and iPad.
• Multi-tasking: Split view and Slide over. (iPad)

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.

	App Name	WordPress Alpha
	Configuration	Release-Alpha
	Build Number	pr23107-eab1dc4
	Version	24.8
	Bundle ID	org.wordpress.alpha
	Commit	eab1dc4
	App Center Build	WPiOS - One-Offs #9778

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Alpha
	Configuration	Release-Alpha
	Build Number	pr23107-eab1dc4
	Version	24.8
	Bundle ID	com.jetpack.alpha
	Commit	eab1dc4
	App Center Build	jetpack-installable-builds #8824

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[salimbraksa]

[Suggestion] if the view controller owns this LikesListController, that in turns owns the view controller through the parent property, then this is a reference cycle and it will cause a memory leak. I'd suggest to mark parent as weak.

Then you can safe unwrap the optional parent property when configuring the cells:

guard let parent else {
   return
}
cell.configure(..., parent: parent)

If the parent is nil, that means the view controller was deallocated and the screen is no longer visible to the user.

[justtwago]

Nice catch! Didn't notice the looped references.

[alpavanoglu]

If it is ensured semantically that Child can only exist when Parent exists, you can also use unowned that removes the need to unwrap. It is kind of a forced unwrapped weak reference in practice. However it highlights the relationship between the 2 objects.

[salimbraksa]

Personally, I prefer using weak in all scenarios, as using unowned carries the risk of the app crashing if the child’s lifecycle outlives that of its parent. In other word, if parent is deallocated and the child attempts to access it, the app will crash.

I'm okey with keeping unowned, but I just wanted to let you know of the potential risks.

[justtwago]

Yeah, I researched the difference between weak and unowned modifiers, and I assume that LikesListController cannot naturally exist without the "parent" NotificationDetailsViewController. Such an incorrect state would lead to crashes and defects by default despite this value. I agree that using this modifier, in this case, more straightly indicates a cycled dependency, which is, in my opinion, more beneficial.

[salimbraksa]

LGTM! 🚀