While I like the minimalism of the beacon API, I wonder if it doesn't limit the usefulness of this technology, as it leads to an over-reliance on mobile Internet (apps need to fetch information after detecting a relevant beacon) and/or preinstalled apps (which will probably not talk to each other very well).
It'd be interesting if beacons could send some structured data along with their identification header. This way you could have general purpose apps which handled common types of beacon data, and an user wouldn't have to install MegaWorld, GroceryMart and BigHealth to get generic grocery or health-related notifications.
For example: if there was a standard beacon format for bus routes, I could install a BusRoute app which would let me see bus routes for any beacon-enabled bus in the world, even in places where I don't have an Internet connection.
It's still possible to have a general-purpose app for beacons, you just need to make that structured data available in a standard format on the Internet.
You could treat the UUID as a domain name, have a DNS-style system where an app looks up a UUID, gets some structured data, and caches it.
That does mean, for your bus example, that you would have to have seen one of those UUIDs before while internet connected, in order to have the route data already cached.
If someone is going through the effort of placing bus beacons, there's a good chance that the location either already has good data coverage, or they could place a wifi hotspot at the same time.
---
Alternatively, certain UUIDs could be taken to mean "connect to this device over wifi, and download structured information". This does have the battery issues mentioned in the article, but I expect that, for permanent installations, people will prefer externally powered beacons anyway.
It's a tradeoff. Packing more data into the beacon would mean more spectrum used per beacon - also, changing what the beacons are saying is much harder than flipping a switch on a cloud server.
Also it's not required that you go talk to the internet after hearing a beacon - if you already knew what beacons to look for and what to do about them, you wouldn't need to use the internet at all to create "local notifications."
It'd be interesting if beacons could send some structured data along with their identification header. This way you could have general purpose apps which handled common types of beacon data, and an user wouldn't have to install MegaWorld, GroceryMart and BigHealth to get generic grocery or health-related notifications.
For example: if there was a standard beacon format for bus routes, I could install a BusRoute app which would let me see bus routes for any beacon-enabled bus in the world, even in places where I don't have an Internet connection.