We have used HTML5s navigator.geolocation and found it to be very good on iOS and Android smartphones. Now the users want the same HTML5 web app to run on a laptop with external GPS. Using Windows 7 on the laptop I just can't figure a way to share the location to a HTML5 browser (tried Safari, FF, IE, Chrome). For testing I am using a GlobalStat BU-353 USB GPS which works standalone and I have found GPSDirect (cool freeware) to feed that signal to Win7 Sensor Location Services but still the HTML5 browsers do not see the GPS.
Anyone had any luck with this please ?
I was looking for similar solution and found this: GpsGate.
It is standalone application which connects to almost any GPS device and publishes it's data in several forms including browsers (through Javascript API which in turn makes jsonp call to http://localhost:12175/gps/[getVersion|getGpsInfo]?jsonp=padding). It's not compatible with Geolocation API, but I think writing simple adapter shouldn't take much time. Another good thing is that it's Express edition is free for both private and commercial use (link).
EDIT: After some digging I found this patch which adds geolocation compatible adapter for GpsGate to some other geolocation library.
Issue 45535 is beginning to address this in the Chromium feature requests. As of Jan 5 2012, the feature has been marked as "started".
Feature request: http://code.google.com/p/chromium/issues/detail?id=45535
As long as you only need a single browser for your client solution (and not a universal solution) this will solve your problem.
A great method to start testing and keeping an eye out for this issue is to download Chrome Canary, which is usually 2 versions ahead of the Chrome release. I'm right now using v18 on Canary and it's great since I've been keeping an eye on the websocket schema changes.
You can find Canary here: http://tools.google.com/dlpage/chromesxs
Related
Originally posted here.
I was under the impression that WebGL should work on Chrome on pretty much any desktop device, but that it may fall back to software rendering in some cases (assuming you don't pass failIfMajorPerformanceCaveat=true when getting the context). However in practice this seems not to be true for a substantial number of users on both Macs and Windows (especially, but not limited to, those within some kind of managed corporate IT system).
As far as I can tell, on all hardware/setups where WebGL is disabled in Chrome, it is possible to run it using a different browser (FF, and even IE11). I believe that IE11 only uses software and FF may be less strict with its blacklisting of GPUs, but that doesn't explain why Chrome can't switch to software when hardware is unavailable. Indeed, in some cases, overriding the GPU blacklist in Chrome does seem to work (but presumably is not a good idea).
So firstly, could I check that my assessment of the situation is correct? And secondly, could anyone suggest how to force software rendering (i.e. flags etc.) and/or point me at an issue discussing this?
Any advice would be very much appreciated - even if the process is rather involved it is still worth knowing about as it may be workable for our clients.
update:
#gman points out that there is no software emulation on Macs in Chrome, but that still leaves the question of what's going on in windows.
update 2:
(to partly answer my own question): it seems that (at least on 32bit Chrome on windows) if you go to chrome://components and see SwiftShader is at version 0.0.0, then simply hitting the update button should download the latest veriso,n and hey presto..it works. Not sure about 64bit Chrome though.
update 3:
As #Nicloas says, M59 in Chrome (to be released in May/June 2017) should fix this issue in Chrome on Windows and Linux, with Mac following later.
Quoting my own answer from swiftshader#googlegroups.com:
I'm happy to let you know that with the upcoming M59 release of Chrome, we have integrated SwiftShader to provide seamless fallback support for WebGL in case the GPU is blacklisted.
We were previously only using SwiftShader as a separately downloaded component, which indeed does not work on managed corporate systems, and required a browser restart. Integrating SwiftShader was only possible after open-sourcing it and substantially reducing its binary size.
You can test it today on Windows using Chrome Canary or the Beta channel, and specifying the --disable-gpu launch flag. Linux is also supposed to work but the libraries were mistakenly not shipped as part of the beta package, which we hope will be rectified in the next update and before it reaches the Stable channel. We haven't started integrating Mac OS X support yet, because Chrome works significantly differently there, but it's on our radar.
TLDR: Can the Chrome Bluetooth API be used on the Windows mobile platform?
I'm on a quest to find a solution for bluetooth connectivity across various platforms.
We plan on having native iOS and Android versions for our app, and a web app for other platforms (limited time and budget).
The setup of our product requires a one-time bluetooth connection to configure a wireless connection if necessary. This is fine for the iOS and Android versions of the app, but presents a problem for desktops/laptops or Windows mobile users.
The option for our device to act as an accesspoint has been considered, but it's not a very user-friendly solution. It needs to be easy enough your grandmother can set it up, and switching to another wireless network doesn't qualify.
In my research, I've come across the Chrome Bluetooth API available in Chrome Browsers starting in version 37. I'm wondering how accessible this would be for, say, the Windows mobile crowd. Or laptop and desktops running Windows, ChromeOS, etc.
Thanks in advance!
First, that api is not available to the web, it is available for Chrome Packaged Apps, which are published to and installed from the Chrome Web Store (they do not have a URL you can just visit).
Second, I do not think that Chrome Apps are available for windows mobile, though they are supported for all the desktop platforms. (Make sure that the bluetooth api support you need is fully support across all platforms, though, since there are some limitations).
Finally, there is ongoing work for an upcoming web-bluetooth api which will be available for the open web -- but that is some ways away.
Best of luck.
This is my first time developing for Chrome. My question is: if i use devtools so i can create panels, will my extension pass through to the store or is it only for developers to test stuff with? So basically is it legal in the store extensions to use devtools?
chrome.devtools.panels is listed as under Stable APIs. Any APIs listed as stable are perfectly ok to publish in the Chrome Web Store. Keep in mind that you should provide enough of a description and getting started guide that people understand what the extension does and how it works.
I have created an application which use HERE Application Launchers and my app work fine on my Nokia Lumia 720.
My problem is certification on marketplace I get the response like:
The application exhibits device specific behavior that inhibits functionality and
features. The application's main functionality
cannot be tested on non-Nokia devices because it requires Nokia Here Drive.
-Launch the application on HTC 8X.
...
-Observe the user is prompted to install the app "Here Drive".
I agree with this becouse HERE maps are only available on Lumia devices. But how to use HERE Launchers if we cannot publish it on the marketplace?
If somebody has had similar situation and know solution for it?
That's because it's better to use the ms-drive-to or ms-walk-to Uri scheme!
When you use those, the phone itself will launch HERE drive if it is present, otherwise Bing maps!
Get the needed example code and usage on MSDN here: http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj710324(v=vs.105).aspx
I think you need to clearly state in your app description for Store and in the app itself, that it works only on Nokia devices. (Or you can implement some kind of fallback behavior for non-Nokia devices as well)
This way it should pass the certification, because the behavior will be expected and not confusing.
I suppose either there were something wrong on the submission time, or the rules have changed. I at least submitted an application which is using the Uri Scheme directly, and it got accepted.
In the essense there is no requirements for any specific Application being installed, but there is a query made for applications which support the Uri scheme protocol. And if the HERE application having it is installed, then it will be launched.
And if there is no handlers available, then the market place should be opened for searching for the handlers. At least that's the way the system is designed for.
I'm using gears.js and geo.js in an attempt to cover all grounds, in terms of finding the user's geolocation. So if the user is using something less than IE9, I would possibly prompt install for Google Gears, so I know for desktop, IE7 + is covered.
For the mobile devices I'm looking at geo
which covers quite a few mobile devices.
I'm wondering if there is anything which accounts for WP7 geolocation as well using JavaScript, and if there is better ways of handling GeoLocation for all devices.
Not entirely sure how Google Gears work for IE7/8 also, so any elaboration on that would be great. (I'm not assuming Gears is the only/best way forward though for non geolocation supported browsers, so any correction on that is fine!)
I ran into this today: http://geosenseforwindows.com/ it basically gives Wifi based geolocation to the Windows 7 Sensor API:
Geosense is a Windows Sensor that
provides the Location and Sensors
platform in Windows 7 with accurate
and reasonably ubiquitous positioning
information without requiring or the
assistance of GPS hardware, enabling
more practical location-based
applications and scenarios on Windows
7.
Unfortunately I don't think IE can access that Sensor API without resorting to COM calls in your javascript.
We also use the free/commercial GpsGate, which lets any browser on a Windows machine directly access a real hardware GPS device on the computer.
In answer to the WP7 part of your question.
There is CURRENTLY no way to get geolocation from in the browser in IE on Windows Phone 7. This should change when the next version of the browser is released.