Significant location change for geofencing

Question

I need to deliver specific messages to the user based on its proximity to a specific location and on some other rules (like if there are any specific messages for that area). For example User gets in car and gets to work. The moment he arrives at work he then gets a message of some sort IF there's a message to be delivered. Here's what I was thinking (no code yet just trying to design the flow while I work at other parts of my app)

1. Listen to significant location change and each time that happens send the user's geolocation to the server to see if there's any message to be delivered near that location. No go. That would drain the battery too much due to overusing the radio.

2. Save the message regions daily, and at each significant location change do a test on the local stored data. If anything matches THEN contact server. Sounds better in theory.

Questions:

1. Can number 2 work?
2. What is the fidelity of the significant location change? I would like NOT to lose a message in a specific area by not getting notified of a location change.
3. Is significant location change REALLY based on cell tower change? (i read on a number of occasion that'it is not)
4. Would region monitoring be more suited to this task? Anybody using it? What is the battery drain on it and does it have better or on par fidelity to significant location change?
5. if app is terminated will significant location change really wake up my app? kinda depending on it.
6. any suggestion on how to approach this in a way I haven't talked about here?

A million thanks to anybody who takes the time to clear some of this stuff up.

EDIT : extra question 7. Region monitoring, having a large number of regions added has any impact on the system? Say having 2 regions vs 100 regions?

Answer 1

I have experimented with a similar process and came to my best use as follows using both significant location changes and region monitoring. After many iterations I currently am experiencing very little effect on battery life and fairly reliable processing.

I use significant location changes to trigger a method which filters the notices, sets up regions for only those within a limited radius from current position.

Based on my experience, significant location changes can be expected to occur about 3-4 miles apart. This can vary greatly but I can't recall seeing much more than that. This makes for very infrequent processing around town, fairly predictable when a user gets on the highway. I tried many variations of region size, refresh radius and location services sensitivity settings.

Keep in mind that the number of regions you may register is limited. Nowhere did I find what that limit is exactly but some users state that any single app should not expect to register more that 10 regions. Myself I haven't found any reference to substantiate that figure and I do sometimes register more than 10.

I have played with increasing the radius and minimum distances for refresh when it is seen the device is traveling at highway speed for substantial durations. That is a circumstance where I feel I may be wasting battery with unnecessary processing cycles. In actual use, it has not seemed to be an issue but I keep trying to maximize efficiency in any case.

My experience as relates to your specific questions;

1- For your case, it depends on how near to a location you are intending to consider for the trigger to notify. If you are notifying when a user gets within a few miles or when the user arrives in town, this may actually be workable. If you want to trigger when a user gets within a few meters of a location, this is not for you. Listening for significant location changes, in my experience, is not generally a big hit on battery life. Of course how much processing and network activity you are doing on receipt of the event is another factor. I check how far the device has moved, how much time since last location was accepted. In my case it is not necessary to refresh everything every time and I limit my reaction accordingly.

2- My experience as to significant location changes is as stated above but all documentation makes clear that it is not matter of a set distance so much as the conditions and availability of the various signals used. I'd imagine in an urban environment it is more predictable and less in wide open spaces. Most all of my experience has been in the former.

3- From extensive google searches, pouring through the docs and a lot of informed speculation I have concluded that significant location change is determined by a magical combination of all the signals available to the unit. There are wifi signals which broadcast their positions to various degrees of accuracy and cell towers generally know where they are. Location services is using all of this along with respective signal strengths to decide when the device has traveled a "significant distance". I think it is clear that the calculation will vary with conditions and is subject to change as they continue to improve the balance between accuracy and power use, hence the vague specs.

4- As indicated in question 1 there are factors to consider that may determine that you could use significant location changes alone but I believe region monitoring is most suited for your purpose in any case. Likely a combination of both is in order. I am using it with great satisfaction for my own application.

5- Significant location changes will wake up your app. You do have to follow some guidelines in your methods intended to run in background and be aware of the limitations. Wrap your background methods in beginBackgroundTaskWithExpirationHandler and UIBackgroundTaskInvalid calls. Watch for thread blocking. Read the documentation and location processing guidelines in entirety.

6- My recommendation is as above. Other considerations are in your use of the location services in general. You'll need to make a custom handler of sorts. Even when you use the service, you do not want to react to each and every message received. You have to check for change, accuracy, recency and all that jazz responding only as often as necessary. I found this series of posts invaluable in getting the basics: Part 1 of 3 from the Long Weekend Website

7- As mentioned above, my understanding is that there is a system wide limit to the number of regions that can be registered. I assume that, since they don't tell you exactly what that number is, it may allow your app more or less depending on how many others have been set by other applications. In my experience I am regularly registering and removing between 10 and 15 regions within my set radius. I set them in order from nearest to furthest as I would assume the last in would be first deleted or denied. Other considerations -region identifiers are global so if yours is not unique, it will replace previous region with same name. -region size and margins are settings that you need to experiment with to hone in on the best for your particular needs.

Answer 2

1. Don't think so. Expect you get the data from server but then a region is added. The App will not check this region because nothing exist (in the old data). It can work if you collect all possible areas even if no messages exist for that area. This will obviously only work for predefined areas.
2. See the WWDC 2011 Videos for further information Session 500 starting at 17 min.
3. No it is using WiFi since iOS5 too (see the video).
4. absolutely if you know the regions already then use them. You can eg. provide the app with an array of regions (download this every 5min or so) and only download the data if the user hits this region. Remember that the region you currently in will not notified. Be sure to regularly update the data for the current region (if its an message relevant region)
5. Yep it will launch your app either it is in background or it is completely shut down.
6. you can also download all message even if they are not in this region. And only show them/pop up if the user hits the region. But this is only possible if the message data isn't that much. For example if you planning to use the same messages for all people (eg. "look at this beautiful building") then it would be too much to download all data from the whole world.
7. sorry don't know. I guess its the same like creating calendar events but I'm not sure.

Answer 3

For #3:

I have tested Android 4.3 Geofencing with WiFi OFF, and found it works fine!

There are new addition Hardware geofencing and Wi-Fi scan-only mode which helps.

Refer: http://developer.android.com/about/versions/jelly-bean.html#43-optimized-location