Skip to content

feat: Port the configuration screens for remaining instruments. #2778

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 9 commits into
base: flutter
Choose a base branch
from

Conversation

Yugesh-Kumar-S
Copy link
Collaborator

@Yugesh-Kumar-S Yugesh-Kumar-S commented Jul 9, 2025

Fixes #2768

Please use commits for reviewing each instrument

Changes

  • Added a configuration screen for sound meter, barometer, gyroscope and accelerometer.
  • Configurations are stored using shared preferences similar to the lux meter.

Screenshots / Recordings

Checklist:

  • No hard coding: I have used resources from strings.xml, dimens.xml and colors.xml without hard coding any value.
  • No end of file edits: No modifications done at end of resource files strings.xml, dimens.xml or colors.xml.
  • Code reformatting: I have reformatted code and fixed indentation in every file included in this pull request.
  • No extra space: My code does not contain any extra lines or extra spaces than the ones that are necessary.

Summary by Sourcery

Port the configuration feature to all remaining instrument screens and persist their settings

New Features:

  • Add options menu entry to accelerometer, barometer, gyroscope, and sound meter screens to navigate to configuration

Enhancements:

  • Implement provider-based configuration screens for accelerometer, barometer, gyroscope, and sound meter
  • Persist configuration settings via SharedPreferences across sessions
  • Extend constants for configuration labels and hints

Copy link

sourcery-ai bot commented Jul 9, 2025

Reviewer's Guide

This PR extends the existing lux-meter configuration pattern to soundmeter, barometer, gyroscope, and accelerometer by injecting an options menu into each instrument screen that navigates to a dedicated config screen. Each config screen is backed by a ChangeNotifierProvider that persists user settings via SharedPreferences, reuses common ConfigWidgets for input rendering and validation, and updates relevant string constants.

Sequence diagram for instrument screen to configuration screen navigation and persistence

sequenceDiagram
    actor User
    participant InstrumentScreen
    participant ConfigScreen
    participant ConfigProvider
    participant SharedPreferences
    User->>InstrumentScreen: Tap options menu
    InstrumentScreen->>InstrumentScreen: Show menu
    User->>InstrumentScreen: Select 'Configurations'
    InstrumentScreen->>ConfigScreen: Navigate to config screen (with provider)
    ConfigScreen->>ConfigProvider: Read config (on init)
    ConfigProvider->>SharedPreferences: Load config
    SharedPreferences-->>ConfigProvider: Return config data
    ConfigProvider-->>ConfigScreen: Provide config values
    User->>ConfigScreen: Update config values
    ConfigScreen->>ConfigProvider: Update config
    ConfigProvider->>SharedPreferences: Save config
    SharedPreferences-->>ConfigProvider: Confirm save
    ConfigProvider-->>ConfigScreen: Notify listeners
    ConfigScreen-->>User: Show updated config
Loading

Class diagram for new and updated configuration models and providers

classDiagram
    class SoundMeterConfig {
      +bool includeLocationData
      +copyWith()
      +toJson()
      +fromJson()
    }
    class SoundMeterConfigProvider {
      -SoundMeterConfig _config
      +SoundMeterConfig get config
      +updateConfig()
      +updateIncludeLocationData()
      +resetToDefaults()
    }
    class AccelerometerConfig {
      +int updatePeriod
      +int highLimit
      +String activeSensor
      +int sensorGain
      +bool includeLocationData
      +copyWith()
      +toJson()
      +fromJson()
    }
    class AccelerometerConfigProvider {
      -AccelerometerConfig _config
      +AccelerometerConfig get config
      +updateConfig()
      +updateUpdatePeriod()
      +updateHighLimit()
      +updateActiveSensor()
      +updateSensorGain()
      +updateIncludeLocationData()
      +resetToDefaults()
    }
    class BarometerConfig {
      +int updatePeriod
      +double highLimit
      +String activeSensor
      +bool includeLocationData
      +copyWith()
      +toJson()
      +fromJson()
    }
    class BarometerConfigProvider {
      -BarometerConfig _config
      +BarometerConfig get config
      +updateConfig()
      +updateUpdatePeriod()
      +updateHighLimit()
      +updateActiveSensor()
      +updateIncludeLocationData()
      +resetToDefaults()
    }
    class GyroscopeConfig {
      +int updatePeriod
      +int highLimit
      +int sensorGain
      +bool includeLocationData
      +copyWith()
      +toJson()
      +fromJson()
    }
    class GyroscopeConfigProvider {
      -GyroscopeConfig _config
      +GyroscopeConfig get config
      +updateConfig()
      +updateUpdatePeriod()
      +updateHighLimit()
      +updateSensorGain()
      +updateIncludeLocationData()
      +resetToDefaults()
    }
    SoundMeterConfigProvider --> SoundMeterConfig
    AccelerometerConfigProvider --> AccelerometerConfig
    BarometerConfigProvider --> BarometerConfig
    GyroscopeConfigProvider --> GyroscopeConfig
