I'm working on an shopping list app where all the family can connect to the same list.
How can i make and save the list on one device and then connect from all the devices to the list?
What you need is the concept of Websockets.
WebSockets represent a long awaited evolution in client/server web technology. They allow a long-held single TCP socket connection to be established between the client and server which allows for bi-directional, full duplex, messages to be instantly distributed with little overhead resulting in a very low latency connection.
Thats means if you create a server with a web socket connection, and you allow other clients(android) to connect to that connection. You can send messages back and forth and every device connected will recieve it. All connected is how i like to call it. Think socket.io and node.js.
You can't fetch the device data without having a medium or network in between them and if you choose Bluetooth or wifi then your data will be local and other family member living another city won't be able to contribute. so at last if i'm guessing right you need a synchronised database which can give you realtime updates from another user.
This is where Firebase Realtime database comes in. you can use it in your project, it's easy and takes few minutes to configure.
since all the user will have their own app they can contribute to same database and others can see it instantly.
Read the docs here for android
Related
I have an android app that connects to a computer version of the app. The computer version stores a list of people in the wait line. It is pretty much a wait line manager. New people come in the peopleInLine variable grows in one, people go out peopleInLine decreases in one.
My goal is to update all users of the app whenever peopleInLine changes.
Only the people who are connected to the computer version in the moment receive the updates.
I thought of:
Adding a peopleInLine field in a database and the computer version updates it when peopleInLine changes. The clients go and check the peopleInLine field every second to see if anything changed.
Or
Keep the connection between the clients and server(I'm using sockets) and whenever peopleInLine changes the server sends it through the socket.
The problem is that the server will be in a computer that will be in a store managed by the store employees. I think the second solution can put a lot of pressure in the computer assuming millions of people are connected at the same time.
The best way to maintain the sync between the clients and the server is using sockets. You can join all clients to a multicast address, and when the server changes state it sends the message to the multicast address and all your clients will receive it.
If you don't want to use sockets you can implement a REST API in the server and run a thread on the clients to periodically (lets say 10 seconds) check if the server changed. (This is a very naive solution)
Other solution would be to use another service to notify the apps that the server status changed. (e.g. Google Firebase)
Good luck
I see that there's an onDisconnect() firebase method, however it looks like that method is intended to update other client devices that the current client device has gone offline. For me this isn't very useful. All of our API calls are coming from a central server which handles updates to our other client devices.
Basically, I only have 1 client device communicating with the firebase server... ever. So my question is, when that single device loses connection how will I know? This is probably the most frustrating part of all, Not only do I not know when I lose connection, but I'm still making calls as if each command is successful.
Offline Behavior
Every client sharing a Firebase maintains its own internal version of any active data. When data is updated or saved, it is written to this local version of the Firebase. The Firebase client then synchronizes that data with the Firebase servers and with other clients on a 'best-effort' basis.
As a result, all writes to Firebase will trigger local events immediately, before any data has even been written to the server. This means the app will remain responsive regardless of network latency or Internet connectivity.
Once connectivity is reestablished, we'll receive the appropriate set of events so that the client "catches up" with the current server state, without having to write any custom code.
Take a look at Detecting Connection State in the Firebase Guide. It describes the magic data location /.info/connected that you can monitor for changes in the client's authentication state.
Note: For version 3.0+ see onDisconnect
when building a server, one sometimes performs asynchronous tasks from client to server (which responds to client in asynchronous time),
or the server needs to send the client a message
now if the client is listening at all times (meaning polling) it takes a lot of resources which is problematic
here is where I assume the operating system steps in and assumes the role of polling for the appropriate port, and letting the application know using the appropriate event (the application subscribes using the OS API)
am I right in my assumptions?
how do I subscribe to a port using the OS's API? (lets say android for the sake of argument)
how is a message from server to client work exactly?
and how does the server know the client's IP at all times?
I have seen many questions in the subject, but wasn't able to figure out the big picture
Edit:
I am using GCM in android, but have seen other apps that does not use it and still manage to do it right, also it's a more general question as to what is the right approach in java VS. any operating system it uses (ubnutu, windows, android, etc.)
Totally right - polling is typically a waste of resources. Until recently, many apps would either keep a socket open and poll every few minutes to keep it alive, or make periodic HTTP calls to a server.
Nowadays, Google Cloud Messaging is used by most apps to push data instead of constantly polling. As you correctly guessed, this is implemented by maintaining a persistent connection with Google's servers. The advantage of this is that it's very efficient for battery life, and that all apps can use this one resource to send push notifications, instead of each app having to poll a different server or create its own persistent connection.
The idea is that you send requests to GCM from your server (this can be in response to user activity, etc), which sends it to all of the client's devices. You can either send a message with a small payload (up to 4kb) or a "send-to-sync" message, which tells an app to contact the server (e.g. to sync new data from the server after user changes).
here is where I assume the operating system steps in and assumes the role of polling for the appropriate port, and letting the application know using the appropriate event (the application subscribes using the OS API)
GCM pushes messages to clients, so there isn't active waiting like you'd see in a simple polling system.
how is a message from server to client work exactly? and how does the server know the client's IP at all times?
There's no need for servers to know the client IP, as any online android device will typically maintain a connection with GCM. Targeting specific users is done via User Notifications.
(Oh, and I realize that your question is more general than just Android, which I have more experience in, but iOS has a similar system in place. Some developers I've met like to use Parse for managing push notifications).
I have several PC's on each of them I set small swing application that get data with JSON request to one web server. Can I receive the data from web server without to send request to the web server, with other words can the Web server send the data without the Java application to ask for this?
If you have enough server resources
you can consider usage of websockets.
Every PC can open a socket to the server.
When you open the socket you need to send to the server, the pc's unique ID.
Then you need to store this ID in some database or file that will contain all online pc's and sockets .
Then the Server will be aware which pc's are online and which socket to use to communicate with this pc. After this you can send whatever information you need to this PC depending on your application.
This can be implemented in several ways. One common way would be to open a connection and do blocking read in the client application. On receiving something it will look like push from the server. Then you process the push and do another blocking read.
Another option would be doing regular checks if there is something for you on the web server. You set the retry interval frequent enough so it will look like real time push from your app point of view.
If you use HTTP i think the smartest way is to drop the realtime requirement and use a thread that polls the server every 5 seconds. Keeping a HTTP Connection open all time is expensive as it blocks a request processor thread and limits the amount of clients you can have.
You might also consider moving to something like a registration mechanism if you really need near-realtime updates which is often not the case. You would have to open a Server on the clients and have the server push the updates after clients registered their Address with the server.
Is that possible to create a LAN messenger ( with user verification ) without a central server..?
I want to use JAVA for the messenger and with the facility of video conference. The main problem I faced is that how/where will I save user's data.
If by without a server you mean without any central computer then yes you can (with any computer listening and dynamically taking server role or something like everyone is server and client simultanously). It could work like p2p.
You could also use brodcast messages to achieve that. User authentication is the issue, but you can store user id's and hashed passwords on each machine (and syncronizing it as often as possible)
I've implemented it some years ago: basically I do a listen on an UDP port for each time a user open his client (I've done that by a separate thread) that accept a particular type of pkt that define username, user ip and so on...
In that way i have a kind of p2p mechanism.
User auth is achived by store user's password in a crypted way (sha5 and so on..)
You can save data locally on each machine.
You can try to use some DHT as an underlying system. It should be able handle all communications between the network nodes as well as distributed data storage.
A new node can join if it knows at least one node that is already in the network. And a node can send a message to some other node if it knows its ip or dns name.
P.S.: If you're interested in the idea you may took a look on Open Chord. Its only drawback is that there's no persistence, i.e. it doesn't store the data anywhere except the RAM, so you'll need to add your own persistence.
P.P.S.: you may event create new skype but without a central server at all