I am trying to implement a Phonegap (HTML5) application which connects to a Websocket server (running in an embedded device, also has Bonjour service) to exchange data within home network.
I would like to know the best possible way of detecting the server IP using Phonegap. I have explored and found that Titanium and Quickconnect support Bonjour. But I would like to stick to Phonegap for various other reasons.
Any alternative way of detecting the server IP within the local network is also okay.
Need your suggestion.
There are two iOS Bonjour plugin implementations for Phonegap (Cordova) on Github:
https://github.com/jarnoh/cordova-dnssd
https://github.com/SayGoSolutions/Cordova-BonjourBrowserProxy
Unfortunately I haven't found a cross-platform implementation.
Related
I'm trying to determine if I can access any browser api for chrome OS that will allow me to identify the device that its running on when the application has been force-installed in kiosk mode as a PWA.
We're running into exactly the same issue right now. The correct path seems to be to create a PWA and to connect it to a (pre-installed) extension that has access to the enterprise.deviceAttributes:
See https://developers.chrome.com/apps/migration:
"If there is a capability that your Chrome App has that the regular web platform can't provide, it might be available as an extension API. In this case, you use a progressive web app together with an externally connectable extension your web app can send messages to."
enterprise.deviceAttributes are only accessible if the calling App/Site is pre-installed to the device and not loaded dynamically, so it cannot run in the PWA by design.
But with this tutorial, it seems possible:
https://developer.chrome.com/extensions/messaging#external-webpage
We're looking into that right now and will post our progess here.
I am developing chrome extension which needs to communicate with my running service. I tried to use Chrome Native messaging, but I didn't manage to make the extension communicate with running service.
I did manage to communicate with native (not already running app), as described here:
Google chrome native messaging
It's impossible for Native Messaging to "connect" to an already-running process.
Therefore, you have to either use something else (a local WebSockets server in your service is a good alternative idea) or make the Native Messaging host be some sort of "proxy": you can start a new one from Chrome, and it uses some other channel to communicate with the already-running service.
The Chrome developer docs refer to something called Native Messaging to communicate with other desktop applications directly from the Chrome extension or app.
How can I tell when a desktop app has such native messaging available and what kind of communication it can accept? Is there a way to get the application to expose what it will communicate about?
If I needed to talk to the original developers of that desktop app, is this even the most common terminology (native messaging) so they understand what I am referring to?
Does native messaging function the same on both Windows and Mac?
An extension can only communicate with a native desktop application if that application is registered as a "native messaging host". This means that there must be some manifest file at a pre-defined, platform-specific location that declares that the application has "native messaging" capabilities and which extensions are allowed to communicate with this native messaging host.
So, by default, it is extremely unlikely that any of your desktop apps support native messaging. This term is a specific to Chrome/Chromium, and might not be understood by developers who are not familiar with Chrome/Chromium. Though every competent developer should be able to get native messaging to work after reading the documentation of native messaging.
Currently, the only supported way of communicating with native applications is through the standard input and output pipes (stdin / stdout) via a simple yet strict protocol. If the desktop app has a command-line interface, then you can easily write a proxy application that serves as a native messaging host and interacts with the desktop application. It is essentially the bridge between your Chrome extension and some other application. This proxy application can be written in any language that supports stdin/stdout, and it does not require any cooperation from the original developers of the desktop app.
The native messaging protocol is the same across all platforms, but you have to take the endianness of the system into account, and the locations of the manifest file also platform-dependent.
I am trying to develop an HTML5 app to be ported to native via PhoneGap. Is it possible for the app to be able to act as a server on a mobile device, with the same app on another mobile device acting as a client and connecting to the former? This is all within a local network.
I am new to PhoneGap and I understand that most server implementations are on platforms such as node.js or PHP and that PhoneGap only supports HTML, CSS and JavaScript. I think I might be partially wrong here as there are various plugins that could help ease the abstraction between PhoneGap and the native developer.
Other alternative suggestions are very welcome :)
What exactly are you trying do by having a client/server app? I think your best bet would be to have one app that posts and gets info to your own webserver (not an app). Therefore, that one app can act as a server by "publishing" information to the server and the other can act as a client by only reading from the server.
I recently created a web application with GWT. Then re-used most of the code to create a Swing version of the application that accesses a local database in offline mode. I am now implementing the 'online' mode of the application and want to access the same data as my GWT application.
Any ideas? Considered connecting directly to the MySQL server via SSL, but that's not working and doesn't seem as scalable. Should I use REST?
Any suggestions would be helpful.
To solve this problem in the past, we've used Jersey to create REST Web services which returns protocol buffers. The Swing app would then interact with the protocol buffers. The GWT app would ask for content type 'json' and receive protostuff objects in return. It worked quite well. That way, both apps can communicate with the server in the exact way.
Edit:
To allow your swing app to communicate with GWT-RPC, look at this blog article.