Loading

File-Level Changes

Change Details Files
Injected options menu in instrument screens and wired navigation to config screens
  • Added _showOptionsMenu() and _navigateToConfig() methods
  • Passed onOptionsPressed callback to CommonScaffold
  • Wrapped config screens in ChangeNotifierProvider on navigation
lib/view/soundmeter_screen.dart
lib/view/accelerometer_screen.dart
lib/view/barometer_screen.dart
lib/view/gyroscope_screen.dart
Added new configuration screens for each instrument
  • Created StatefulWidget screens with AppBar and form layout
  • Initialized controllers from provider state and disposed them
  • Used ConfigInputItem, ConfigDropdownItem, ConfigCheckboxItem with validation
lib/view/accelerometer_config_screen.dart
lib/view/barometer_config_screen.dart
lib/view/gyroscope_config_screen.dart
lib/view/soundmeter_config_screen.dart
Implemented ChangeNotifierProviders persisting configs via SharedPreferences
  • Loaded JSON from prefs in constructor and notified listeners
  • Exposed update methods per field that copy config, notify, and save
  • Included resetToDefaults for each provider
lib/providers/accelerometer_config_provider.dart
lib/providers/barometer_config_provider.dart
lib/providers/gyroscope_config_provider.dart
lib/providers/soundmeter_config_provider.dart
Defined config model classes with JSON serialization
  • Implemented default values, copyWith, toJson, fromJson
  • Mapped each field to appropriate type and range
lib/models/accelerometer_config.dart
lib/models/barometer_config.dart
lib/models/gyroscope_config.dart
lib/models/soundmeter_config.dart
Updated constants and hints for all config screens
  • Renamed existing lux meter hint constants
  • Added titles and hint strings for new instruments
lib/constants.dart
lib/view/luxmeter_config_screen.dart

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

Copy link

github-actions bot commented Jul 10, 2025

@Yugesh-Kumar-S Yugesh-Kumar-S marked this pull request as ready for review July 10, 2025 07:32
Copy link

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @Yugesh-Kumar-S - I've reviewed your changes - here's some feedback:

  • The showOptionsMenu and navigation logic is almost identical across each instrument screen—consider extracting it into a shared helper or base widget to reduce boilerplate.
  • Your shared‐preferences keys (e.g. "Sound_config" vs "accelerometer_config") are inconsistent—standardize the naming convention to avoid confusion or collisions.
  • All ConfigScreen classes repeat very similar form layout and validation logic; think about creating a generic config form builder or abstract widget to DRY up the code.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The showOptionsMenu and navigation logic is almost identical across each instrument screen—consider extracting it into a shared helper or base widget to reduce boilerplate.
- Your shared‐preferences keys (e.g. "Sound_config" vs "accelerometer_config") are inconsistent—standardize the naming convention to avoid confusion or collisions.
- All ConfigScreen classes repeat very similar form layout and validation logic; think about creating a generic config form builder or abstract widget to DRY up the code.

## Individual Comments

