Invalid validation variable for midlet
I am programming a game in j2me on client side that connects to a server written in java. This game will have a chat function, but as an additional function.
For every midlet that connects to the server, a server game thread is generated. These threads talk between them so that they can sync and write one by one to a series of configuration files on the server. Now, if a chat message is written in one of the midlets, it is passed to a client-side thread that manages the socket communication and is sent to the server. On the server, all other players of the same game are notified, and the chat message is sent to all of them. Thus, each server thread (but the one who sent the message initially) sends a message to its correspondent thread.
Here's my question. How can I signal each MIDlet to know a new message?
I was thinking about creating a thread that will poll the client side communication thread to see if there is a new message. But then how can I learn from the midlet without interrupting it halfway through? Ideally I would like to read a line that is in the client side communication stream, but that line can be written, so I need a stream to access and sync with it.
Can any of you give a hand? I really don't know how to do this and it seems like it should be pretty simple ...
early
Unfortunately, since mobile phones do not usually spend most of their lives connected to the Internet, the only available mechanism available is SMS / MMS via API PushRegistry
. The real problem with true push is that the server needs a way to identify the client and you cannot rely on the temporary IP address provided by your phone by the Mobile Network Operator.
If you plan on using an HTTP connection channel, you MUST poll the server to update chat messages. However, there are ways to make it less bad.
If your game is designed to send / receive data to / from the server on a regular basis anyway, you can bundle the chat data into your own protocol in the body of http requests and responses.
You can technically mix the two approaches using SMS push to trigger an HTTP lookup for data, but this can get expensive.
Regarding the correct use of the keyword synchronized
in your MIDlet Java code, I suggest you ask a more precise question with the sample code included, as this is a different domain of concern.
source to share
You almost never want a poll. Polling is a terrible waste of resources in almost every case. With the proposed design, you will have a context switch every time the polling thread starts, which will also take several cycles to check if it should process the request. Add polling to the netcode and you're talking about severe delays.
The problem you are having is easily solved using the Observer pattern. ( Here 's a pdf description of this pattern from patterndepot.org. Explained here at JavaWorld.com). Also, working in a multi-threaded environment, polling has a lack of context switch and synchronization, and then figuring out that you don't need to spend those resources checking your message bus. Have a look at using a parallel collection from java.util.concurrent to store your messages.
Finally, your overall architecture sounds like it will require some server side rework. If you plan to have a high user load, as introducing a new mid-tier processing thread for each user will eventually lead to degraded server performance as you have more context switches and tasks become more powerful.
source to share