We recently ported our application from Linux to Solaris and suddenly pound signs on the web front-end became a ? marks. This was because Solaris has a different default character set that cannot display a pound sign. Since we were not allowed to change the character set of the operating system, we had to make changes in our code.
In tracking down the issue a developer logged out the pound sign at various points in the code. They all appeared as ? marks. So it seemed that the moment the pound sign was created it was converted. It turned out that this was a wild goose chase. The byte value fro the pound sign was correct. The operating system was converting it when it wrote it to the screen or log file. It seems obvious now that this should happen, but it was not that obvious at the time.
It is very important to always specify the character set when converting byte values to characters. If you are not sure of the character set to use UTF-8 should be adequate for most applications.
In Java web applications you also need to ensure that the HTTPServletRequest's character set is set otherwise some characters sent to the server in the GET or POST requests will not convert correctly. This needs to be done before reading any parameter values from the request.
The other common place to set the character set is when reading and writing files or reading and writing data from a network connection.
Tuesday, May 20, 2008
SMS message lengths
One of the critical issues with writing a system that interacts with users using SMS messages is the cost of the SMS messages. This cost needs to be accommodated in the business plan as it has a major ongoing cost. Since SMS messages are normally 160 bytes for a single message and 140 bytes for concatenated messages it is critical to ensure that you message fits into the fewest number of messages. You do not want your message to span 2 SMS messages because it is one byte too long.
SMS messages use a 7-bit alphabet and the majority of characters fit into one byte. There are as always exceptions such as the euro symbol or a square bracket. This alphabet is specified in the GSM 03.38 specification.
Have a look at http://www.dreamfabric.com/sms/default_alphabet.html to see the full alphabet.
SMS messages use a 7-bit alphabet and the majority of characters fit into one byte. There are as always exceptions such as the euro symbol or a square bracket. This alphabet is specified in the GSM 03.38 specification.
Have a look at http://www.dreamfabric.com/sms/default_alphabet.html to see the full alphabet.
Tuesday, May 13, 2008
Processing incoming requests
Let us look at processing incoming request from different mobile applications. Depending on the channel the request might be asynchronous or synchronous, by this I mean the response is is sent using a different connection to the request vs the response being sent on the same connection of the request.
An example of an asynchronous channel would be SMS. The mobile phone sends a SMS to the server via the mobile network operator's infrastructure, the server process the request and then establishes a connection to the mobile network operator to send out the reply SMS. The incoming and out going SMS are not tied together in any way other than by the data they contain.
An example of a synchronous channel would be HTTP over GRPS. Here a connection is opened, the HTTP request data is sent to the server, the server processes the request and sends the response data down the connection and the connection is closed.
For asynchronous communication your application will require a level of internat thread management. This is difficult to achieve using many web scripting languages such as php whereas for synchronous communication you can get away with a web scripting language. To build an application that supports both types of communication requires a lot of thread management and synchronization techniques.
An example of an asynchronous channel would be SMS. The mobile phone sends a SMS to the server via the mobile network operator's infrastructure, the server process the request and then establishes a connection to the mobile network operator to send out the reply SMS. The incoming and out going SMS are not tied together in any way other than by the data they contain.
An example of a synchronous channel would be HTTP over GRPS. Here a connection is opened, the HTTP request data is sent to the server, the server processes the request and sends the response data down the connection and the connection is closed.
For asynchronous communication your application will require a level of internat thread management. This is difficult to achieve using many web scripting languages such as php whereas for synchronous communication you can get away with a web scripting language. To build an application that supports both types of communication requires a lot of thread management and synchronization techniques.
Friday, May 9, 2008
Security for mobile applications
Security capabilities differ considerably depending on the channel used. By channel I mean the technology used for the user interface and the communication mechanism to the back-end application. Some channels allow for no encryption at all and are deemed to be very insecure. A standard text SMS would be such a channel. The text cannot be encrypted so entering a password in an SMS is not a good idea. SMS messages use a store and forward protocol and thus can be intercepted and changed. In addition to this they are left in the 'Sent Messages' list on the users phone. More secure channels such as the SIM Browser solution from Gemalto and Smarttrust allow for data encryption within the SIM card of a GSM mobile phone. The encryption normally used 3DES and a secure key resident on the SIM card. This channel will be extremely secure as the encryption is performed within hardware components. For the MTN Banking run by the MTN mobile operator a Mastercard PIN is entered on the mobile phone.
Off-deck applications
On mobile devices off-deck applications are much easier to deploy since deployment of on-deck applications can be difficult for the average user. Off-deck applications include SMS, USSD, IVR, WAP, HTML etc. The way this type of application works it the the user submits a request by dialing a phone number, submitting a url from the phone browser or sending an SMS. The server on receiving this request guides the user through the application using menus and prompts for input.
In general off-deck applications are easy to use, but require more bandwidth and this could be expensive. It is critical to look at the cost of communication when building this type of application. The Fundamo mobile banking and payment system supports a wide range of channels and each of these have been tuned to reduce the bandwidth of the communication.
I will look at each channel in more detail in later posts and explain how they work and communicate to the server, but in my next blog I will look at the security aspect of the communication. Security is crucial for m-commerce, m-payments and m-banking systems.
In general off-deck applications are easy to use, but require more bandwidth and this could be expensive. It is critical to look at the cost of communication when building this type of application. The Fundamo mobile banking and payment system supports a wide range of channels and each of these have been tuned to reduce the bandwidth of the communication.
I will look at each channel in more detail in later posts and explain how they work and communicate to the server, but in my next blog I will look at the security aspect of the communication. Security is crucial for m-commerce, m-payments and m-banking systems.
Wednesday, May 7, 2008
On-deck applications
There are a number of on-deck application frameworks that can be used for developing mobile applications. Some examples include Java ME, Windows Mobile, Google's Android phone, Symbian applications etc. Some of these frameworks are more widely supported across and range of mobile phones and some are specific to certain operating systems on the phone. Determining what to develop your application in really depends on which phones are more widely used. This information can normally be obtained off the web or from the mobile network operators.
One you decide on the application framework you will need to look at the differences in screen resolution for the phones used by your customer base.
For the above reasons on-deck applications are difficult if your application has a wide user base. Java ME is probably supported my the widest variety phones, but ways to managed the screen resolutions will need to be built into your application. In the past the Java classes present in the virtual machines differ from one phone manufacturer to the next. This adds to the complexity of your deployment because classes might be missing or clash with existing ones. The bottom line is that there is an ongoing overhead to test new phones as they become available and manage the screen resolution and packaging differences.
One you decide on the application framework you will need to look at the differences in screen resolution for the phones used by your customer base.
For the above reasons on-deck applications are difficult if your application has a wide user base. Java ME is probably supported my the widest variety phones, but ways to managed the screen resolutions will need to be built into your application. In the past the Java classes present in the virtual machines differ from one phone manufacturer to the next. This adds to the complexity of your deployment because classes might be missing or clash with existing ones. The bottom line is that there is an ongoing overhead to test new phones as they become available and manage the screen resolution and packaging differences.
Tuesday, May 6, 2008
Future proofing your m-commerce application
It is essential to abstract the communication and user interface rendering layer from the business process of the application as one would in a typical web application. This is critical whether you are writing an on-deck (mobile device resident) application or a thin client application. What makes this more complicated is that your application will need to deal with multiple communication and user interface rendering implementations concurrently.
My suggestion would be to employ agile development processes. If you have not read Lean Software Development: An Agile Toolkit by Mark and Tom Poppendieck then I strongly recommend reading it. One of the tools they cover is in how to delay decisions as long as possible during the development process. One of the benefits of this is that it forces interfaces to be build thereby abstracting the decision. So by using this tool changes in the communication mechanism and/or the user interface will not impact the rest of your application. Future devices with new user interfaces or ways of sending your application data can also easily be added.
Why is m-Commerce not like e-Commerce
m-Commerce applications are considerably more complex. The biggest complexity lies in the user interface and the communication to the back-end server. With e-commerce applications typically a browser with HTML is used for the user interface and HTTP/S is used fro the communication to the back-end server.
With m-Commerce you are dealing with a wide variety of potential devices. Most of devices that will use your system are probably not even built yet. There are a lot of different mobile phones and devices and each one has different criteria in terms of screen size, supported colors and input mechanisms. How do you write a user interface that will work with a wide variety of devices and look good? More importantly in the time it takes to build your m-commerce application a whole new set of device will have been developed. How do you deal with that added complexity?
Then there is the communication to the back-end server. Will your application communicate using HTTP/S, SMS, USSD or another one of the many protocols supported by mobile devices? How will this data be securely transmitted to your back-end server? In future posts I will be looking at how you can decide what to support and how to implement some of these solutions.
With m-Commerce you are dealing with a wide variety of potential devices. Most of devices that will use your system are probably not even built yet. There are a lot of different mobile phones and devices and each one has different criteria in terms of screen size, supported colors and input mechanisms. How do you write a user interface that will work with a wide variety of devices and look good? More importantly in the time it takes to build your m-commerce application a whole new set of device will have been developed. How do you deal with that added complexity?
Then there is the communication to the back-end server. Will your application communicate using HTTP/S, SMS, USSD or another one of the many protocols supported by mobile devices? How will this data be securely transmitted to your back-end server? In future posts I will be looking at how you can decide what to support and how to implement some of these solutions.
Subscribe to:
Posts (Atom)