User tracking is a very important feature for any web site whether it's for desktop computers, mobile devices, set-top boxes or anything else. When a user visits your site you want to know how long his visit lasted, which contents he visited, what navigation path was followed and so on. This is functionality we have become used to having in most, if not all the web sites. Tracking can be used for many different reasons – what we are going to cover here is focused on navigation sessions.
Transactions are not preserved between HTTP requests, but you often want to let your users to register, login, set preferences and create a session that can store all these information, plus avoid to ask for login and pass at every following request. This also has the advantage of letting you, the site owner, know which contents were requested by a specific user. This is very useful for analytical tools and to generate statistics. There are in general two ways to create and maintain a session on the web, you can send a Cookie or you can use what is normally called URL decoration.
Cookies are supported by every modern programming language and it is very common practice to use them on the web. Cookies are very useful because when you set them you can define an expiration date. One nice feature of Cookies is that if you don't define an expiration time they will be deleted when the browser is closed, this is important if you want to have a certain level of security on your site, when the user wants to quit, the session is closed automatically. The same happens for mobile devices. When you create a session you might also want to store some data in the session, such as the last page visited, the visited items if you are an online shop, etc. You can either send this information to the browser or store it locally, in a database or elsewhere. If you decide to send all the session information to the remote browser you will save space locally, but you might have security issues because the contents of the session might be changed. If you decide to send only the session ID and store all the information locally you are safer, but you have to make an extra effort to save the information. My preference is definitely to store locally for a number of reasons that I will now explain (added to security that came first). First of all there is a technical reason and this is specific to the mobile: mobile devices have limited memory, limited CPU and run on slower networks than desktop computers. Storing only a short string such as session ID reduces all these overheads. This is certainly a best practice. As an added benefit, if you define a long expiration time, users coming back to your site will not need to login again. Again, this is good practice for the mobile because the user will not have to authenticate again (if you are not too concerned about security) and also because you will know that the same user has come back, good for your statistics.
You will be wondering how well Cookies are supported on mobile browsers. The answer is that Cookies are fairly well supported. The OMA has required the support for all WAP 2 browsers and a minimum of 512 Byte should be made available (and this goes back to the hint of store little data in Cookies). Also, WAP Gateways, when used, should act as a proxy for Cookies too, storing them locally if the browser is not able to do so. This should not be the case in modern browsers.
The bottom line is that you can use Cookies with due caution: avoid overloading the browser, or sending 3 or 4 different Cookies, use one if you can and store the rest of the information on the server. If you don't trust Cookies you may use URL decoration. By URL decoration I mean adding a session ID to the URL, this can be done as a parameter or in the URL itself, for example:
http://example.mobi/index.jsp?sid=1234567890
http://example.mobi/index.jsp/sid=1234567890/
As long as you can keep the session ID alphanumeric and the URL is below 256 characters you should NEVER have any problems. The advantage of this solution is that you don't rely on the Cookie support of the browser, but only on the very basic GET request. You will have to store all the information on the server side, of course. Another advantage other than reliability of this practice is that you will be able to track user navigations in the logs of your web-server.
The only disadvantage of this solution, as compared with Cookies, is that the session will end when the browser is closed, unless the user has bookmarked the URL including the session ID. Also, when a user sends a URL to a friend he might at the same time pass his own session.
