I wish to create a Cordova/Android app that will be called/executed from my server. Both devices are on the same intranet and connect via WiFi, therefore no cloud messaging required .
For another scenario I have done the opposite. i.e. Android calls, via Ajax, an application on a Raspberry Pi for door opening purposes but this time I want to call an Android application from a Raspberry Pi. Where do I start? Ajax? Socket Server? What is the recommended connection method?
I think that websockets are the way to go. Implementing such a real time application allows you to 'push' data from the server to connected clients.
This can be initiated by clients (like in a chat application) but also by the server based on whatever events.
Have a look at Primus as a possible implementation. It abstracts the functionality from the websockets layer. This way it is possible to work with different websocket implementations.
Related
I have an embedded device that exposes its functionalities via a RESTful Web service. I want to consume those Web services via my android device by connecting my mobile to the embedded device via Wifi? Is it possible to do so?
The possible use cases are transferring the control panel UI of the embedded device to the android and controlling it remotely. The UI is exposed as a REST endpoint.
If the chip you are using supports Wi-Fi Direct, you should search for its code yourself since I don't know about it really, but you can find documentation and examples of wifi direct here, and if it doesn't support it, there are two scenarios, one is that you want to make your android device a server and your chip a client, which leads you to use Nanohttpd in your android code to make a server, and the other one is to bring up a server on your chip and make your android device a client, which leads to using a library like loopj which saves lots of pain. so I guess that was all.
I'm looking for options for communication between an Android device - running a native app - and a website.
In basics, the Android device is just a sensor for movement, while the website is the receiving end and will process the sensor data. The website will then have to visualize this movement.
The goal is that this happens instantly and constantly, as the sensor data can easily reach up to 50 updates a second.
I'm looking for some proper options and possibly shared experiences for streaming this data as far as possible;
So far it has crossed my mind to;
Use techniques like Bluetooth, Wifi Direct or USB. Probably not
reachable from a website.
Use a Node.js server for a simple socket connection.
Use Google App Engine. The channel (java) client would be nice for
this, but it seems that the app engine can only be the transmitting end.
I would do this:
Webserver: node express + socket.io
Android device: use https://github.com/Gottox/socket.io-java-client to stream events to webserver.
Browser: uses socket.io client to get a live stream of events.
The node socket.io server just takes the sensor data and broadcasts it.
About socket.io:
Socket.io uses Websockets. However, if the client doesn't support Websockets, it falls back to long polling etc... to emulate Websockets. On top of that, it gives you a pub/sub framework which Websockets doesn't provide out of the box.
The new version of socket.io (available on github) uses engine.io to provide the websocket abstraction and then puts a pub/sub framework on top of that.
In appengine use a frontend to post data to it, no need for 2way channel. If you really want 2way use sockets.
I have to develop a chatting application and I want to use socket connection. is there a way in android for it. Which will be better way for long time application.
Give me suggestion about it.
Have you looked at the Sockets class? You can use sockets to write and read data between two clients in background threads that update the UI thread with the data received/sent.
Generally with sockets one device (the client) connects to another (the server) and it is expected that the server's hostname will not change. However, you can't guarantee this with devices on mobile networks so a better approach might be to have two devices connect to a well known server that relays chat messages through. If you're just trying to do a basic chat application between devices on the same LAN it would be fine to directly connect them however.
https://developer.android.com/reference/java/net/Socket.html
I'm planning to build an Android application.
In this app the users must be able to communicate each other when they are close (a priori fixed distance).
I think that the easiest way to implement this model is with a server-client architecture where every message goes from a client to the central server and then the server will forward the message to the target client.
CLIENT A ---M---> SERVER ---M---> CLIENT B
But this way the the system doesn't scale and, in a scenario with a lot of Clients, the Server will become the bottleneck.
I'd like to ask what are the alternatives (on Android) to allow two smartphones to communicate and exchange message in a bidirectional way when they are close to each other.
CLIENT A ---> CLIENT B CLIENT C ---> CLIENT D
CLIENT A <--- CLIENT B
For example, is it possible, assuming a distance small enough, a solution based on Bluetooth? Or it is possible open a TCP/UDP socket between the two devices?
You could use NFC (if the device has it) to pair the devices via Bluetooth or WiFi Direct. If you don't have NFC, simple Bluetooth pairing without it should still work, NFC just makes it convenient.
I have used this server solution, and it's pretty awesome: http://www.rabbitmq.com/
RabbitMQ is a messaging service with a pretty awesome interface for Android.
I can't speak as to how you would implement either bluetooth or TCP/UDP.
I'm building a multi-OS mirroring system which I would like to implement using a hybrid client-server and p2p communication method (at least that's the best way I have of describing it).
My issue is that at some point I have a central server (appengine, so there are limitations to what I could do because of time and networking capability constraints) that would need to get a message to a host of different devices which are not necessarily running the same OS (Windows, Android, iOS, Linux, etc...).
Android and iOS (or any other mobile platform) are the main problems it looks like I will be having on 2 levels.
1 - They are both limited by battery power (more so than a laptop and desktops shouldn't have that issue at all), so whichever method I use needs to take that into account.
2 - NAT (harder because the user has relatively less control over their firewall than on a network that they are running). My central server will maintain a table of which device has what IP address, but from what I understand if there is NAT or a firewall it won't be able to get to it if the port was not forwarded.
Since I will be writing a specific client for each OS I prefer a solution that is more universal. I have been leaning towards writing an extremely simple HTTP server that sits on each client and takes requests (which appengine is able to send) and treats them as messages that alert the client to perform an action (either with the server or another client). However, I run into the issue of NAT/firewall. For instance if appengine needs to send a message to AndroidDevice1 it would grab its IP address from a table and make a request to it. However this doesn't work if the ports aren't forwarded correctly, and if the user is on 3g/4g the firewall is controlled by the data provider.
Because of this, I started thinking about using Android C2DM but I want a solution I could implement across platforms.
The only other method I could think of is to just have the client poll the server for messages. This has the battery and network consumption issue though.
Would there be any other way to implement this, and if not, which one of the above methods are best in terms of balancing usability, power and data consumption and user input (the less the user has to do to get the client set up (ie port forwarding, etc...) the better)? Please note that I do not intend for this to become a discussion/flame war but a logical presentation of facts.
Thanks in advance!
You can create a persistent TCP connection from the device to the server and then communicate over this open connection. This would be a very simple connection with keepalive packets for the most part.
In theory this would consume some battery through the radio, but in practice I have experienced that the battery is not affected much at all. Key is to keep the communication over this line to a minimum.
If AppEngine does not allow this approach, you can run your own socket server and then communicate between this server and the appengine server using REST. A socket server I have used is Apache MINA and had no issues with scalability.
Another problem you will have with this approach or any other approach is that on iOS (afaik) you cannot keep a tcp socket open when the App goes into background. The only thing to communicate with the iOS device is Apple Push Notification Service
I would prefer rather than having HTTP Connection you should create TCP/IP tunnel and make communication fast and reliable. I have one Chat application which runs perfact for me using TCP/IP. If you use this you will have same logic for multiple platforms. Only thing you need to write is different code for iOS and android.