Introduction
MUPE is an application platform for multi-user mobile applications. MUPE applications are client-server applications, where the client device has a MIDP client that is constantly connected to the MUPE server. Due to the limited bandwidth of the current mobile devices, and the latency of the HTTP or even TCP protocol, real time communications with the server is not easy. To make the system more responsive for user interaction, functionality should be uploaded to the terminals itself so they can quickly respond to the user input. The data transmission should be kept minimal, yet the user should feel that the system is responsive. Especially keeping in mind that each request to the server can take several seconds regardless of amount of data transferred. Because of this the it is good to minimize the times client has to interact with the server.
The XML script language is a method of creating UIs and client side functionality with simple scripts. The scripts allows the MUPE MIDP client to change its behavior and UI dynamically while the user is connected to the MUPE server. A part of the MUPE script language is based on MIDP 2.0 LCD-UI specification supporting most of the features defined in the MIDP 2.0 UI specific feature set.
The MUPE script language supports dynamical changes to the client device behavior. The new functionality can be uploaded to the terminal either by specifying a new template or uploading individual objects. The template defines all previous components and creates a new container for client functionality. The template contains any number of other objects. The objects can be changed dynamically using the script language and there is no need to change the template to change the behavior of the client device. The client is constantly connected to the MUPE server and the actions the user does can either be handled in the client or they can be sent to the server. Application designers need to decide how they want the MUPE applications to work. The bandwidth is usually scarce, and it should in most cases be preserved. The client supports the following features:
- Messages between the client and server. These are used for communications between he MUPE client and server.
- Form Uis. These are simple "user input" based Uis. The user can input text, create lists, choice groups etc.
- Canvas Uis. Graphical user interfaces.
- Event hooks, user input, timers, UI events can be handled with the XML script.
- Resources that can be loaded and then re-used in the content.
- Support for third party plugins.
A typical MUPE application has only one server and a larger number of MIDP clients. This should be taken into account when designing applications. As much of the functionality as possible should be uploaded to the client terminal and the data traffic should be kept minimal.
Client-to-Server Messaging
The client sends information regarding its state to the server. When the client needs response from the server, such as new objects or new information, it sends a request to the server. When the client does not need a response from the server, the client sends a notification. System messages are internal messages. The client can also send standard XML-RPC requests. These can be used to extend the use of the MUPE client to get information from other sources.
Note: Messaging protocol between client and server is handled automatically by the client. Read more about "send" method in the "Common script language" section to learn more about how to send requests to the MUPE server.
request
Request is a message that waits a response from the server. The message is sent to the server and the client waits a response until it comes, it is timed out, or the server closes the connection. In addition to the client the server should also be aware that it is required to respond to the message.
notify
Unlike request, a notification does not wait response from a server. This type of interaction with the server is used when the client does not need an update from the server for each message it sends. Client can “front-load” information to the server using notifications and then send a request to download the update.
This method of interaction with the server is considerable faster than using multiple requests. The server does not have to acknowledge notifications, since client will close connection immediately after sending the message to the server.
Server-to-Client Messaging
Server-to-client messages are responses to client-to-server requests. The common format for server-to-client message are as follows:
<msg>
xml content here
</msg>
The message follows a certain XML format thought the whole system. Each XML section can have a series of parameters that is given to it. The parameters can be given in two ways. Either they are given in the header of the XML section (xmlsection and subsection1 in the example) or they are given inside a special purpose tag called parms. There can be only one parms section for each tag. The parameter values are given inside the variable tag, as PCData.
<xmlsection var1="value1" var2="value2">
<parms>
<var3>value3</var3>
<var4>value4</var4>
</parms>
<subsection1 var1="value1" var2="value2" var3="value3" />
<subsection2 var1="value1">
<parms><var2>value2</var2></parms>
</subsection2>
</xmlsection>
The next XML section is equal to the previous example:
<xmlsection var1="value1" var2="value2" var3="value3" var4="value4">
<subsection1 var1="value1" var2="value2" var3="value3" />
<subsection1 var1="value1" var2="value2" />
</xmlsection>
