fix(ui): increase dashboard RefreshIndicator edge offset

[Domenic-MZS]

🔧🎨 UI Fix: Increase dashboard RefreshIndicator edge offset

This change adjusts the edge offset for the RefreshIndicator in the home view dashboard UI with the CustomSliverAppBar maxExtent size, ensuring a better user experience by moving the RefreshIndicator under the SliverAppbar.

Fixes #1568

Overview

The HomeView / Dashboard [CustomScrollView] refresh functionality has been enhanced by matching the starting refresh position with the [SliverAppBar] height, and by reducing the displacement range to settle the refresh.

• Issue: The RefreshIndicator starts the animation on top of the [SliverAppBar], disturbing the user experience (?).
• Context: The current functionality lacks an increased starting point ([edgeOffset]) or a better layout.
• Related Solutions: (None).
• Impact: Improves the user experience by making the refresh indicator more concise and easy to use by reducing the needed displacement to work and by correct positioning the indicator on the affected area (the body and not the header).

📓 Description

This PR sets the Dashboard [edgeOffset] (indicator starting point) to match the [CustomSliverAppBar] (title) height and changes the default [displacement] to execute the refresh callback.

✍🏼 Changes Made

• Added property ([edgeOffset])[edge-offset].
• Reduces the refresh indicator needed [displacement] to settle.

Technical Overview

> (For the RefreshIndicator widgtet wrapping the content) - Add the `edgeOffset` property with the `CustomSliverAppBar` hardcoded `extendedHeight`. (~magic number) - Add the `displacement` property to 50. (reduces the needed scroll to settle the "refresh" action)

🦯 Testing

• Update Tests (ToDo - Not Found nor needed for now...)
• Compile/Build code
  • 🐞 Tested with Stable Flutter v3.19.3 and dart 3.3.1.
  • System: Linux archlinux 6.7.9-arch1-1 GNU/Linux

WhatsApp.Video.2024-04-07.at.19.39.42.mp4

📋 Notes & References

RefreshIndicator - edgeOffset
Current Custom Sliver App Bar - ExpandedHeight

🔬 Reviewers

N/A (any mod is ok)

---

👾 Feedback, changes, or suggestions are welcome! ✌🏼 🏖️ this time an 🥑 emoji...

[Domenic-MZS]

Opened as draft as I don't know if using "magic numbers" (actually a static number related to another static magic number) is right or not...

I'm using a static edgeOffset based on the static CustomSliverAppBar expanded height, Line Number 22

revanced-manager/lib/ui/widgets/shared/custom_sliver_app_bar.dart

Lines 20 to 23 in a23f032

	return SliverAppBar(
	pinned: true,
	expandedHeight: 100.0,
	automaticallyImplyLeading: !isMainView,

[ILoveOpenSourceApplications]

Can the refresh icon animation be also improved or is it because the manager refreshes too quickly that the animation is getting canceled out?

[Domenic-MZS]

Can the refresh icon animation be also improved or is it because the manager refreshes too quickly that the animation is getting canceled out?

The animation is not cancelled; it's just fast because the completion of the promise for refresh happens almost instantly. This occurs because the code doesn't wait for the promises.

revanced-manager/lib/ui/views/home/home_viewmodel.dart

Lines 494 to 498 in a23f032

	Future<void> forceRefresh(BuildContext context) async {
	_managerAPI.clearAllData();
	_toast.showBottom(t.homeView.refreshSuccess);
	initialize(context);
	}

[oSumAtrIX]

Is this ready for review?

[Aunali321]

@Domenic-MZS Can you try to remove magic numbers if possible?

[Domenic-MZS]

@Domenic-MZS Can you try to remove the magic numbers if possible?

While it's technically feasible, the current trade-offs involved wouldn't add significant value. Incorporating this functionality while maintaining the current user interface would unnecessarily increase complexity for this particular case.

I can think one of three possible solutions:

1. Make the extendedHeight of the CustomSliverAppBar parametrizable to match the offset.
2. Encapsulate the entire component tree within a LayoutBuilder to obtain metrics and sizes after rendering, which would allow us to compute and adjust the offset during a second redraw. / Or use a NestedScrollView (Way different of the current UI as it's always scrollable)
3. Utilize a GlobalKey to retrieve the expanded height of the SliverAppBar after it renders and then update the offset on a subsequent redraw.

However, none of these solutions are particularly appealing, as the requirement is specific to only one file, and the drawbacks outweigh the benefits.

---

In addition, the CustomSliverAppBar widget will most likely not change frequently, and if it does change in the future, the current implementation is most likely to work.

The most realistic scenario would be that in the future the hardcoded expandedHeight value will instead become a default which could be override. Thus, making the current implementation still functioning.

Sure, there's still a need to ensure that updates on the shared widget don't cause disruptive changes over time, but most likely, it wouldn't happen.