Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Value-based Billing for Wireless Java Applications  : Page 4

If you're going to deploy sophisticated mobile applications such as m-commerce, you have to design sophisticated programs to handle billing for those applications simultaneously. JSR 190 is a new J2ME extension that purports to offer a streamlined, flexible mobile billing process. Find out what it can do.


advertisement
What the Code Looks Like
JSR190 is still in its early stage. Therefore, the current APIs are not available to the general public yet and are likely to be changed from their current form. However, some code is provided below to give the readers an idea of how the APIs may appear.

Consider the following pseudo-code.

public class MyMIDlet extends MIDlet { public MyMIDlet() { startup = true; } public void startApp() throws MIDletStateChangeException { if(startup) { UsageTracking ut = UsageTracking.getInstance(); // increment the usage counter ut.incrementCounter(); // Send the event to the server ut.submit(); } startUp = false; } public void destroyApp(boolean unconditional) { notifyDestroyed(); } }

In the above example, upon start up of the application, the application usage counter is incremented through the Event Tracking API. Note that the counter is stored locally at this point as submission to the event-tracking server is achieved through another call (see below). Also, the counter is stored persistently and the value should be retained unless the MIDlet is uninstalled. Specific implementation of JSR190 can choose to utilize MIDP's RMS (Record Management System) to achieve this.



After the counter is incremented, the application can decide when to submit the count to the event-tracking server. In the above example, the count is submitted to the server immediately after the counter is incremented. However, the application can decide when the best time is to submit.

Importantly, it is up to the implementation to optimize the submission. For example, the implementation can combine multiple "submit" calls into a single submission to the server in order to conserve bandwidth. The implementation can also delay the submission until the phone is idle, as certain mobile devices have only limited number of available socket connections. These types of details will be addressed when the specification is finalized.

Not only does the Event Tracking API track how many times the applications has run, it can also be used to track fine grain application events. Consider the following code of a stock ticker program:

public class StockerTicker extends MIDlet { public StockerTicker () { } public void checkStock(String url) { HttpConnection c = (HttpConnection) Connector.open(url); int code = conn.getResponseCode(); if(code == conn.HTTP_OK) { // process response here process(conn); // increment the usage counter UsageTracking ut = UsageTracking.getInstance(); ut.incrementCounter(); // Send the event to the server ut.submit(); } } }

In the above example, after the stock quote information is successfully processed, the usage counter is incremented accordingly and subsequently submitted to the event-tracking server. It should be noted that the usage counter is quite generic and can be adapted to different type of usages. The Event Tracking API facilitates tracking of various types of application usage that are otherwise not easily registered by server-side only technology.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap