We have implemented rabbitmq chat in android. but java client of rabbitmq is power hungry.is rabbitmq good for android chat?. we have used direct exchange individual queue for persons and individual routing keys. what is the best design pattern for one to one chat in rabbitmq.
and also ways to reduce battery usage
I don't think that use RabbitMQ directly for developing a chat is the better solution.
There are other solution more light please read this post about MQTT.
Another standard solution is use XMPP protocol (for example whatsup uses a custom XMPP).
We made some test and we also had some problem about battery consuming.
BTW, you can mix the technologies, mixing RabbitMQ as back-end and some other server (XMPP,MQTT) as front-end.
Read this post about the MQTT.
MQTT used by Facebook Messenger
EDIT
I would add this post MQTT vs. XMPP Which Should I Choose?
EDIT2
Please read also this and this on the official rabbitmq-group
Maybe you could combine RabbitMQ with GCM to save power as GCM gets triggered by the system and doesn´t need to keep any extra connection alive.
For example:
The app gets notified via GCM when any new event comes in.
Then a new Rabbit connection gets established, retrieving the data and timeouting after a short while again, if no messages are coming in again.
So the actual "hungryness" exists only for a short moment and only when neccessary.
You can also analyze which users are tending to always write multiple messages close behind one other and vary the timeout based on that value
I think chat applications for real time delivery is sending messages over network instantly rather than reliability. Reliability means confirm receiving against delivery. But in real time chat application does not make sure it. RabbitMQ is a message broker server and it is dedicated for reliability first, but it is not responsible for real time message communication. You may use RabbitMQ for real time communication but sometimes may not be in real time.
You can use STOMP-WebSocket(For simple messaging), Firebase(easy development for instant messaging), but most professional and usable protocol is XMPP(Extensible Messaging and Presence Protocol) for real time communication.
If you have any suggestion or query against this answer, let me comment bellow.
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.
What's the best way to send constantly updating data from a server (over a REST API or a socket) to an iOS or Android app? Should I create a socket connection and have a socket server that pumps out data, or should I have the app periodically poll a backend resource? Thanks!
Should I create a socket connection and have a socket server that
pumps out data
This is an option. I know some top apps on the play store that use web sockets for streaming data.
Have the app periodically poll a backend resource
I would recommend against this. Polling drains the battery. The android OS will keep the CPU in idle mode at times and constant polling can wake the CPU up and cause a drain in battery. Users wont like that. You are also wasting processing power when there are no results from the server.
The easiest way to send push notifications / minor updates to the android phone is via GCM. The GCM messages are delivered in near real-time (I noticed a lag of about a second for my apps). The payload is limited to 4k and the messages are stored for up to 4 weeks. This is another option you can consider based on your use case.
The typical model I follow is to hit the server on a specified interval and download the updated data.
Polling is bad, it drains out the battery
If you want to update the screen when the application is in the foreground, it is better to go with Socket Connection. You can see the changes in realtime.
For this, you need to create a socket server and open a connection between the device and the server.
https://www.raywenderlich.com/3437391-real-time-communication-with-streams-tutorial-for-ios
I would suggest to use MQTT protocol to publish and subscribe data. Libraries for iOS(Moscapsule) and Android(Paho) for integrating MQTT protocol are available and can easily be integrated in mobile apps.
Backend needs to be configured to support MQTT also. Detail information about how MQTT works can be found here.
I am going to paste my accepted answer from a similar question that was posted a few hours ago.
It can be done using sockets or polling the server but I wouldn't recommend either for a production level app. You will eventually need security features and as a frontend developer, it would be difficult to start from scratch.
I would suggest using a third party service. Take a look at Space Cloud. It is an open source alternative to Firebase where you can use your own database and has built in security features. If you want to go deeper, it uses Apache Kafka for realtime database features.
If those don't suit you then the best option would be to go with GCM.
should I have the app periodically poll a backend resource?
this must be the last option to put in consideration. as long as the client number increases you need to scale out backend/server and this is not as simple as putting an another server next to existing one.
the perfect solution will be a push oriented design and best approach will be to register clients to events and server will push clients if that specific events occur.
you need to be more specific about your business case. you had mentioned real-time in your question but what kind of real-time is that. is it a video streaming, chat application or just ordinary rest calls?
Typically, you'll want your server to push updates to the clients because polling is expensive, may not scale well with N number of clients, and will drain your phone batteries faster. Depending on your server technology:
.NET/Core:
May want to take a look at SignalR to push notifications from the backend to your client apps.
Java:
May want to take a look at Atmosphere to push notifications from the backend to your client apps.
I have used SignalR with good results publishing to phone clients. Have not used Atmosphere, but it has good reviews.
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.
I recently learned about the ability of iPhone apps to receive nearly instantaneous notifications to apps notifications to apps.
This is provided in the form of push notifications, a bespoke protocol which keeps an always on data connection to the iPhone and messages binary packets to the app, which pops up alerts incredibly quickly, between 0.5 - 5 seconds from server app send to phone app response time. This is sent as data - rather than SMS - in very very small packets charged as part of the data plan not as incoming messages.
I would like to know if, using Android, there is either a similar facility, or whether it's possible to implement something close to this using Android APIs. To clarify, I define similar as:
Not an SMS message, but some data driven solution
As real time as is possible
Is scalable, i.e., as the server part of a mobile app, I could notify thousands of app instances in seconds
I appreciate the app could be pull based, HTTP request/response style, but ideally I don't want to be polling that heavily just to check for notification; besides which it's like drip draining the data plan.
Firebase Cloud Messaging FCM FAQ is the new version of GCM. It inherits GCM’s core infrastructure to deliver messages reliably on Android, iOS and Chrome. However they'll continue to support GCM because lot of developers are using GCM SDKs today to handle notifications, and client app upgrade takes time.
As of June 26, 2012, Google Cloud Messaging is the preferred way of sending messages to applications running on devices.
Previously (and now deprecated), the service was called Cloud To Device Messaging.
XMPP is a good solution. I have used it for a push enabled, realtime, Android application. XMPP is powerful, highly extensible and easy to integrate and use.
There are loads of free XMPP servers (though out of courtesy you shouldn't abuse them) and there are open source servers you can run on one of your own boxes. OpenFire is an excellent choice.
The library you want isn't Smack as noted above, it's aSmack. But note, this is a build environment - you will have to build the library.
This is a calculation I did on battery life impact of an XMPP solution:
The Android client must maintain a persistent TCP connection by waking up periodically
to send a heartbeat to the XMPP server.
This clearly imposes a cost in terms of power usage. An estimate of this cost is
provided below:
Using a 1400mAh battery (as supplied in the Nexus One and HTC Desire)
An idle device, connected to an 3G network, uses approximately 5mA
The wake-up, heartbeat, sleep cycle occurs every 5 minutes, takes three seconds
to complete and uses 300mA
The cost in battery usage per hour is therefore:
36 seconds 300mA = 3mAh sending heartbeat
3600 seconds 5mA = 5mAh at idle
4:95 + 3 = 7:95mAh combined
A 1400mAh battery lasts approximately 11.6 days at idle and 7.3 days when
running the application, which represents an approximate 37% reduction in
battery life.
However, a reduction in battery life of 37% represents the absolute worst case
in practice given that devices are rarely completely idle.
I recently started playing with MQTT http://mqtt.org for Android as a way of doing what you're asking for (i.e. not SMS but data driven, almost immediate message delivery, scalable, not polling, etc.)
I have a blog post with background information on this in case it's helpful http://dalelane.co.uk/blog/?p=938
(Note: MQTT is an IBM technology, and I should point out that I work for IBM.)
Have a look at the Xtify platform. Looks like this is what they are doing,
Google is depreciating C2DM, but in its place their introducing GCM (Google Cloud Messaging) I dont think theirs any quota and its free! It does require Android 2.2+ though! http://developer.android.com/guide/google/gcm/index.html
If you can depend on the Google libraries being there for you target market, then you may want to piggy back on GTalk functionality (registering a resource on the existing username - the intercepting it the messages as they come in with a BroadcastReceiver).
If not, and I expect you can't, then you're into bundling your own versions of XMPP. This is a pain, but may be made easier if XMPP is bundled separately as a standalone library.
You may also consider PubSubHubub, but I have no idea the network usage of it. I believe it is built atop of XMPP.
I have been looking into this and PubSubHubBub recommended by jamesh is not an option. PubSubHubBub is intended for server to server communications
"I'm behind a NAT. Can I subscribe to a Hub? The hub can't connect to me."
/Anonymous
No, PSHB is a server-to-server
protocol. If you're behind NAT, you're
not really a server. While we've
kicked around ideas for optional PSHB
extensions to do hanging gets ("long
polling") and/or messagebox polling
for such clients, it's not in the core
spec. The core spec is
server-to-server only.
/Brad Fitzpatrick, San Francisco, CA
Source: http://moderator.appspot.com/#15/e=43e1a&t=426ac&f=b0c2d (direct link not possible)
I've come to the conclusion that the simplest method is to use Comet HTTP push. This is both a simple and well understood solution but it can also be re-used for web applications.
There is a new open-source effort to develop a Java library for push notifications on Android, using the Meteor comet server as a backend. You can check it out at the Deacon Project Blog. We need developers, so please spread the word!
Google recently(18May2016) announced that Firebase is now it's unified platform for mobile developers including near real time push notifications.It is also multi-platform :
The company now offers all Firebase users free and unlimited
notifications with support for iOS, Android and the Web.
source
I cannot find where I read it at, but I believe gmail utilizes an open TCP connection to do the e-mail push.
As GTalk is gone from the SDK, it might be a good idea to make a 'standard' push messaging system. That way, only one service has to run, only one extra tcp connection needs to be open. Applications should talk to this service using Intents and should first request permission to send and receive notification from the service. The service should then notify the user a new application wants to send and receive messages. The user will then grant or deny permission, so he stays in control. The application will then register an action + category to the service, so the service knows how to deliver the pushed message.
Would the a good idea or not?
Why dont you go with the XMPP implementation. right now there are so many public servers available including gtalk, jabber, citadel etc. For Android there is one SDK is also available named as SMACK. This we cant say a push notification but using the XMPP you can keep a connection open between client and server which will allow a two way communication. Means Android client and server both can communicate to each other. At present this will fulfill the need of Push in android. I have implemented a sample code and it really works great
I have recently developed http://pushdroid.org its a single application that should be installed on the phone just like google has implemented it in 2.2 this works from 1.5 and is broadcasting via intent.
The problem with GCM is that there is a lot of configuration involved in the process:
You have to add a lot of boilerplate to you Android app
You need to configure an external server to comunicate with the GCM server
You will have to write tests
If you like simple things (like me) you should try UrbanAirship. It is (IMHO) the easiest way to use GCM in your app without doing a lot of configuration. It also gives you a pretty GUI to test that your GCM messages are being delivered correctly.
You can find the docs and getting started guide here
You can find a sample application here
Note: I am not afiliated with UrbanAirship in any way
https://github.com/Guti/Google-Cloud-Messaging--Titanium-/blob/master/src/com/google/android/gcm/GCMRegistrar.java
Its reaily good and working solution for push.
Please try it
They have their listeners which has to be used by you by using their library classes in your code. You need not to bother about pushing. You have to send the message to server server will push the message to the device. They use OAuth. Regarding Protocols, there are two methods using CCS and XMPP. CCS just uses XMPP as an authenticated transport layer, so you can use most XMPP libraries to manage the connection. To send notifications to device you can write code in android app to send as well as your server code. the message sending will be done only by your code. Rest will be taken care by Google Server in GCM case. You can check detail at this link
http://developer.android.com/google/gcm/server.html
Also, for security issues
google cloud messaging security https://groups.google.com/forum/#!topic/android-gcm/M-EevBitbhQ
In case your app is not running then also devices can recieve notification because you have to write code for broadcast listeners. In background it will be listening to server and whenever any message packet will be there it will recieve the message as notification. Android has service you need to not to bother about it. You have only to use those resources using the library class that makes your work easier and let them write if your app is not running then also it recieve notification. Obviously, there would be some listener whick make the app to recieve.Check "Recieve the message" section in this link
http://developer.android.com/google/gcm/client.html
It will acccept request from users also. For GCM it will do. Please check "Send a message"
http://developer.android.com/google/gcm/client.html