Push messages that automatically launch a Java mobile application

Add MIDP 2.0's push registry feature to your device application

Mobile technology continues to grow in popularity. And Java Micro Edition, or Java ME (Sun's new name for the J2ME platform), is one of the most prevalent technologies for developing mobile applications. Using Java ME, we can run many wireless applications in handheld devices that use either a JVM or KVM.

Included with Java ME is the Connected Limited Device Configuration (CLDC), which targets those devices that have limited resources and use a KVM. Also included in Java ME is the Mobile Information Device Profile (MIDP), a CLDC-based profile for running applications on cell phones. The application component, which runs in the mobile device, is a MIDlet, a MIDP application. A MIDlet is basically a set of classes designed to be run and controlled by the application management software (AMS) inside a mobile device.

The latest version of MIDP, 2.0, has introduced many new features for helping developers build robust enterprise applications, with one of the more important being the push registry. In Java ME applications, sometimes we need to push data from the server and launch a mobile application automatically in the device, without the device being explicitly started by the user. Imagine a situation where a user must be automatically notified when a work item has been created against his/her name and must respond to the work item as soon as possible. Java ME's push registry easily pushes a message to a Java ME application and automatically launches the application. In this article, I will show you how you can add the push registry feature to your mobile application.

The push registry's behavior can be described in the following three steps:

  1. The MIDlet registers a port along with the protocol name in the mobile device such that, if any message arrives in the specified port with the protocol mentioned, the AMS delivers it to the MIDlet. The registration is done statically using the Java ME application descriptor (JAD) file. The program can also perform dynamic registration using an API inside the application.
  2. From the server, a message is sent to the specific mobile device using the particular protocol and port where the MIDlet application is registered to listen.
  3. After the message is delivered to the mobile device, the AMS calls the MIDlet application, which has registered to listen to that particular port and particular protocol. Once the message is delivered to the MIDlet, it is the application's responsibility to process the message accordingly. Typically, an application may choose to open a screen, depending on the message, and allow the user to do some server transaction.

To push the message from the server, in this article's example, we will use a GSM (global system for mobile communication) modem. Figure 1 describes at a high level the exact scenario we will achieve in this article.

Figure 1. High-level scenario of SMS push to a mobile device from the server

Each push registration entry in the jad file contains the following information: MIDlet-Push-<n>: <ConnectionURL>, <MIDletClassName>, <AllowedSender>.

  • MIDlet-Push-<n>:: The push registration attribute name. Multiple push registrations can be provided in a MIDlet suite. The numeric value for <n> starts from 1 and must use consecutive ordinal numbers for additional entries. The first missing entry terminates the list. Any additional entries are ignored.
  • ConnectionURL: The connection string used in Connector.open().
  • MIDletClassName: The MIDlet responsible for the connection. The named MIDlet must be registered in the descriptor file or the jar file manifest with a MIDlet-<n> record.
  • AllowedSender: A designated filter that restricts which senders are valid for launching the requested MIDlet.

The MIDP 2.0 specification defines the syntax for datagram and socket inbound connections. When other specifications define push semantics for additional connection types, they must define the expected syntax for the filter field, as well as the expected format for the connection URL string.

A typical example of push registry in the jad file, using socket connection, resembles the following: MIDlet-Push-1: socket://:77, com.sample.SampleApplication, *. This sample descriptor file entry reserves a stream socket at port 77 and allows all senders.

Pushing the message from the server to the mobile device leads to some issues: If we want to send a message to a particular device that has registered to listen to the socket stream on a specific port, we must know the mobile phone's wireless network IP. As many phones do not use the always-connected environment in the wireless network (sometimes the provider does not support the device's static IP inside its network), sending a message to such a device is problematic. If we do not know the device's wireless IP, we will not be able to send a message to the device using the socket connection from the server.

Short message service (SMS) comes in handy for this situation. With SMS, we specify the destination device's phone number; so in this situation, we do not need to know the device's IP address. But using SMS as a trigger also involves some issues: Since the MIDP 2.0 specification defines the syntax for datagram and socket inbound connections and not for SMS connections, it is not guaranteed that all the devices supporting MIDP 2.0 will be able to use SMS as a trigger for the push registry. But the Wireless Messaging API (WMA 1.1)—an optional package over MIDP, which can support SMS—is now supported by many mobile devices, so there is a better chance that SMS will be supported by many devices as a trigger to the push registry. For this article, I use a Nokia 6600 mobile handset, which supports SMS as a push registry trigger.

