What I'm trying to achieve is a connection between a users browser (logged in with his Google account) and an Android application on his phone (also logged in with the same Google account). I want to send a bunch of text formatted as JSON from GWT to the device and the other way round too.
My first thought was to send a C2DM ping to the Android devices and wake up a service witch connects to the App Engine server or the GWT client directly (if that's possible).
What I'm doing now is a socket with the Channel API from GWT to App Engine. And for a large amount of text I would just send a notification via the Channel to the GWT client, which then gets the data with a RPCall. Missing is the connection between the App Engine and the Android application. What I could do is C2DM for one direction and simple HTTP requests for the other direction. I don't like this solution, because C2DM can be really slow some times. Is there a solution to connect these two (GAE & Android app), or even a better without App Engine and a connection between the GWT client and the Android client directly ?
Thanks in advance :)
If I understand your question correctly, you're looking to push messages from a server (in your case GAE) to an Android app without using C2DM? In that case you can give pubnub a try.
Edit: of course you have a few options in this area (another one being Urban Airship) but you'll notice that they're not cheap!
I'm not sure what you mean by "a connection between GWT and Android directly" -- do you mean a connection between a GWT client and an Android phone? If so, there's not a good way to do that without installing client software; you'll need some sort of server to proxy messages.
So, given that you're using App Engine and GWT already, and C2DM is potentially too slow, you could wrap up an HTML page on the Android and use the Channel API. Then when you get messages, have your javascript client (again, running on Android) call the container to do anything you want.
This is nice because you have parity in the message delivery between your browser clients and your Android clients. It's not nice because it's not native and probably will eat battery, unlike C2DM.
Ideally I know you'd like a native API for Android to consume Channel API messages. You can vote for this issue but I unfortunately can't provide an ETA for it: http://code.google.com/p/googleappengine/issues/detail?id=4189
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.
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.
I have two android devices that runs a gcm client app. I get the Reg IDs of both the devices. I also have a server API key. Now the thing is, Using a simple php code using cUrl or Zend framework, I'm able to send message from a web server to one of my droids (Of course I can broadcast too). But, with this in hand, is there any way to send a string from one device to another?
Quoting myself from my book:
You might be tempted to use GCM for peer-to-peer messaging, without a server of
your own. In effect, each Android app is its own server, using the same JAR you
might use in a Web app inside your Android app to send messages to some other
party. For example, you could implement a chat system without having a dedicated
chat server.
The danger here is that this would require your API key to be embedded within
your Android application. Anyone with that API key is perfectly capable of forging
messages from you. The IP address restrictions you could place on that API key are
unlikely to help, since your legitimate uses might come from any IP address, not
just some single server. Since finding magic strings in APK files is not that difficult
for those with the inclination, putting your API key in your APK file is a dangerous
move.
Hence, you will want some server of your own as a middleman.
One thing you could do is to make a POST request to your web server with the message and the registration ID of the other Android device, but that would be a little cumbersome as you'd have to figure out a way to retrieve the registration IDs of the other Android devices from your web server.
I would recommend looking into XMPP as this protocol has been built from the ground up to be an extensive messaging protocol. I'm pretty sure you'll find good XMPP server frameworks to implement your functionality.
what is the best way to create a two way constant communication between a server and an android app?
When I say constant communication, I mean client asking server for data or server constantly pushing data to clients.
From what I saw, I can't use websockets since they are designer for server/browser setups. Is that right? If so, what is the alternative?
Is there free frameworks to work with this in Android?
What I am trying to do is an application that works like a chatting but for multiple people. So they all will get in one "room or channel" on their devices, and then interact with each other, in a way handdled by the server.
Thanks!
As far as I know , one possible way is using a web service where the client can connect to the server , if the web service is RESTFul there are many libraries to access it , one of them is the apache HTTPClient , for the server pushing the only way I know is C2DM for pushing data to clients.
For continuously-open data connection, you may use Sockets. But you should also consider the fact that an always-open connection will drain your battery quickly too. For more details, read this and this
You may want to look at AutobahnAndroid:
https://github.com/tavendo/AutobahnAndroid
which provides native Android/Java WebSocket client framework (plus WAMP = PubSub/RPC over WebSocket .. http://wamp.ws).
This is fully interoperable with WebSocket servers that server browser clients.
The AutobahnXX libraries (where XX = Python, JS, Android) are Open-Source (Apache 2.0). We (Tavendo) are offering a commercial virtual appliance based on Autobahn: http://autobahn.ws
Disclaimer: I am author of Autobahn and work for Tavendo.
But keeping the connection running on the background on iOS and Android devices does drain the battery, for people who have this issue, I suggest using push notifications when the app is not on the foreground.
From what I saw, I can't use websockets since they are designer for
server/browser setups. Is that right? If so, what is the alternative?
Websocket is an IETF/W3C protocol, so it is not confined to a specific client platform. You can use Android websocket to get a two-way communication between Android and server side. For Android websocket client, I recommend using AndroidAsync. It has all websocket API that you need to establish the communication link and exchange data between Android and the server.
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.