[Push Notifications Revamp] Support deeplink for Staff Picks

[mebarbosa]

Description

• Supports the deep link for opening discover stuff picks. This will be used for the new Stuff Picks notification that will be implemented in the next PRs: pktc://discover/staffpicks
• See document with deeplinks: p1743685755349989/1743684484.596599-slack-C08KX131YRJ

Testing Instructions

Since we don't have the notifications implemented, we can test this in command line:

1. Install the app
2. In Android Studio terminal, run: adb shell am start -a android.intent.action.VIEW -d "pktc://discover/staffpicks"
3. Ensure Stuff Picks screen ✅

Checklist

• If this is a user-facing change, I have added an entry in CHANGELOG.md
• Ensure the linter passes (./gradlew spotlessApply to automatically apply formatting/linting)
• I have considered whether it makes sense to add tests for my changes
• All strings that need to be localized are in modules/services/localization/src/main/res/values/strings.xml
• Any jetpack compose components I added or changed are covered by compose previews
• I have updated (or requested that someone edit) the spreadsheet to reflect any new or changed analytics.

[wpmobilebot]

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

	App Name	📱 Mobile
	Build Type	debugProd
	Commit	68a8c34
	Direct Download	pocketcasts-app-prototype-build-pr3872-68a8c34.apk

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

	App Name	🚗 Automotive
	Build Type	debugProd
	Commit	68a8c34
	Direct Download	pocketcasts-automotive-prototype-build-pr3872-68a8c34.apk

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

	App Name	⌚ Wear
	Build Type	debugProd
	Commit	68a8c34
	Direct Download	pocketcasts-wear-prototype-build-pr3872-68a8c34.apk

[mebarbosa]

Hey @MiSikora
I've pushed another approach for this. You can check aa65d05

[MiSikora]

I found two issues:

1. When I navigate using adb shell am start -a android.intent.action.VIEW -d "pktc://discover/staffpicks" and then go to the previous screen I can no longer navigate using the same deep link.
2. When I navigate using a deep link, go back, and then change device's configuration the staff pick screen is added to the back stack and is added twice. See the video below:

screen-20250414-092318.mp4

[wpmobilebot]

Version 7.87 has now entered code-freeze, so the milestone of this PR has been updated to 7.88.

[mebarbosa]

@MiSikora I've fixed it d67720f

[MiSikora]

Thanks for the update! I noticed there’s still a navigation-related issue:

1. Deep link to Staff Picks.
2. Change the configuration a couple of times.
3. The screen stacks on top of itself multiple times, requiring multiple back presses to exit.

Functionally, this solution doesn’t differ much from the previous one. The navigation destination is still managed as top-level state. The main change is that it’s now decoupled from the UI state of the Discover page.

However, the core approach to navigation still raises some concerns. Since the fragment stack is already handled internally by the FragmentManager, managing it externally can lead to subtle and hard-to-diagnose issues like the one here.

A more robust solution might be to lift the Discover data (or at least the Staff Picks part of it out of the DiscoverViewModel. That way, the flow could look like this:

1. Receive a deep link to Staff Picks.
2. Check if the Staff Picks screen is already visible.
3. If not, retrieve data from the Staff Picks data source.
4. Navigate to the Staff Picks screen.

This approach eliminates the need for a separate state holder just for navigation, and it promotes a single source of truth for the Staff Picks data, Making it more reusable and easier to reason about.

Even in the current PR, navigating to Staff Picks requires passing through both DiscoverFragment and DiscoverAdapter, which adds a fair bit of coupling and makes the logic harder to follow.

That said, I understand the goal here may not be to overhaul the structure. While I still have reservations about the architectural principle being reused from the previous implementation, if you're able to resolve the bugs without adding too much complexity, I’m okay with moving forward as-is.

[mebarbosa]

@MiSikora Thank you for your inputs. I refactor this and created the DiscoverDeepLinkManager that will fetch discover data and look for staff picks list. See the new approach 68a8c34

[MiSikora]

Thanks for doing all the changes. I'd be great if we shared the data source between DisoverViewModel and this feature but it probably isn't necessary at the moment.