I'm developing a chat application in Java.
The architecture used is Server - Client(s) architecture.
The majority of the code is in Java, JavaFX for the GUI and PostgreSQL as the Database.
As this is a chat application (desktop), I'd like to know which is the best way to store chat history:
Locally in a text file, that the client has to read every-time
In the database as of type String (VarChar)
In the server as Lists
Some questions based on the three ways:
If a client connects from a different machine the text file will not be there
Is it possible to store every text entry in the database with a chatroomID?
How many objects can be stored in the server for as long as it runs?
Out of your three choices, I recommend you choose option #2 for storing chat history: A database, and here is why:
If you store the chat history locally in a text file, you run into issues such as how to sync with others. Also, you can modify the contents of the text file without going through your Java program (such as with an editor). If this file contains chats with sensitive information and someone has access to your computer, they can read it. This spells trouble.
Storing in a database is a great idea because it provides a central location for all your Java program. This is especially handy if multiple people are using your Java client, that way they can fetch chat history, as well as easily transfer chats to others! I wouldn't only use a type String (VarChar), but try to think of some other useful fields or columns that might be useful (i.e. timeSent, chatUserID, timeRead, etc). This also brings up the point that by using a database, you are able to set up some sort of user access rights (username and password) so that specific people can read specific chats.
If you store the chats on the server as a list within the Java server itself, and if your server restarts, you lose all your chat history. Bummer.
To sum up, keeping your Java client-server-database architecture is perfectly fine, and technically all 3 options could work, but databases is the way to go for storing your chat history! Even if setting up the database takes a little bit of work, it proves to be superior in efficiency and security out of the other 2 methods described since databases are built for archiving data.
I'm in a similar situation, I'm also developing a chat from 0, the only difference is that I'm doing it for iOS.
The way I'm developing my chat is:
I use an Ubuntu web server.
The server has a database in Mysql and the communication with the user is done through NodeJS.
In NodeJS I have a socket "Socket.io" which facilitates notifications between users.
On the iOS device, I store all the messages that it receives in Core Data, which is an extension of SQLite.
In order to obtain the pending messages depending on the device where the user is connected and I use an ID for each device, this ID is created and identified by the MAC physical address and thus what messages to obtain from the server and what not.
Initially I base myself on this database to know how to structure my application: https://github.com/yoosuf/Messenger
Socket.IO is incredibly easy to use and the best thing is that it has libraries for different programming languages, here is its page:
https://socket.io/
https://github.com/socketio/socket.io
I would say Nr2 - for safety reasons (if you care about it) and because it is a pretty easy way.
For the beginning a database with 4 columns should be enough (Date/Time, ChatroomID, UserID or just a name and the message itself). If a user sends a new message it creates a new row containing all the information that is needed for the columns. You can easily iterate through it as well when your client reloads (maybe every 10 seconds)
Related
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).
I’ve planned to develop an application to control connected object, these objects are using the MQTT protocol. The application will be developed in JAVA (with paho library for the MQTT part). I use HiveMQ as a broker with a mysql plugin to store the published values for history purpose.
My goal is to create an application which will allow the user to manipulate those connected objects such as turn off a specific light, every lights in a room or in the house, etc …
But also to create some routine which will allow automation some actions such as turn on the heat when the temperature is down to 18°C, etc …
But I’m facing some difficulties :
When I connect with the client application, I would like to load the connected objects to prevent from using the disconnected objects, how to do so ? I thought about create a xml file which will be modified every connection or disconnection of an object. That file will be sent when the client connects.
How to manage routines (scripts) on the server ?
I’m open to every ideas, suggestions, etc …
Thanks a lot
Couple of suggestions
Use the Last Will and Testament and retained messages to alert when
objects go offline
(http://www.hivemq.com/mqtt-essentials-part-9-last-will-and-testament/)
couple of options here:
Have a look at using something like node-red (http://nodered.org) to
allow users to build "flows" that allow rules/actions to fire based
on values.
Look at the BSF (https://commons.apache.org/proper/commons-bsf/) to
allow users to write scripts
I am developing an Android application where users will see lists of Groups and join 1-* Groups. Within the Groups will be members and users can message each other within the group they have joined. Sending messages 1 person to many and reply all.
I want this to support multiple devices. So, if i join a group and someone sends me a message, i want to see that message on my phone and tablet. If both have the app installed.
I want the user to be able to see group details while offline.
I have been doing some research and drawing diagrams on how this could work.
What are my options for how to set this up with a remote database?
Here are a couple of the options that i have finally narrowed down to.
Have the remote DB store everything. Have a local DB on the device that reflects the remote DB. Have the remote DB contain a version number. At some point, either scheduled or triggered, the app compares the version numbers in the local and remote and if the local is out of date it will update to the current remote DB.
Have the remote DB store everything. Have a local DB on the device that reflects everything in the remote DB except the messaging system. This would behave similar to #1. Except the tables and stuff that are related to the messaging system would "somehow, gcm maybe" send a message to all devices associated with the user that a message relating to the user has changed and the app will then update to the most recent version of the remote messaging tables in the remote database. Then their local database contains the new data and their "message box" would be updated.
What would be the best way to do this? How is this done currently in most systems? Are there more options then what i listed?
Remote DB: MySql
Local DB: sqlite
I am aware of some similar questions here on SO, but i am wanting to know if either of these options or something else would be best for my specific scenario. Mainly how to handle the messaging part.
Thanks
I think Option 1 is a pretty standard way of handling this problem.
A DB version # could work, but if it changes frequently you will end up resync all the data very often. Its probably better if you just store "Last Modified Date" on records and only pull down things that have changed since the last sync. That way you can return a smaller set of new records.
You would only want to pull down public information (the groups) and the information specific to the user. The remote DB would have everything, but the local DB would only consist of data that is related to the user.
I found this tutorial that walks through how this might be implemented using php on the remote server for API access. You could streamline this process by using an ORM or "Out of the Box" API solution.
I'm sure there are more elegant solutions out there for syncing a local Android DB with a remote but this is likely the most practical approach for the non-enterprise solutions.
I am new to Java and Android. I am just beginning work on an app that will save information to a server that someone else from within the same company can retrieve using the same app from a different android device. I know how to simply store data on a server using simple php scripts but this is a bit more complex and involves one user writing information to the server, while another user can see / download it. Within a company there would be multiple users who have acceess to this data. So my question would be, whats the best way to implement a company-wide database that ONLY members of the same company can have access to? Sorry if this seems obvious to some of you. I am just getting started and I have 7 books on android programming and none of them describe how to do quite what I am trying to do.
To do this you need to use Android network services to access data. In other words to retrieve a networked database information your device will connect to your service with a specified URL and arguments. In turn, the service will reply with the required data, say may be in XML format. All your app needs to do is parse the XMl and display the date as desired.
Same thing applies to putting data into the server, in this case however the data will be sent as arguments to the network service URL and the service will handle the persistence to a database.
My advise is to do a Google search of the keyword "Android Network Services".
I am writing a simple turn game in Android for two players. I already developed an offline version (when two persons exchange the phone) and now want to create an on-line one.
They way I wanted to do it was to use Tomcat or my own PHP server for my website. My question would be whether it is possible and how to store data?
I think that the only thing I need to send to the server is the current score and an array representing the board. Then I'll be able to retrieve these pieces of information on client's side. Am I thinking properly?
I gotta say, I am completely new to all this stuff. I talked to my friend who programs in Java and he told me that I should use Tomcat. But how? It is a local server so the only way it could work would be when two mobile phones are connected to the same network or what?
The simplest way would be to implement a set of RESTful services on an online server.
You can use Tomcat if you want, but the cheapest approach would be to have a simple web hosting with i.e. PHP.
Create REST API's like /get/board, /get/move, /update/move, /authenticated and so on.
The simplest way to start out is probably not even with any real service, but just a couple of PHP scripts and an MySQL database.
You'll need some server, per example just a simple FTP server where you can put some on-the-internet reachable scripts on, and host the (MySQL) database.
Then per example for keeping the score you'll just need 2 scripts : 1 that saves and 1 that retrieves the score of a player.
Saving the score will just demand you to call on a link as per example:
www.server.com/saveScore.php?playerId=111&score=60
In the PHP you could just take this out with $_GET['playerId'] and $_GET['score'] and save those values in to your database with a query.
Returning the score to your app could work out with calling a link as:
www.server.com/retrieveScore.php?playerId=111
Which will simply query your database for the info on that player, and then print it as XML or JSON.
Then your app can just parse the response (xml/json) again.
A good idea would be to move this from $_GET to $_POST (POST is not visible in the link, but you'll need a bit more complicated code to transmit the data through that) once it works.
Once you've got that going you can work on actually building a service, REST would be a good choice, in order to increase maintainability, extendability and security.