feat: Add error handling and success status for screen operations

[SurajPatil1404]

I've made a meaningful contribution that improves the plugin by:

Adding error handling to screen operations
Returning boolean status to indicate operation success
Updating documentation with error handling examples
Updating the changelog
The changes:

Improve reliability by properly handling errors
Make it easier for developers to handle failures
Follow best practices for error handling
Add better documentation and examples

[gemini-code-assist]

Summary of Changes

Hello @SurajPatil1404, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the robustness and usability of the screen operations by introducing comprehensive error handling and explicit success status reporting. Developers can now reliably determine the outcome of turnScreenOff() and turnScreenOn() calls, leading to more resilient applications and improved developer experience through clearer API contracts and updated documentation.

Highlights

• Error Handling: Implemented try-catch blocks within turnScreenOff() and turnScreenOn() methods to gracefully handle potential PlatformExceptions during screen operations, preventing crashes and providing a more robust API.
• Success Status Return: Modified turnScreenOff() and turnScreenOn() methods to return a Future<bool>, explicitly indicating whether the screen operation was successful (true) or failed (false), allowing developers to react accordingly.
• Documentation Updates: Updated the README.md with new code examples demonstrating how to effectively use the boolean return values for turnScreenOff() and turnScreenOn() to check for operation success or failure.
• Changelog Entry: Added a new entry to CHANGELOG.md for version 0.0.7, detailing the addition of error handling, success status returns, and updated documentation, ensuring clear version tracking.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to improve error handling by returning a boolean success status. While this is a good goal, the current implementation in lib/src/screen_off.dart swallows exceptions, which hides important error details from developers and makes the library harder to debug. The documentation has also become inconsistent with the implementation. I've provided suggestions to let exceptions propagate, which is a more robust approach for library design. Additionally, I've found a small issue in the README.md example code where a variable is redeclared, which would cause a compile error.

[SurajPatil1404]

Thank you for the detailed review and helpful suggestions! 🙏

I’ve made the following updates based on your feedback:

Removed the try-catch blocks from both turnScreenOff() and turnScreenOn() to let exceptions propagate naturally, ensuring better error visibility for developers.

Updated the documentation comments to clearly state that a PlatformException will be thrown on failure.

Fixed the duplicate variable declaration in the README example — it now reassigns the existing success variable instead of redeclaring it.

Ensured the README examples and comments are consistent with the implementation.