I want to make an HTML5 game that can be controlled with mobile. So how to communicate between mobile and browser on PC?
I think of the following ways:
Bluetooth This may be the most easy way to use. But I searched and found that Chrome made bluetooth API proposal last year but is now available only on Chrome dev, which means I cannot make the game popular for everyone.
WiFi I don't know how to set up a host on browser using WiFi information. If so, I can then connect my mobile to WiFi. This is considered to be faster than web socket since it's local network.
Web Socket There're a lot of information about how to use this. But as this use WAN, it is considered to be slower and is my last choice.
So, does anyone know how to achieve this with the former 2 ways?
Related
We recently implemented the webHID API for one of our sites (it is such a godsend) and have the client asking if they can use the devices over a Microsoft RDP connection?
I imagine this would depend on the RDP client and whether they can/do send HID events over the RDP connection.
From some initial research it looks like you can redirect USB over RDP but don't think this will work for us as I couldn't get my device mapping done with the webUSB API.
If anyone has any input on this it would be greatly appreciated.
Thx
WebUSB, WebHID and Web Serial should work with a remoted USB device.
That said, there may be bugs if these devices don't appear to applications like Chrome in quite the same way they do when connected locally. If they don't, it would be interesting to get logs from chrome://device-log and see how the device appears in the Windows Device Manager.
Please file a bug at https://crbug.com/new and let us know so that we can keep track of this issue.
I have some devices which provide small webserver applications for users to access from their phone or laptop using a browser or thin client. All that the thin client does is a UDP broadcast to find devices on the local network and then connect a browser to the device(s) when found - or notify when no devices are found after a timeout.
Would it be possible to implement this thin client as a webpage served from a known host, so that the users' device wouldn't need any software installed beyond a browser and a link to the known host? The webpage would broadcast some UDP packets and wait for (appropriate) responses from any devices on the local network, if/when device responses are received present a list of devices to connect to, so the user can just select from a list, instead of having to determine the device addresses and type them in for themselves or install and use the thin client.
I can see how this sort of thing might be abused, and therefore made difficult or impossible by browsers, but no more than so many other technologies that are currently wide open for use...
Any help getting started with this kind of solution would be appreciated, thanks!
Unfortunately, this can't be done directly. I think it would be really great if there were some sort of "local peer" API to enable simple WebRTC connections without going through servers, but this doesn't exist.
You do have some options:
Write a browser extensionThis needs to call some native code to shuffle your data around, but it can work.
Deploy a server on the networkThe server can do all the initial connection/negotiation.
I'm planning to realize the following project and would be thankful if somebody could verfy my approach!
I want to establish a fully bidirectional wireless realtime communication between a smartphone (cross platform) and a embedded microcontroller running a webserver.
The webserver should provide data of the connected hardware in realtime e.g. temerature.
The smartphone should render these on screen and you should be able to configure the hardware e.g led color with the smartphone and save the config to the embedded webserver.
My first guess was to use HTML5 websockets but they aren't available on all platforms so I got inspired by XBMC, which uses JSON-RPC.
Just imagine a car stero system with bluetooth connected to a µC with webserver and wifi dongle.
My plan is to implement a webapp on the webserver which lets serves the purpose mentioned above. But the tricky part is to get the user to establish a bluetooth connection to the stereosystem because i looked up similar questions which say you can't access stuff like bluetooth on the smartphone with HTML5.
long story short, this is the current idea:
hardware -> µC -> webserver -> HTML5 Webapp-> WIFI -> Smartphone
communication via JSON RCP.
I would be highly thankful if somesone could give a statement to said idea and planned implementation because I never done this before!
Thanks guys!
We at muzzley, have developed a framework to simplify this process. We provide a way for your browser applications to communicate with smartphones. In the side of the smartphone you have widgets that are already done (gamepad, drawpad, switch, swipe, others) or you can build your own html based widget.
(disclaimer: i work for this project)
Most of the work is already done for what you want to do :)
Quick start here:
http://www.muzzley.com/documentation/quick-start.html
You can pull from github several examples here:
https://github.com/muzzley/muzzley-demos/
Lib for browser:
http://www.muzzley.com/documentation/libraries/javascript.html
I hope it helps.
Best
I think your first instinct was probably right. Have you looked at socket.io for node? It's essentially a shiv which ensures that you can use websocket functionality in virtually any combination of device and browser (see list of supported transport mechanisms and browsers here).
It should allow you to avoid bluetooth altogether.
trying to create a program that works as following .video is captured by web cam of laptop and it is streamed to android phone using wifi .According to the video displayed, user types some messages and sents back to laptop simultaneously.
googled and found that making an ad-hoc wireless network will work,but forum
discussions says its not supported by android.want my app to work from 2.2 onwards
Which Socket communication protocol (UDP or TCP) protocol should be used to stream video?
Since want to implement two way communication, which one must be the server (laptop or mobile device)
Please guide me how to implement this
use connectify or any virtual router to get connected to your android phone.so app can be connected with your laptop or desktop.
go for UDP its fast and recover data even if it's lost and also use a proper data streaming strategy or a protocol.
According to your application design , i will recommend you to make your laptop work as a server. Also it would be best if you choose to use threading in both application and recommend your app to act as server or client as it's required shows more robustness..!
So I have been thinking about building quite a complex application. The idea of building an html5 version has become quite an attractive possibility. I have a few questions about it first however.
My first concern is how reliable the offline application API's are at the moment. I have been looking into this standard: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html and it looks pretty easy to implement and use, but I am wondering how easy it is to use? And assuming you set up the manifest etc, is the web application just accessed (offline) by going to the same url you originally downloaded the application from?
My other concern is the use of sockets. This offline application still needs to be able to communicate with local servers, I ideally wanted to avoid having to host a web-server, a socket connection however would be plausible. How well do websockets currently work when the browser is offline? Is it possible, to have a fully networked / interactive browser application running even without an active internet connection? (after the app is first downloaded)
Any insight would be great!
That's a lot of questions, you may want to consider breaking it up into more easily answerable portions more directly related to what, exactly, you're trying to achieve. In the meantime I'll try to provide a short answer to each of your questions:
My first concern is how reliable the offline application API's are at
the moment.
Fairly reliable, they have been implemented for a number of versions across most major web browsers (except IE).
is the web application just accessed (offline) by going to the same
url you originally downloaded the application from?
Yes. Once the offline app has been cached, the application is served from that cache. No network requests will be made unless you explicitly request URLs from the NETWORK or FALLBACK sections of the manifest or aren't covered by the manifest at all, apart from to check whether the manifest itself has changed.
This offline application still needs to be able to communicate with
local servers, I ideally wanted to avoid having to host a web-server,
a socket connection however would be plausible.
A Web Socket still requires a web server. The initial handshake for a Web Socket is over HTTP. A Web Socket is not the same thing as a socket in TCP/IP.
How well do websockets currently work when the browser is offline?
They won't work at all, when you've set a browser to offline mode it won't make any network requests at all. Note that a browser being set to offline is not the same thing as the offline in 'offline API'. The offline API is primarily concerned with whether or not the server hosting the application can be reached, not whether the the browser is currently connected to a network or whether that network is connected to the internet. If the server goes down then the app is just as 'offline' as if the network cable on the user's computer got unplugged. Have a read through this blog post, in particular the comments. My usual approach to detecting offline status is to set up a pair of files in the FALLBACK section such that you get one when online and the other when offline - request that file with AJAX and see what you get.
Is it possible, to have a fully networked / interactive browser
application running even without an active internet connection?
Yes, but I don't think that means what you think it does. Separate instances of the app running on different browsers on different machines would not be able to communicate with each other without going via the web server. However, there's no requirement that the web server be 'on the internet', it will do just fine sitting on the local network.