bugfix/system-brightness-not-decreasing

[aaassseee]

No description provided.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.21%. Comparing base (67a6077) to head (03cc0b1).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop      #91      +/-   ##
===========================================
+ Coverage    99.14%   99.21%   +0.07%     
===========================================
  Files            4        4              
  Lines          117      128      +11     
===========================================
+ Hits           116      127      +11     
  Misses           1        1              

Flag	Coverage Δ
unittests	99.21% <100.00%> (+0.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aaassseee]

Fix #53 by adding an option to tweak auto brightness

[aaassseee]

Summary: Good structure and clear method handlers. Main concerns are potential crashes from uninitialized/force-unwrapped state and inconsistent permission flows. Fix those before merging.

🔴 Blocker: uninitialized Delegates.notNull fields

• Risk: maximumScreenBrightness/systemScreenBrightness may remain uninitialized if getSystemScreenBrightness throws, causing IllegalStateException later.
• Suggestion: initialize sensible defaults (e.g., 255.0f / read fallback) in the catch block or use nullable + safe-access with fallbacks.

🔴 Blocker: forced activity!! (NPE)

• Location: setWindowsAttributesBrightness (lines ~417–425).
• Why: activity can be null (detached), calling activity!! will crash.
• Suggestion: check activity != null, return false or surface a clear error.

🟡 Suggestion: clamp/validate brightness inputs

• Location: setSystemScreenBrightness / setWindowsAttributesBrightness.
• Why: callers might pass out-of-range values; clamp to [0f,1f] before applying.

🟡 Suggestion: unify permission UX

• Issue: setSystemScreenBrightness opens WRITE_SETTINGS and returns false; setAutoBrightness opens the settings but returns success immediately.
• Suggestion: pick consistent behavior (either return a distinct result indicating "permission requested" or open settings and fail until caller retries).

💭 Nit/cleanup:

• Minor typo in MethodChannel comment ("will the communication"); consider small doc fix.
• Consider removing unused imports if any (tooling will catch).

Questions:

• Should requesting WRITE_SETTINGS auto-retry after user grants permission, or should the Dart side re-call the method? (Document whichever you choose.)

Nice work on the stream handlers and reflection fallback for maximum brightness.

[aaassseee]

🔴 Blocker — iOS animation uses Thread.sleep + many BlockOperations

File:
ios/Classes/ScreenBrightnessIosPlugin.swift:253–283 (notably 277–279)

Why: Sleeping and queuing many BlockOperations can starve threads, be imprecise, and cause UI jank on the main thread.

Suggestion:

• Animate on the main thread using CADisplayLink or UIView.animate, or use a single scheduled Timer to step brightness.
• Ensure all UI updates run on DispatchQueue.main.

Example:

DispatchQueue.main.async {
  UIView.animate(withDuration: 0.3) {
    UIScreen.main.brightness = CGFloat(target)
  }
}

Or use CADisplayLink to step smoothly for custom timing.

---

🟡 Suggestion — Android brightness sentinel compare

File:
android/src/main/kotlin/.../ScreenBrightnessAndroidPlugin.kt:200–207

Why: Comparing to -1.0f is unclear and brittle.

Suggestion:

• Compare to the named constant for clarity: WindowManager.LayoutParams.BRIGHTNESS_OVERRIDE_NONE.

Example:

if (brightness != WindowManager.LayoutParams.BRIGHTNESS_OVERRIDE_NONE) {
  // apply override
}

---

🟡 Suggestion — unify error codes/messages & method-name constants

File:
screen_brightness_platform_interface/** and native handlers (android/ios)

Why: Mismatched strings between platform_interface and native code cause runtime errors and fragile tests.

Suggestion:

• Define shared constants in platform_interface (error codes, method names) and reference them from native wrappers.
• Add unit tests asserting native ↔ platform string equality.

Example (Dart):

class ScreenBrightnessPlatform {
  static const String methodSetBrightness = 'setScreenBrightness';
  static const String errorInvalidValue = 'invalid-argument';
}

---

💭 Nit — copy/paste throw texts & boundary tests

File:
screen_brightness_platform_interface/lib/src/screen_brightness_platform_interface.dart
test/screen_brightness_test.dart

Why: Some thrown messages reference the wrong context; no tests for out-of-range values.

Suggestion:

• Fix incorrect messages in ScreenBrightnessPlatform throws.
• Add tests for values < 0 and > 1 and for correct clamping behavior.

Example test:

expect(() => platform.setScreenBrightness(-0.1), throwsA(isA<PlatformException>()));
expect(await plugin.getScreenBrightness(), inInclusiveRange(0.0, 1.0));

If desired, produce small patches for the iOS animation and Android check.