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

[Feature] Support for Config.triggerActivities on iOS #283

Open
chrisbiscuit opened this issue Oct 10, 2024 · 11 comments
Open

[Feature] Support for Config.triggerActivities on iOS #283

chrisbiscuit opened this issue Oct 10, 2024 · 11 comments
Labels

Comments

@chrisbiscuit
Copy link

Request:

I would like to request the addition of Config.triggerActivities, which is currently only supported on Android, to be made available for iOS as well.

Current Usage Example on Android:

BackgroundGeolocation.ready({
  triggerActivities: 'on_foot, running', 
});

Thanks

@christocracy
Copy link
Member

Test by installing version 6.1.1-rc.1

@csotiMatyas
Copy link

csotiMatyas commented Oct 17, 2024

@christocracy Good 'any time of the day you at', i just went through the Philosophy of Operation for something unrelated, and got my eyes on 'both android and ios supporting motion-activity', so i arrived here. While the docs specify android only ( been like this for the past year+ we have been using the plugin, btw: this is by far the best documented / meticulous plugin i have ever used, hands down ). So is the iOS activity feature being added now ( or in work in progress ) assuming your comment ?

How reliable is this feature ( both platforms )? We did not test it for the above reason. Our problem is the phones being used as ..phones as well, not just fleet tracking GPS devices, so the GPS data is mixed and its quite a pain diffing in_vechile data from any other activity data. So can can motion-activity solve this? ( if you have experience with this )

Best regards,

@christocracy
Copy link
Member

How reliable is this feature

It requires that the user authorize the “Physical Activity” permission request. The quality of results depends upon the results provided by the Motion API. The quality on Android varies greatly with the quality of the device.

@csotiMatyas
Copy link

csotiMatyas commented Oct 17, 2024

@chrisbiscuit Were you able to test the feature on ( 6.1.1-rc.1 ) iOS in the meantime? I will not have time to upgrade the native version of the app these weeks.

@chrisbiscuit
Copy link
Author

chrisbiscuit commented Oct 17, 2024

@csotiMatyas We are currently busy testing this feature, I'll send an update as soon as I have more information.

@csotiMatyas
Copy link

@chrisbiscuit i am very, very grateful 🙇

@csotiMatyas
Copy link

csotiMatyas commented Oct 28, 2024

@christocracy I have another question regarding activity type on android, i dont know where else can i ask specific questions like thiese, so i'm sorry for posting it here. How does the plugin actually handle the activity type? Reading through the android docs it specifies a confidence level for a specified activity type, so is the plugin filtering out entries at an arbitrary confidence level like specified type with a a confidence of 60? Or it
just forwards whatever it receives from the DetectedActivity. What or where should i look for any difference in the data received?

I am receiving an activity type of still with a confidence of 100 when using fake locations ( lokito ), but should'nt then i get either no locations if lokito can't spoof my activity type, or give back activity type as in_vehicle ( since thats what i did specify ) and activity confidence 0?

@christocracy
Copy link
Member

The plug-in uses the a higher level MotionTransitionApi which does not provide confidence. confidence is always 100 on Android.

@csotiMatyas
Copy link

@christocracy Then as of my understanding, setting activity type in_vehicle should result in the plugin not recording any locations even if my location is changing, ex: lockito. Or are there any heuristics happening under the hood, ex: speed check, or this is an artifact of fake locations.

Also: the Activity Recognition Api as per the docs: https://developer.android.com/develop/sensors-and-location/location/transitions

requires the following :

To declare a dependency to the API, add a reference to the Google maven repository and add an implementation entry to com.google.android.gms:play-services-location:12.0.0 to the dependencies section of your app build.gradle file. For more information, see Set Up Google Play Services.
To specify the com.google.android.gms.permission.ACTIVITY_RECOGNITION permission, add a element in the app manifest, as shown in the following example:

This is not specified in the plugin docs, are these not required?

@christocracy
Copy link
Member

ex: lockito. Or are there any heuristics happening under the hood, ex: speed check, or this is an artifact of fake locations.

While using Lockito to mock the LOCATION, your device is still sitting stationary on your desk. The accelerometer and gyroscope believe the device is stationary. If you observe the logs, you'll see the plugin recognizes that the location is being mocked and allows the location to come through and be recorded. You cannot test Config.triggerActivites with mocked location. You need to actually go outside and move.

This is not specified in the plugin docs, are these not required?

If it's not specified, then it's not something you need to be concerned about. The entire purpose of this plugin is to shield you from those specific requirements and excentricities of native iOS / Android development, doing all that difficult work for you.

Copy link

This issue is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale label Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants