You've come a long way, and you now have a fully functional mobile sales force application. The last step is to make this application available to an international audience. Your application needs to display dates, currencies, and numbers in the right format when used in different countries or locales. For example, dates are displayed in Japan year first, followed by the month, and then the day. In the U.S. (and most parts of the world), the decimal point is a dot (.), whereas in France, it is a comma (,). Therefore, $1,500 may mean entirely different things in these two countries. The need to present locale-accurate data is even more important when you deal with financial information.
Globalizing your application is actually easier than it sounds. The .NET Compact Framework automatically handles most of the intrinsic formatting of dates and currencies based on the culture used in the regional settings of the device. In fact, you can globalize most of your application without even writing a single line of code at all! In this chapter, you will explore the following:
- How double-byte data can be stored in the database
- How to design culture-sensitive forms within the Visual Studio IDE
- How to programmatically retrieve device culture information
The first thing you need to do to globalize your application would obviously be to support a particular locality's language. Let's take a look at how we can support the display and entry of foreign languages such as East Asian languages. Most East Asian languages are stored in double-byte format. This means that each Chinese or Japanese character takes up two bytes in the database.
Let's take a look at how SQL Server CE and Oracle Lite handles double-byte languages.
To type East Asian characters (such as Chinese, Japanese, or Korean) on a mobile device, you need to have an Input Method Editor (IME) for each language. An IME allows you to type East Asian characters via various methods. For example, a Chinese IME would allow you to use Pinyin, or the phonetic value (in Romanized form), of a character as input. Another method would be to input the strokes of the character. The following screenshot shows an example of a Japanese IME:
Unfortunately for us, Microsoft does not ship or provide for any East Asian IME on the Windows Mobile platform. There is no other way but to download or buy a third-party IME. There are a few open-source and commercial IMEs online that you can explore, such as CEStar (http://www.mobem.com/products/CE-Star.php), ookii.org, and Bagoj's Japanese IME. We will not go into the details of their setup as it would be out of the scope of this book.
It is recommended for you to set up an IME on your emulator or device before proceeding with the examples in this chapter.
You will notice that unlike the desktop-based SQL Server or Oracle versions, which makes distinctions between the VARCHAR and NVARCHAR data types, SQL Server CE and Oracle Lite do not make any such distinction. Both the SQL Server CE and Oracle Lite databases readily support double-byte data.
All you need to remember is that when you pass parameters to the DataAdapter or DataReader objects, you need to declare the VARCHAR parameters using the SqlDbType.NVarChar data type and TEXT parameters using the SqlDbType.NText data types (highlighted as follows).
_adapter.UpdateCommand = new SqlCeCommand("UPDATE AccountTasks
SET TaskSubject=@TaskSubject,
TaskDescription=@TaskDescription, TaskDate=@TaskDate,
TaskStatus=@TaskStatus WHERE TaskID=@TaskID",
_globalConnection, _transaction);
_adapter.UpdateCommand.Parameters.Add("@TaskSubject", SqlDbType.NVarChar, 255, "TaskSubject");
_adapter.UpdateCommand.Parameters.Add("@TaskDescription",
SqlDbType.NText, 16, "TaskDescription");
_adapter.UpdateCommand.Parameters.Add("@TaskDate",
SqlDbType.DateTime, 8, "TaskDate");
_adapter.UpdateCommand.Parameters.Add("@TaskStatus",
SqlDbType.Int, 4, "TaskStatus");
_adapter.UpdateCommand.Parameters.Add("@TaskID",
SqlDbType.Int, 4, "TaskID");
_adapter.DeleteCommand = new SqlCeCommand("DELETE FROM
AccountTasks WHERE TaskID=@TaskID", _globalConnection,
_transaction);
_adapter.DeleteCommand.Parameters.Add("@TaskID",
SqlDbType.Int, 4, "TaskID");
_adapter.InsertCommand = new SqlCeCommand("INSERT INTO
AccountTasks(AccountGUID, TaskSubject, TaskDescription,
TaskCreated, TaskDate, TaskStatus) " + "VALUES
(@AccountGUID, @TaskSubject, @TaskDescription, GETDATE(),
@TaskDate, @TaskStatus)", _globalConnection, _transaction);
_adapter.InsertCommand.Parameters.Add("@AccountGUID", AccountID);
_adapter.InsertCommand.Parameters.Add("@TaskSubject",
SqlDbType.NVarChar, 255, "TaskSubject");
_adapter.InsertCommand.Parameters.Add("@TaskDescription",
SqlDbType.NText, 16, "TaskDescription");
_adapter.InsertCommand.Parameters.Add("@TaskDate",
SqlDbType.DateTime, 8, "TaskDate");
_adapter.InsertCommand.Parameters.Add("@TaskStatus",
SqlDbType.Int, 4, "TaskStatus");
_adapter.Update(Account.Tables["AccountTasks"]);
If you try keying in East Asian characters as the first name or last name of a new account, you will find that you can successfully save East Asian characters to the database for storage and, likewise, retrieve them correctly, as shown in the following screenshot:
The great thing about working with mobile databases is that they're double-byte ready, and this helps remove a great deal of programming otherwise needed to support Unicode formats.