Mobile Optimized Links Avoiding Resets

Avoiding Resets By Optimizing the Time

I've been a Treo user for about two years now. I've had both a Treo 600 and a Treo 650. Over the last two years, I've had my share of freezes and resets (thankfully, I've never had a forced, non-voluntary hard reset). And over those two years, I've tended to notice a pattern.

For the most part, my "freezes" (that require that I manually do a soft reset) occur when travelling outside my primary areas of work and residence or driving long distances. And more often than not, they occur when I have a persistent data connection. I tested this theory this last weekend as I drove from Southern California (San Diego area) up the 5 Freeway to San Francisco.
       On the trip up, I left my data connection connected and SnapperMail set to retrieve email every 20 minutes. With Snapper, if you lose your data connection, it will automatically reconnect it when it needs to retrieve email. My phone froze up 9 times during this 10 hour drive.
       On the way home, I set SnapperMail to manual retrieve and left my data connection active. I checked it every now and then and after awhile saw the data connection was no longer active. Every hour or so, I told SnapperMail to do a send/receive and each time it reconnected the data connection and was successful. My Treo didn't freeze up even once. And, yes, I had phone calls during both lags of the trip... nine on the way up, seven on the way home. The best conclusion I can draw is that there's something about persistent data connections (and apps that use them) and roaming that leads to my Treo freezing up. And, unfortunately, I don't have much of a solution for this problem other than to disable auto mail-retrieval and check my mail manually while travelling through different areas.

Resets are a different story. Early last week, I had 8 calendar items that were all set for 10am. I also had SnapperMail set to retrieve email every 20 minutes starting at 7am. I found that right at 10am, my phone did an unexpected reset.

