[WIP] Rebase of continued Geofence implementation (see #86, #88)

[friesenkiwi]

Overview

Rebase of #88, continuing to implement Geofencing support, also the API level bump is reverted

Proposed Changes

• bump gradle versions
  

• add dcendents dependency
  

• implement adding Geofences by List in builder
  

• implement adding Geofences by List
  

• implement Geofence removal
  

• add GeofencingEvent scaffold
  

[ecgreb]

@friesenkiwi The rebase looks good :)

Test coverage just needs to be added for the new methods implemented in the geofence API and then we should be good to merge. @sarahlensing posted a few suggestions on #88 for how to approach this.

Also I noticed Circle CI is not building your branch even though the pull request is now pointing at master... we'll look into this issue on our end.

[friesenkiwi]

OK, thanks for the review. So it's (on my end):

• Implement test coverage (see [WIP] Continue implementing Geofences (see #86) #88 )
• Connect the GeofencingApi to LOST's location mocking infrastructure so proximity alerts can be tested using setMockLocation() and setMockTrace() in the FusedLocationProviderApi.
• Test whether the ProximityAlert is working at all on my device (I think it still is not and I have no idea why :-(, maybe it's because there is only a GPS provider (no cell, no WLAN), maybe it's because of missing Google, maybe it's because of another problem in the EXPIRATION parameter, see https://code.google.com/p/android/issues/detail?id=107, https://stackoverflow.com/questions/23034298/android-addproximityalert-locationmanager-method-doesnt-send-boradcast#23036720, )
• Execute Checkstyle rules
• Review throws SecurityException vs @RequiresPermission
• Implement Geofence.Builder().setTransitionTypes(), .setNotificationResponsiveness(), .setInitialTrigger();
• flesh out GeofencingEvent

I'll have to see, when I have time to work on it, probably on the weekend.

[ecgreb]

If you can add some basic unit tests for creating multiple geofences and removing a geofence I would be happy to merge what we have here so far :)

Device testing and other APIs (transition types, initial trigger, etc.) can come later in follow-up pull requests.

[friesenkiwi]

I added the testcases @sarahlensing suggested over at #88, added one more (looks a little bit complicated, but there's no way, to make it simpler, or is there?) and included some checkstyle fixes.
How to handle those conflicts?

[friesenkiwi]

OK, never mind, I am starting to get the hang of rebasing and force-pushing :D

[ecgreb]

Thanks @friesenkiwi!

I'm going to merge this now and create new issues for any outstanding TODO items related to geofences.

[friesenkiwi]

Thank you! :)

[ecgreb]

@sarahlensing @friesenkiwi I created issues for the following outstanding features related to geofences:

• Geofencing intent should have a GeofencingEvent extra Geofencing intent should have a GeofencingEvent extra #100
• Implement transition type Implement transition type #101
• Implement notification responsiveness Implement notification responsiveness #102
• Implement GEOFENCE_TRANSITION_DWELL and loitering delay Implement GEOFENCE_TRANSITION_DWELL and loitering delay #103
• Set geofence initial trigger Set geofence initial trigger #104

Out of this list I would say we definitely want to flesh out (and return) a GeofencingEvent when an alert is triggered. Currently only the boolean extra created by the LocationManager is returned.

Also we should definitely have support for GEOFENCE_TRANSITION_ENTER and GEOFENCE_TRANSITION_EXIT transitions since we get these "for free" from the LocationManager.

Things that I would consider nice-to-haves but optional at this time are support for GEOFENCE_TRANSITION_DWELL and loitering delay. Also setting the initial trigger.

Finally, I'm not even sure we can implement anything useful for notification responsiveness as long as we are relying on the LocationManager proximity alert implementation as this would require access to the underlying location listeners.