Update the Physical Web documentation

[laurijamsa]

As the Physical Web project has been quietly shut down and the Chrome support has been removed, all the documentation should be updated. Now, there is a risk companies start to develop their services on top of it as the current status and future support is not clearly explained.

For example, we at Ruuvi used to encode and embed environmental sensor data to Eddystone-URLs, which did work great, but now we've moved to our own sensor protocol. Currently, I feel that future of Eddystone-URLs cannot be trusted and right now, we don't actively encourage our clients to build their services on top of it.

[helenclarko]

I've submitted a pull request to update some of the iOS documentation. More work is required to correct things completely, but it is a start.

7b69b97 - Pull request can be found here.

[auge2u]

@laurijamsa Would be happy to have your involvement in the Physical Web Association (PHWA) to reboot and repair the path on the PW. We have a pretty clear path on what we need to do to leverage this technology correctly and expand adoption without depending on a single company for support and direction.

[laurijamsa]

@auge2u Happy to see PHWA taking off. All the best from Finland. Will follow your progress.

[andersborgabiro]

My understanding is that Eddystone-URL is intended to be supported by the Nearby Notifications support in Google Play Services for the foreseeable future. The issue is really iOS, that Google doesn't seem to do anything for in this area, which is a pity. The Physical Web app still exists (but is not maintained, so when will it break due to iOS upgrades?) and there are vendors that have made their own iOS apps supporting (at least) Eddystone-URL.

Overall. I'm interested in how this evolves.

My scope for now is building Eddystone reception logic in JavaScript, on top of Cordova and a generic BLE plugin. Main focus is of course to make it work well on iOS, but there might be proximity marketing, IoT and other scenarios also for Android that Nearby might not be able to handle.

Hence, what's most interesting to me is best practice in terms of scanning/battery-saving intervals (especially when the app is in the background), suitable distance of (logical) detection, rough but reliable distance measurements, as well as getting ideas for new use cases etc.