We are developing an app that will have Web service in JAVA and Application in iOS.
Web-service will compute the list on a Particular Algorithm and that list has to be Shown realtime on the Device.
We were thinking of making a Routine Post Calls on every minute and get result from server but I think this would be very Costly and inappropriate way for syncing data with the Web-service's Result.
Can anyone provide Best alternative and Ideal Way for such type of requirement. Which approach should we choose to Provide such Real-time Sync for application.
You can use a WebSocket connection for this. WebSocket establish a full duplex connection between iOS and your server. This allows the server to trigger the client if new data is available.
As you mention it doing a routine post call every minute could work, but it will cost a lot of resources. It's not a good solution.
One solution could be to use websocket. So the server will send notification when data have changed. See here what is websocket http://fr.wikipedia.org/wiki/WebSocket
Use netty-socketio java realtime framework, it supports long-polling and websocket transports. javascript, ios, android client libs also available.
After googling and research, I found Socket.io better option for Our case
Socket.IO is a WebSocket API created by Guillermo Rauch, CTO of LearnBoost and lead scientist of LearnBoost Labs.
Socket.IO will use feature detection to decide if the connection will be established with WebSocket, AJAX long polling, Flash, etc., making creating realtime apps that work everywhere a snap. Socket.IO also provides an API for Node.js which looks very much like the client side API.
Related
I'm developing an Android app that requires 2 (or more) devices to communicate with each other.
I tried using Google Cloud Messaging but I was disappointed to find out that the GCM max capacity is 100 messages, so it is broken and does not fit my requirements.
I was thinking about java sockets. Every device will open a new socket (or keep its socket open) and communicate with a group of sockets (devices).
In order to communicate this way I need a server-side app that can send messages to the client (android device). So I figured out that HTTP or web-service won't help me. Am I right?
What is the best way for me to implement such a server-side app?
You can refer to this question I previously asked and implemented. It was for implementing my own Notification mechanism but it equally (or even more) applies to chatting applications since message queues perfectly fit that usecase.
Building an Android notification server
I ended up not doing it and using GCM at the end but I did have a fully working solution using ActiveMQ and Paho. You can research them both and understand their inner workings. It's easy in principle and definitely possible but the problem is, you may not be able to do this for iOS or WP as it requires running a service in the background (in case your app is not open and you want to make sure the messages are at least sent in a notification).
The possible solution to that problem would be to use both the notification service (GCM or equivalent) for background notifications and then using your MQ for actual communication but I decided that was too much for my project.
If you look at Paho, it will have a fully working MQTT solution that will work even if the phone is not "online" (sleeping or otherwise) and there are plenty of samples for ActiveMQ and drivers for multiple programming languages.
I think this solution is much better than having open sockets between two apps, at least because they allow you to persist messages and guarantee delivery which is an important aspect for a chatting application.
As it is said by kha, choose one of the message queue protocols is the best solution. 3 reasons in brief,
Delivery guaranteed regardless of temporary offline or long latency.
As simple as subscribe / publish, no worry about transport layer any more.
Broker available online. You save time and money for setting up your own.
For mobile devices like in your case, I'd prioritize MQTT too. It's lightweight and stable. If you are totally new to message queue or MQTT, refer to this documentaion and example code
I am new to both Stack overflow and Google app engine.
in a Java Web application, how ddo I achieve COMET, are there limitations in terms of connection timeout or if that is not possible, can a websocket server be implemented on appengine ?
If you need server-to-client push, you have to use Channel API for GAE.
It not a COMET or WebSockets, technically, but it's same. And, I guess, I'll be functioning as a web sockets, sometimes in future (maybe it's already working, but i don't know where to get a browser that supports this feature, right now. Can anyone correct me there?). Btw, for you it'll be still same Channel API
I'm about to start a game project. It will be a network game with client-server architecture with Java server and a Web and Android clients. Impact is on low bandwidth (for use on mobile devices) and fast response. What technologies / libraries are out there for client-server communication? I am somehow experienced in web applications (GWT/Vaadin and servlets) but have no clue what to use when implementing a game server, mainly for the communication.
I am aware that I could use Java sockets with Object serialization or maybe JSON to pass the data from client to server, but I don't know how efficient in terms of bandwidth these approaches are? Or are there any more suited than these? Just pointing me in the right direction will suffice.
Thanks in advance!
As far as Android client libraries go, there's two main options. The first is just the java.net.* package in which you'll mainly use HttpUrlConnection.
The better option is to use the Apache HTTP package that also comes standard in the Android SDK. It gives you a lot more control / flexibility / verbosity in dealing with network connections.
Here is a decent example of how to use the Apache client libraries. I suggest using these, as the java.net packages are really only suited for the most basic of GET requests.
I suggest using the JSON method, because then you're not stuck having to write a Java servlet backend to deserialize the Java objects. The backend can then change independently of the client.
The main problem is, if you use WebTechnologies, than you can't implement an efficient way to realize the communication from Server to Client ...
Client to Server over HTTP GET works fine, but you must use some kind of Comet to realise the communication from server to client.
Thats why plain old tcp connection over socket would may be the better to communicate with a Client, especially with Android Client.
But implementing it with tcp socket work great with android, but not with a Browser.
My solution: implement the communication via WebSocket.
WebSockets (part of HTML5) is a HTTP extension to enable full duplex communication between client and server.
The most major web browser support WebSocket, like Firefox 4, Chrome 9, Opera 10.7
BUT NOT the Internet Explorer (support planned in IE 10, comming with Windows 8)
And for android, there exists also java libaries to implement the communication and i would excpect, that they work also well with android.
Expample:
http://code.google.com/p/weberknecht/
For the server side: Servlet API 3.0 support that, like Jetty 8
In my opinion WebSocket would save the problem, so you can implement a single server which supports WebSocket and communicate via WebSocket to an Android client as well as with a Browser Client (except Internet Explorer)
It depends on timeframe of your project. If time is enough – try in your hands and compare the technologies related to your purposes.
I have a Node.js app that uses HTTP / REST (using Express.js), and a native Android application that communicates with this. This works fine.
I am now looking at writing a more real-time version, which can push messages to a native client. Unfortunately, it needs to be a native client, as there is some fairly complex work done with the data that simply will not be possible in a mobile browser for the forseable future (otherwise I would just wait for WebSockets support to appear in the Android browser).
So, my question is what are my options?
I know about the Android Cloud to Device Messaging framework, but this requires registration and a Google sign-in, and I would much prefer the server to be client agnostic.
Is there a reliable WebSocket client that I can use (ideally) to talk to a Node.js server running Socket.io? Or any other native method (using the NIO classes)?
See Java socket.io client
you could use https://github.com/koush/android-websockets. It is also mentioned in the socket.io wiki pages
PS: i know it is a bit late to respond to this post, but this for other like me who didn't find an answer to question like this.
compile node.js on Android natively
implement jni wrapper of node.js
...
refer this link
https://github.com/paddybyers/anode/issues/15
I'm currently working on a project that is building a java-based desktop application to interface with a website. We want to incorporate IM capabilities, so we decided to use XMPP.
The problem is our application has other features, and anyone using another client to connect to our XMPP server will cause problems with our website (e.g. our client will be able to send our messages with a certain message type that the user won't be able to use, but with another client they could send those message types).
Is there anyone to either allow only our client to access the XMPP server or prevent other clients from using certain features? I know this is against the idea of open standards, but we don't want to build a proprietary IM solution from scratch.
You are building a proprietary solution, it just might not be completely from scratch, and that's not necessarily a bad thing. But please don't call it a XMPP service unless you are going to support XMPP clients. You will get the same reaction as you get with a "web site" that requires your proprietary browser.
For features that can be negotiated, look at Feature Negotiation and you might be able to get away with saying your server doesn't have a specific feature to other clients, but secretly supporting it in your own. That won't actually block something from being attempted, so it's pretty poor solution.
You can get instant messaging capabilities without building a desktop application (with all of the platform support headaches that entails). Consider Orbited which can give you the instant messaging interactivity your looking for and would make it much easier to integrate on the server.
And just as a side point, there shouldn't be any messages that cause problems with your web site, any more than there could be a URL that causes it problems, or a query combination, etc.
Not sure of all your requirements, but it sounds like you could probably use the pubsub or pep features of XMPP. These are extensions to XMPP that allow you to create specialized payloads that can be accessed on a user to user level (Personal Eventing Protocol XEP-0163). If it is simply a general notification to everyone who is interested, then PubSub (XEP-0060) may be what you want.
These protocols allow for securing access to the pubsub nodes and will not get affected by the standard chat messages, as they are a different protocol.