Add FXiOS-10521 [Homescreen Rebuild] Add wallpaper to new homescreen

[Cramsden]

📜 Tickets

Jira ticket
Github issue

💡 Description

Move wallpaper to new homescreen

• Duplicate WallpaperView and move existing WallpaperView to LegacyWallpaperView
• Remove notification logic for wallpaperDidChange as this will be handled by redux

Add redux for wallpaper actions like initial load and changing the wallpaper

• WallpaperAction
• WallpaperMiddleware as interface for WallpaperManager
• WallpaperManager is still being interacted directly everywhere other than the new home screen
• WallpaperState as as sub-state for HomepageState

TODO:

• Handle scrolling for custom wallpaper
• Handle actual wallpaper selection in new redux flow

📝 Checklist

You have to check all boxes before merging

• Filled in the above information (tickets numbers and description of your work)
• Updated the PR name to follow our PR naming guidelines
• Wrote unit tests and/or ensured the tests suite is passing
• When working on UI, I checked and implemented accessibility (minimum Dynamic Text and VoiceOver)
• If needed, I updated documentation / comments for complex code and public methods
• If needed, added a backport comment (example @Mergifyio backport release/v120)

[cyndichin]

thanks @Cramsden for working on this!! looks 🔥 , the main structure looks great, left a couple of comments for consideration. Let me know what you think~

I didn't run down and build the app to test the wallpaper work, but happy to when the feature is more complete. Thanks again for taking this on :) !

[cyndichin]

what do you think about using the WallpaperState here to populate the details of the view and passing only what's needed from the wallpaper instead of setting the Wallpaper object here? For the other cells, I've been using the states, so can maintain consistency and clear on what is needed as well.

i.e. wallpaperState.landscapeImage

[Cramsden]

We get nice functionality on wallpaper like providing a default image as well as fetching an image for landscape vs portrait. Are you proposing that it would be better to pass in these as separate items to the wallpaper view? We definitely could I guess i am not sure what the benefit as wallpaper is already a lightweight struct.

[cyndichin]

By adding wallpaper, we are surfacing other properties and logic that the view doesn't need to know. So by providing a specific state for the view, we only pull in what's needed from wallpaper.

Also, we can follow a consistent structure in our codebase which our views take in a state, which I'm happy to rethink or restructure. So for other views, PocketStandardCell populates its data by passing in PocketStoryState and HomepageHeaderCell takes in HeaderState.

The downside of this that I can see is that now the views are heavily tied to a state instead of specific properties if we decide to move from Redux.

However, now that I think about it, maybe this should be a team discussion to see what is preferred. Let me know what you think!

This also doesn't need to block this PR. So happy to get this merge in first and have that discussion later.

[Cramsden]

https://mozilla.slack.com/archives/C05C9RET70F/p1732034555214689

[Cramsden]

It seems like the outcome of that discussion is we actually do want to have the view have a reference to wallpaper state with just the information it needs instead of the the wallpaper object.

[Cramsden]

This comment did make me think of a question I had earlier:
Do orientation changes need to be redux actions as well or if the view controller can just directly update the view. @cyndichin

[cyndichin]

I think it would be a nice to have if we can add redux since some of that orientation logic makes more sense to live in the state, then in the view. Ideally, all we need to do is dispatch an action here, and then the state updates with the new wallpaper image.

However, that's increasing the scope a bit, so we can add this to the back burner of our wishlist of things we would like to update. What do you think?

[Cramsden]

It seems based on this discussion, It does not need to be part of redux:

Broadcasting an action when you know there will be nobody listing for it is not necessary. Someone can always come back later and add it if a use case pops up where they need to listen for it.

[mobiletest-ci-bot]

	Messages
📖	Project coverage: 33.28%
📖	Edited 10 files
📖	Created 6 files

Client.app: Coverage: 31.41

File	Coverage
HomepageState.swift	92.31%	✅
WallpaperStorageUtility.swift	41.86%	⚠️
WallpaperAction.swift	100.0%	✅
Wallpaper.swift	89.43%	✅
WallpaperBackgroundView.swift	94.55%	✅
AppState.swift	95.89%	✅
LegacyHomepageViewController.swift	35.94%	⚠️
WallpaperManager.swift	21.68%	⚠️
WallpaperMiddleware.swift	97.83%	✅
HomepageViewController.swift	37.64%	⚠️
LegacyWallpaperBackgroundView.swift	90.63%	✅
WallpaperState.swift	97.3%	✅

Generated by 🚫 Danger Swift against ce7a6ae