[Feature] Support for Config.triggerActivities on iOS

[chrisbiscuit]

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]

Test by installing version 6.1.1-rc.1

[csotiMatyas]

@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]

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]

@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]

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

[csotiMatyas]

@chrisbiscuit i am very, very grateful 🙇

[csotiMatyas]

@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]

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

[csotiMatyas]

@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]

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.