def

We received some suggestions from Client Team at MXit who designed the Graphics Markup, namely Jaco Loubser. We will highlight some of the lesser know features of MXit Graphics Markup.

1. Tables can be updated in Full Mode or Update Mode
This means that you can either resend the entire screen/tables to the user each time, or you can send the changes (deltas) to the screen. This saves data and can make the user experience smoother and faster.
You the app creator do not need to maintain the state of what to send when, as the SDK will manage this for you if you set appropriate mode type. The default mode is Replace/Full.

A table can have one of the following TableSendModeType modes

• Update mode refers to the incremental table changes that will be sent through to the client to save bandwidth/data/speed.
  Note: The update mode is only supported if the client has the following DeviceFeatures flag defined - GamingUpdate
  
• Replace refers to the full mode that requires the entire table is re-sent for each change to the table.

2. Making big clickable buttons without having to use images
You can make a cell's entire body clickable by setting the SelectionMode on the table. For example, you can have 100% width buttons in a menu structure format, where the user can click anywhere on the link to activate the button.
Turning this on means that all cell's that have an action associated with them will be clickable.
-
Table.SelectionRectType (selm) selection rectangle mode. Specifies how the selection rectangle should look for table data cells that have an action that is not empty. Possible values are:

• Outline: Draw the outline of a rectangle (with rounded edges) in the current selection background color.
• Fill: Draw a filled rectangle in the current selection background color. If this mode is set, the text in that cell will be drawn in the current selection foreground color.

Here's an example to illustrate:

The top cell rows are all clickable at any point in their cell, i.e. not just the word.

If there is a clickable link in the table, the link's text will be highlighted as per usual and not the entire cell. The cell's with actions (and no link) will be highlight-able in full.

3. The selection cursor can be placed on a specific cell
It's possible with the SelectionRect setting on a table to place the cursor at a specific location on the table. This means that when you update the table after some submission you can place the cursor at the most likely next location for the user to save him having to click.

4. The selection cursor can be customised
The standard blue selection rectangle isn't the only option you have, using Graphics Markup you can have a custom icon, for example, a picture of a needle can appear if you are about to pop a bubble.

The Table's SelectionFrames property allows you to specify which image strip/sprite frame(s) to use for the cursor selection.

Here's an example from the harsi.solitaire game that makes use of a custom selection icon:
Notice the green selection image used instead of the default cursor drawn by client software.

MXit C# WCF SDK 1.3.2
and
MXit API 1.3.6 have been released.

So what has changed?

API
On the API level we have made improvements to the throughput and stability of the API Service.

• Apps only allowed to connect once every 30s.
• We are running solidly, let's see how much traffic you can push through.

SDK Features
Redirection between Apps.
You can send a user between two app's that you own with a single click.

Use cases:

• You can open another app in a new temporary tab that persists for the user's session. e.g. run multiple game sessions at once per user in different windows.
• Create a service that performs a shared function that is linked to from different app's.

Key points regarding the implementation: there is a history (stack) of redirects, the special redirect Back takes you to the previous app that you were redirected from.
There is a global whitelist of allowed redirects and a list of allowed redirects per app.

Contact us if you want to redirect to a certain location that isn't allowed yet.
We will open redirects between all your own apps that you have on your dashboard account.

Receive files from users

• You app can now receive audio clips or pictures that the user takes while using your app. Or receive a file that he loads from his phone.
• The possibilities are endless, and you can target a much larger audience to receive files from than MMS or browser based uploads allow.

New samples and connection framework
We now provide a sample application that abstracts the connection handling away from the developer so that you can focus on your application logic and not the WCF specific faults and re-connection handling.

There is also a demonstration snippet for each functionality of the SDK to show how it is used included in the SDK samples.

Demographics added
Gender - male or female: what targeted look and feel will you give to your users now?

RegisteredCountry - in a similar vein to the user's current country, this specifies which country the user chose as his registered country vs his ip based country (currentCountry).

Where do we get this?
The SDK is available on code.mxit.com/download and the API improvements are available to everyone automatically.

We have released an App Showcase on the code.mxit.com/showcase website.

This view only MXit app store lists all published app's that are available inside MXit.
Published means your app was approved, it's running fine, and then you have opted to have it publicly published via the Dashboard on code.mxit.com

This online listing of developers App's shows the app's avatar (profile pic), a description of the app as well as where the app can be found in MXit.

Future enhancements
Some great ideas we have received to improve this online MXit App Store are:

• Adding a Game or App to your MXit account with one-click.
• Breaking down the app's into categories, currently all are presented on one page.
• Showing app popularity and ratings.

What kind of features would you like to see?

