Google is now attempting to create the environment shown in the movie Minority Report, where ads pop up as you walk by a store which are gear towards you specifically. They will know who your are, your search and buying habits and now your locations and market the hell out of you.
My initial reaction was to just ask you which pats of my comment were unclear. I then decided to read the article you provided a link to...
I had no misconceptions whatsoever. In fact, I was on target.
Samsung has its own iBeacon-like technology, which could mean Samsung favors its own technology over Google's technology.
Misconception #1: You think Samsung's beacon useage would preclude the use of Eddystone. It doesn't . Beacons can support Eddystone as well as Samsung's version in the same beacon. That's up to the beacon provider and/or the beacon user.
HTC, LG, Sony and other major non-Chinese manufacturers MIGHT support Google's technology IF the telephone carriers choose to include support of the technology in their flavors of Android.
Misconception #2: You think carriers can somehow block this. They can't. Carriers have no control over it. Zilch. This is handled on Android thru Google Play Services which bypasses carriers. And since it's baked into Google Android and updated thru Google Play Services it doesn't even need an OS update.
As expected, the technology has a proprietary cloud side that links to Google's data collection servers..
Misconception #3: Unless the beacons are interfacing with Google Android devices the actual management and software solutions are left up to the provider. Granted Google would prefer it to be using Google services, which they of course recommend "for the best experience" :rolleyes: , but it isn't required. The basics are all open-sourced. The nice detailed stuff that's ready to run with little work is Google's. Think of it as similar to the way Android licensing is done. The basics are open to anyone. Some of the pre-built "goodies" are proprietary.
Misconception #4: Unlike you've assumed, existing beacons are compatible with Eddystone with a simple firmware update. There doesn't need to be redundant "Eddystone" beacons placed alongside Apple compatible beacons. The article made that clear with comments from hardware suppliers. Eddystone can happily co-exist with other BLE solutions in the same beacons used right now. Heck it's just BLE and software.
Possible Misconception #5: I think you believe most current Android phones don't support BLE. They do. My apologies if you already knew that, but it would make your comment about iPhones and the 4S a little confusing.
And, since Apple is not supporting Google's technology, iOS developers would have to support the technology in their apps, which would force the developers to support two beacon technologies.
Misconception #6: They won't have to develop twice, once for iOS and another for Android. Instead they can use the Nearby API. They don't have to do the work twice.
Misconception #1: You think Samsung's beacon useage could affect the inclusion of Eddystone. It doesn't . Beacons can support Eddystone right alongside Samsung tech in the same beacon.
Misconception #2: You think carriers can somehow block this. They can't. Carriers have no control over it. Zilch. This is handled on Android thru Google Play Services which bypasses carriers. And since it's baked into Google Android and updated thru Google Play Services it doesn't even need an OS update.
Misconception #3: Unless the beacons are interfacing with Android devices the actual management and software solutions are left up to the provider. Granted Google would prefer it to be using Google services, which they of course recommend "for the best experience" , but it isn't required. The basics are all open-sourced. The nice detailed stuff that's ready to run with little work is Google's. Think of it as similar to the way Android licensing is done. The basics are open to anyone. Some of the pre-built The "goodies" are proprietary.
Misconception #4: Unlike you've assumed, existing beacons are compatible with Eddystone with a simple firmware update. There doesn't need to be redundant "Eddystone" beacons placed alongside Apple compatible beacons. The article made that clear with comments from hardware suppliers. Eddystone can happily co-exist with other BLE solutions in the same beacons used right now. Heck it's just BLE and software.
Possible Misconception #5: I think you believe most current Android phones don't support BLE. They do. My apologies if you already knew that, but it would make your comment about iPhones and the 4S a little confusing.
Gatorguy, the mere fact you are trying so hard is a strong indication I am on target with my views about this new cross-platform, open source, free Google technology. I know you are pro-Google on an Apple-centric Web site, but shake this off. You will be unable to convince me to change my views.
"Fornecedor de Verdade" lol more like clueless GOOG fan of the week..
Quote:
Originally Posted by Gatorguy
Quote:
Misconception #3: Unless the beacons are interfacing with Android devices the actual management and software solutions are left up to the provider.
What is the point of using this if not to interface to Android devices? That's precisely why Google made this. And for that to work you need to register the beacons with Google via the developer portal and even provide a latitute/logintude location for each. Google can then use this information - the information you provided while signing up your beacons - to both track your users and sell more ads - maybe even ads for your competitors! (Apple doesn't ask anyone to register iBeacons with them)
Quote:
Misconception #4: Unlike you've assumed, existing beacons are compatible with Eddystone with a simple firmware update. There doesn't need to be redundant "Eddystone" beacons placed alongside Apple compatible beacons. The article made that clear with comments from hardware suppliers. Eddystone can happily co-exist with other BLE solutions in the same beacons used right now. Heck it's just BLE and software.
No, you're misinformed. Go ask any of the beacon providers if they can sell you a beacon that both works with iBeacon and Eddystone at the same time. No one is making making this, they either operate as iBeacon or Eddystone beacons. If you want both you need to buy two.
Possible Misconception #5: I think you believe most current Android phones don't support BLE. They do. My apologies if you already knew that, but it would make your comment about iPhones and the 4S a little confusing.
According to the latest Play Dashboard data, 48.5% of phones still run Android <=4.4 where BLE is either inexistent or buggy.
No, you're misinformed. Go ask any of the beacon providers if they can sell you a beacon that both works with iBeacon and Eddystone at the same time. No one is making making this, they either operate as iBeacon or Eddystone beacons. If you want both you need to buy two.
"Configure Estimote Beacons to broadcast Eddystone
Update your beacons’ firmware to version 3.1.1. You can use the Estimote iOS or Android app to do that.
Change the broadcasting scheme of a beacon to Eddystone-UID or Eddystone-URL. You can change back to the default Estimote packet at any time—your current UUID, major and minor values won’t be lost."
You can use the same beacon with both iBeacon and Eddystone, and even change which one is broadcasting whenever you wish, but as you correctly point out not at the same time (for now). Thanks!
(My misconception )
With that out of the way there are beacon manufacturers that produce hardware capable of simultaneous but differing beacon broadcasts, for example Radius: "Radius Networks' RadBeacon proximity beacons are the industry’s first multi-beacons, providing concurrent support for both iBeacon™ and AltBeacon™ proximity technologies, and seamless proximity services across iOS, Android, and other emerging mobile environments." I expect that beacons supporting multiple concurrent broadcasts will soon be available from other manufacturers.
Gatorguy, Android did introduce BLE in 4.3 to to chagrin of the industry. It sucked badly and the whole thing cashed if you just happened to be in a room with beacons in it:
It's really not until API level 21 (ie Android 5.0) that it's core issues were solved.
Also there are no simultaneous iBeacon + Google copycat beacons on the market and there won't be anytime soon. It just doesn't work like that.
Actually if Google had straight up cloned iBeacon like AltBeacon just changed two numbers on the iBeacon protocol) it would work, but they tried to appear smarter by adding some clumsily conceived extensions which make this harder to do (also terribly inefficient)
You've already admitted to not really understanding how/if beacons support both protocols. As it's clear you actually have no knowledge of the subject you shouldn't go around positing "Misconception 1... 2 ...3... " on people.
Seems you're only disagreeing with a single point of the five rather than 1, 2 or 3. Accurate? BTW I do appreciate the detail about beacons and multiple broadcast support. "It doesn't work that way" is good enough for me. Honestly.
Gatorguy, the mere fact you are trying so hard is a strong indication I am on target with my views about this new cross-platform, open source, free Google technology. I know you are pro-Google on an Apple-centric Web site, but shake this off. You will be unable to convince me to change my views.
I wasn't trying to convince you to like'em. I was pointing out that you might have misunderstood some of the Eddystone details.
]Also there are no simultaneous iBeacon + Google copycat beacons on the market and there won't be anytime soon. It just doesn't work like that.
You've already admitted to not really understanding how/if beacons support both protocols.
What does this mean: http://bluvision.com/physical-web-eddystone-ibeacon-support/
"BEEKS beacons now include full support for all three of the new Eddystone advertisement formats. Interleaving between iBeacon and Eddystone is now simple. Your beacons can broadcast Eddystone UID, URL and TLM along with sBeacon and iBeacon."
It seems to be saying they can broadcast all three standards simultaneously. If that would actually be impossible could you explain why so I could understand it? Learning something new is rarely a bad thing.
Comments
I agree.
Eyebeacon could've been a better choice.
Agreed. I'm waiting for Google and or Samsung to come out with a new logo any time soon, an apple with a slightly different shaped leaf.
Then let's start here: Misconception #1: You think Samsung's beacon useage would preclude the use of Eddystone. It doesn't . Beacons can support Eddystone as well as Samsung's version in the same beacon. That's up to the beacon provider and/or the beacon user.
Misconception #2: You think carriers can somehow block this. They can't. Carriers have no control over it. Zilch. This is handled on Android thru Google Play Services which bypasses carriers. And since it's baked into Google Android and updated thru Google Play Services it doesn't even need an OS update.
Misconception #3: Unless the beacons are interfacing with Google Android devices the actual management and software solutions are left up to the provider. Granted Google would prefer it to be using Google services, which they of course recommend "for the best experience" :rolleyes: , but it isn't required. The basics are all open-sourced. The nice detailed stuff that's ready to run with little work is Google's. Think of it as similar to the way Android licensing is done. The basics are open to anyone. Some of the pre-built "goodies" are proprietary.
Misconception #4: Unlike you've assumed, existing beacons are compatible with Eddystone with a simple firmware update. There doesn't need to be redundant "Eddystone" beacons placed alongside Apple compatible beacons. The article made that clear with comments from hardware suppliers. Eddystone can happily co-exist with other BLE solutions in the same beacons used right now. Heck it's just BLE and software.
Possible Misconception #5: I think you believe most current Android phones don't support BLE. They do. My apologies if you already knew that, but it would make your comment about iPhones and the 4S a little confusing.
Misconception #6: They won't have to develop twice, once for iOS and another for Android. Instead they can use the Nearby API. They don't have to do the work twice.
Misconception #1: You think Samsung's beacon useage could affect the inclusion of Eddystone. It doesn't . Beacons can support Eddystone right alongside Samsung tech in the same beacon.
Misconception #2: You think carriers can somehow block this. They can't. Carriers have no control over it. Zilch. This is handled on Android thru Google Play Services which bypasses carriers. And since it's baked into Google Android and updated thru Google Play Services it doesn't even need an OS update.
Misconception #3: Unless the beacons are interfacing with Android devices the actual management and software solutions are left up to the provider. Granted Google would prefer it to be using Google services, which they of course recommend "for the best experience"
Misconception #4: Unlike you've assumed, existing beacons are compatible with Eddystone with a simple firmware update. There doesn't need to be redundant "Eddystone" beacons placed alongside Apple compatible beacons. The article made that clear with comments from hardware suppliers. Eddystone can happily co-exist with other BLE solutions in the same beacons used right now. Heck it's just BLE and software.
Possible Misconception #5: I think you believe most current Android phones don't support BLE. They do. My apologies if you already knew that, but it would make your comment about iPhones and the 4S a little confusing.
Gatorguy, the mere fact you are trying so hard is a strong indication I am on target with my views about this new cross-platform, open source, free Google technology. I know you are pro-Google on an Apple-centric Web site, but shake this off. You will be unable to convince me to change my views.
"Fornecedor de Verdade" lol more like clueless GOOG fan of the week..
Quote:
What is the point of using this if not to interface to Android devices? That's precisely why Google made this. And for that to work you need to register the beacons with Google via the developer portal and even provide a latitute/logintude location for each. Google can then use this information - the information you provided while signing up your beacons - to both track your users and sell more ads - maybe even ads for your competitors! (Apple doesn't ask anyone to register iBeacons with them)
No, you're misinformed. Go ask any of the beacon providers if they can sell you a beacon that both works with iBeacon and Eddystone at the same time. No one is making making this, they either operate as iBeacon or Eddystone beacons. If you want both you need to buy two.
Want a comment from hardware supplier to go with that, where's from one of the biggest - Estimote: https://forums.estimote.com/t/eddystone-and-ibeacon/1508
According to the latest Play Dashboard data, 48.5% of phones still run Android <=4.4 where BLE is either inexistent or buggy.
I'll respond without insults which look even sillier when you turn out to be incorrect.
...to be a cross-platform solution with added capabilities beyond what Apple's iBeacon currently offers.
"Configure Estimote Beacons to broadcast Eddystone
Update your beacons’ firmware to version 3.1.1. You can use the Estimote iOS or Android app to do that.
Change the broadcasting scheme of a beacon to Eddystone-UID or Eddystone-URL. You can change back to the default Estimote packet at any time—your current UUID, major and minor values won’t be lost."
You can use the same beacon with both iBeacon and Eddystone, and even change which one is broadcasting whenever you wish, but as you correctly point out not at the same time (for now). Thanks!
(My misconception
With that out of the way there are beacon manufacturers that produce hardware capable of simultaneous but differing beacon broadcasts, for example Radius:
"Radius Networks' RadBeacon proximity beacons are the industry’s first multi-beacons, providing concurrent support for both iBeacon™ and AltBeacon™ proximity technologies, and seamless proximity services across iOS, Android, and other emerging mobile environments."
I expect that beacons supporting multiple concurrent broadcasts will soon be available from other manufacturers.
That's fine, except BLE was rolled out with Android 4.3 meaning most Android devices in use offer it. Even your figure for 4.4 and up was incorrect. Most Google Android devices in use have 4.4 or better, 51.6%
https://developer.android.com/about/dashboards/index.html?utm_source=suzunone
Gatorguy, Android did introduce BLE in 4.3 to to chagrin of the industry. It sucked badly and the whole thing cashed if you just happened to be in a room with beacons in it:
https://code.google.com/p/android/issues/detail?id=67272
It's really not until API level 21 (ie Android 5.0) that it's core issues were solved.
Also there are no simultaneous iBeacon + Google copycat beacons on the market and there won't be anytime soon. It just doesn't work like that.
Actually if Google had straight up cloned iBeacon like AltBeacon just changed two numbers on the iBeacon protocol) it would work, but they tried to appear smarter by adding some clumsily conceived extensions which make this harder to do (also terribly inefficient)
You've already admitted to not really understanding how/if beacons support both protocols. As it's clear you actually have no knowledge of the subject you shouldn't go around positing "Misconception 1... 2 ...3... " on people.
Seems you're only disagreeing with a single point of the five rather than 1, 2 or 3. Accurate? BTW I do appreciate the detail about beacons and multiple broadcast support. "It doesn't work that way" is good enough for me. Honestly.
Edit:
Eddystone support is rolling out faster than might be expected.
https://www.morningstar.com/news/pr-news-wire/PRNews_20150715DA56807/bluvision-and-texas-instruments-lead-beacon-innovation-with-full-support-for-eddystone-and-ibeacon-standards.html
http://bluvision.com/physical-web-eddystone-ibeacon-support/
"BEEKS beacons now include full support for all three of the new Eddystone advertisement formats. Interleaving between iBeacon and Eddystone is now simple. Your beacons can broadcast Eddystone UID, URL and TLM along with sBeacon and iBeacon."
It seems to be saying they can broadcast all three standards simultaneously. If that would actually be impossible could you explain why so I could understand it? Learning something new is rarely a bad thing.