In addition, sending an SMS message from the server to the device is not straightforward, since multiple approaches are available. SMS service providers provide the APIs (or expose service URLs) through which you can send messages to the designated mobile phone from your server-side application. But this approach requires a dependency on the SMS service provider and its special plans. The alternate way is to use a GSM modem, where you need to interface the GSM modem with your server-side application. In this article, I use an open source product, SMSLib for Java v1.0 (formerly jSMSEngine), which interfaces the GSM modem with the Java server-side application.

Another important point to note here is that a simple SMS message will not activate the MIDlet. We must send the SMS message to the particular port where the MIDlet is registered to listen. Hence, the software (or the SMS service provider) used to send the SMS message must be able to send it to a device's specific port. The SMSLib for Java v1.0 supports this functionality.

When we use the GSM modem approach, we must understand that the GSM modem will internally use the SIM (subscriber identify module) card to send the SMS message. This SIM card is tied to a mobile service provider. So each SMS message will cost the same as a message sent from a normal GSM mobile phone. On the contrary, sending bulk SMS messages via the provider's SMS gateway may prove more cost effective for an enterprise application (depending on the service plan). But if an application does not need to send many SMS messages to trigger the MIDlet, then a GSM modem approach may be cost effective and removes the special bulk SMS service dependency from the mobile service provider.

Though I suggest buying a separate GSM modem for the approach's production usage, testing the behavior does not call for buying one. Currently, many GSM mobile phone models come with a built-in GSM modem. One of these mobile models can be used as a GSM modem instead of a separate one. In this article, instead of a separate GSM modem, I use another Nokia 6600 mobile phone, as Nokia 6600 has a built-in GSM modem.

Let's now develop a sample application that will enable us, from a Java server-side application, to send an SMS message to a mobile phone's specific port and automatically launch a MIDlet in the mobile device.

Develop the client-side MIDlet using the push registry feature

To develop the client, we will use the Sun Java Wireless Toolkit (formerly known as J2ME Wireless Toolkit). I use version 2.2. This product is free and can be downloaded from Sun's Website. To install and run this toolkit you must have J2SE 1.4.2_02 or a more recent version installed in your machine.

I use Windows 2000 Professional as the operation system.

After installing Sun's toolkit follow the steps described below:

  1. Open the KToolbar from the Start menu: select Programs, then J2ME Wireless Toolkit 2.2, then KToolbar. An application window will open, shown in Figure 2.

    Figure 2. Open the KToolbar. Click on thumbnail to view full-sized image.
  2. Now click on the New Project icon in the window just opened. A pop-up window will open; there you can specify the project name and MIDlet class name. Type MySamplePushRegistryProject for the project name and com.sample.MySamplePushRegistry for the MIDlet class name.

    Figure 3. Create a new project
  3. After Step 2, another pop-up window will automatically appear, which will allow you to set other settings for the project. Make sure you are in the API Selection tab. In this tab, select JTWI from the target platform drop-down menu (if not already selected). Also make sure the CLDC 1.0 radio button is selected. Uncheck the Mobile Media API checkbox (as we are not going to use any API related to multimedia). Refer to Figure 4 for your reference.

    Figure 4. Set the API preference. Click on thumbnail to view full-sized image.
  4. Now go to the Push Registry tab. Click on the Add button. A pop-up window will appear. Type sms://:50001 in the Connection URL field, com.sample.MySamplePushRegistry in the Class field, and * in the Allowed Sender field. Refer to Figure 5 for your reference.

    Figure 5. Set the push registry property
  5. After Step 4, an entry will be added in the parent window, as shown in Figure 6.

    Figure 6. Set the push registry property (continued). Click on thumbnail to view full-sized image.
  6. Now go to the Permissions tab. Click on the Add button. Select the javax/microedition/io/Connector/sms from the permission tree and click OK. Repeat the same step to add the permissions javax/wireless/messaging/sms/receive and javax/microedition/io/PushRegistry.
  7. After Step 6, three permissions will be added in the application, as shown in Figure 7.

    Figure 7. Add the permissions. Click on thumbnail to view full-sized image.
  8. Now go to the User Defined tab. Here we add a user-defined variable, which will contain the SMS port. From our program, we refer to this user-defined variable to read the SMS port. In this tab, click on the Add button. A pop-up window opens. Type SMS-Port as the property name. Select OK. The original pop-up window appears. Type 50001 as the value of the SMS-Port key, as shown in Figure 8.

    Figure 8. Add the custom property SMS-Port. Click on thumbnail to view full-sized image.
  9. Now click on OK in the Settings window. This action will bring back the KToolbar.
  10. After Step 9, if you look into the jad file generated by the above steps, C:/WTK22/apps/MySamplePushRegistryProject/bin/MySamplePushRegistryProject.jad (assuming that the J2ME Wireless Toolkit 2.2 has been installed in the C:/WTK22 directory), you will find the entire configuration, which you set in the earlier steps. One of the important entries is the following: MIDlet-Push-1: sms://:50001, com.sample.MySamplePushRegistry, *. This entry ensures your application will listen on port 50001 for an SMS message.

