I'm trying to build a task-manager application. Two or more client applications should be able to change (such as mark off or change the title etc) certain tasks stored in the database over the web.
While creating the requirements, the following question came up:
How is it possible to inform client applications (Android Apps, Java-Applications on a Mac) about changes in the database, without constantly checking the database? I planned on storing the data objects in a SQL-Database on a Webserver.
Should I use another database? What is the standard way to go right now in SE world? Any keywords for me or explanations would help!
Firstly, make sure you are not accessing the database directly from the client applications, that's a very dangerous route.
Secondly, as for your requirement it looks like you want a server side push notification.
As far as I know there are 3 ways to do this.
Check updates from the server every X seconds (if you don't have too many clients that needs to be notified this way is okay to go)
Use HTTP long polling.
Use WebSocket to keep a long lasting connection between server/client applications.
For mobile devices though, if you want to be notified even when the app is closed, take a look at all the push notification frameworks available out there (e.g. FCM/GCM).
Related
I was reading about background service limitation in Android 8 and from what I read it seems that you can't run your service in the background for a long time. This seems reasonable but because I use background service to keep connection to server - currently pooling new stuff, sending location and responses I am a bit confused. The responses are OK, I can respond only when interacting with the app, but the pooling new stuff is problematic because it needs to get an stuff from server and if something new come present the user with a notification to respond to it.
If I understand it correctly I can use JobScheduler to schedule some job every several seconds. I can basically schedule the pooling. For the background locations, well there are those restrictions so only foreground service is an option to get updates in requested time.
I will be migrating to websockets and then the pooling is off, the connection to server will be persistent and the app will get updates from server, I was planing to do this in the background service so something would receive stuff from server everytime. However it seems I can't since Android 8. How would you solve this? Should I use foreground service for location and server connection? Or is there a better way to do background networking in an android app on android 8?
Thanks
Here are a few options for performing background work on Android O:
Use JobScheduler. You already seem to have a good grasp on this one- the downside is that it is periodic, not persistent.
Use GCM/FCM or a similar push service to push data to your app when it is relevant instead of constantly holding a connection to your server.
Use a foreground service. This will allow you to continue performing your background work without your app being in the foreground, but will put a notification in the status bar to inform your user that you are doing that work.
Before you select one of these methods, you should take a moment to step back and look at the data that you need from your server and determine why you need a persistent connection and whether the first or second options might be sufficient.
If you absolutely need a persistent connection to your server, the last option is your best option. The idea behind the changes in O is to still allow background work such as what you are describing, but to make it painfully obvious to the user that your app is doing so. That way if they don't think your data is as important as you do, they can take action.
I have an Android App and a Server for maintenance. My App has a onetime registration process, where the user has to add a unique ID. And for this unique ID the user gets his data from the server. And the server gets this data from another Webservice.
App -> data request to App server -> request to other webservice -> repsonse from webservice to app server -> response from App server to App
Now this works for only ONE user, but now it has to work for more user or respectively for a endless amount of users. And I dont know exactly how to do this well.
Does it work with multithreading? That I create for each user a own thread? or how do I handle this that this works parallel and each user gets his data when he wants.
Can anyone give me some help?
Its server side problem, its nothing to do with android.
For this make sure that your sever code capable to handle multiple request at a time.
I suggest you look at netty. It is designed for flexibility and scalability and even if your write your own, you should understand how it works.
It can handle tens of thousands of connections and is a good start to writing a multi-threaded application efficiently.
In terms of how to write a multi-threaded application I suggest you read Java Concurrency in Practice. If you only read one Java book this year, make sure you have read this one.
I'm building an Android app in which I want to display some real time data (updated every second) which I want to stream directly from my server to the App. There will be multiple Apps connected at the same time, which should all get the same stream. I am now looking for a way to do this from both the server and the client/Android side. From the server side I can basically build anything, so I thought I'd start from the client side.
In the Android docs I found the inputStream class which I guess is what I need for this. So my first question: is the inputStream class the right tool for the job?
If so, I guess I can set it up (found some examples on the net), but from here I'm still unsure of how to build this service from the server side? Do I need to build a simple page which I constantly update, or should I use a messaging lib such as zeromq with multicasting? Any more tips/hints/pointers on which technology to use for the server side would be very welcome as well!
This depends on your data. For example if you need to keep your clients updated on some values, like weather data in a location, a simple polling mechanism will suffice. You would have to build a web page that shows the current values and the clients would have to keep polling and parsing the page in the time intervals desired.
On the other hand, if you've got a stream of binary data that need to be transferred to the client, you would need to do some socket programming. There are tons of samples like this to help you get started. Also keep in mind that to maintain your sockets with the server, you will have to keep them running in the background as a service.
Purpose:
I'm trying to make a real-time web service in Java. When there're changes in database, the data in clients(probably Android client) will be changed automatically without refreshing.
Platform:
I'm using Tomcat 7 container and Axis2.
Problems:
I'm stuck in the way to approach. I've realized that there were 2 ways:
1. When the data in server changes, notice to all the clients. Web-service allows us to do this, but I don't know what clients I have to inform!
2. Clients connect to the server, keep the connection alive and whenever there's a change, update data. However, if the client is the handheld, it will consume much power and data exchange over 3G network.
I know that's a complicated problem. So I just want to ask if there is an efficient way to approach? And if possible, anyone can give me one example of realtime web service like this?
I've searched over many pages, but nothing's helpful. Can anyone give me some suggestions? Tkx!
Is it a requirement to use webservices or Axis? Otherwise, you might be interested in WebSockets. These are connections over plain HTTP that provide two way communication. Your clients will connect to your server, and as soon as new data is available your server can push data to every connection it knows of, thus informing all clients that are connected.
I'm working on a browser game with the play framework, and I definitely need longpolling, but I don't quite understand how to use it. WebSockets would be perfect for this, but it's not supported by that many browsers yet.
Here's what I want to do: When the user logs in, and navigates to the play game controller, I want to start a connection, and keep it open. I want to do this for all users that are online, so I can show a list of them on the site, so they can play with each other. I've looked at the documentation, but I don't understand how I could implement it in my case. Because there simply isn't anything I want to calculate (in the example they're generating a pdf) I just want the connection to stay open.
What I'm also wondering is, how I should keep track of all these open connections? Right now, I just have an online column in my users table in the database, which I update. SO everytime someone connects I have to update the database. Are there better ways to do this, or is this fine?
And lastly, assuming all of the above works. When player A, selects player B to play with: how do I notify player B of this? Do I just send some JSON code, and change the page with javascript, on player B's side, or do I send him to a totally different page? I'm not sure how to communicate when the two connections are established and the game has started.
Firstly, I think you need to appreciate the difference between Websockets and Long Polling.
Websockets creates a connection and keeps it open until the browser terminates the session, via some javascript or the user moving on from the page. This would give you the desired nature of what you are requesting. Looking at the Chat example in the Play download will show you how an entire Chat application is handled using Websockets.
Further to Pere's answer regarding Play's statelessness. The Play creators have suggested that a single Websocket connection, regardless of how long it is open for and how many requests are sent back and forther, is considered to be a single transaction. Therefore, saving to the database in between each Websocket request is not needed (again, you can see that nothing is saved in the Chat example). Using this method, you would be expected to save the details when the Websocket is finally closed, or indeed all Websockets, depending on your use-case.
Long Polling on the other hand opens a connection to the server, and the server simply waits until there is something to send back to the client. If you need to push any data to the server, you would do this as a separate AJAX request, so you would effectively have two requests open at once. You don't necessarily know when a user logs off, unless you send a request just as they leave the page, to let the server know they have gone, but this is not always successful. Long Polling can work, but it is not as neat a solution as Websockets, but as you say, this is not widely supported yet.
My suggestion would be to study the Chat example (as it has a Long Polling and Websockets version). This will be the most effective way to get up and running with your requirements.
As for your final query regarding how to notify the other player. In Long Polling, you would simply respond to the suspended request with some JSON. With websockets, you would send an event back to the client. Again, both approaches can be pretty clearly figured out from the Chat example.
I have also written a Blog post on Websockets, which may help you understand this process a little better.
On the Websocket part, as you can see here (1st answer) the support is not so bad, and you have a Javascript fallback if there is some problem with the browser. This would simplify your scenario, as long polling may be more complicated to manage.
On the issue of keeping track, as Play is stateless you have to store the flag in the database and remove it when they close the connection. Otherwise you are breaking the statelessness.
About the notification, you have to send some message to B, but don't move them to another page as it may be confusing and cause bad user experience. Use Json to pop some message (in a div) alerting them of the game starting or the request to play.
I'm not using the "play" framework.
But I've been lately researching and tinkering with http-based long polling. Websockets, if available, is much more appropriate for realtime messages!
As for long-polling, I found that using a "cargo truck" analogy helped me reason about long-polling quite effectively. Here's a little note I wrote on the subject:
http://dvb.omino.com/blog/2011/http-comet-realtime-messages/
Perhaps you or future greppers may find it useful.
You might also want to take a look at the Juggernaut project which is based on node.js and Redis and gives you a "realtime connection between your servers and your client browsers". When using a Java Redis client like Jedis, you should easily be able to integrate the whole thing with the Play framework!