Skip to content
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

fix(sensors_plus): corrected iOS magnetometer source #3019

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Zabadam
Copy link
Contributor

@Zabadam Zabadam commented Jun 3, 2024

Obtain magnetometer events from DeviceMotion rather than raw startMagnetometerUpdates(). This also makes the magnetometer onCancel() method now correct.1 Added set showsDeviceMovementDisplay to true for magnetometer.

1 While working on the changes, I noticed the current implementation in onCancel() calls _motionManager.stopDeviceMotionUpdates(). This is interesting, because the correct course is to obtain events from MotionManager, but the current implementation is not. Because it currently calls startMagnetometerUpdates(), the onCancel() method ought to call stopMagnetometerUpdates(). Current users of sensors_plus, after obtaining magnetometer readings, could never have the sensor correctly canceled, to my understanding.

At any rate, the onCancel gets to stay as it is while the source of the events is corrected.

Description

When this package was converted to Swift, a previous fix that corrected magnetometer source to DeviceMotion was reverted to using startMagnetometerUpdates().

This pull aims to restore the calibrated magnetometer readings that users are expecting.

As before, I have no way to test this code (no iOS device), and would appreciate someone's assitance in verifying the functionality.

Related Issues

Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I titled the PR using Conventional Commits.
  • I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
  • All existing and new tests are passing.
  • The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

  • Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
  • No, this is not a breaking change.
    • Fixes incorrect behavior with no API changes.

@Zabadam
Copy link
Contributor Author

Zabadam commented Jun 3, 2024

I dug into that test file at sensors_plus\example\integration_test\sensors_plus_test.dart and saw this:

Failing test
void main() {
  IntegrationTestWidgetsFlutterBinding.ensureInitialized();

  // NOTE: The accelerometer events are not returned on iOS simulators.
  testWidgets('Can subscribe to accelerometerEvents and get non-null events',
      (WidgetTester tester) async {
    final completer = Completer<AccelerometerEvent>();
    late StreamSubscription<AccelerometerEvent> subscription;
    subscription =
        accelerometerEventStream().listen((AccelerometerEvent event) {
      completer.complete(event);
      subscription.cancel();
    });
    expect(await completer.future, isNotNull);
  }, skip: !Platform.isAndroid);
}

So perhaps this test was expected to fail regardless of my changes. (My changes are not tested by subscription = accelerometerEventStream().listen(...) and the comment describes the simulator's downfall.)

Thus it would still be beneficial for someone to manually test this change:

dependencies
  # Testing calibrated magnetometer on iOS (https://github.com/fluttercommunity/plus_plugins/pull/3019)
  sensors_plus:
    git:
      url: https://github.com/Zabadam/plus_plugins.git
      ref: 1e2248d # Branch mag-sensor-ios
      path: packages/sensors_plus/sensors_plus

Edit: It did occur to me that some error may be unhandled due to the inclusion of the showsDeviceMovementDisplay flag set, but I struggled to find any such handling in a comparison with peer zesage/motion_sensors who also indeed sets the flag to true.

@vbuberen
Copy link
Collaborator

vbuberen commented Jun 5, 2024

Thanks a lot for your contribution. I will try to test the change by the end of the week.

@Zabadam
Copy link
Contributor Author

Zabadam commented Jun 7, 2024

It seems that @Silverviql has provided confirmation of corrected functionality. Happy to hear this.

@vbuberen
Copy link
Collaborator

Sorry for not getting back in the promised timeline.
Will do some additional testing myself today for sure.

…netometerUpdates(). This also makes the magnetometer onCancel() method now correct. Added set 'showsDeviceMovementDisplay' to true for magnetometer.
@vbuberen
Copy link
Collaborator

Finally got to this PR to test it and do some research.

When this package was converted to Swift, a #812 source to DeviceMotion was reverted to using startMagnetometerUpdates().

This is not the case. In fact, this change was done on purpose. See #2248 and #2250

However, I see that the calibrated values provided in your branch are actually the ones users might want to get. Also compared the output with a few apps obtaining magnetometer data and see that with changes from this PR getting same output.

Unfortunately, I see that the problem mentioned in #2250 with userAccelerometer and magnetometer sharing sampling rate is back with these changes, so there we need to find some solution to avoid this issue before releasing changes with this PR.

I will do some additional research in the nearest days to see what we can do here.

@Zabadam
Copy link
Contributor Author

Zabadam commented Jun 22, 2024

When this package was converted to Swift, a #812 source to DeviceMotion was reverted to using startMagnetometerUpdates().

This is not the case. In fact, this change was done on purpose. See #2248 and #2250

Better phrasing: "At some point after this package was converted to using Swift . . ." I was gone a while and, without the full research on newer PRs, was trying to reason about a sort of deja-vu feeling. "Did I or didn't I get this corrected last time?" 😅 I never did receive full confirmation of fix. So, thank you for the full timeline.

However, I see that the calibrated values provided in your branch are actually the ones users might want to get. Also compared the output with a few apps obtaining magnetometer data and see that with changes from this PR getting same output.

It seems to be the case overwhelmingly, yes, and it's excellent to hear the results match expectations after this PR.

Unfortunately, I see that the problem mentioned in #2250 with userAccelerometer and magnetometer sharing sampling rate is back with these changes, so there we need to find some solution to avoid this issue before releasing changes with this PR.

I need to familiarize myself with the sampling rate code before I could be of further assistance here.

@miquelbeltran miquelbeltran added the sensors_plus stuff related to sensors plus label Aug 12, 2024
Copy link

@mshzhb mshzhb left a comment

Choose a reason for hiding this comment

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

Tested and the values are correct on IOS now.

@erdemyunsel

This comment has been minimized.

@vbuberen
Copy link
Collaborator

Magnetometer values are wrong on 6.1.0 IOS

This is not the place for a bug report. Open an issue or provide info in the existing one

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

Successfully merging this pull request may close these issues.

[Question]: sensors_plus reports different magnetic values in Android and iOS platforms
6 participants