Let's now look at the code for the MIDlet application. Here, I only provide a partial code snippet of the MIDlet. See Resources to download the whole codebase used in this application.


public class MySamplePushRegistry extends MIDlet implements CommandListener, Runnable, MessageListener { //.... public void startApp() { smsPort = getAppProperty("SMS-Port"); String smsConnection = "sms://:" + smsPort; if (smsconn == null) { try { smsconn = (MessageConnection) Connector.open(smsConnection);

smsconn.setMessageListener(this); } catch (IOException ioe) { ioe.printStackTrace(); } } display.setCurrent(resumeScreen); } public void notifyIncomingMessage(MessageConnection conn) { if (thread == null) { thread = new Thread(this); thread.start(); } } public void run() { try { msg = smsconn.receive(); if (msg != null) { if (msg instanceof TextMessage) {

content.setString(((TextMessage)msg).getPayloadText()); } display.setCurrent(content); } } catch (IOException e) { e.printStackTrace(); } } //other methods to follow }

In this snippet, the following points need attention: The class MySamplePushRegistry extends MIDlet. This class implements the CommandListener, Runnable, and MessageListener interfaces. Inside the MIDlet's startApp() method, we receive the value of the SMS-Port property using the getAppProperty() method. We also create a connection to listen for SMS messages using the Generic Connection Framework (GCF). GCF's Connector class's open() method creates the SMS connection. If a message arrives, the notifyIncomingMessage() method is called, which creates and starts a thread (if not already created). In the thread's run method, the program waits for a message (smsconn.receive()). When the message is received, we get the original message and set the message in the Alert class. In a real-world application, users typically open a screen to process the message.

Once your code is ready, build it using the Build icon in the KToolbar. After a compilation and preverified error-free build, you need to package the application as a JAR. To do that, select the Project menu, then Package, then Create Package.

Before deploying the application in a real device, we test whether the application is behaving correctly with the simulator. Select the Project menu, then Run via OTA. This step actually simulates the MIDlet's over-the-air installation. Figure 9's sequence diagram describes the total procedure. Keep this simulator window open.

Figure 9. Install the application in simulator over the air. Click on thumbnail to view full-sized image.

Now, in the KToolbar go to the File menu and select Utilities. A pop-up window, shown in Figure 10 opens.

Figure 10. Open the Utilities

Click on WMA, then Open Console. Another pop-up window opens:

Figure 11. Open WMA Utility console. Click on thumbnail to view full-sized image.

Select the Send SMS button in this window. The window's content will change, as shown in Figure 12. Select +5550000 as the phone number in the To Selected Clients area. In the Port textbox, type 50001. In the Message field, type Hi Test Message. Now click on the Send button.

Figure 12. Send the SMS message from Utility. Click on thumbnail to view full-sized image.

If everything goes fine in the above steps, the simulator window, shown in Figure 13, will show that a message has arrived in the simulator mobile phone, telling the user a message has arrived and is waiting for approval.

Figure 13. Simulator MIDlet getting activated in SMS

If you select Yes on the simulator, the MIDlet automatically starts and "Hi Test Message" appears in the simulator, as shown in Figure 14.

Figure 14. Simulator MIDlet received SMS

The next step is to install the MIDlet in the real device. You can do an OTA installation of the application. For details, refer to Sun's toolkit documentation. Instead of OTA, we can also install the MIDlet using cable/infrared/Bluetooth technologies if the device supports those options. For a client device, I use Nokia 6600, which supports infrared technology, and since I have an infrared adapter available, I installed the MIDlet in Nokia 6600 using infrared technology.