Perhaps it's not too clear from the documentation, but it is possible to layer images on top of each other in MXit. There is no imposed limit to the number of frames you can use.

For example, you can have a background image, a foreground image, and a selection image frame. This is how you can do client side changes to your table.

• Background layer -
• Pieces layer -
• Selection layer -

For example chess is a bunch of layered images. Transparent PNG’s is what you would use.

In code: Each table has a cell that can contain an array of indexes that points to a frame in a frameset.

For example: A cell containing the list of frames: “i=bg.1_fg.7” means "For this cell, paint bg.1 and fg.7 on top of each other".

To know which frame to paint over which one, you have to look at the “layer” attribute of each image strip. The order in which images are drawn are such that a layer of 0 will be drawn first and then an image from an image strip with a layer of 1 will be drawn on top of it.

For example:
::op=is|nm=bg|dat=iVBORw0KGgoAAAA%3d%3d|v=63398|fw =8|fh=8|layer=0:
::op=is|nm=fg|dat=iVBORw0KGgoAAAA%3d%3d|v=633988|f w=8|fh=8|layer=1:
, in this case the frame in bg should be painted first in a cell, and then the frame in fg should be painted on top of it.


Other Features of Tables
SelectionFrame - The default selection frame is a blue rectangle. You can set this property to specify which frames should be used as your selection frame. This can be use to have a special crosshair or mouse cursor even to represent the user's current selection frame.

DefaultSelection - This means that when you click on a cell that allows placements to be placed, then what set of frames should be used as if the user had selected something? For example, you have an empty board, and everytime you click on a cell, it places a green ball. The green ball was never selected, but it is the default selection that gets placed.

SelectionRect - The coordinates of the position where the selection rectangle should be placed. Basically where you want the cursor to start off at.


Actions
Each cell has a list of select actions that get applied when you select something and a place action that gets applied when you place something. For example, a typical on placement rule would be: place the selected frame foreground layer on this cell.

A cell can be a place action, a select action or a submit action.
A select action happens when a cell is selected (e.g.pick up a piece, draw the selection frame over it).
The place actions occur when a selection is placed (e.g place the piece frame on the placeable cell and clear the selection piece frame).
And a submit action submits the current selections and placement(s) to your app.

After a bunch of moves are made you can submit the table, either automatically or manually, which returns all the selected and all the placed cell’s so that your game engine can make a decision on what to do, e.g. check is a valid move, change the table appropriately etc.

Action rules
This section describes how the client responds when a user clicks on cells, based on the actions that could be configured for each cell.

• User clicks on selectable cell
• If a placement has already been made on another cell, then all previous selections and placements are cleared before the operation is processed. Otherwise a new selection is just made.
• If this cell has previously been selected, then the state of the cell is returned to it's default.
• If selection limit has been reached (with this selection) and autosubmit is enabled, then all current

...

We break down the process of how a message is routed from the end user to your app or service.

MXit users obtain MXit from our site, m.mxit.com or from app stores such as the Apple App Store, Android Marketplace and BlackBerry App world.

Once they have successfully logged in to their account, they then have access to a shop called Tradepost which contains all sorts of services and items. Currently MXit API Apps from third parties are being listed under Tradepost's Workshop Inventions. Specialized placements throughout MXit are available through our business division.

Now, the MXit user has a TCP connection open to the MXit backend (login servers or proxies). This is naturally a duplex connection so that information can be pushed back and forth between the user and the backend in realtime.



Client protocol
There is a MXit Protocol that is spoken between the devices and the MXit backend. i.e. the way messages are packaged over the TCP connection.

Your App Servers Connection
Your App server connects to the MXit backend via the API server. The app opens a TCP connection (nettcpbinding in WCF) to the API server and receives all the messages from all the users over one pipe. Therefore the bandwidth of your connection to the API server will play a role in determining how many concurrent messages your application can ultimately handle.

Processing messages
Your App Server will also be responsible for processing as many messages as possible. Do not try to process and send the response to a message received on the same thread as on which you received the message. This is so that there are always threads in the .NET ThreadPool available to process incoming messages regardless of how long your processing and replying takes. A way to do this would be to handle the processing and responding of messages onto a queue to be processed by another threadpool you create.

When a user sends a message, it travels through the backend and reaches your app server pretty much as it was sent from the device. Above the MXit Protocol there is a Command Markup called the MXit Command Markup, which defines how specially formatted items should look, e.g. clear screen commands, clickable links etc.

There is also another section of markup called Graphics Markup which defines some client side features, e.g. moving and placing of objects, image sprite caching, accurate layouts etc. There will be another article where we explain Graphics Markup in more detail and how you can use it in your app or service.