5 ms·

As a web application developer, one idea that comes to mind is that, if I were writing an app that supports offline usage, I'd probably want to be aware of a lo

As a web application developer, one idea that comes to mind is that, if I were writing an app that supports offline usage, I'd probably want to be aware of a low battery situation so that I can save my state and warn the user that the app needs to shut down to avoid data loss. I might also switch from online mode to offline mode, again letting the user know (and letting them override the choice, maybe.) I can't see any reason to make use of the battery status server-side. But, there's also no way to prevent the information from being sent, once you make it available to javascript code on the device. If the standard api didn't send it, then you'd just see ad-hoc apis gathering the data locally and sending it.

DashRattlesnake 10y ago
However, I don't think the battery state needs to be as granular as it is to support those use-cases. A simple boolean hasLowBattery or a much coarser 0%-25%-50%-75%-100% enumeration seems like it would have been sufficient.
- zaroth 10y ago
  If anything, I would propose the mode should be a user-controlled bit called simply: "LOW" Maybe I request low mode because... I hope you serve me less crappy ads I haven't bought a new phone in 3 years I am running other apps which need more CPU I find too much interactivity distracting or confusing I just want to read black text on a white background I hate your website, but need to visit it for some reason anyway ... I have full battery, but I need to conserve it I have low battery EDIT: Fuck, I just realized, this already exists, and it's called NOSCRIPT. Wait, we could call this LOWSCRIPT!
  - deleted 10y ago
    [deleted]
  - vmateixeira 10y ago
    So much truth in here... this proposal would be very welcome!
- bentruyman 10y ago
  Good luck defining "low". Also, coarse percentages of charge provide no indication of the amount of time left of a battery based on current activity. Which is something you would need in the above offline/save example.
- DougWebb 10y ago
  Maybe a boolean would work. I don't think 0%-25% would work for the scenario I described; 0% is too late to do anything about the low battery situation, and 25% is too soon to worry about it.
  - joshkpeterson 10y ago
    Said this in another comment, but - maybe an integer between 1 and 100 would be fine. Some granularity, but not enough to identify.
vmateixeira 10y ago
...warn the user that the app needs to shut down to avoid data loss.. Doesn't the client (laptop, phone, etc) does this already?
- DougWebb 10y ago
  I've seen my devices give notifications about the battery level to me, but I don't think they notify the apps I'm running, and if I ignore the notifications until the battery dies the device just shuts down. The apps have no chance to save their state. Often, that's probably just fine. But if I'm developing an app and I have a requirement to save state before my app gets shut down due to power failure, this api will allow me to do that. It's the equivalent to a drive flushing any writes before shutting down; normally they'd get flushed sooner or later, but if you have to shut down NOW, you'd better flush now too while you can.
  - vmateixeira 10y ago
    I mean, but if the device notifies you that it's running low on battery... maybe you should close the app? Shouldn't this be enough? You would avoid loosing data, and regarding user experience, also avoid a slower performance of your app (and perhaps complaining about it?), and also seeing your device shutting down itself with your app screen running in background (which is pretty lame).
    - DougWebb 10y ago
      As a user, maybe that should be enough. Maybe not. It depends on the app and how critical the data/state is, I guess. As a developer, trying to implement requirements set by a product designer/owner who thinks saving the data is critical even if the user doesn't cooperate, the api is useful to have.
      - vmateixeira 10y ago
        Maybe a critical app shouldn't be web based? If you're really worried about your battery running low and working with critical data, removing the browser overhead which is draining you battery should be one of the first things to do.
aeorgnoieang 10y ago
> But, there's also no way to prevent the information from being sent, once you make it available to javascript code on the device. Surely it's possible for JavaScript engines to either (a) optionally prevent code from accessing this; or (b) return random nonsense, or even just a single fixed static value (for every instance of the engine anywhere).
- DougWebb 10y ago
  Nope; either the information is not available to Javascript code at all, or the Javascript code can do whatever it wants with the info. A security permission, or config setting, can/should be used to prevent access to the api that returns the battery level. But once access is enabled, there's no way to prevent the code from getting the level (which is just a number) and sending it to a server (which is just calling an ajax request with a numeric argument.)
Mister_Snuggles 10y ago
I would think that if you architect your app to handle disappearing network connections gracefully, it will probably handle the user shutting down the phone gracefully too. If the battery is critically low, the user will get popups from the operating system at various points and can make a decision whether or not to keep using your application. You could also expose an offline-only option somewhere in your application. A user might want to do this if they are in an area with marginal coverage (e.g., there is a connection, but it's basically useless) or roaming, etc.
- DougWebb 10y ago
  A disappearing network connection is a different case, because the app continues running. Imminent power failure is different because the app is about to be terminated, probably not gracefully. This is also different from the user shutting down the app manually, because that's probably a graceful shutdown which will give you a chance to save some state before termination.
mikeash 10y ago
The user can close your page at any moment, so you need to design your web app to save data continuously and automatically anyway.

DashRattlesnake 10y ago

However, I don't think the battery state needs to be as granular as it is to support those use-cases. A simple boolean hasLowBattery or a much coarser 0%-25%-50%-75%-100% enumeration seems like it would have been sufficient.

zaroth 10y ago
If anything, I would propose the mode should be a user-controlled bit called simply: "LOW" Maybe I request low mode because... I hope you serve me less crappy ads I haven't bought a new phone in 3 years I am running other apps which need more CPU I find too much interactivity distracting or confusing I just want to read black text on a white background I hate your website, but need to visit it for some reason anyway ... I have full battery, but I need to conserve it I have low battery EDIT: Fuck, I just realized, this already exists, and it's called NOSCRIPT. Wait, we could call this LOWSCRIPT!
- deleted 10y ago
  [deleted]
- vmateixeira 10y ago
  So much truth in here... this proposal would be very welcome!
bentruyman 10y ago
Good luck defining "low". Also, coarse percentages of charge provide no indication of the amount of time left of a battery based on current activity. Which is something you would need in the above offline/save example.
DougWebb 10y ago
Maybe a boolean would work. I don't think 0%-25% would work for the scenario I described; 0% is too late to do anything about the low battery situation, and 25% is too soon to worry about it.
- joshkpeterson 10y ago
  Said this in another comment, but - maybe an integer between 1 and 100 would be fine. Some granularity, but not enough to identify.

vmateixeira 10y ago

...warn the user that the app needs to shut down to avoid data loss.. Doesn't the client (laptop, phone, etc) does this already?

DougWebb 10y ago
I've seen my devices give notifications about the battery level to me, but I don't think they notify the apps I'm running, and if I ignore the notifications until the battery dies the device just shuts down. The apps have no chance to save their state. Often, that's probably just fine. But if I'm developing an app and I have a requirement to save state before my app gets shut down due to power failure, this api will allow me to do that. It's the equivalent to a drive flushing any writes before shutting down; normally they'd get flushed sooner or later, but if you have to shut down NOW, you'd better flush now too while you can.
- vmateixeira 10y ago
  I mean, but if the device notifies you that it's running low on battery... maybe you should close the app? Shouldn't this be enough? You would avoid loosing data, and regarding user experience, also avoid a slower performance of your app (and perhaps complaining about it?), and also seeing your device shutting down itself with your app screen running in background (which is pretty lame).
  - DougWebb 10y ago
    As a user, maybe that should be enough. Maybe not. It depends on the app and how critical the data/state is, I guess. As a developer, trying to implement requirements set by a product designer/owner who thinks saving the data is critical even if the user doesn't cooperate, the api is useful to have.
    - vmateixeira 10y ago
      Maybe a critical app shouldn't be web based? If you're really worried about your battery running low and working with critical data, removing the browser overhead which is draining you battery should be one of the first things to do.

aeorgnoieang 10y ago

> But, there's also no way to prevent the information from being sent, once you make it available to javascript code on the device. Surely it's possible for JavaScript engines to either (a) optionally prevent code from accessing this; or (b) return random nonsense, or even just a single fixed static value (for every instance of the engine anywhere).

DougWebb 10y ago
Nope; either the information is not available to Javascript code at all, or the Javascript code can do whatever it wants with the info. A security permission, or config setting, can/should be used to prevent access to the api that returns the battery level. But once access is enabled, there's no way to prevent the code from getting the level (which is just a number) and sending it to a server (which is just calling an ajax request with a numeric argument.)

Mister_Snuggles 10y ago

I would think that if you architect your app to handle disappearing network connections gracefully, it will probably handle the user shutting down the phone gracefully too. If the battery is critically low, the user will get popups from the operating system at various points and can make a decision whether or not to keep using your application. You could also expose an offline-only option somewhere in your application. A user might want to do this if they are in an area with marginal coverage (e.g., there is a connection, but it's basically useless) or roaming, etc.

DougWebb 10y ago
A disappearing network connection is a different case, because the app continues running. Imminent power failure is different because the app is about to be terminated, probably not gracefully. This is also different from the user shutting down the app manually, because that's probably a graceful shutdown which will give you a chance to save some state before termination.

mikeash 10y ago

The user can close your page at any moment, so you need to design your web app to save data continuously and automatically anyway.