A mobile app I'm working on requires the server to communicate with it frequently over a short period of time, including real-time (or very close) things for the app to show (from other users).
It will be an iOS and Android app.
I was researching C2DM and on this page http://code.google.com/android/c2dm/quotas.html, at the bottom it recommends considering "implementing XMPP or your own protocol to exchange messages".
What I want to communicate between the server and the app does not fall easily into XMPP's usual chat roll, how would you go about actually implementing it?
Would it be a case of choosing appropriate XMPP libraries for the server and mobile app languages, then making a custom server (and client side)? Wouldn't this drain the battery on the phone? Can it be done over a RESTful architecture?
(If it helps, there are currently no decisions made for the server - other than it has to be highly scalable).
If what you want to communicate can be easily represented as XML and is not too large, then it can be easily done via XMPP. XMPP is very extensible. You will have to write the client side (to be expected) and use one of many available servers. Customization on the server usually means writing a component (generic and supported by the spec) or some sort of plugin (this will be server specific), but without more information I couldn't tell you if that would be required or not.
It is used for much more than just chat apps, although that would be the most common usage. Pretty much any text based instant messaging can be handled (as well as others). There are a huge number of extensions to the base protocol to support a wide variety of functionality.
Related
Is it possible / does it make sense to use an Android app as a "Producing client" for Apache Kafka?
Let's say my Android App need to capture and analyse reaction time data. Goal is to collect all data and show the average reaction time in real-time in the App.
The alternative is having an app server of some kind as an
intermediary that accepts messages from the android app and posts them to
Kafka, rather than having the app be a Kafka Producer on its own.
Even if it's possible, in my opinion it has some disadvantages.
In general I like clients to be as simple as possible to avoid maintenance issues. Instead I'd route all client requests through a REST API on my app server. The disadvantages are not related to Kafka, but are common problems of native clients.
Coupling
You're coupling the Android app closely to your messaging infrastructure. If you later decide that a Kafka solution is too much and Plain Old Java would be good enough, you'll first have to update the Android app and wait until enough users do an update.
Network issues + delivery guarantees
Kafka clients also require a direct connection to each of the brokers. Mobile clients can have very inconsistent/spotty network connectivity, making direct client access susceptible to dropped events and overall network connectivity issues.
Authentication
Probably you already have some kind of authentication in your app. You can also create authenticated connections to Kafka. So you'll have two authentication paths, whereas with an app server Kafka only needs to check if the requests are coming from the trusted app server, which means less implementation effort.
...
I think it would make lots of sense:
Kafka-clients.jar provide auto-reconnecting capability which is very useful when the phone is on a flaky internet connection
The Kafka-clients.jar is quite thin and does not include any of Kafka Server code (it doesn't even depend on Scala).
Unfortunately, it isn't compatible with Android just now: KAFKA-7025 . If you'd like to see this happen, please upvote the JIRA issue.
I believe that an Android Application can use a secured connection to a Kafka Broker cluster using SASL, for example. However, it must be done in coupling with any other communication, which can support synchronized keys rotation, which is initialized by any remote server with synchronization with the broker's cluster.
Any concrete instance of mobile application can listen to a concrete topic, and produce messages to a related topic, which is created when registering the instance using a REST server. Any deserializer verifies headers or Keys for a token, which are appointed using REST while registering on the same service. Custom encryption can be provided similarly.
Technically it is solvable. But what are the benefits, in front of using Firebase, for instance? Expenses I see from the start. Benefits???
I am making a chat application for android. For that, I decided to use GCM (Google Cloud Messaging). But having researched a bit about it,I have read that it shouldnt be used for something like chat.
I will be implementing Upstream messaging (sending data from the device to the GCM directly, without a send-to-sync). Here are my concerns:
Will the messages transfer instantly? (will be fast enough that the user can see 'typing'/seen)
If all devices are online, what is the guarantee of the message from GCM reaching the client.
The main reasons I want to use GCM is
GCM uses the least amount of battery life
This is an android-only app.
If GCM is not what I should use, what should I use?
I am working on a similar requirement and Looking at the requirement of being able to show feedback such as typing/lastseen etc, as per my knowledge XMPP based solution would be appropriate.
you can try with available xmpp server like ejabberd/mangooseim (open source) by installing it on your server and use asmack or any other client side java library to communicate it with your server. (There are lot of tutorials available for this).
With this much setup you will be able to get to the stage where you are able to get status such as "typing", "gone" which whatsapp and also some chat clients like gtalk/pidgin shows.
It would roughly give an idea of how existing chat clients work.
Ejabberd is completely written in erlang and if you want to extend any functionality erlang knowledge is must. (it is specifically designed for highly concurrent fault tolerant and non-stop systems, which was helpful in chat applications.
GCM would be definitely able to communicate between the android phones 99.99%of times with not much delay but if you want to have roasters status like normal chat applications, you will have to reinvent the wheel completely.
Update:
Here are the considerations.
from client A to client B I want to send chat messages with roasters and dont require to store messages on any central server but just on the clients - XMPP (like whatsapp)
in case you require all the communication to be stored in server - XMPP with sql driver or mongodb driver / gcm (Depending on your time and resources)
in case you require communication between devices not necessarily chat, then gcm should be sufficient.
I am using this approach in my app currently which is live on playstore with beta version and it absolutely works fine in most of the cases. I havent seen much of bottle necks as of now.
I'm creating a viber-like application, i.e. android users can make instant messages in their android-powered devices. I've created client-to-server webservices using ASP.NET (ASMX service with JSON response) and it works like a charm, but the other side, i.e. server-to-client requests is just a little headache. Of course I can make my application so that there is no need to server-to-cliend requests (sending dummy requests from client to server in short periods) but in this way server will be overloaded specially when number of users increases. I've found some technologies regarding instant messaging, including GCM and XMPP. What are my other options? or let me ask what is my best option?
Should I use sockets? If so, how can I always have my clients IP (considering that clients are mobile users which may be using WiFi or GPRS/3G/4G internet). I'm thinking of a system in which my clients send their IP each n seconds (n can be around 30), so server always has a (nearly) up-to-date list of client IPs.
Is it possible or even logical to do so?
You should definitely consider using GCM (Google Cloud Messaging for Android)
You need to setup a few things in your server to be able to use it to send via GCM.
Its the built-in way to send data from a server to an android device, hope this can help
Implementing GCM Server
Using the good old strategy of long-polling is always possible, but there are much better ways to do it nowadays. That's perhaps the fastest to implement of the mentioned (not so if you want to implement it correctly and with min amount of load on your server/DB engine). I've seen some projects that start around that architecture with the idea to move to something better in the future .... and the moment to move never comes of course. If you start browsing your Android phone connected to a proxy like Charles you'll see what I mean :)
WebSockets are an option, but I don't see a reason why I'd use them for a Viber-like app, which is event-based (you've received a message) and not "real-time" (monitoring some stock graphics movements for example).
Your best choice here is a Google Cloud Messaging (GCM)! It's easy to implement it both on your backend and on the client, and it's built specifically with the problematic connectivity in mind (switching between wifi/poor 3g/4g/etc). It has some pretty nice features that other methods don't provide "out of the box" - message resending (the common scenario of a client loosing his connection - GCM it'll send the push notification later, when he comes online), automatic syncing between devices (smartphone, tablet, etc) and others.
Is it possible / does it make sense to use an Android app as a "Producing client" for Apache Kafka?
Let's say my Android App need to capture and analyse reaction time data. Goal is to collect all data and show the average reaction time in real-time in the App.
The alternative is having an app server of some kind as an
intermediary that accepts messages from the android app and posts them to
Kafka, rather than having the app be a Kafka Producer on its own.
Even if it's possible, in my opinion it has some disadvantages.
In general I like clients to be as simple as possible to avoid maintenance issues. Instead I'd route all client requests through a REST API on my app server. The disadvantages are not related to Kafka, but are common problems of native clients.
Coupling
You're coupling the Android app closely to your messaging infrastructure. If you later decide that a Kafka solution is too much and Plain Old Java would be good enough, you'll first have to update the Android app and wait until enough users do an update.
Network issues + delivery guarantees
Kafka clients also require a direct connection to each of the brokers. Mobile clients can have very inconsistent/spotty network connectivity, making direct client access susceptible to dropped events and overall network connectivity issues.
Authentication
Probably you already have some kind of authentication in your app. You can also create authenticated connections to Kafka. So you'll have two authentication paths, whereas with an app server Kafka only needs to check if the requests are coming from the trusted app server, which means less implementation effort.
...
I think it would make lots of sense:
Kafka-clients.jar provide auto-reconnecting capability which is very useful when the phone is on a flaky internet connection
The Kafka-clients.jar is quite thin and does not include any of Kafka Server code (it doesn't even depend on Scala).
Unfortunately, it isn't compatible with Android just now: KAFKA-7025 . If you'd like to see this happen, please upvote the JIRA issue.
I believe that an Android Application can use a secured connection to a Kafka Broker cluster using SASL, for example. However, it must be done in coupling with any other communication, which can support synchronized keys rotation, which is initialized by any remote server with synchronization with the broker's cluster.
Any concrete instance of mobile application can listen to a concrete topic, and produce messages to a related topic, which is created when registering the instance using a REST server. Any deserializer verifies headers or Keys for a token, which are appointed using REST while registering on the same service. Custom encryption can be provided similarly.
Technically it is solvable. But what are the benefits, in front of using Firebase, for instance? Expenses I see from the start. Benefits???
I am an android developer and I made some board games. Now i want to make some of my board games multiplayer. I don't want to create and host my own web service, so i thought about P2P.
The first thing i found was the XMPP protocol, however it's not real P2P, but if i can use the existing google talk service, i'm ready to go. Is this possible while using your existing google account without interfering with the normal working of your google talk client?
Then i heard about JXTA, a real P2P solution, and it's already ported from J2ME to Android (http://code.google.com/p/peerdroid/).
Maybe i am overcomplexing things here (as i do sometimes)
I just want to know the easiest way to do simple P2P for a boardgame.
All your opinions are welcome! Thanks in advance
Kristof, Did you get an answer to your question? I've been working on a multi-player application recently as well, though I've chosen to host the server (originally). I'm now reconsidering my choice, though, but the library I'm using fully supports peer to peer communications. The underlying protocol is built on top of Google Protobuf. It's essentially a full duplex RPC stack built on top of Netty, which can use Protobuf. Here's the URL to the RPC protobuf stack: http://code.google.com/p/protobuf-rpc-pro/
The author has been very helpful and I've found a couple of bugs, nothing major. I also had very little issues getting these libraries working on my Android phone, but they're not terribly "compact." Nothing extraordinarily large, just not small :). So far, I've had no issues getting the communications working both synchronously and asynchronously. As such, I may be moving my game over to a "peer to peer" style, and just provide the necessary location/registration server that would be used to find existing games/server.
Using XMMP should be possible for you case. Look at smack from igniterealtime. They have a nice and active java api that helps to build you own jabber extension packets that can be used to transport the changes in game state.
I think that using two google talk clients at the same time with the same account could be difficult. But it would be great because you could invite all the friends from you list to play with you directly from your game. This way you could easily get more people to play your game.
You can't use the existing Google Talk Service/Connection from what we've seen. You should take Janusz's advice and check out the smack library, that's your best bet. To allow multiple non-interfering connections with the same GTalk login take a look at the resource component of the XMPP address, it's what allows you to be logged into two clients at the same time to the same account. You can effectively make your game another client. More here: http://code.google.com/appengine/docs/java/xmpp/overview.html#JIDs_and_Resources
Finally, there appears to be some new functionality in 2.2 relating to device push communication, but I haven't looked into it yet. 2.2 is not widely deployed yet either, so probably of limited use.
Basicly, if you want to write a multi user game or a game built on top of XMPP (Jabber), you should have a serious look at pubsub extension of XMPP. It's designed for pushing data from a server to clients, in the opposite way of HTTP. In HTTP the client has to pull information from the server all the time to be able to know when some new data is pushed. While XMPP is designed to push data to clients, when something happens. Less resources used on server and clients.
You should not use the Chat part of XMPP, as that will interfere with the users presence.
In pubsub you can create a tree of nodes, where clients can listen to any new data published in any node or subnod in the tree that the client subscribes to. So if some client publish data on one node, all clients that has subscribed to that node, or any parent, will be notified about this data.
The good part with XMPP is that it's extensible so you can extend the protocol with your own extensions. I also give you user authorization, authentification and encryption, and you don't need to debug that yourself.
You could use any XMPP-server with good support for pubsub or you can host one server yourself. There are plenty of servers usable for this. GTalk doesn't have support for PubSub last time I looked.