Could someone explain to me a use case for the battery API? I can't think of a single situation where it would be beneficial. The article states that you can detect if a user's battery is low to avoid battery-intensive processes, but do you think developers are going to spend their time inflating their scripts to deliver a poorer web experience to their users just because they have a low battery?
Android's APIs enable easy implementation of a sqlite-based data model, where changes are always persisted.
That doesn't solve the problem for things like CAD that need an in-memory object-oriented data model, but the Android support for observer patterns can be wrapped around any data model, and the ability to quickly, which means, in practice, incrementally, persist changes is driven by both Android-specific issues like needing to respond to lifecycle events quickly, and by general mobile considerations like a battery that could fail unexpectedly.
In other words, you need to solve the "don't explicitly save" problem for reasons ranging from "it's more robust" to "it fits Android UI conventions" anyway.
I think its a step in the correct version if HTML5 is every able to compete with native apps on mobile. HTML5 needs better access to hardware elements. We can see two out of these five here - the camera and battery level.
The one way in which web apps still cannot compete effectively on mobile and which gets no attention is access to a user's contacts/address book.
Right now on the web Facebook and convoluted non-standard APIs to your email provider are pretty the only way to get access to contacts. This is the number one barrier to allowing web apps to spread easily when a user wants to share the app or something in the app with a friend.
HTML 5 games can show battery status, or warn when the battery is running low. HTML 5 apps can suggest that the user save their work as they are running low on power, to name a few.