***(FYI: as a disclaimer, I must say that while I don't like any instability in my devices, I much prefer a reset over a freeze. At least with a reset, everything starts back up. With a freeze, the device remains hung and until you notice it, you miss phone calls, emails, calendar reminders, etc.)***

I must also digress a bit and give a little background on the usage of my Treo. I run many different apps on my Treo... some in local memory, some from an SD Card via PowerRun. But the three most heavily used apps I have are GoodLink, SnapperMail, and TreoAlarm. I use GoodLink for instananeous wireless syncing to my Exchange server of email, calendar, tasks, contacts, etc. (In case you're wondering, in my travelling tests mentioned above, GoodLink was turned off the entire time). Normally however, GoodLink is always running on my phone and as such I always have a data connection. I also have SnapperMail running and sync'ing email from three POP accounts every 20 minutes. And, lastly, I use TreoAlarm daily.

Over the course of normal use, I came upon the discovery that one morning I had multiple 10am reminders popping up via GoodLink as well as SnapperMail trying to retrieve my email and my phone unexpectedly reset. After seeing similar results for a few days, this prompted some thought and investigation into whether having multiple *things* from different apps trying to work at the same time might be a factor in my resets. Now, my calendar cannot change. Ninety percent of my meetings are on the hour (ex: 10:00am) or 30 minutes after the hour (ex: 10:30am). And I occasionally have one that starts at 15min or 45min after the hour (ex: 10:15am). However, I could not recall the last time I had a meeting at 10:03am or 10:10am or 10:23am, etc.

Thus, I determined that it was SnapperMail and TreoAlarm that I needed to adjust. While GoodLink runs 24x7 (yes, even while I sleep), SnapperMail only checks email from 7:00am to 11:00pm. And, I have TreoAlarm set to wake me up at 7:00am Mon-Fri (10am on Sat & Sun). TreoAlarm is also configured to check the current weather forecast right before sounding the alarm. Thus, on Mon-Fri, I had TreoAlarm checking the weather, sounding an alarm, and Snapper Mail checking email all at 7am. Worse, the "snooze or cancel" screen for TreoAlarm takes the foreground which Snapper also wants as the current release of Snapper cannot work in the background. The first thing I did was change TreoAlarm to wake me up at 7:05am Mon-Fri (and 10:05am Sat & Sun)... after all, what's an extra 5 minutes of sleep?

The next thing I did was to adjust SnapperMail, but here I must again digress for a minute. SnapperMail allows you to check for email every 5, 10, 20, 30, or 45 minutes or every 1.5, 2, or 4 hours. I had mine set to check every 20 min. The catch is that SnapperMail starts at one of two intervals. If you have a sleep period set (such as I do), for example from 11pm to 7am, it starts its "interval check" at the begining of the "wake-up period" (7am in my case). Thus, it will check your email at 7:00am, 7:20am, 7:40am, 8:00am, 8:20am, etc. If a check fails, it doesn't matter, it still uses the next interval. If you manually check your mail at say 7:05am, it will still check again at 7:20am, not at 7:25am.

(Note: in this regard Snapper is much different from ChatterMail... Chatter has more customizable interval check times [called 'qsync'] and adds the interval from the last checked time. Thus, Chatter will be much like Snapper if you have a sleep time and it starts checking at 7am. However, if you manually check it at 7:13am and its set to qsync every 20min, the next check time will be 7:33am, not 7:20am. Thus Chatter checks on the increment following the last qsync while Snapper checks every increment regardless of previous checks and based on the wake-up period). With Snapper, if you don't have a sleep time, it starts its increment clock at 12:00am. Thus, my next change was to tell Snapper to sleep from 11:03pm to 7:13am (instead of the prior sleep time of 11:00pm to 7:00am). And thus, Snapper now checks email for the first time at 7:13am, then again at 7:33am, 7:53am, etc.

So now I have GoodLink still running and reminding me of my 10:00am, 10:30am, & 10:45am meetings, TreoAlarm wakes me up at 7:05am (Mon-Fri) or 10:05am (Sat-Sun), and Snapper is checking email at 7:13am, 7:33am, 7:53am, etc.

(FYI: it takes TreoAlarm about 15 seconds to check for the updated weather and it takes SnapperMail about 30 to 90 seconds to check for new mail from all three of my POP accounts).

The end result is that my apps are no longer all trying to do things at the same time and thus competing for resources, foreground screen, data connections, etc. And after 4 days of running my Treo this way, I went from an average of 2 to 5 resets a day to only 1 reset in the last 4 days.

In summary, I still have no solid fix for the occasional "freeze up" that occurs while travelling. I can only assume that as networks and roaming agreements get better and as my own provider (AT&T Business/Cingular) rolls out more towers and data connections that the number of freezes will decrease. However, I do seem to have a solid solution for the occasional resets. Simply auditing those apps that do things on a regular schedule and then adjusting them to not interfere with each other seems to do the trick. In my particular case, my audit revealed the calendar/alarm function of GoodLink, the weather retrieval and foreground need of TreoAlarm, and the mail retrieval of SnapperMail. I chose to "reserve" the :00, :15, :30, & :45 times for calendar events from GoodLink, then adjusted SnapperMail and TreoAlarm to run within these 15 minute increments, but with a 1 to 3 minute gap between the two.

NOTE 1: So you have a similar setup, but Snapper checks email all the time and never has a "sleep period". How do you adjust it to not start at 12:00am and thus potentionally conflict with other apps as described above? Easy. Simply set a very short sleep period. For example, tell Snapper to sleep from 12:00am to 12:03am. Now, if, like me, you have it checking email every 20 minutes, it will check at 12:03am, 12:23am, 12:43am, etc.

NOTE 2: Why I don't use ChatterEmail. I've been asked this a lot. I have used Chatter. In fact, about every other month or so I try a new version to see if I can switch over to it. I like Chatter and I think it has a wealth of options. Unfortunately, at least for my experience, Chatter is too unstable. I fear that its wealth of options is its own undoing. For me (and I've tested with both POP, IMAP, and both) it was very unstable. Even recent versions caused resets and freezes or excessive time-outs. All of these worked to make me realize that email delivery was unreliable and I needed it to be reliable. With SnapperMail, I have fewer options and a more simple interface, but greater stability and increased reliability in email delivery. In the end, it was a trade-off between features or stability and I chose stability. Some people can live with freezes and resets to gain features. I cannot. Last, is the issue of battery life. If I take no phone calls in a day and have only GoodLink and SnapperMail delivering my email, I still have 65% to 70% of my battery remaining when I go to bed at night. With ChatterEmail instead of Snapper, I had about 40% of my battery remaining. That extra 25% to 30% makes a huge difference when it comes to phone calls.

NOTE 3: You might've noticed that in my end scheme, I have SnapperMail checking email after the sleep period before TreoAlarm. There's a reason for this. If Snapper checks email at 7:13am, its next email check interval is at 7:33am. When TreoAlarm checks the weather, then alarms me at 7:05am, I can hit the snooze button for 5 minutes. In fact, I can snooze up to 3 times before Snapper wakes up again. This is important since both the alarm function of TreoAlarm and the mail retrieval function of Snapper want the foreground screen. In my experience, competing for the foreground screen is one cause of unexplained resets.

Update: About 1 week ago, I switched over from SnapperMail to ChatterEmail. I'm halfway through a 30 day trial version of CE and am running the latest, stable version (1.0.6.4[89:41]). It has proven quite stable. I have it checking 3 POP accounts; 2 every 15 minutes and 1 every 30 minutes. Each account also sleeps from 11:00pm to 7:XX am. Initially, I'd find that my Treo was frozen each morning. But then I realized that it had quite a bit of mail to download. Thus, I changed the sleep times to:
*TreoAlarm - 7:00am
*Account 1 - 11:00pm to 7:15am
*Account 2 - 11:00pm to 7:30am
*Account 3 - 11:00pm to 7:45am

The end result is that all three accounts aren't being initially checked at the same time and conflicting with each other. Once this change was made, my Treo hasn't frozen up once except while travelling and roaming.

The other added benefit is that since ChatterEmail checks for email in the background (with the screen off), if it does freeze up, it doesn't do so with the display on and thus doesn't drain my battery. With SnapperMail, if it froze, it did so with the display on and if not caught immediately my battery would drain very quickly.

Follow-up...

I came across an interesting observation quite by accident. If you read through the article above, you'll see that I note resets caused by applications as well as resets caused by roaming. Interestingly, one of my users bought a Treo, but used it as only a phone for almost a month. He had third party applications installed, but absolutely none that used data. His Versamail wasn't configured, he didn't have GoodLink installed, he never opened up Blazer. All he did was use the device as a phone. From the day he took it home, he claims it never reset once (I asked if he ever went to use it and found the phone [GSM] disconnected, perhaps indicating an unknown reset) and he said no. Most interestingly, during that month, he travelled by car through most of California. While not completely conclusive, this does seem to validate my earlier observations that its the roaming with data (and likely non-seemless handoffs) that are to blame for many reset issues.