If the above steps run fine, you are all set with the client-side application. Now it's the time to develop the server-side application, which will actually send the SMS message to the MIDlet listening on port 50001.

Develop the server-side application to send the SMS message to a particular device port

As mentioned previously, to develop the server-side code to interface with a GSM modem, I used the open source SMSLib for Java, which uses attention commands (AT commands) to interface with a GSM modem. It also uses either the Java Communications API or RxTx to communicate with the underlying operating system and talk with the external device (GSM modem) to send the AT commands.

To send a message to a particular port, the user data (UD) and user data header indicator (UDHI) fields of the protocol data unit (PDU) must be modified. SMSLib does it internally, so the complexities involved in sending the SMS message are all wrapped inside the SMSLib code. If you are interested in looking into how exactly the message is sent, you can go through the SMSLib code on your own.

Follow the steps below to complete the server-side coding and deployment:

  1. Download the SMSLib code from the SMSLib Website. While downloading, make sure you are downloading the SMSLib-Java-v1.0.1.zip. SMSLib for Java can be used with either the Java Communications API or RxTx. Sun has recently removed support for the Java Communications API for Windows, so it is better to use RxTx. But if you already have the Java Communications API, you can run it with SMSLib also. I will detail both approaches for running the sample program in this article.
  2. To start with Java Communications API 2.0, first, make sure you have installed the API correctly. Unzip the javacomm20-win32.zip. Inside the subdirectory commapi, you will find the following files, which are of interest:

    • javax.comm.properties
    • win32com.dll
    • comm.jar

    Copy the javax.comm.properties to your Java Runtime Environment's lib directory. Copy the win32com.dll to your JRE's bin directory. While running any program using SMSLib, make sure that comm.jar is in the classpath.

    To ensure the Java Communications API has been installed properly, go to the commapi\samples\BlackBox directory from the command prompt. Set the PATH variable as follows: For my case, the JRE home is C:\j2sdk1.4.2_03\jre. Change this according to your JRE settings. Set PATH=.;C:\j2sdk1.4.2_03\jre\bin;. Now execute the Java BlackBox program using the following command: java -classpath .;../../comm.jar;BlackBox.jar; BlackBox.

    If the Java Communications API has been installed properly, then a Swing window, shown in Figure 15, will appear with your machine's available serial ports (COM ports). After closing the window, the command prompt will contain some lines related to the available COM ports, as shown in the sample command prompt output below. Remember that this Swing window content and the command prompt content will vary depending on the available ports in your PC; the output will not be same as mentioned here. But the important point is, if you are able to see the GUI and the lines in the command prompt (like the following), you can assume that the Java Communications API has been installed properly. After this test, close the Swing window to terminate the BlackBox program.

    Figure 15. Test the installation of Java Communications API

    Sample command prompt output:

    Closing port 1 (COM2)
    Closing COM2
    Closing port 0 (COM1)
    Closing COM1
  3. Now it's time to attach the GSM modem to your computer. I have used a Nokia 6600 mobile phone to act as a GSM modem. Nokia 6600 does not have a serial port connector (COM port connector). But it provides infrared technology to connect to the computer and then act as a GSM modem. If you have a phone that has a direct serial port connector, that will prove easier to use. Generally, the actual GSM modem provides a serial port connector. But if your device lacks a serial port connector, but does include a built-in GSM modem and can connect using infrared or Bluetooth technologies, this option should also work.

    To achieve the COM port functionality without a physical COM port, you must map a virtual COM port to your infrared or Bluetooth connection. SMSLib requires a compatible GSM phone or GSM modem. Most GSM phones can be used if they offer modem capabilities. SMSLib uses the serial connection (either physical or emulated, i.e., Bluetooth, infrared, USB, etc.) to communicate with the GSM modem. Using Nokia 6600, you can send SMS messages using SMSLib, but these messages cannot be received using this model as Nokia 6600 stores the incoming messages in a memory card instead of a SIM card. Also Nokia 6600 does not allow the reading of messages using AT commands from the memory card. But since we just have to send the SMS message to wake up our MIDlet, Nokia 6600 will be able to do that successfully (no receiving of SMS message is required). The most important point for the phones, which connect using infrared or Bluetooth technologies, is to map the infrared or Bluetooth connection to a virtual COM port. Consult your mobile phone document to find out whether it supports the virtual COM port mappings.

    For my case, I have Nokia PC Suite installed on my PC. To connect Nokia 6600 from my PC, I use an external USB infrared adapter. So, for that, I have the infrared driver also installed in my PC.

    Now, I connect to the external infrared adapter using the USB port with my PC. In the Nokia 6600 device, I select Menu, then Connect(ivity), then Modem. The option Connect via Infrared is available under Modem. Now I select the option "Connect" and put the mobile phone in the range of the infrared adapter.

  4. The next step is to verify that from the PC, we can access the GSM modem using the AT commands. To do that, select the Start menu, then Programs, then Accessories, then Communications, then HyperTerminal. A dialog box will open and ask for a logical name. Provide any name you wish. For my convenience, I have provided the name "GSM Modem." Select OK.

    Figure 16. Open the HyperTerminal
  5. Another pop-up appears. In the Connect Using drop-down menu, select the COM port name (virtual or actual) through which the GSM modem is connected with the PC. In my case, it is COM4.

    Figure 17. Select the COM port in HyperTerminal
  6. In the next dialog box (properties of the COM port), just click OK.
  7. Now you will be directed to a window where you will write some commands (in our case, we will write AT commands). Type the following command to test the connectivity—but remember, when you type the command, it does not write anything in the console: AT+CPMS=?.

    Important point: Do not type any unknown commands in HyperTerminal. It may permanently damage your mobile device or erase all its data.

    If everything goes fine, you will be able to see some outputs, as shown in Figure 18. The outputs may vary, but no output, an error, or a terminal hanging indicates an error in connectivity.

    Figure 18. Executing the AT commands in HyperTerminal
  8. Now from the Call menu, use the Disconnect command and disconnect from the HyperTerminal.
  9. After completing the previous steps, we are now ready to write the sample Java program, which will send the SMS message to the specific port using the GSM modem we have just configured:


    import org.smslib.*;

    public class SendMessageWithPortsSMSLib { public static void main(String[] args) { CService srv = new CService("COM4", 9600, "", ""); System.out.println("SendMessage(): sample application."); System.out.println(" Using " + srv._name + " v" + srv._version); try { srv.setSimPin("0000"); srv.connect(); srv.setSmscNumber(""); COutgoingMessage msg = new COutgoingMessage("+9198301...", "Message from smslib API."); msg.setMessageEncoding(CMessage.MESSAGE_ENCODING_7BIT); msg.setSourcePort(0); msg.setDestinationPort(50001); srv.sendMessage(msg); srv.disconnect(); } catch (Exception e) { e.printStackTrace(); } System.exit(0); } }

    In the code snippet above, we first create an instance of the CService class with four arguments. The first argument takes the COM port name. (In my case, it is COM4, as my GSM modem is connected by a virtual COM port. Make sure you change it according to your COM port name.) The second parameter specifies the baud rate. This limit you will find when the modem is connected. The third argument specifies the make of the mobile/GSM modem. The fourth argument specifies the model. The third and fourth parameters sometime play important roles where a specific make and model needs a different set of AT commands to interface with the GSM modem. For example, for the Sony Ericsson model, a different set of AT commands and logic is needed; thus, with the jSMSEngine distribution, you will find a separate handler for Sony Ericsson. jSMSEngine has different handlers for specific types of makes and models. For Nokia, the default handler is good for Nokia 6600 and for our purposes. Thus, I have not specified any values in the third and fourth arguments.

    After CService has been initialized, we connect to the GSM modem using the method call connect(). We set the SMSC number (SMS center number) to blank. This will be retrieved from the SIM card. After that, we create an outgoing message using the class COutgoingMessage(). The constructor of COutgoingMessage() takes two parameters: the device number where the message must be sent and the message itself. In a typical real-world application, some indicator like numeric codes may be passed as an SMS message; according to that code, some action occurs on the MIDlet side. Another important point is the setDestinationPort() method, where we actually set the destination port.

    Figure 19 shows the detailed setup.

    Figure 19. Detailed setup

    Important note: The SMSLib uses a J2SE 5.0 API inside CLogger.java. CLogger.java uses a line that uses a PrintStream constructor that takes the java.io.File type. This constructor in the PrintStream class is supported from J2SE 5.0. But as I am using J2SE 1.4, I have changed the line from: stream = new PrintStream(new File(filename)); to: stream = new PrintStream(new FileOutputStream(filename));.

    After this change, I build the source supplied by SMSLib and make the new JAR using JRE 1.4.2.

  10. To compile the sample program, make sure you have the new JAR (which you built after modifying the CLogger code) and the comm.jar in your classpath. Then compile the sample application.
  11. After compilation, run the application. Make sure the two JARs mentioned in the earlier step are in the classpath. If everything goes well, you will be able to see that the MIDlet, which you have installed in another device, has automatically started and shows your message.

Now, let's see how to use RxTx instead of the Java Communications API 2.0. You can download RxTx from SMSLib. While using RxTx, we need to take care of the following points:

  1. Copy RXTXComm.jar to the (JDKDIR)\jre\lib\ext directory and copy the rxtxSerial.dll file to the (JDKDIR)\jre\bin directory.
  2. SMSLib is packaged for use with the Java Communications API, but with a little code change, we can use it with RxTx also. For SMSLib to work with RxTx, edit CSerialDriver.java and remove line javax.comm.*;. Add line import gnu.io.*;. Then rebuild.
  3. RxTx also supports Win32. As I write this article, RxTx supports physical serial connections well, but shows some exceptions for "virtual" serial ports, i.e., emulated serial ports via Bluetooth/infrared/USB connections. But in a real-world scenario, you will not use a mobile phone as a modem, but a real GSM modem, which connects through a real COM (serial) port. This should not be a problem. Now, in my case, I received some errors while sending the SMS message because I have a virtual port mapping for infrared connections. To eliminate those errors, I commented out some lines in CSerialDriver. Specifically, find the line outStream.flush();, comment it out, and then rebuild.
  4. Now follow the steps starting from Step 3 in the previous list. In Step 11, make sure while running the SendMessageWithPortsSMSLib, you have the recently built JAR (the changes for RxTx) in your classpath and that it is using RXTXcomm.jar and the rxtxSerial.dll file instead of the Java Communications API's comm.jar and corresponding dll file.

