-
Notifications
You must be signed in to change notification settings - Fork 12
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
GPS Passive recording feature #275
Conversation
Merge Onaio mater into eotin master
merge master into Develop
get master from onaio
Merge onaio master to Develop
Add PassiveRecordObjectActivity Refactor Storage helpers First commit -> Need refactoring now + tests + testing mService bounded to avoid null reference exception
Register smaple string in values/string.xml Move StoreLocation from TrackingStorage
Refactor TrackingService
Merge Onaio Master to local master
Eo/merge passive record location
From master to update develop
Fix code regarding Codacy/PR Quality Review
Fix code regarding Codacy/PR Quality Review
Update .travis.yml file to modifiy the build tools version
Fix code regarding Codacy Bot
Add Comments in TrackingServiceTest
Very true. I also understand separation of concerns and did not mean that literally. We are putting a lot of effort to make sure all features are configurable and not default so the the client application can use whichever part it wants and in whichever way.
I don't refute that and sorry 🙏 if there was a misunderstanding. You guys are part of the small GeoWidget community and we(Ona and I) are very thankful for your contributions to the repository. The aim from the start of the project has been to create a library that can be used by the multiple host applications that are currently using it for various purposes, and in the near future. That is why you were able to convince us on using an actual View. The general aim is to provide the configurability aspect whenever required and makes sense.
From the discussions on the feature and how important this feature is:
need to be configurable. @bripatand I hope this makes sense? |
Add Comments in TrackingServiceTest
Update eotin master
update Develop branch
@ekigamba: Ok for making the following configurable: |
sample/src/main/java/io/ona/kujaku/sample/activities/PassiveRecordObjectActivity.java
Show resolved
Hide resolved
Fix TrackingService binding when resuming Add method initializeTrackingService
Make the TrackingService icon configurable
@bripatand Sorry, I forgot to reply to this
It does provide inaccurate points sometimes and it aggregates all. The use of the tracking feature means that is will be on for long hours as the user performs duties in the field. The team thought that it would be good to provide the option to use a different provider not necessarily completely change to GPS. GPS is still the most accurate but it might have some cons that might not fit the situation as opposed to FusedLocation API which includes all these providers to provide an OK location while not using too much energy. I also tested the feature while commuting(3 times) and it worked excellent once. One of the cases was a bug which caused the app to crash when I tried to check my route on arrival. For the other case, the only points that were recorded was when I started the journey and when I arrived. My assumption is that it lost GPS connection and therefore only got the points when I was stationery. On the other hand, I used Google Maps for directions twice still commuting in the similar manner and it was pretty accurate. I never lost connection, thus it would be nice to have other options. I believe FusedLocationAPI. **
Only the google maps situation is different and circumstances much more harsh @bripatand What are your thoughts? |
@ekigamba: as you have seen, the FusedLocationAPI is unpredictable as you cannot garanty to get a point every X meter using this API. You tested it 3 times and you got 3 different behaviour. And if you don't have any connectivity, the FusedLocationAPI is going to use the GPS anyway, just adding an unpredictability... Note we have 2 modes in the current API, one that keep the GPS on all the time which gives the best results in term of accuracy and another one which relies on the GPS to tell us when the phone has moved by X meters but it is much less accurate. If we want the ability to use the FusedLocationAPI, we would need to make significant changes to the code and provide clear instruction on when to use GPS and when to use Fuse. We honestly don't know when we would recommend to use the Fuse if your objective is to collect a "route" you can use. Note as well that Google apps (Map etc...) have root privililege and can do some actions that no other app can, typically bypassing the power saving feature enforced by Android when needed... |
Cool, I understand why you are against it. Would it be possible to just abstract the specific location provider used just as we have done before in the KujakuMapView, so that all one would have to do is implement their own provider and pass it over? There is a location client interface already https://github.com/onaio/kujaku/blob/master/library/src/main/java/io/ona/kujaku/interfaces/ILocationClient.java and all that would be required is to have this as the client in the service and have a GPS client or rather Would this be OK by you guys? |
Fix crash when the TrackingService is running and another sample activity opened
Update kujaku_permission_reason string
private final IBinder binder = new LocalBinder(); | ||
|
||
// Listener to register to some Tracking functions | ||
private TrackingServiceListener trackingServiceListener = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been testing for memory leaks and your code is pretty good. Listeners attached or implemented in activities or contexts are going to have a shorter life compared to the event emitter causing memory leaks.
This listener here causes a memory leak of the PassiveRecordObjectActivity
because there is no way for the activity to nullify the listener when it exits. The service however still holds a reference to the activity through the listener. Bound services fix this by having the unbind
Provide a good way to handle such memory leaks. I can see that registerTrackingServiceListener
can take in nulls.
Provide a way to unregister through both the service and mapview.
Also fix the memory leak in the sample activity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Ephraim, i have fixed this memory leak last week. Could you please tell me how do you test/fin memory leak ? do you use a tool or a library ? Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can generally test for leaks in code using https://github.com/square/leakcanary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The leak is fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok cool
List<Location> stopTrackingService(@NonNull Context context); | ||
|
||
/** | ||
* Unbind from the TrackingService instance to be able to stop the service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- At this point our service life is not controlled by the
binding
idea - Add the
TrackingService
link to the Table of Contents - I would like to know how much you have tested the code in the field using the Kujaku sample app probably moving for more than 1 km. I am having unexpected results
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What kind of unexpected results ? i have tested the kujaku sample multiple times during the itinerary between office and home and the passive activity shows me the exact route i have driven.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I walked out of the office to a Cafe and left the app as the foreground application and put it in my pocket. It recorded half my route. The route is recorded halfway there and from that point back.
Device is Android version 8.1.0
What android version did you test with?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok,There are some Android settings to modify :
- You need to whitelist the sample application from the battery optimization. This is mandatory.
- On some Huawei phones on Android 8.1, there is a new setting to modify : Settings->Battery->Launch->Managed Manually: Set the 3 Auto-launch, Secondary Launch, Run in Background
I tested the app with Android 8.1, 8.0, 7.0, 5.1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this worked and it recorded for 3 hours without a gap while using other applications.
Can you create that as an issue and we can also document it later for easy reference and troubleshooting? The issue will basically state that this has to be done manually and that documentation for how to do it is to be added using the issue. A different issue will address adding the ability to prompt the user to enable this from the following guidelines
https://developer.android.com/training/monitoring-device-state/doze-standby#support_for_other_use_cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok make sense
Add method to unregister the tracking listener
We should test it first to see if we can get the FuseAPI to provide a good enough sequence of points. Our experience of this API is that it can be unpredictable. We should also discuss with the geo spatial widget group. But for a future release potentially. |
That's OK, any notes on the issue can be added here for future reference #283 |
No description provided.