Great example of why client side software is more exacting (and frightening) than building for the web. I wish I had more of these tales as ammo for future "native vs mobile web" debates.
What exactly protects web developers from this problem? Badly written AJAX-based code could do this just as easily as client software. Web development isn't a magic cure-all and it certainly doesn't protect you from the problem described in this post.
Part of the issue, a bit tangent to your point, is that when dealing with thick client software, once a version is released you can typically expect it to be in the field for quite some time. Many customers are upgrade-averse and simply won't upgrade a piece of software that is working suitably for them. Software developers have a bad habbit of fixing one bug and introducing another. With a web-based application you essentially control the release platform and can change things behind the scenes.
How about this revolutionary idea: don't connect if you've got nothing to send. That way, the first power event sends the logs, and the next several hundred do nothing! Timeouts work great too. Don't send a log if you've just sent one in the last hour. Yeah, the android is acting weird here, but the problem is defiantly the application logic.
This is why it's often a good idea to outsource tasks that aren't your business's core competency. I've used Flurry for mobile stats tracking because they've devoted a lot of time figuring out solutions to problems like this. Time I don't have, and DDOSs I don't have to diagnose.
I guess just setting the phone to state to sending file while uploading the logs to the server was the solution. Is there a better way to solve this issue? The user did not put it as part of the article.
Meh, to me that's just band-aiding the problem. The core issue here is that they anticipate getting the log from each user approximately once every day or two (that's on average when people plug in their phones to charge). I would just keep track of the timestamp of the previous log upload, and simply ignore the Intent if it's within a certain threshold (say, less than 12 hours ago).
Do you think it makes sense with the mobile architecture to have an application store its current state? This is obviously a more general question regarding mobile application architecture. This would specifically to be handle broadcast listeners performing conflicting actions.
application state storage is part of the package with android isn't it? that's how apps always start up where you left off, even if the OS killed them to free up memory.
Buying every existing phone that is sold in reasonable volume across all major networks in all major countries and testing them individually on each release is probably not the testing plan I would go with.
The problem wasn't really lack of testing, unless you expect these devs to test their app on every extant Android device and all future devices as well. The problem is that they assumed they could rely on the behavior of the Android system on one device to apply to another, and that turned out not to be the case.
Even worse, the device in question ("Fascinate") was apparently just a Verizon-branded version of the Galaxy S, which probably gave them a false sense of security if they tested their app on the Galaxy S.
But, as you touch on, there do seem to be some things they could have done differently here. Checking the last time the logs were sent, not connecting unless there is data to send, etc.
