Enhance Performance of PopularMonumentsViewMobile with Optimized Lazy Bloc Initialization✅

[kareemabdeen]

Description

Here’s a brief and simple introduction before detailing each of the key points in the refactor of your PopularMonumentsViewMobile widget:

In the recent update to our app, we made some changes to how the PopularMonumentsViewMobile widget operates to make it simpler and more efficient. Here’s a straightforward breakdown of what’s improved:

1. Automated Bloc Management:

   • Simple Explanation: BlocProvider handles creating and destroying the bloc automatically, eliminating the need for manual management and helping to avoid unnecessary memory usage.

2. Lazy Initialization:

   • Simple Explanation: The bloc is set up only when it is actually needed, not immediately when the app launches. This approach conserves resources, improving the app's speed and responsiveness.

3. Refactoring Impact:

   • Simple Explanation: Changing from a StatefulWidget to a StatelessWidget and using BlocProvider simplifies the code by automating the bloc's lifecycle management. This reduces the complexity and potential for bugs, ensuring the app runs smoothly without manual intervention for bloc cleanup.

---

For insights into why the creators of the flutter_bloc package recommend it for effective state management
the official documentation at [flutter_bloc package](https://pub.dev/packages/flutter_bloc).

Next Steps: I will submit a PR to integrate BlocObserver, allowing us to monitor the enhancements closely. This tool will enable us to track the bloc's behavior effectively and address any issues promptly.

Type of change

• Refactor (does not change functionality, e.g., code style improvements, linting)

How Has This Been Tested?

The changes have been tested by:

• Performing manual testing to verify that the PopularMonumentsViewMobile behaves as expected when navigating to and interacting with the widget.

Test Configuration:

Please include screenshots below if applicable.
The current view remains stable, unbroken, and performs well.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (if applicable)
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works (if applicable)
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules (if applicable)
• I have checked my code and corrected any misspellings

Maintainer Checklist

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tag the PR with the appropriate labels

[kareemabdeen]

I have rebased the current branch with the latest merged branch #228 . It’s now ready for review, inshaAllah. Can you please review? @mdmohsin7

[mdmohsin7]

We currently use a service locator that creates a single instance of the objects (follows the observer pattern to an extent). This PR change would create a new bloc instance again I believe and the service locator already initialises them lazily. So there's not much of a benefit to do it this way unless we remove the initialisation from the service locator

[kareemabdeen]

@mdmohsin7
Thank you for the feedback! While the service locator handles lazy initialization, it doesn’t automatically clean up the bloc when the widget is removed from the tree. This can lead to unnecessary memory usage. My approach ties the bloc's lifecycle to the widget using BlocProvider, which ensures it is created only when needed and disposed of automatically when the widget is removed. This improves resource management and avoids manual cleanup, making the code more efficient and reliable.