I continue to see notification's from a Google Nearby registered Beacon even when the Beacon is set to be INACTIVE in the Dashboard. Is this expected? I was hoping to not see the Nearby notifications any longer but I still see them constantly irrespective of the Beacon's state. Is this a known bug?
It's a caching issue on the local device only. Once the message for that beacon is found and cached it stays on that device and associated with that beacon id. Another device will not see that message.
That said, issue was found and already fixed and roll out in a later release.
Related
I am working on my home automation app. I am using estimotes iBeacons and what I want to do is give my Home Automation Control the ability to know my proximity in my home. Each iBeacon is given a virtual switch on my Home Controller and when I come in contact with a iBeacon my device either in foreground or background will update my control to turn on my switch for when I am near a beacon and turn it off when I have wondered away from my beacon. All of this works perfectly and I am loving it, however some of my conditions rely on me to be in a proximity for a period of time, and what I am noticing is after a couple of minutes or even after a half hour of being near a beacon, the iPhone 5s basically drops its connection and then fires it back up, causing it to perform an exit (turn off my virtual switch) and then immediately perform an enter (turn back on the virtual switch). As you can imagine this is very annoying to the wife and myself in the middle of the night when the bedroom lights start to flicker on and off because of the exit/enter. I have read about people having this problem and tried everything I have seen on the internet to no avail.
What I noticed is that whenever a monitor crossing has been crossed for a iBeacon, both the didDetermineState and the corresponding Enter/Exit call back functions are called. What can I do to get this to stop occurring? I can provide code examples if needed but this is more of a general question.
This is a common problem with iBeacons (and wives of geeks like us), and the simple solution is a software filter. You must ignore region exit events that last only a few seconds until you verify that there is no subsequent entry event.
You can do this by creating a variable (e.g justExitedRegion) that tracks these events. When you get an exit region notification, set justExitedRegion=YES and start a five second timer. When the timer goes off, if justExitedRegion==YES, perform your exit logic normally and set justExitedRegion=NO. Otherwise skip processing the exit logic.
Meanwhile, if you get an entry notification and justExitedRegion==YES, set justExitedRegion to NO and skip your entry processing.
If you just want to know whether you're at home or not at home, you could fire up the GPS on the phone and check your location.
Assuming you have a wifi network at home that your iPhone sees regularly, geolocation will work very well even inside the house where there will be no GPS signal. It will know no the latitude/longitude of the wifi base station and give that as your current location.
So use iBeacon as your primary location detection, but verify the data it gives you using GPS.
Also, you should contact Estimote to be sure you don't have a faulty unit or something. It is pretty new hardware, there could be issues.
My application uses location service in background. To reduce the battery drainage, i found that it is better to register for significant-location change notification. It says to get this notification device need cell radio. Now my doubt is that whether i can get significant location change notification in iPod....I searched a lot but couldn't get an exact answer..any help is greatly appreciated...
As significant Location Change Monitoring needs radio signals and iPod is not capable of having that signal so it wont work on iPod (as per my knowledge).
But you can check from this method to know whether your device is capable of this service or not
+ (BOOL)significantLocationChangeMonitoringAvailable
In Apple's developer portal , it states that startMonitoringForRegion:desiredAccuracy: will eventually wake up my app (even if it's killed) and send the Core location delegate a message.
The question is : Is it possible to start GPS tracking (precise tracking, instead of cell-tower based tracking) after receiving this message (even if my app is in the background ) ?!
Well , I searched for it , and it appears as it does wake up the app.
I can also use startUpdatingLocation to get more frequent (and even GPS) updates.
I'm having trouble keeping wifi from disconnecting after 30 mins in an iphone app that needs to function when locked by the user.
The app normally does not sleep, but if the user so chooses they may lock the display. I'm adding a new feature to the app that sends data out over the network at 1 second intervals. prior to this there has been no network requirement for the app, and it has functioned as desired (music, timer-based processes) while user-locked.
The answer seemed to be here:
Wifi connection doesn't stay alive when asleep, with iOS4
But adding UIRequiresPersistentWifi boolean to info.plist doesn't keep it from timing out the wifi (i'm testing on Touch, iOS4.02) after 30 mins, even while the app is busy sending data out over the connetion. Maybe this only applies if the display sleeps itself, rather than user locks?
Related, I think there is no way to "stir" the display at any interval? User pressing the home button is sufficient to bring back the wifi; unlocking is not necessary.
Also, I've read on the interwebs that it was stated in a WWDC that UIRequiresPersistentWifi applies to keeping alive 3G as well. Can anyone verify?
thanks
Your app may be getting suspended by the OS after a long enough period of user inactivity.
Under iOS 4.x there are certain types of apps that aren't suspended when the display is locked (music player, VOIP, etc.) Apps that register as a VOIP type app might be allowed to keep a persistant network connection over a longer period. However Apple may require that an app actually provide some VOIP functionality in order to register for that type in any app submitted for review.
Is there some activity that you need to perform network activity? From iOS5 onwards, we have noted that even if we send network packets (heartbeat timers), then also iOS 5 blocks it after locking device.
It is to be noted that services which requires VoIP continue to receive calls, and notifications do come when your phone is on sleep mode or locked. This means that WiFi is not totally closed. I dont know how this happens.
As an alternative you can use data carrier of your network provider as an alternative to WiFi in case WiFi has gone down. With UIRequiresPersistentWiFi, you just inform iOS5 that you would require WiFi to run your application, nothing else signifies whether it keeps your screen ON or OFF. For keeping your phone from autolock you can however use disableTimer = YES flag, in lieu of your battery charge.
I have a requirement in my iPhone app that I know when somebody running the same app is close by.
I'm thinking that GameKit using Bluetooth would let me do that. GPS location is not precise enough in this particular case.
However, if the user closes the app then the function won't work anymore. Even under iOS4, the task switching will close down the BonJour services so I can't have the app run in the background.
Seems to me I can only have this function if the user leaves the app up and running. Would you agree? Or is there a different approach I can take?
People are very concerned with privacy, so they would naturally expect such privacy invading functionality to be switched off when they close down the application.
If they choose to have this feature enabled, then it's a different matter. Then they expect that somebody else may locate them.
You might however consider implementing some sort of opt-in offline service, where the latest gps position is stored on a server including a timestamp. When somebody else (with the app running) moves within a certain distance of this location while it's still "fresh", then you send off a notification to the first device. That way the user would be notified that somebody may be close, and can then switch on their own device.