In releases previous to 1.0.9 the Lightning Bug alarm didn’t function when Lightning Bug was closed or not running; a source of much confusion and quite a few feature requests. So, for the 1.0.9 release, Lightning Bug’s alarm and snooze functions were re-coded with the goal that the alarm would continue to function outside of the main Lightning Bug application. That is, so that the alarm still goes off even when Lightning Bug isn’t running.*
Unfortunately, since our 1.0.9 release we have received complaints that Lightning Bug’s snooze feature no longer works correctly. Even more unfortunately, the problem appears intermittent making it impossible to reproduce reliably. So before the 1.0.10 release we reviewed our new alarm code and spotted a potential cause. “Potential” being the operative word … the cause only partially explained the incorrect snooze behavior. Snooze worked great during testing after the problem was patched though, so we finished the release and crossed our fingers.
If you use the snooze feature regularly, you probably know our 1.0.10 fix didn’t fully correct the problem. Usually snooze works fine, but occasionally hitting snooze appears to do nothing and the alarm doesn’t go off again.
The good news? We’ve reviewed and tested the code again and this time we’re 100% sure we’ve located the issue.** The fix has been made and will be available in our upcoming 1.0.12 release, scheduled for next week. We apologize for any inconvenience this may have caused and want you to know we greatly appreciate your patience!
To that end, what else will be in 1.0.12? Currently we plan to release the snooze fix along with a much requested Landscape mode feature giving user’s with horizontal phone docks an enhanced experience!
*A Side Note on 1.0.9
We’ve had a couple complaints about Lightning Bug “running in the background” and “loading at boot”. We can assure you that Lightning Bug is NOT a virus! We actually had to do this in order to ensure that the alarm worked properly. This behavior that you may see is actually just the interaction between the Android OS and Lightning Bug’s alarm functions. The main Lightning Bug scene player, however, is *not* running in those cases. When your phone starts up, Lightning Bug *is* loaded into memory (explaining why you might see it listed in apps like TasKiller or Advanced Task Killer) to check to see if the alarm is set. In the Android OS, when an application has stopped running it is kept in memory until Android decides to reclaim that space.
So to be clear, if it looks like Lightning Bug is running in the background of your phone unnecessarily chewing away at your battery or memory, it isn’t! If you think you see otherwise though, please email us!
**So what was wrong with snooze, should be easy right?
In order for Lightning Bug’s alarm feature to function reliably in most-to-all situations we’ve tapped into several operating system level events including: whenever the system time is set and whenever the system time zone is changed. Why? The reason is that any alarms set in the Android operating system could be invalidated when such events occur. This is true for Lightning Bug, this is also true for any other app using the Android alarm system. In Lightning Bug’s case, whenever one of these events is detected it resets its alarm.
Great, what does this have to do with snooze? When you hit the snooze button a new alarm is set (by default for 9 minutes from when you hit the button). Generally, you’d expect this to work great; we don’t expect any of those system level events to occur during snooze so the snooze alarm shouldn’t be effected. Our latest debugging sessions proved otherwise though. Occasionally the system TIME_SET event is picked up during snooze causing the snooze alarm to be cancelled!
We were a bit baffled by this initially: who or what was changing the system time without user interaction and why did it seem so irregular? Android, and presumably any connected operating system, must occasionally check that its system time is in sync with whatever networks it communicates on. And whenever this happens Android raises its TIME_SET event. Further testing verified that this was the cause of our snooze woes. Frustrating that we didn’t catch this before, but great news otherwise because the fix is trivial: if a system time event is caught while snoozing, we can just ignore it!