With physical web integration in new google chrome browser (still in beta), its possible to detect beacons that emit Eddystone Url frames.
source: http://www.blueupbeacons.com/index.php?page=/blog/physicalweb
I downloaded Chrome Beta, enabled physical web going to chrome://flags, gave the app access to location services, gave runtime permission for using location (I am using Marshmallow), but the browser still wasn't able to detect a beacon nearby. I tried using physical web app as well as Opera Labs version and both are able to detect the same beacon.
I am using RadBeacon USB by Radius Networks.
What am I missing here?
My first guess is that your URL is an HTTP URL. You have to be pointing to an HTTPS URL for Chrome to display it.
Chrome 50 will have a physical-web diagnostics page to show issues like this.
Now that Chrome 49 is out for Android, it's built in natively to the functionality but you still have to enable the physical web flag on your device (Chrome://flags#enable-physical-web). You will get prompted to restart the browser. Also, make sure your bluetooth is on and you allow Chrome to have access to your location which you will be prompted for. Now you should start to see Eddystone-URL broadcasts that are close to you. Make sure that your RadBeacon is Eddystone-URL compliant as I know that some of the usb beacons they released did not support eddy-url. I'm using a bkon beacon and it's working well. Make sure that your end destination site is https as well and you can do this for free using letsencrypt. Good luck!
Go to your chrome beta settings, then privacy and check if physical Web is on. Also, the broadcasting URL should be an https secured URL. Also, your browser location should be on.
Sometimes it takes time for your browser to detect for URL's. Try to lock your phone screen by pressing the power button and then unlock it. You should se physical web.
Repeat this activity several times.
Still if you are not able to see physical Web then try reinstalling chrome beta.
Related
I am a bit confused with regards to availability of Caches API on mobile devices.
https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage
Documentation states this API is available on both service worker scope and window scope.
I can clearly access it on desktop's Chrome without issues.
Now whenever I do feature detection on Android's Chrome I get undefined as if feature is not available.
I tried to detect this way:
if ('caches' in window)...
if ('caches' in self)...
calling from console log via connected device etc
What do I miss?
PS: I understand Safari has very basic implementation so I expected this to go wrong with Safari, but here I am testing it with Chrome on Android;/
It seems window.caches (CacheStorage) is only available on chrome mobile when the page is served through SSL.
I'm testing with my Progressive Web App (PWA), containing a Service-Worker for caching and a manifest file.
When serving the PWA via HTTP over the LAN window.caches is not available.
When served via a domain-name with SSL enabled, window.caches is available and behaves like on the Desktop-Version of chrome.
It doesn't make a difference, whether you run it in a browser tab or standalone (when added to home-screen).
Edit:
In fact, the same behavior also applies to chrome on desktop.
Caching on my app was working only, because i tested with 'localhost' or 127.0.0.1. On any other domain / ip-address, caching gets denied when not using ssl.
I'm trying to port a web application to a native Android application using Cordova. It's fairly simple, primarily just sending Midi messages to a connected device. I know the WebMidi API is only supported on recent versions of Webkit on Android, and I have been testing on 5.1. I've managed to prove that the basics work by running the original web version on Chrome on the device, it works fine.
The problem when running in Cordova is the messages themselves are not sent for some reason, no error, just not getting there. I know the API is working, as a separate part of the application lists the connected devices and presents a dropdown list to choose from, this works fine, and recognises the connected Midi device. However, when I send messages they don't have the desired effect on the Midi device. They are SysEx messages, which I believe needs additional permissions, android.webkit.resource.MIDI_SYSEX, is it possible that this is enabled on Chrome but not on the Cordova application? I've tried adding this permission to the ./config.xml, and ./platform/android/AndroidManifest.xml but to no avail, it doesn't seem to have any effect, and doesn't even show as an additional permission when installed.
Based on various searches, I've also tried installing the Crosswalk plugin, but couldn't get that to work at all, not even the device listing.
Any thoughts welcome.
The problem you're facing is that you won't even be prompted for midi sysex permission unless you meet certain criteria. You either have to be accessing your web midi code via a localhost, OR on an https URL. Sysex is potentially harmful, so they have used this as a minimum security requirement.
I had it working on android by opening a URL on my to my dev PC (using a self signed SSL cert on wamp). It gives the security prompt for sysex and then works as expected, so chrome on android works for sure. Crosswalk Cordova however, I'm not so sure.
I've tried running a little webserver in my cordova app (on Android), starting the webserver on 127.0.0.1:8080 and then connected to it using chrome (separately on the same device). Feels tantalizingly close, but I need it to run in my app!
My attempts to run an iFrame with the webserver's URL (http://127.0.0.1:8080) have failed. it's just not found. No security error, so doesn't seem to be to do with white-listing, although I need to look into that further to be sure.
It seems that the webserver plugin is running successfully, but is not visible from within the app.
You should have a play with this, and see if it gets you anywhere...
Or perhaps you'll find another one that is visible from within the app itself.
The alternative approach is to use a socket server to connect to your computer, and have the midi devices connected to it. Not exactly portable though!
I want to send a notification on that mobile which is in the range of beacon without any app and bluetooth is on.
Is it possible to send the notification?
Right now I'm using alt beacon library.
The closest you can come to doing this on Android devices is to use a beacon to advertise an Eddystone-URL frame. Users with newer versions of Chrome for Android who have opted in to receive physical web notifications will see a notification to show the page of the URL transmitted by your beacon when Chrome detects it.
You can read more here.
There are lots of caveats. Users must have Bluetooth on, must have a newer version of Chrome installed, and must have enabled this feature.
Yes, it's possible to send notifications without app if your beacon device supports Eddystone-URL protocol. On Android devices version 6.0 and later Google Nearby feature should be enabled. For earlier Android versions, it's possible to use Physical Web feature on Chrome browser. For iOS devices with iOS version 8 and later and installed Chrome browser, Physical Web feature is also available.
We are currently seeing a problem where mobile devices that surf to our website don't seem to get picked up, not with page view or in realtime or in the events tracking. This all happened since March 15th but we are only now really starting to notice it. Debugging the analytics code snipped based on this https://developers.google.com/analytics/resources/articles/gaTrackingTroubleshooting was no problem on desktop but how do you do that on a mobile device. Android Phone or iPhone. Is there any way to debug the tracking code on the phone to make sure it works? We had been successfully using ga.js with async snytax without problems for a good long while.
For testing on iOS 6 and later you can plug your iPhone into your desktop and use your desktop version of Safari as described here by Apple. You can then see the results of the ga_debug.js.
Android has a similar tool, however, it does require you to install the Android SDK.
I'm not too sure about other phone operating systems, but that covers the main two in your question :)
I am trying to use gwt-mobile-webkit, particularly its location api. It works well with iPhone (both device and simulator) and Firefox and on G1 with 1.6 Android, however, it does not work on G2 with Android 1.5 on it. In result I am getting onFailure callback with Permission Denied error.
So it seems, that there is some geolocation API (gears or HTML5) in the browser available, but it just does not want to ask user for granting permissions.
Do you know if there is any workaround or just enable it somewhere in settings?
I had what sounds like a similar problem on G1. The fix for me was to do Factory Reset - a bit extreme, but it was the only solution I had at the time.
See http://groups.google.co.uk/group/android-discuss/browse_thread/thread/f9233991a1affbd5/3b318c6bed932790
I guess you have read the gears doc here on geolocation (android section):
http://code.google.com/p/geo-location-javascript/wiki/SupportedPlatforms#Google_Gears
Interesting that it says the permission is only asked once per site (see excerpt below).
"Gears is a javascript framework available for Android, Windows Mobile (IE Mobile, Opera Mobile), Mac (Firefox, Safari), Linux and Windows . One of its cores is the Geolocation API. On the mobile phone it asks the user once for permission per site and user, so not every session as in the iPhone OS 3.0."
I would try clearing the android browser cache and then re-visit the site to hopefully cause it to ask permission to enable geo location. - just a guess.
I know the support was flaky at best in 1.5 android.