Cordova-plugin-background-geolocation: Location recording in the db should use a provided id given in the configure option

[anymos]

The use case is the following

Different users are using an app that allow the tracking, the users are track by the plugin by url or by headers, the call back then record the position by user.

If the device is offline, then the position are recorded in the db.

if the user is logging out and another user using the same device logged in then, the previously recorded offline position are sent under the new user identity.

if it was possible to add and id that would be recorded in the db within the position and send also to the url it will be possible to have a workaround

It's kind of a hedge case, thank you very much in advance :-)

So at the moment to avoid this problem I am using : backgroundGeolocation.deleteAllLocations();
when a user log out. So please do not deprecate it ;-)

[mauron85]

make sense. worth implementing

[mauron85]

... send also to the url it will be possible to have a workaround

ok I'll add user_id into location table.

However I see potential issues:

1. privacy (any user can get location history of another user by calling getLocations method) - also kind of problem with current implementation. The only way how to solve this is to make user_id mandatory and all methods like getLocations will filter locations for user_id only.
2. location syncing (option.syncUrl) should also sync locations of other users, even when they're not logged in? The problem here is that server implementation will have to deal with this. Currently you can use different syncUrl or httpHeaders for different users (but have to deleteAllLocations on logout/login). But this would not make sense anymore, if locations of any user will be sent.

Any suggestions are welcome.

[jamesdixon]

@mauron85 I second the addition of this option. However, if possible, I'd probably make it something more generic like identifier_id or something that's not necessarily tied to a user. For example, in my case, I need to track location by an appointment id.

As for the above issues that you have pointed out, I believe that shouldn't be a concern of the plugin and all authorization should be handled by the application itself.

My two cents :)

Thanks for all of your hard work!

[anymos]

@mauron85 Great !, I was not thinking you will be that quick to reply to me. Thank a lot !

@jamesdixon, agreed with your point of view as well

As for the above issues that you have pointed out, I believe that shouldn't be a concern of the plugin and all authorization should be handled by the application itself.

privacy (any user can get location history of another user by calling getLocations method) - also kind of problem with current implementation. The only way how to solve this is to make user_id mandatory and all methods like getLocations will filter locations for user_id only.

--> I agree on this, but if you are sharing device between user, you can basically accept that it might have some kind of privacy risk doing so. What I am saying is that kind of privacy issue should not be too much of a real issue.

--> let me give you a typical use case : the app is used for tracking drivers, there is morning and afternoon shift, the device is shared between the morning and afternoon shift. The privacy issue is quite limited in that case :-) even if it s still exist I agree.

--> I am thinking that it should be the task of the javscript to sort out the results when calling getLocations by using the "identifier_id"

--> of course if could be neat to have getLocationsByIdentifierID as well to be optimal

location syncing (option.syncUrl) should also sync locations of other users, even when they're not logged in? The problem here is that server implementation will have to deal with this. Currently you can use different syncUrl or httpHeaders for different users (but have to deleteAllLocations on logout/login). But this would not make sense anymore, if locations of any user will be sent.

===> I believe like you said that it should be the job of the server side to sort the locations received by using the "identifier_id" transmitted in the same time than the position. The plugin should not have to take care of this. The server side will use the "identifier_id" to attribute the location to the right user/object.

[mauron85]

--> I am thinking that it should be the task of the javscript to sort out the results when calling getLocations by using the "identifier_id"
--> of course if could be neat to have getLocationsByIdentifierID as well to be optimal

thank you for your suggestions. I'm also thinking about alternative approach to this problem. Will come with my proposal we can discuss later on.

[anymos]

Great thank you in advance :)

[anymos]

Thinking back about this feature, it also mean that the plugin will have to be restarted when detecting a new login/logout, to been able to change the configuration around the id

Which was making me thinking , is it possible to know if the plugin is already running in bg ?

that way no need to try to stop before running it again.

[mauron85]

Which was making me thinking , is it possible to know if the plugin is already running in bg ?

yes, there is no official android API as far as I know.
But IMHO one can implement some kind of mechanism to send message to service and wait for response with its status (started/stopped). kinda like ping command (ICMP echo message).

[anymos]

ok sounds complicated maybe I will not needed it.

It ultimately depends on what happens if I try to start the service 2 times, is it 200% sure that only one service can be up at a time ? ( for the same app )

If it is in that case stop and start would be just enough and it s already working well, I would just have to change the conf regarding the id.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed, because it has not had recent activity. If you believe this issue shouldn't be closed, please reopen or write down a comment requesting issue reopening with explanation why you think it's important. Thank you for your contributions.