fix: added bluetooth connection support for ubuntu

[nope3472]

Fixes #1496

Changes

Screenshots / Recordings

Checklist:

• No hard coding: I have used resources from constants.dart without hard coding any value.
• No end of file edits: No modifications done at end of resource files.
• Code reformatting: I have reformatted code and fixed indentation in every file included in this pull request.
• Code analyzation: My code passes analyzations run in flutter analyze and tests run in flutter test.

[sourcery-ai]

Sorry @nope3472, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[mariobehling]

Please fix the common build. Thanks

[github-actions]

Build Status

Build successful. APKs to test: https://github.com/fossasia/badgemagic-app/actions/runs/18715870948/artifacts/4339685112.

Screenshots

Android Screenshots

iPhone Screenshots

iPad Screenshots

[mariobehling]

Thanks for the Ubuntu/Linux Bluetooth support addition. The changes are meaningful and directionally correct. Below are issues that I believe must be addressed before merging, plus suggestions and a test plan.

---

✅ Must-Fix Before Merge

1. Hardcoded known-device MAC & constructing fake ScanResult

   In badge_message_provider.dart’s _tryKnownDevices, there is:

   final knownDevices = ['5C:53:10:B7:AC:F6'];
   for (final id in knownDevices) {
     final mock = ScanResult(
       device: BluetoothDevice(id: id),
       advertisementData: /* some constructed AdvertisementData */,
       rssi: -50,
     );
     completer.complete(ConnectState(mock, manager));
   }

   • This is brittle: it embeds a specific device ID in the app code.

   • Creating a fake ScanResult may lead to inconsistent or incorrect state (e.g. using dummy RSSI, advertisement data) and may not map well to the UI or connection flow.

   • Fix: Instead, either:

     • Remove the known-device fallback altogether (default to scan-only).
     • Or make the fallback list configurable (e.g. via a settings or developer mode), and avoid fabricating ScanResult. If needed, refactor the connection API to accept a raw device ID or identifier in Linux context rather than forcing a ScanResult.

2. Inconsistent use of isCompleted snapshot vs completer actual state

   The method signature is:

   Future<bool> _tryKnownDevices(Completer<BleState?> completer, bool isCompleted)

   You pass isCompleted = completer.isCompleted into the method, then inside you also check completer.isCompleted. This duplication risks state divergence (the boolean captured may differ from the actual completer state later).

   • Fix: Remove the bool isCompleted parameter. Inside the method, always check completer.isCompleted to know if we should abort. Storing a snapshot is unnecessary and error-prone.

3. Ensure stopScan() always runs on failure / exception paths

   The scan logic is somewhat complex with repeated startScan() / stopScan() calls and delays. If an error is thrown in between, the Bluetooth adapter may remain scanning indefinitely.

   • Fix: Wrap scan-start / scan-stop phases in try/finally blocks so that stopScan() is guaranteed to run in failure paths. E.g.:

     try {
       await FlutterBluePlus.startScan(...);
       // scanning & waiting logic
     } finally {
       await FlutterBluePlus.stopScan();
     }

4. Localization: Linux-specific messages not using l10n

   In BadgeMessageProvider, lines like:

   showToast('Bluetooth is not available on this system.');

   are hardcoded English strings. Meanwhile, other branches use l10n.xxx. All user-facing strings should be localized.

   • Fix: Move these messages into ARB / localization keys and replace with l10n.<key>.

---

🔍 Suggested Enhancements / Robustness

• After the broad scan (fallback), filter discovered devices by expected service UUID(s) before attempting connect. This avoids connecting to irrelevant devices.
• Consolidate timeouts into constants and document them clearly (e.g. "initial scan up to 5 s, fallback up to 3 s").
• Use appropriate log levels (e.g. logger.i, logger.w, logger.e) for major events, not just logger.d.
• If there is coupling of downstream logic to ScanResult fields (e.g. advertisement data or name), refactor to make Linux connection flows agnostic to dummy vs real scan data.

[samruddhi-Rahegaonkar]

@hpdang @nope3472 This looks Good to me!

[samruddhi-Rahegaonkar]

@nope3472 Just remove the hardcoded GUID. we are using it in connect_state.dart also it will be good.

[hpdang]

@nope3472 please address the comment of Samruddhi so we can merge this

[adityastic]

Have a common interface with your functions exposed. Implement platform specific code into their own classes that extend the interface. Create a small manager which can look at the platform and instantiate the right implementation class for you. Which is then used across states/anywhere you like