Fix: NullPointerException in MediaDetailPagerFragment during state sa…

[Kota-Jagadeesh]

Description

Fixes #6581

This PR addresses a java.lang.NullPointerException in MediaDetailPagerFragment.onSaveInstanceState. The crash occurred because the fragment attempted to access binding!!.mediaDetailsPager after onDestroyView() had already nullified the binding during navigation to other screens like Profile or Custom Selector.

Changes:

• Replaced the force-unwraps (!!) with safe-calls (?.) and .let blocks in onSaveInstanceState to safely handle cases where the View is destroyed before state saving.
• Ensured binding = null remains active in onDestroyView() to prevent memory leaks while maintaining stability.

Tests performed

Tested ProDebug build variant on Redmi Note 13 Pro (Android 15) with API level 35.

Steps verified:

1. Open the app.
2. Open a contributed image.
3. Navigate to Profile/Custom Selector.
4. Confirmed the app no longer crashes during the fragment transaction and state saving.

[github-actions]

✅ Generated APK variants!

• 🤖 Download betaDebugAPK
• 🤖 Download prodDebugAPK

[RitikaPahwa4444]

Hey @Kota-Jagadeesh, I love the proactivity, but I would suggest checking in for context before assigning yourself and raising PRs for these types of issues. It will save you some re-work! :)

If it were as simple as adding a null check or a safer call, we would have done it and wouldn't have re-introduced memory leaks to mitigate it the way it was being done. Several contributors have tried preventing memory leaks like the way it's being done in the current PR but unfortunately, our codebase is not ready for it yet. Check out this open PR to understand why it has been a challenge for us to simply add binding = null everywhere: #6347.

This is just one crash report, we could have more. It needs to be approached systematically and not just based on one crash report. Rohit gave an amazing suggestion on that PR.

I would also suggest using the debugger and checking the flow with that safe check. Binding will always be null there, so that code block will never get executed. That's why I commented on another PR of yours — we need to think of an alternative 🙂

[Kota-Jagadeesh]

@RitikaPahwa4444 Thanks for the guidance and the context! I see now that a simple null-check is just a 'band-aid' that effectively skips state saving entirely since the binding is already gone by the time onSaveInstanceState is called.

I'm closing this PR for now and will unassign myself to study #6347 and Rohit’s suggestions. I want to understand the deeper architectural shift needed here so I can contribute a more systematic fix in the future rather than just patching individual crash reports. I appreciate you saving me the re-work!