- From: MeritBased via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 Nov 2017 00:50:36 +0000
- To: public-device-apis-log@w3.org
@dontcallmedom I doubt many would disagree [ I only know of one :-( ] that a Wake Lock is unsuitable for background Geolocation. Please note the Background Location "Fleet Management" business case. The UWA may not have to be aware (once permission is granted or periodic toast) that it is happening, Geofencing is also inherently a Server Based function. If the user has traversed a boundary then a notification can be sent if need be. @chaals can I please ask you to consider looking outside the W3C/IETF opinion pool for solution and design ideas on this? Stackoverflow for example: - [Background Geolocation ServiceWorker - onMessage Event order when Web App regains focus](https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain) has over 430 views and 12 votes and the answer a further 2 votes. [Expected ratio of ServiceWorker instances to Geolocation Updates](https://stackoverflow.com/questions/45206149/expected-ratio-of-serviceworker-instances-to-geolocation-updates) has 126 views plus 5 and 1 votes respectively. The source-code for the TravelManager POC and polyfill, along with an aaa_readme.txt, can be found [here](https://drive.google.com/drive/folders/0B7Rmd3Rn8_hDNW1zSWRoXzBTclU) If you wish to see the example without copying then, after reading the readme file, run the Ultimate Web App from [Brotkrumen](https://hypocampus.applications.uwa.edu.au/travelmanager.html) The CPU Wake Lock may well be all that is needed for other/true sensors but Background Geolocation needs the Service Worker Travel Manager! -- GitHub Notification of comment by MeritBased Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/98#issuecomment-343783143 using your GitHub account
Received on Monday, 13 November 2017 00:50:38 UTC