Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Settings highlight does not follow 'back button' #17447

Closed
wants to merge 1 commit into from

Conversation

jainv4156
Copy link
Contributor

@jainv4156 jainv4156 commented Nov 15, 2024

Purpose / Description

Approach

  • When the back button is pressed, the current fragment is popped from the back stack, and the previous fragment is displayed.

  • The onResume method of the newly visible fragment is triggered.

  • In the onResume method, the current fragment passes its unique key to the associated Preferences activity.

  • The Preferences activity locates the HeaderFragment using the fragment manager and passes the received key to it.

  • The HeaderFragment uses the key to identify the appropriate header and highlights it.

Description of Changes

HeaderFragment.kt

  • Added a New Function: handleHighlightHeaderPreferenceOnBack
    • Purpose: Highlights a specific header preference when the back button is pressed.

Preferences.kt

  • Introduced a New Function: handleHighlightPreferenceOnBack
    • Details:
    • Fetches the HeaderFragment instance.
    • Calls the handleHighlightHeaderPreferenceOnBack method on the HeaderFragment.

SettingsFragment.kt

  • Overridden the onResume Method:
    • Purpose: Ensures the highlighting logic is triggered when the fragment resumes.
    • Details:
      • Calls the handleHighlightPreferenceOnBack method from Preferences to handle the highlighting logic.

Fixes

Checklist

Please, go through these checks before submitting the PR.

  • You have a descriptive commit message with a short title (first line, max 50 chars).
  • You have commented your code, particularly in hard-to-understand areas
  • You have performed a self-review of your own code
  • UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
  • UI Changes: You have tested your change using the Google Accessibility Scanner
Screen_recording_20241115_173821.webm

@jainv4156 jainv4156 closed this Nov 15, 2024
@jainv4156 jainv4156 reopened this Nov 15, 2024
@lukstbit lukstbit added the Needs Author Reply Waiting for a reply from the original author label Nov 15, 2024
@Aditya13s
Copy link
Contributor

@jainv4156 , can you complete all the details in the PR template? Thanks!

@jainv4156
Copy link
Contributor Author

jainv4156 commented Nov 18, 2024

@jainv4156 , can you complete all the details in the PR template? Thanks!

just to be sure ,do you mean testing with accessibility scanner.

@Aditya13s
Copy link
Contributor

just to be sure ,do you mean testing with accessibility scanner.

It's about the description and the approach you used, present in the template

@lukstbit lukstbit added Needs Review and removed Needs Author Reply Waiting for a reply from the original author labels Nov 19, 2024
Copy link
Member

@mikehardy mikehardy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems reasonable - tiny nitpicks just a typo

@@ -43,7 +42,7 @@ class HeaderFragment : PreferenceFragmentCompat() {
highlightHeaderPreference(requirePreference<HeaderPreference>(selectedHeaderPreferenceKey))

requirePreference<HeaderPreference>(R.string.pref_backup_limits_screen_key)
.title = CollectionManager.TR.preferencesBackups()
.title = TR.preferencesBackups()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a reasonable change but is a refactor (along with the removal of collection manager - and I was curious why it was in the same commit - we usually split refactor stuff into separate commits so that review stays focused on the functional changes. No big deal this time though - just something to keep in the mind when developing in the future - think of the person that will review your code and make sure you keep their attention focused on the important bits by not including unimportant bits at the same time

@@ -105,6 +104,10 @@ class HeaderFragment : PreferenceFragmentCompat() {
requirePreference<Preference>(R.string.pref_dev_options_screen_key).isVisible = isVisible
}

fun handelHighlightHeaderPreferenceOnBack(key: String) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo

Suggested change
fun handelHighlightHeaderPreferenceOnBack(key: String) {
fun handleHighlightHeaderPreferenceOnBack(key: String) {

val fragmentManager = supportFragmentManager
if (key != null) {
val headerFragment = (fragmentManager.findFragmentById(R.id.lateral_nav_container) as? HeaderFragment)
headerFragment?.handelHighlightHeaderPreferenceOnBack(key)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo

Suggested change
headerFragment?.handelHighlightHeaderPreferenceOnBack(key)
headerFragment?.handleHighlightHeaderPreferenceOnBack(key)

@mikehardy mikehardy added the Needs Author Reply Waiting for a reply from the original author label Nov 26, 2024
@@ -100,6 +100,15 @@ abstract class SettingsFragment :
dialogFragment.show(parentFragmentManager, "androidx.preference.PreferenceFragment.DIALOG")
}

override fun onResume() {
super.onResume()
preferenceScreen?.key?.let {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(requireActivity() as Preferences)

This is going to conflict with

Please be sure that this method would work once the fragment is extracted from the activity

@@ -100,6 +100,15 @@ abstract class SettingsFragment :
dialogFragment.show(parentFragmentManager, "androidx.preference.PreferenceFragment.DIALOG")
}

override fun onResume() {
super.onResume()
preferenceScreen?.key?.let {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't necessary. handleHighlightPreferenceOnBack handles a nullable string

(requireActivity() as Preferences).handleHighlightPreferenceOnBack(preferenceScreen.key) without the let { will work

Comment on lines +195 to +201
fun handleHighlightPreferenceOnBack(key: String?) {
val fragmentManager = supportFragmentManager
if (key != null) {
val headerFragment = (fragmentManager.findFragmentById(R.id.lateral_nav_container) as? HeaderFragment)
headerFragment?.handelHighlightHeaderPreferenceOnBack(key)
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extract finding the header fragment into a property so the intent of the method is clear:

    fun handleHighlightPreferenceOnBack(key: String?) {
        if (key == null) return
        lateralNavigationFragment?.handleHighlightHeaderPreferenceOnBack(key)
    }

@david-allison david-allison changed the title fixes Settings highlight does not follow 'back button' fix: Settings highlight does not follow 'back button' Nov 26, 2024
@mikehardy mikehardy added this to the 2.19.3 release milestone Nov 26, 2024
@jainv4156
Copy link
Contributor Author

jainv4156 commented Nov 27, 2024

Thanks, @david-allison , for mentioning this PR #17487 to me. I checked my implementation by bringing these PR changes locally. As this PR introduces a lot of changes to my implementation, would it be okay if I continue working on my PR after this one is merged?

@BrayanDSO
Copy link
Member

That PR also fixes the issue, and closes this PR. So it won't be necessary to continue working on this PR after that. Sorry for the time spent here.

@jainv4156
Copy link
Contributor Author

That PR also fixes the issue, and closes this PR. So it won't be necessary to continue working on this PR after that. Sorry for the time spent here.

sure

@jainv4156 jainv4156 closed this Nov 27, 2024
@jainv4156 jainv4156 reopened this Nov 27, 2024
@jainv4156 jainv4156 closed this Nov 27, 2024
@jainv4156 jainv4156 deleted the bug-fixes branch November 27, 2024 17:19
@mikehardy mikehardy removed this from the 2.19.3 release milestone Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Author Reply Waiting for a reply from the original author Needs Review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG]: Tablet: Settings highlight does not follow 'back button'
6 participants