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.
Related
I want to use an USB HID from a website. The website will only be accessed by Chrome browsers. The solution should require a minimum amount of extra software and setup for the website user to work.
The USB device presents itself as USB HID to the OS and I need to write and read byte arrays to and from it in order to implement the manufacturers specification for some of the device's features.
My current solution consists of two parts:
A Chrome App that uses the chrome.hid API to talk to the device. This App exposes a Chrome Cross-Extension messaging port to provide and interface for "service calls".
JavaScript code on the website that sends requests to the Chrome App, which then talks to the USB device to process the request.
In order to make it easier for the user I want to get rid of the App, so the user can just surf to the website, grant access to the device if necessary and then be able to use the device.
To be clear, I want the user to be able to use the website without installing any dependency first.
I already tried using the WebUSB navigator.usb API but Chrome blocks access to USB HID devices. Is there another way to accomplish this?
WebHID is being developed for this use case. It has been available behind a feature flag since Chrome 78, with an original trial expected in Chrome 84 (probably later due to current Covid-19 situation), estimated stable August 2020 .
For more details: https://github.com/robatwilliams/awesome-webhid
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.
I have been programming for windows since about v2.1 and am interested in some apps for the phone now that it seems to be coming of age.
Search as I might, I cannot find a developer's unlocked version of a phone other than CDMA one and I can't use that as there is only AT&T and TMo available out here in the boonies.
Buying a dev's version for Android was simple as going to Moto's site and dropping one in the shopping cart.
If msoft are wondering why there are so few win-phone devs and/or, they might start looking at how hard or easy it is to get started. I have installed the SDK and the emulator is OK, but not something I would trust enough without testing it on my own phone.
Any helpful thoughts and suggestion on where to get a phone that it is not against the warranty to unlock?
You can use any windows phone as long as it supports the OS version (windows phone 8/8.1 is not supported in the older models) you're coding for. You don't need a developer version of a phone.
You need a developer's account though (should be 20/year now) and take a look at this page for registering your device. For older devices you need Zune software but it's not needed for windows phone 8 and up.
And if you want to use a real device for testing, without wanting to buy a device, you could use the Remote Device Access service
With it you can use a real device (located in Tampere/Finland) over the internet with your browser. Limitations include the lack of physically touching/rotating the device, and that calls/SMS are disabled both incoming & outgoing ones.
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.
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