### Comment 1
<location> `lib/providers/soundmeter_config_provider.dart:14` </location>
<code_context>
+  }
+  Future<void> _loadConfigFromPrefs() async {
+    final prefs = await SharedPreferences.getInstance();
+    final jsonString = prefs.getString('Sound_config');
+    if (jsonString != null) {
+      final Map<String, dynamic> jsonMap = json.decode(jsonString);
+      _config = SoundMeterConfig.fromJson(jsonMap);
</code_context>

<issue_to_address>
Inconsistent key casing for SharedPreferences may cause config loading issues.

Consider renaming the key to match the lowercase format used by other config providers to maintain consistency and prevent potential issues.
</issue_to_address>

### Comment 2
<location> `lib/providers/gyroscope_config_provider.dart:17` </location>
<code_context>
+
+  Future<void> _loadConfigFromPrefs() async {
+    final prefs = await SharedPreferences.getInstance();
+    final jsonString = prefs.getString('gyro_config');
+    if (jsonString != null) {
+      final Map<String, dynamic> jsonMap = json.decode(jsonString);
+      _config = GyroscopeConfig.fromJson(jsonMap);
</code_context>

<issue_to_address>
SharedPreferences key 'gyro_config' is inconsistent with class naming.

Consider renaming the key to 'gyroscope_config' for consistency with class and file names.

Suggested implementation:

```
    final jsonString = prefs.getString('gyroscope_config');

```

```
    await prefs.setString('gyroscope_config', json.encode(_config.toJson()));

```
</issue_to_address>

### Comment 3
<location> `lib/view/accelerometer_config_screen.dart:95` </location>
<code_context>
+                      controller: _updatePeriodController,
+                      onChanged: (value) {
+                        final intValue = int.tryParse(value);
+                        if (intValue != null &&
+                            intValue >= 100 &&
+                            intValue <= 1000) {
+                          provider.updateUpdatePeriod(intValue);
</code_context>

<issue_to_address>
Update period upper limit is inconsistent with other sensors.

If the 1000 ms limit is intentional, please document the rationale; otherwise, align it with the 2000 ms limit used for other sensors.
</issue_to_address>

### Comment 4
<location> `lib/view/barometer_config_screen.dart:115` </location>
<code_context>
+                      controller: _highLimitController,
+                      onChanged: (value) {
+                        final doubleValue = double.tryParse(value);
+                        if (doubleValue != null &&
+                            doubleValue >= 0 &&
+                            doubleValue <= 1.10 &&
+                            doubleValue.toString().length <= 4) {
</code_context>

<issue_to_address>
String length check for doubleValue may not reliably limit decimal places.

Using doubleValue.toString().length may not accurately restrict decimal places. Use string formatting or a regex to enforce the desired precision.
</issue_to_address>

<suggested_fix>
<<<<<<< SEARCH
                        final doubleValue = double.tryParse(value);
                        if (doubleValue != null &&
                            doubleValue >= 0 &&
                            doubleValue <= 1.10 &&
                            doubleValue.toString().length <= 4) {
                          provider.updateHighLimit(doubleValue);
=======
                        final doubleValue = double.tryParse(value);
                        final regex = RegExp(r'^\d+(\.\d{1,2})?$');
                        if (doubleValue != null &&
                            doubleValue >= 0 &&
                            doubleValue <= 1.10 &&
                            regex.hasMatch(value)) {
                          provider.updateHighLimit(doubleValue);
>>>>>>> REPLACE

</suggested_fix>

### Comment 5
<location> `lib/models/gyroscope_config.dart:40` </location>
<code_context>
+  factory GyroscopeConfig.fromJson(Map<String, dynamic> json) {
+    return GyroscopeConfig(
+      updatePeriod: json['updatePeriod'] ?? 1000,
+      highLimit: json['highLimit'] ?? 20,
+      sensorGain: json['sensorGain'] ?? 1,
+      includeLocationData: json['includeLocationData'] ?? true,
</code_context>

<issue_to_address>
Default highLimit for gyroscope is 20, which may be low compared to the allowed range.

Since the UI permits values up to 1000, consider aligning the default highLimit with this range unless 20 is intentional.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment on lines +95 to +96
if (intValue != null &&
intValue >= 100 &&
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Update period upper limit is inconsistent with other sensors.

If the 1000 ms limit is intentional, please document the rationale; otherwise, align it with the 2000 ms limit used for other sensors.

@marcnause
Copy link
Contributor

@Yugesh-Kumar-S Merging #2779 introduced conflicts with this PR. Could you please have a look and resolve them?

@Yugesh-Kumar-S
Copy link
Collaborator Author

@Yugesh-Kumar-S Merging #2779 introduced conflicts with this PR. Could you please have a look and resolve them?

Done👍 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Port configuration screen for instruments and store the configuration.
3 participants