Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
My aim right now is just to make an Android app that has WhatsApp-like capabilities (not necessarily a clone of WhatsApp; just has similar, perhaps not-so-good features). What's important I guess is group chat, online/offline presence, as well as offline messaging.
Right now I'm aware mostly of the possibility of having a WebSocket server (because I was introduced to it as a real-time solution that could open me up to endless possibilities), and I've tested it before--it looks good. However, I'm facing the following issues:
I don't know how to manage online/offline presences; do I have to implement that myself? Perhaps the Android client querying the server every 30s if his friends are still connected...
How about offline messaging? If a particular person is not connected, the message will not be delivered to him. Does the message then need to be stored somewhere (say MSSQL), and then when the person logs in the client will automatically retrieve all offline messages from the server?
What about group chats? I'm unsure how WebSocket is able to acheive that, do I have to implement that separately as well? That would mean a lot of biz logic to work on (and a whole lot of room for bugs to appear)...
I'm aware there is a protocol called XMPP (and that it's totally different from WebSocket) but I'm not sure how it relates to my problem. Is XMPP my silver bullet (i.e. are there .NET libraries out there that implement most of it there for me?). I've also heard of Comet, but I don't know how it relates at all...
There are so many missing pieces, I thought implementing my chat server/client would be a piece of cake, but apparently not so. Anyone with a l'il experience can give me some feedback?
You can and should be using WebSocket for presence and instant messaging functionality. In fact, instant messaging is the "Hello world" example of the WebSocket world.
Also, the WebSocket standard was designed to support higher level, richer business protocols (which ironically the standard calls sub-protocols). XMPP is one of such protocols, and there are several implementations out there with the exact features you're looking for.
If you'd like to try it out, Kaazing (the company I work for) has a free download available. It contains an open source XMPP server (OpenFire), along with the XMPP edition of a pre-configured Kaazing WebSocket Gateway. What Kaazing does is it extends the XMPP protocol to Web clients over WebSocket. It does so transparently, so from the XMPP server's perspective your (browser) client is just another XMPP client.
Another good resource is chapter 4 of The Definitive Guide to HTML5 WebSocket (of which I'm a co-author), titled Building Instant Messaging and Chat over WebSocket with XMPP. The book also comes with a free downloadable VM with open source software pre-installed and configured for your testing. Here you can see detailed screencasts of the VM - to get an idea.
Hope this helps.
let's go per parts:
first: Do not use sockets. That means you will need to keep a service running and maintain a connection at all times on each client device. That will drain the battery like crazy and no one will use it. What every-single-one of those apps use including WhatsApp, Hangout, Gmail, Facebook messenger is the Google cloud messaging (GCM) http://developer.android.com/google/gcm/index.html service.
maybe you want can send those status change via GCM at the moment they happen, or once the user enters the friend-list screen you do a one-off query with the status, the important thing here is that you will not query every 30 seconds in a mobile device.
Yes, if the device is not connected your server have to do the stuff. And I don't believe you'll use SQL, what a lot of companies are doing nowadays is noSQL approaches due to scalability, but it's not my expertise.
I'm not sure what you're asking here. You're mixing how you're going to send the data with how your application will treat the data. Those are two completely separate things, learn the difference. Example, Someone could create a group chat that works over WiFi-Direct over UDP (that's HOW the data will be sent) but what u do with this data doesn't matter, it could have arrived over Bluetooth that will be the same for the parser/interpreter. It's just data.
Good luck.
Related
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.
This is an edit of a question I asked about a week ago.
I'm working on an Android app which communicates with the users' home PCs to control some 3rd-party PVR software running on the PCs. The model is as follows...
Android app < - wifi/3g -> Windows Service <- localhost -> 3rd-party PVR software
The Windows Service is written by me (C# .NET) and acts as a proxy between the Android app and the PVR software.
What I'd like to do is use C2DM to notify users of various things - one example is if one family member sets a TV show to record, a C2DM message is sent to other family members' devices so everybody is up to date.
I now seem to have 3 possible options for how to proceed. The Windows Service is a key player in the system so plays a part in them all but I don't know what the best approach is.
Use the Windows Service as the C2DM 3rd-party app server. Downside - I need to embed my C2DM credentials into the software and there will be potentially 100s of servers around the world requesting authentication tokens (not sure if Google would allow that).
I have a hosted web server I could use which allows PHP/MySQL. The Windows Server would simply act as a relay but my PHP experience is minimal and I can't find any comprehensive PHP examples for C2DM.
Use Google App Engine (again with the Windows Service as a relay). The problem is I don't know if Google are happy with GAE being used as a C2DM app server although I've seen a few mentions of it.
I've basically Google'd until my head hurts and keep coming back to the same tutorials and partial code examples. I know how C2DM works and actually have option 1 working in my dev environment but it doesn't seem like a good option to go public with.
So (trying to keep my question as objective as possible)...working on the principle that option 1 is not a good idea, are there any reasonably comprehensive PHP examples out there for a C2DM app server or, alternatively, does anyone know definitively if GAE is an acceptable approach?
With C2DM you can target the device that the message goes. So in you example the one that sets the TV show sends a message to the Windows Service to notify each one of the other users.
You can do that with 1 C2DM server
UPDATE
I whould go with the 3rd server.But of what i can tell you are not sure about the structure. Shared now GAE later maybe finally ec2. What can you actualy do is to create a CNAME that points to the server of choice.(less hard coded). I don't think that GAE cannot be used for C2DM. It's a simple server with http requests.
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.
I have developed a simple two player chess game in android to be played using Bluetooth. I want to extend it by making it possible to be played through internet. whenever a player makes a move, the move should be transferred to the other player via internet.
How to make this possible?
I have heard of C2DM mechanism.Does that suites the scenario i described and is it reliable?
Thanks:)
Yes, C2DM is ideally suited to this type of game. This is what I am using for my own game (http://www.chesspresso.net) which is a correspondence chess client for android.
Things to consider when using C2DM:
You don't send the info to the devices, you notify the devices that a move has been made. You don't use C2DM to transfer data, you use it to notify that something has changed.
Its available for 2.2+ Android, which is the majority of devices. But if you wanted to support older devices you'd have to consider an alternative. I am using polling for older devices.
You have to request for developer access, then once your app is ready you have to request production status. If you don't do this you'll hit the developer status quota very quickly once its released! They are very generous with production quota, but you have to explain what you're using it for and it also can take a few weeks to get accepted!
Your users will have to have a google account that is authorised, otherswise C2DM won't work. Most users will have an account associated with their device, but some don't so this means that you'll possibly want to validate for the presence of an account to notify the user.
Its reliable, but every now and again a device will have to wait for the message. Sometimes a few minutes. Usually its instant.
Hope that helps!
UPDATE:
C2DM has now been deprecated, and replaced by Google's GCM.
Also, I strongly suggest looking at other options as tying yourself down to a Google specific API means you won't be able to support external marketplaces. For alternatives, I am currently evaluating Amazon SNS and I will also be looking at Urban Airship. There are possibly other alternatives I have not considered evaluating yet.
UPDATE:
Evaluation update of non google based push notifications:
Amazon SNS is just not a project for this task and Urban Airship for the vast majority of apps is too expensive. Unfortunately all the other alternatives are all very expensive also, especially if your app (like mine) relies heavily on push.
A good way of doing that is using a simple direct TCP connection between the peers.
If you're new to socket programming on Java, try this:
All About Sockets
Another option is to use some sort of IM as a communication medium for app. For eg. Use Asmack to connect to XMPP Im like GTalk. Prompt user to create an account there, for your game.
And use it to send and receive commands via IM. This way you won't need to setup your mediating server.
This works if user knows who he is playing with. To collect the user data and let them search for available players, you still need to setup a server. IRC chat room may be an option to avoid this also.
GTalk was just an example. You can use any IM or IRC also.
C2DM it's not design to transfer informations, even if they are small like "horse in b4" or things like this. It's designed to inform the device of something, maybe a newer version of a document or more articles on a website.. Stuff like this.. It's not designed to communicate device to device. And also it may be not fast enough for a real time chess play.
You should look for a more traditional way of communicate via internet or to search for some libraries (I'm pretty sure that something exists..) that will help you.
IMHO, C2DM is exactly the kind of thing you would want for a chess game; to be notified when the oppo has made his turn (which may be minutes /hours / days later ?). I have discussed my game with a few google android devs and they've stated that C2DM is ideal for this. You'll need to go via a centralised server though (well, not essential but very advisable) as there may be issues with resync'ing game state etc. Worried about "hitting the limit" ? Well, for a start my c2dm acct is restricted to "just" 100,000 messages per day. I guess you're buying the drinks if you hit that !!
Chess is often played by email. You could do that.
Of course, any centralized/federated messaging system will work.
What might be better for your use is to add a jabber client to the application and have the program generate an account name that is used for automated messaging. You could host the jabber server or generate the accounts on a free provider.
Google App Engine if you know Python or Java.
Alternatively there are two web app API styles in wide use today: SOAP XML and RESTful web services.
If you know RoR I would recommend using JSON/REST, because you can just use Phusion Passenger with Apache to deploy your app. Free, extremely easy, and makes your server very reliable.
You could, and I only mention this because my friends do this all the time, use twitter as a server between the games.
I also found a lib called mages which looks quite promising.
Good luck.
I did this for my online 2D rpg: http://developingthedream.blogspot.com
Basically, use a middle-man server to co-ordinate data between all your clients.
You simply open a socket and communicate with the middle server and it takes care of passing on the information to any other connected clients.
I wouldn't recommend C2DM because of the message limit, and because the latency is still to big. Using your own server you can optimize it, plus you'll be the only one using the service so your data will be delivered faster.
I think that C2DM is not right way for playing chess because there is no warranty that messages will be delivered. You need more reliable way for data transfer
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.