Well I'm just learning this as I go along but I think all three pieces, the app, the iBeacon and the server, each should to be flexible enough to be reprogrammed as needed.
For example there should only be one CVS app but there are many different CVS stores of varying sizes, layouts and locations. In the northeast the store manager may want to put flu remedies on the end cap near the cash registers where as a CVS in SoCal might want to feature sunscreen on that front display. This is a perfect argument for why the app itself should contain no data and it all should come from the server. I also can imagine a case for reprogramming the iBeacon transmitters as well depending on the individual store requirements.
What would you reprogram it to do? It only sends out a beacon and that beacon is matched against a database. The iBeacon device is not a server! It's not a kiosk!
I don't understand why you aren't able to grasp how incredibly simple iBeacons are. It makes no sense to give it a database, GPS, accelerometer, processing, it's own web server, etc. so that it can intelligently update itself if it happens to be moved. That defeats the entire purpose of the iBeacon. How the hell does such an expensive device get implemented by the thousands of million when they become so costly to deploy?
These are unmanned devices with a unique ID! That's it! If a CVS store decided to move merchandise around outside what corporate wants and/or corporate wants them to move merchandise around and forgets about the iBeacon associated with it that's their issue but you can't feasible make the iBeacon understand what products reside where.
Finally (and I really hope this is finally), the app needs to be aware of the iBeacon for it to work. You can't have every app that is iBeacon aware querying a server to see if that iBeacon is part of their iBeacon list. The server play comes into effect once you launch an app. This does mean that if a new store get build the app needs to be updated in some way, either through regular app update channels or being launched and getting a new list of iBeacon IDs to add to the phone's iBDB for that app (which may or may not be possible with Apple's policies).
Things change all the time in retail locations and you need to have the flexibility to modify the data as necessary.
That has absolutely zero to do with what you quoted.
The fact that the battery can last a couple years and it's inexpensive should be a clue to how it works but apparently not. IMO this is pretty simple stuff and I think you're overcomplicating it for reasons I can't fathom, but that's fine, I still don't get Bitcoins. At this point I'm done with the conversation because I have no additional avenues in which to explain the simplicity of this open system.
That has absolutely zero to do with what you quoted.
The fact that the battery can last a couple years and it's inexpensive should be a clue to how it works but apparently not. IMO this is pretty simple stuff and I think you're overcomplicating it for reasons I can't fathom, but that's fine, I still don't get Bitcoins. At this point I'm done with the conversation because I have no additional avenues in which to explain the simplicity of this open system.
Very well. As I said, I'm just learning about this subject and still reading as much as I can about it. There is not a lot of authoritative information available right now so I'm imagining how things may develop over time. In my experience nothing involving computer programming is ever simple.
An [B][I]iBeacon[/I][/B] is a high-level BLE protocol developed by Apple. It has a very rigorous implementation -- basically it can identify itself and data that a listening device can use to determine how near it is to the iBeacon, That's It!
A BLE device can act as an iBeacon by implementing Apple's iBeacon protocol.
Sometimes a non-iBeacon BLE device is called a beacon (not to be confused with an iBeacon)
Also, sometimes an iBeacon is referred to as a beacon (not to be confused with a non-iBeacon beacon)...
Still with me?
There is a lower-level BLE protocol that Apple implements as Core Bluetooth.
Using this Core Bluetooth protocol, a BLE device can operate as [at least] one of 2 classes of device.
A Central device or a Peripheral device.
To make things interesting, the Bluetooth org defines a Central device as a Client and a Peripheral device as a Server.
Do you detect the workings of a committee, here?
The Peripheral is called a Server because it has some data that Central AKA Client wants.
The peripheral can advertise its UUID along with some other data in an Advertising packet.
Included in this Advertising Packet the Server AKA Peripheral may indicate that other services/data are available upon request...
Hey, I m doing all this from memory -- because if I read about again, I'll never be able to explain it.
To access the Server/Peripheral data/services, the Central/Client must request a connection with the Server/Peripheral...
If a connection is established, the Central/Client can request (and possibly even receive) data from the Server/Peripheral in packets of, say 29 bytes.
A whole lotta' [hand]shakin' goin' on!
Now, Apple doesn't pass through the Server/Peripheral's real UUID to the app -- instead it assigns a virtual UUID to the Server/Peripheral...
Further, the virtual UUID may change at any time....
Why did Apple do this... Nobody's ever asked that question before...
So, there is this BLE device out there with some great data -- that I really need -- but I don't have any idea who it is...
Finally, an app running on an iDevice can act as a Listener for iBeacons, an iBeacon, a beacon, a BLE Client/Central, a BLE Server/Peripheral -- all at the same time...
Though there is no real definition of how many or how much...
Is this a joke? This is some guys in the office just jerking me around, isn't it?
How do you turn the dang thing off? I work a block away from an Apple store and my iPhone thinks I'm in there to shop- keeps displaying my Apple gift card in passbook on my home screen , etc.
That must be a very small block …
I don't get a peep from Apple until I'm standing next to the shop.
Wanted to reach out and send a quick note on GLIIF. GLIIF with iBeacon is the best possible solution for a superior retail experience.
GLIIF is a technology that empowers brands, builds brand networks and opens direct communications with customers at the mobile level.
We are in BETA and are actively seeking strategic partners and agencies to work with. You can get more information here. http://gliif.com/#business
From publications, packaging, in store displays we brand interactivity into every piece with a sophisticated tech. solution and provide a savvy solution for the mobile user. Every scan adds to a brand concentric network for push and in-app messaging for an open line of communication. Basically a hyper-targetted database is established with our solution.
Comments
What would you reprogram it to do? It only sends out a beacon and that beacon is matched against a database. The iBeacon device is not a server! It's not a kiosk!
I don't understand why you aren't able to grasp how incredibly simple iBeacons are. It makes no sense to give it a database, GPS, accelerometer, processing, it's own web server, etc. so that it can intelligently update itself if it happens to be moved. That defeats the entire purpose of the iBeacon. How the hell does such an expensive device get implemented by the thousands of million when they become so costly to deploy?
These are unmanned devices with a unique ID! That's it! If a CVS store decided to move merchandise around outside what corporate wants and/or corporate wants them to move merchandise around and forgets about the iBeacon associated with it that's their issue but you can't feasible make the iBeacon understand what products reside where.
Finally (and I really hope this is finally), the app needs to be aware of the iBeacon for it to work. You can't have every app that is iBeacon aware querying a server to see if that iBeacon is part of their iBeacon list. The server play comes into effect once you launch an app. This does mean that if a new store get build the app needs to be updated in some way, either through regular app update channels or being launched and getting a new list of iBeacon IDs to add to the phone's iBDB for that app (which may or may not be possible with Apple's policies).
These are unmanned devices with a unique ID! That's it!
Each beacon has three identifiers:
proximityUUID: a unique UUID to distinguish your beacons from those others are using.
major: used to group related sets of beacons
minor: used to identify a beacon within a group
Things change all the time in retail locations and you need to have the flexibility to modify the data as necessary.
That has absolutely zero to do with what you quoted.
The fact that the battery can last a couple years and it's inexpensive should be a clue to how it works but apparently not. IMO this is pretty simple stuff and I think you're overcomplicating it for reasons I can't fathom, but that's fine, I still don't get Bitcoins. At this point I'm done with the conversation because I have no additional avenues in which to explain the simplicity of this open system.
That has absolutely zero to do with what you quoted.
The fact that the battery can last a couple years and it's inexpensive should be a clue to how it works but apparently not. IMO this is pretty simple stuff and I think you're overcomplicating it for reasons I can't fathom, but that's fine, I still don't get Bitcoins. At this point I'm done with the conversation because I have no additional avenues in which to explain the simplicity of this open system.
Very well. As I said, I'm just learning about this subject and still reading as much as I can about it. There is not a lot of authoritative information available right now so I'm imagining how things may develop over time. In my experience nothing involving computer programming is ever simple.
In a way, you/we are all correct.
An [B][I]iBeacon[/I][/B] is a high-level BLE protocol developed by Apple. It has a very rigorous implementation -- basically it can identify itself and data that a listening device can use to determine how near it is to the iBeacon, That's It!
A BLE device can act as an iBeacon by implementing Apple's iBeacon protocol.
Sometimes a non-iBeacon BLE device is called a beacon (not to be confused with an iBeacon)
Also, sometimes an iBeacon is referred to as a beacon (not to be confused with a non-iBeacon beacon)...
Still with me?
There is a lower-level BLE protocol that Apple implements as Core Bluetooth.
Using this Core Bluetooth protocol, a BLE device can operate as [at least] one of 2 classes of device.
A Central device or a Peripheral device.
To make things interesting, the Bluetooth org defines a Central device as a Client and a Peripheral device as a Server.
Do you detect the workings of a committee, here?
The Peripheral is called a Server because it has some data that Central AKA Client wants.
The peripheral can advertise its UUID along with some other data in an Advertising packet.
Included in this Advertising Packet the Server AKA Peripheral may indicate that other services/data are available upon request...
Hey, I m doing all this from memory -- because if I read about again, I'll never be able to explain it.
To access the Server/Peripheral data/services, the Central/Client must request a connection with the Server/Peripheral...
If a connection is established, the Central/Client can request (and possibly even receive) data from the Server/Peripheral in packets of, say 29 bytes.
A whole lotta' [hand]shakin' goin' on!
Now, Apple doesn't pass through the Server/Peripheral's real UUID to the app -- instead it assigns a virtual UUID to the Server/Peripheral...
Further, the virtual UUID may change at any time....
Why did Apple do this... Nobody's ever asked that question before...
So, there is this BLE device out there with some great data -- that I really need -- but I don't have any idea who it is...
Finally, an app running on an iDevice can act as a Listener for iBeacons, an iBeacon, a beacon, a BLE Client/Central, a BLE Server/Peripheral -- all at the same time...
Though there is no real definition of how many or how much...
Is this a joke? This is some guys in the office just jerking me around, isn't it?
Sadly, no!
Whew!
I don't know all I understand about this!
That must be a very small block …
I don't get a peep from Apple until I'm standing next to the shop.
GLIIF is a technology that empowers brands, builds brand networks and opens direct communications with customers at the mobile level.
We are in BETA and are actively seeking strategic partners and agencies to work with. You can get more information here. http://gliif.com/#business
From publications, packaging, in store displays we brand interactivity into every piece with a sophisticated tech. solution and provide a savvy solution for the mobile user.
Every scan adds to a brand concentric network for push and in-app messaging for an open line of communication. Basically a hyper-targetted database is established with our solution.