Most basic messaging system for sending simple text messages

Question

0.00/5 (No votes)

See more:

As part of a project I am working on, what would you consider to be the most basic framework for sending and receiving simple text messages in a Windows Forms application.

What I am planning on implementing is to use a single table in a MySql DB, write both Sent and Received messages to the table. Remember, it is simple text messages with a length of no more than 150 characters.

I make use of 2 columns to differentiate between Sender and Recipient. When fetching "my" messages, of course here I look at both the Sender and Recipient columns for my usrID. From there I can then separate the messages between my Sent messages and Received messages.

What pitfalls do you for see, how would you approach this or how would you improve on it.

Remember: Simple Text messages only.

Regards,
T

PS: In case you are wondering why I bother of reinventing the basic wheel and not use existing applications (Email or Skype, etc)... I work in an environment where a single user can have up to 8 - 10 applications open just to be able to do their normal work. In some cases there are users using up to 12 applications. I am working on reducing that by at least 5 applications through my project.

What I have tried:

As explained above in detail as can be seen by my question. (30 characters are a lot to type)

Posted 12-Nov-18 4:41am

Tino Fourie

Updated 17-Nov-18 14:01pm

Add a Solution

3 solutions

Solution 3

Your initial solution seems viable.  I would add a timestamp column to allow selecting messages.  The simplest implementation (unless I am missing something) would be a table with five columns.

 MessageID
 MessageText
 SenderID
 ReceiverID
 TimeStamp

If not using a notification system, polling for new messages could be done using a short time delay if the application is in the foreground (e.g., 3 seconds) and longer if not (e.g., 10 seconds).

Posted 17-Nov-18 14:01pm

W.G.C.

Comments

Tino Fourie 2-Feb-19 11:24am

Hi WGC, my apologies for the late reply.

I totally agree with you on your suggestion of implementing a timestamp field. In my approach I have such a field specifically used for the BackGroundWorker when retrieving messages. I have set the BackGroundWorker to fetch messages every 5 sec, which means that my MySQL Stores Procedure will only look for messages that is 5000ms younger than NOW().

Thanks for your reply.

Solution 2

I am no DB expert but I would be tempted to have three tables. One for the user, one for sent messages, and one for received. All messages are keyed on userid (one of the user columns), so tying them all together should be easy.

Posted 12-Nov-18 5:58am

Richard MacCutchan

Comments

Tino Fourie 12-Nov-18 13:01pm

Hi Richard MacCutchan, thanks you for your input.

Alas, I initially went with 2 tables: one for SentMsgs and the other for RecvMsgs. I reconsidered because it would make no sense to be honest because both tables would be a 100% duplicate of the other because they store the same data, except for the SenderId and the RecipientId.

You could argue that 10,000 msgs will take longer to process (relatively speaking ofc) than processing say 1,000 messages. That is a strong argument in an environment where you have no control over the age of messages. I am however considering to remove messages older than 21 days (3 weeks). Not sure how well received it will be.... but then again, use you email instead.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

MadMyche · Accepted Answer · 2018-11-12T05:57:00

Solution 1

It is not as complicated as you think; it is after all just simple INSERT and SELECT statements. The tricky part gets into implementation; particularly on the instant retrieval portions.
Some methods that have been done over the last 20 years is looping to "read" new messages on a timer, or to utilize COMET (aka reverse AJAX). With HTML5 you now have WebSockets as a decent update to this.

Up until 2015, Facebook Chat was based on the XMPP protocol, which is open source and API accessible. There are standalone server packages available and several mail servers have it built in (eg SmarterMail).

Posted 12-Nov-18 5:57am

MadMyche

Comments

Tino Fourie 12-Nov-18 12:55pm

Hi MadMyche, thank you for your input.
I use a BackgroundWorker to do the looping. I use Win Forms application, but don't want to bring HTML into it at the moment since WebBrowser is native to IE7 and you need to do a bit of work for force it to treat the HTML page for an earlier version of IE, e.g.: Edge, IE11, IE10, etc.

I just finished a section where I had to use StringBuilder to assemble an HTML page and then send it off to the WebBrowser control (I don't want to have the HTML page outside the application). You can probably imagine the effort it takes to build on the HTML inside of a Win Forms application.