I've been studying App Engine for a work assignment which is to implement a chat service similar to Facebook's desktop page chatting. I had previously implemented something similar but since it ran on proprietary servers where there was no limit to traffic and technologies, I'm not sure that same implementation will work on App Engine.
Some things to notice:
This is for a web page/app. There is no specific messaging client application
App Engine doesn't support websockets
App Engine doesn't allow threads to outlive their requests (meaning I can't hold a background thread that awaits for new messages and pushes them to the user)
App Engine wants to service requests in a matter of seconds. I had thought of using long polling like facebook does but I'm not sure if this will be allowed
Is long polling every 30 seconds even an option? I'm afraid it massively increases my traffic costs...
I looked at XMPP but I think it doesn't really apply to web applications. Also I think I read somewhere in the docs that it is not/will not be supported anymore?
I'd like some advice on how I should go about this. I'm going to use Cloud Datastore for storage and I was hoping to implement this as a simple RESTful microservice to be honest but I'm not sure anymore.
You can merge goole app engine with google firebase to easily achieve a realtime chat application
you can access the realtime database on firebase using only javascript to update and display chats
Related
I'm building a website using springboot as RestAPI and angular in frontend. Also, i will be getting data in my rest(consumer) from around 40-50 swing standalone apps(producers) through kafka. I need to implement online status for those swing apps. Basically, i need to know when and which one of swing apps went offline or back online. Is there a way to implement this? If this is impossible with kafka can you recommend something else for communication?
Clarification:
By online status i mean whether device on which swing app is installed has internet connection or not.
Swing app will be installed on around 40-50 devices on remote locations.
Eventually i got rid of kafka and used websockets. Using WebSocketHandler i had information when certain standalone app is connected or disconnected. When standalone app looses internet connection server is notified relatively quickly (within 60 seconds). Keep in mind that in my case standalone app will be sending data quite often. If this is not the case for you then i recommend looking for some other solutions and taking a look at #OneCriketeer comment regarding Nagios.
I have a very basic design of my entire application, where several users with my app on there android devices commits data to the server (I have used REST web services(java) + postgresql as my server) through HTTP post request from the android application. I am successful in achieving this and app runs absolutely fine. Now i want to implement a scenario where any change(CRUD operations) on my db on server should create a notification on my users android device. How should i achieve this with my server design unchanged? I have looked into Google Cloud Messaging, but could figure out the server implementation.
For now i have implemented db triggers on postgresql and able to get control back into java code using Notify/Listen feature of postgresql. From here i need to connect to android device. How can this be achieved. Is Google Cloud Messaging the only way? I have not seen any insert/update statements in there server implementation. Could anyone please guide me on this?
either you can use GCM or implement a Socket at server end and open a socket connection from mobile but this approach may add some additional processing overhead because it will create a daemon thread to listen socket port from mobile device.
You should use native library (NotificationManager etc.), here you can find a great tutorial.
My Advice is for you to use GCM. GCM normally takes a maximum of 4kb, so you could have your own defined "commands". You could use them to determine the requests on both ends, ie on android app and the server end. A php script on the server would help you in this.
I am working on an app where by the android app sends messages to the server via POST and the server forwards the message to the appropriate user via GCM. In my case I have very many things to share so in that case I am using commands, for example if it is a new incoming message I send a GCM to the app with one variable as the command and the rest as the data. On the android app I use the command variable to determine what to do with the data.
Kindly avoid that socket advice, it will have your app drain the battery to sustain the open socket , besides you don't have to re-invent the wheel while Google servers already has it
We already have a quite complex mobile backend written in Java which is deployed and works fine, so we do not have any need to use the Google mobile backend. Now we have requirements for pushing some data from the back end to the phone. Earlier I used GCM regularly. Our first requirement is only simple messaging, but it may evolve to something like a pub sub (phones subscribing to topics).
The issue I am not understanding is should I now use GCM like before, and later develop my own pub/sub overlay, or can I use the products Google has developed for that? Is this even possible, since everything I am finding on Google pages is just related to communication between Android phones via their cloud storage, so no library for communication between a custom back end and a phone?
In short, what should I use, regular GCM or is there something Google is providing which I am not understanding?
You can use regular GCM. A custom back-end can send messages to an Android app via GCM. The library for sending messages from a 3rd party server to GCM still exists (com.google.android.gcm.server package in the Google Cloud Messaging for Android Library), but you don't have to use it - you can implement the HTTP POST requests yourself.
If I am developing an Android application, what is the most feasible way to get near real-time notifications about an incoming email? Is there a push-like mechanism, or can I hold my IMAP connection for a long time, or do I use IDLE command?
Consider that user is authorized to use GMail services via OAuth and I don't want to poll IMAP server madly.
Update:
I'm not using the phone's configured-in Google account. There is another account set up using OAuth.
I'm using Apache Commons Net to connect to IMAP/SMTP in my app. It's a bare-bone library for IMAP, but I can perhaps modify it to add IMAP commands/extensions.
You can register a ContentObserver with GMail, anytime something changes in GMail, the observer will be called.
contentResolver.registerContentObserver(Uri.parse("content://gmail-ls"), true, myContentObserver );
Override onChange in your ContentObserver to do stuff when something in GMail changes.
Since IMAP does natively provide any sort of push notifications and the Google extensions don't either, you have to implement it yourself.
One way is to use IDLE requests, which is still a cheap way to do polling. Of course, you can't expect your app to be running all the time, so you need to use a background service. An 'always-on' service is however an anti-pattern on Android and will drain the battery quickly and likely get you many 1-stars. Additionally the system may decide to kill it at any time. The other alternative is to use AlarmManager to start the service periodically, but starting it every couple of seconds or so is just as bad. So you are basically back to square one: polling.
The other way is to get push notifications using GCM or a similar service. This does require you to have a server, and the server needs to have the authentication info for the user (which might be a problem), but there are no real constraints concerning keeping open connections and sending IDLEs each second, etc. On the Android side, if you want to implement push yourself, you need to keep an open socket to get notifications. This is not very easy to do if you are not a system app (see above), so that leaves GCM. The connection it uses is manged by the system (Google Services framework), it can do things a regular app cannot, and you basically get it for free, since it's already there. It receives small pieces of data when there is something to do, called 'tickles'. Those in turn trigger broadcasts, Google Play updates, etc.
So, take your pick. Or just give up, register the account and use GMail and its labels Android API.
I'd check out Google Cloud Messaging (GCM):
http://developer.android.com/training/cloudsync/gcm.html
My understanding is that this works without requiring the user's Google account, and lets you handle authentication.
See a tutorial here:
http://www.techrepublic.com/blog/app-builder/implementing-googles-cloud-to-device-messaging/428
You would need additional server-side code running to do this though.
A friend and I are currently working on a turn-based game with chat with both desktop browser and Android clients, with Google App Engine as the server.
We're using the Java API for GAE and using HTTP for communication with the server. We've implemented simple chat functionality, and we're getting undesirable latencies 1-3 seconds from both the browser and Android clients while just posting simple one-word chat messages.
My friend thought it would be best to use XMPP instead of HTTP, but we want to use a Google Accounts cookie for authentication from the Android client, and according to the GAE documentation, XMPP clients cannot use a Google Accounts cookie and must use the user's password.
Does anyone have any suggestions as to where the latency might be coming from, how to troubleshoot it, and/or what to do about it?
Also, is anyone aware of any opensource implementations of chat (or something similar) on GAE done in Java? Can't seem to find any.
One way to analyze the situation would be to use Wireshark to look at the network traffic during the delays.
You don't say how your chat messages are getting from one JVM to the other. If you're using the datastore, maybe try memcache?
Also, startup time is often an issue; app engine starts and stops JVMs all the time, particularly for a low-traffic app. A way to diagnose this is to reload the page a bunch of times (send more messages) and see if it gets faster after a while. It should be pretty easy to tell the difference in the admin console logs.