Point to note: Since SMSLib uses the Java Communications API, or RxTx, which makes native calls to the operating system, I suggest not embedding such code directly in the application server or Web server. An alternate solution embeds such code in a separate standalone, vanilla RMI (remote method invocation) server or Web service server, and accesses it from the application server. But, since we're using a GSM modem, the SMS sending speed is slow; so if we call the interface (RMI or Web service) directly, it is better to use an asynchronous design. For example, when you try to send a message to a device, put it inside a Java Message Service queue with the required information (mobile number, port, message, etc.). Write a message-driven bean to pick up the message, and then it will make a Web service call to the service (which embeds the SMS sending code).

I have just mentioned one possible approach; you can choose any design that fits best for your architecture. But while making any decision, keep in mind the following two points:

  • Using a GSM modem, the speed of sending an SMS message is not fast (depends on GSM modem you have chosen and the SMS service provider)
  • SMSLib uses the Java Communications API or RxTx, which makes native calls to interact with the operating system

Though I have suggested the use of two Nokia 6600 mobile sets (one to be used as GSM modem, another to be used as the Java ME client), you can test the behavior with only one. First, install the MIDlet in the device. Then use the same device as the GSM modem. While sending the SMS message, send it to the same mobile number that you are using as a GSM modem to send the message. In this situation, the sender and receiver mobile phone are the same.


In this article, you have learned how to write a Java ME application using the push registry feature. You have also learned how to send an SMS message from the server and automatically launch the MIDlet. To test only the push registry feature, you can use two mobile phones that support MIDP 2.0 and WMA 1.1 (without using server-side SMS push), and use the sample SMSSend and SMSRecieve program supplied with the Sun Java Wireless Toolkit. But in a real-world application, you may need to send an SMS message from the server, rather than from another MIDlet.

The code snippets shown in this article are not complex; the procedures for setting up the environment are. But once the environment is set up properly, you will be excited to see the push registry feature working in a real device using server-side SMS push. If you face any problem while using SMSLib, you can always post questions and ask for help in the SMSLib user group. Finally I would like to thank the owner of the SMSLib project, Thanasis Delenikas, for sharing some valuable information regarding the latest development of SMSLib.

Srijeeb Roy holds a bachelor's degree in computer science and engineering from Jadavpur University, Calcutta, India. He is currently working as a technical architect in Tata Consultancy Services Limited in a Java EE-based project. He has been working in Java/Java EE for more than six years and has a total experience of more than seven years in the IT industry. He has developed several in-house frameworks in Java for his company and clients. He has also worked in several other areas such as Forte, CORBA, and Java ME.

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies