- From: Tobie Langel <tobie@w3.org>
- Date: Fri, 18 Oct 2013 17:57:01 +0200
- To: Dimitris Michalakos <dimitris@visionmobile.com>
- Cc: public-web-mobile@w3.org, Dan Appelquist <daniel.appelquist@telefonica.com>, MIGUEL SCHNEIDER <msf@tid.es>, Michael Vakulenko <michael@visionmobile.com>, Andreas Constantinou <andreas@visionmobile.com>, Carlos Domingo <carlosd@tid.es>
On Friday, October 18, 2013 at 3:46 PM, Dimitris Michalakos wrote: > Let's define WiFi and Power Management, in the context of our research. > > WiFi means "Get a list of available WiFi connections. Setup a new connection. Connect to specific WiFi network". Results show it's mostly used to: > view Wi-Fi connections > connect and disconnect from WiFi > change network connectivity > Power Management means "Prevent device from sleeping or screen from turning off". It is mostly used to prevent device from sleeping while running an app. > > The way I interpret these findings is that HTML5 apps need to be able to open a network connection at will (i.e. on launch). What's wrong with XHR/Web Sockets? > At the same time we have to come up with some sane way (not by using hacks) to prevent the screen from turning off while an app runs. Would you agree with this? Is this the WAKE_LOCK[1] permission? This seems to be as much about managing CPU shutdown as it is about keeping the screen on (which no longer requires specific permissions on recent release of the SDK). My impression is that this is more tied to specifics of the platform (the CPU shuts down by default and needs to be kept awake) than real use cases (though I agree there are some). This also touches on background tasks, application lifecycle, etc. which are all important issues to spec and implements, but which are completely secondary compared to things like offline (how can you even start thinking about application lifecycle without having a way to somehow store the app?) or inhibiting auto-rotation (which is basically a deal breaker for pretty much every game genre out there). Real use case for keeping the screen on when there's no user interaction are actually limited to a small class of apps (mostly video, turn by turn navigation). For battery performance reasons, it might worth looking at other options to keep the screen on for such use cases (e.g. on fullscreen video playback or when the GPS is being used actively). All in all, I don't buy the argument that providing these two APIs would increase the percentages of apps build on top of the Web platform. However, fixing rendering perf + adding orientation lock would really open up things for gaming on the mobile Web. > > Is the facebook research you mentioned public? Could you send me a link? Yes (see the coremob mailing list[2]), unfortunately the doc returns a 404 at present. I'll post it back to this mailing list as soon as I have a copy available (I've pinged Matt internally). Best, --tobie --- [1]: http://developer.android.com/reference/android/Manifest.permission.html#WAKE_LOCK [2]: http://lists.w3.org/Archives/Public/public-coremob/2012Jul/0058.html
Received on Friday, 18 October 2013 15:55:56 UTC