J2ME Clients, .NET Web Service (on IIS) and kSOAP for CLDC 1.0 based devices

If you are about to start building mobile application clients using J2ME which would be accessing a .NET Web Service, you might want to go through this post to save valuable time and effort.

Of late I have been using J2ME Wireless Toolkit 2.5 and have been pretty impressed over the add-ons to the first Wireless Toolkit version that I used in 2002. I still use the simple Sun Studio IDE for building J2ME mobile apps for the familiarity reason.

When it came to accessing web services written in .NET I used the Stub generators (under Utilities) and quickly implemented the consumption of .NET web services. But when I wanted to port the same app to a CLDC 1.0 device, I realized that those devices cannot leverage on the JSR 172 Web Services package. When you change the device settings to target CLDC 1.0 you would get compilation errors because of the lack of support to the Web Services package.

I then figured out couple of ways to deal with the situation.

One was to simply call the Web Service over HTTP and parse the XML response. For example, I make calls like

www.mydummywebserver.com/xyzwebservice.asmx/webservicemethod?argument1=value&argument2=value

and retrieve the XML response as a string. Then I parse them using kXML/NanoXML and retrieve what I want.

The above approach as it seems is quite old-fashioned and you cannot levearage the true benefits of a SOAP based XML Web Service. Therefore, I used kSOAP open source library to connect to the same web service.

import org.ksoap.*;
import org.ksoap.transport.*;
import org.kobjects.serialization.*;
import org.kxml.*;
import org.kxml.io.*;
import org.kxml.parser.*

.

.

.
String endPoint = "www.mydummywebserver.com/xyzwebservice.asmx";
SoapObject method = new SoapObject("NameSpace","webservicemethod");
method.addProperty("argument1", "value");
method.addProperty("argument2", "value");
HttpTransport rpc = new HttpTransport(endPoint, "NameSpace/webservicemethod");
ClassMap cm = new ClassMap(Soap.VER11);
rpc.setClassMap(cm);
String response = (String)rpc.call(method);

But the solution doesn't end here. You will have to spend additional time on .NET Web Services side. The .NET Framework makes a web service appear to be in RPC style to clients. We must make sure that .NET generates WSDL also in RPC style. For this you need to make use of SoapRpCService class level attribute. Example:

<%@ WebService Language="c#" Class="SumService" %>

using System;

using System.Web.Services;

using System.Web.Services.Protocols;

using System.Web.Services.Description;

[SoapRpcService(RoutingStyle=SoapServiceRoutingStyle.SoapAction)]

public class SumService : System.Web.Services.WebService

{

[WebMethod]

public int Add(int a, int b) { return a + b; }

}

If you do not have this, you would get an error which is similar to "org.kxml.io.ParseException: unexpected: @-1:-1". And it would be a hard reialization that it has nothing to do with kSoap library. It is to do with the WSDL style attributes that controls overall SOAP body formatting

To remove the warning on the browser, you might want to add the following code under the section to the config file on the .NET Web Services solution:

Here are some useful links to read on:

SOAP Style Attributes that control SOAP body formatting

Controlling SOAP Formatting and XML Serializations

SoapRpcServiceAttribute Class

.NET CF Helpful Links

• .NET Compact Framework FAQs
• .NET CF Advanced Memory Management
• Insights into .NET CF Garbage Collection
• Performance statistics for .NET CF apps
• Issues with multiple instances
• App Verfier

.NET Data Objects Links

• SQLCommand examples in ADO.NET
• Object Binding
• Object Binding Tips and Tricks in VS2005
• Data Centric Overview
• Filtering and Sorting Data using ADO.NET
• ADO.NET Data Binding with XML

Accessing Web Services

• Creating and Using an ASP.NET Web Service in VS2005
• Calling Web Services asynchronously
• Canceling asynchronous Web Services call

Points to ponder - To choose the best synchronization option

Data Synchronization techniques using SQL Server 2005

What is the Data Synchronization?

In a scenario where multiple applications hold the same sets of data and one of the users change the state of their shared object, this change will have to be propagated to the shared objects of the other users. The process of sending, receiving, and updating data between multiple systems is called Data Synchronization.

The mobile devices scenario

In case of a business solution involving mobile devices, the chances of an update to a central database which is shared is very high. For example, if we consider a sales force automation application, it would have business entities like customers, estimates, invoices, sales receipts and payments. The information regarding each of them can be dynamically updated by different sales men and also by the operator at the corporate server end. In order for everyone to be in sync, data synchronization techniques would have to come into picture.

Though there are numerous databases today which support more than one data synchronization technique, here the emphasis will be on latest techniques available and widely used for Windows Mobile and Symbian based mobile devices.

For Windows Mobile, SQL Server provides very good synchronization techniques via Merge Replication (MR) and Remote Data Access (RDA).

For Symbian, J2ME is one of the widely used application development platforms. J2ME supports raw byte based record stores and does not have a true RDBMS in place. PointBase Micro Database is a database layer on top J2ME record store and provides many features including the ones to perform synchronization and filter.

Replication Model in MS SQL Server

Replication is a set of solutions that allow you to copy, distribute, and potentially modify data across your enterprise. SQL Server 2005 includes several methods and options for replication design, implementation, monitoring, and administration to give you the functionality and flexibility needed for distributing data and maintaining data consistency. The model is composed of Publisher, Distributor, Subscriber, Publications, articles, and subscriptions.

Publisher
The Publisher is a server that makes data available for replication to other servers. The Publisher can have one or more publications, each representing a logically related set of data. In addition to being the server where you specify which data is to be replicated, the Publisher also detects which data has changed during transactional replication and maintains information about all publications at that site.

Distributor
The Distributor is a server that hosts the distribution database and stores history data, and/or transactions and metadata. The role of the Distributor varies depending on which type of replication you implement. A remote Distributor is a server that is separate from the Publisher and is configured as a Distributor of replication. A local Distributor is a server that is configured to be both a Publisher and a Distributor of replication.

Subscribers
Subscribers are servers that receive replicated data. Subscribers subscribe to publications, not to individual articles within a publication, and they subscribe only to the publications that they need, not all of the publications available on a Publisher. Depending on the type of replication and replication options you choose, the Subscriber could also propagate data changes back to the Publisher or republish the data to other Subscribers.

Article
An article is a table of data, a partition of data, or a database object that is specified for replication. An article can be an entire table, certain columns (using a vertical filter), certain rows (using a horizontal filter), a stored procedure or view definition, execution of a stored procedure, a view, an indexed view, or a user-defined function.

Publication
A publication is a collection of one or more articles from one database. This grouping of multiple articles makes it easier to specify a logically related set of data and database objects that you want to replicate together.

Subscription
A subscription is a request for a copy of data or database objects to be replicated. A subscription defines what publication will be received, where, and when, synchronization or data distribution of a subscription can be requested either by the Publisher (a push subscription) or by the Subscriber (a pull subscription). A publication can support a mixture of push and pull subscriptions.

Snapshot Agent
The Snapshot Agent is a replication agent that makes snapshot files, stores the snapshot on the Distributor, and records information about the synchronization status in the distribution database. The Snapshot Agent is used in all replication types (Snapshot, Transactional, and Merge replications), and can be administered by using SQL Server Enterprise Manager.

Log Reader Agent
The Log Reader Agent is a replication agent that moves transactions marked for replication from the transaction log on the Publisher to the distribution database. This replication agent is not used in Snapshot replication.

Distribution Agent
The Distribution Agent is a replication agent that moves the snapshot jobs from the distribution database to Subscribers, and moves all transactions waiting to be distributed to Subscribers. The Distribution Agent is used in Snapshot and Transactional replications, and can be administered by using SQL Server Enterprise Manager.

Merge Agent
The Merge Agent is a replication agent that applies initial snapshot jobs from the publication database tables to Subscribers, and merges incremental data changes that have occurred since the initial snapshot was created. The Merge Agent is used only in Merge replication.

Merge Replication (MR) technique

Merge replication is best used when there are few chances for changes to be made to the same records by different locations. Horizontally segmented tables are useful with merge replication. Separate publications are created and subscribed to, based on a region code or some other discriminatory mechanism.

For merge replication to work properly, some changes are made to the table schema as well as the distribution database. These changes are made to allow SQL Server to perform conflict resolution.

Merge replication is a sophisticated replication type that allows making autonomous changes to replicated data on the Publisher and on the Subscriber. With Merge replication, SQL Server captures all incremental data changes in the source and in the target databases, and reconciles conflicts according to rules you configure or using a custom resolver that you create. Merge replication is best used when there is a need to support autonomous changes of the replicated data on the Publisher and on the Subscriber.

1. The snapshot agent (which lives on the distribution server) takes an initial snapshot of the data and moves it to the subscribers. Remember that the subscribers must first be synchronized with the publishers for replication to begin (with the exception of snapshot replication).
2. A distribution working folder is created on the distribution server to handle merges. 3. Replication now begins.
4. The merge agent takes modifications from the publishers and applies them to the subscribers.
5. The merge agent takes modifications from the subscribers and applies them to the publishers.
The merge agent receives any update conflicts and takes the appropriate action.

SQLServer Mobile Database Engine

The SQL Server Mobile Database Engine manages the local database on a device. For subscription databases, the SQL Server Mobile Database Engine tracks all database records that are inserted, updated, or deleted by maintaining change tracking information with each record.

SQLServer Mobile Client Agent

The SQL Server Mobile Client Agent is the primary SQL Server Mobile replication component on a device. The SQL Server Mobile Client Agent implements the SQL Server Mobile Replication object interface. Applications call this interface to programmatically control replication.

SQLServer Mobile Server Agent

The SQL Server Mobile Server Agent is the component responsible for managing the communication between SQL Server and SQL Server Mobile. The SQL Server Mobile Server Agent resides on the server that is running Microsoft Internet Information Services (IIS), and handles all HTTP requests made by the SQL Server Mobile Client Agent.

SQLServer Reconciler and SQLServer Mobile Replication Provider

The SQL Server Reconciler invokes the SQL Server Mobile Replication Provider when synchronization is performed. Both the SQL Server Reconciler and SQL Server Mobile Replication Provider reside on the server that is running IIS, on which SQL Server Mobile Server Tools is also installed. When the SQL Server Reconciler is started, a Merge Agent at the Publisher is associated with the subscription.

Internally...

* System tables are added to the distribution working folder. These are used to track changes for use during synchronization as well as for conflict resolution.

* SQL Server creates triggers on both the publishing servers and the subscription servers involved in merge replication. These triggers are fired when a data modification occurs in one of the tables involved in replication. Information about the change is stored in the system tables added to the distribution working folder. These saved changes allow you to track changes to each row or column of modified information.

* SQL Server creates a new “uniqueidentifier” column for each row in tables being replicated. A GUID or ROWGUID is then added to uniquely identify that row. In this fashion, when a record is updated at different sources, the different updates can be differentiated.

Remote Data Access (RDA) technique

RDA provides a powerful yet simple way for a Windows Mobile application to access SQL Server data located in a remote SQL Server 2000 SP3a, SQL Server 2000 SP4, or SQL Server 2005 database. RDA can be used whether the Windows Mobile device is continuously connected or intermittently connected to the SQL Server system.

Applications use RDA when they do not need the full functionally of merge replication. You can use RDA without configuring SQL Server replication or creating publications.

Applications can use RDA in two ways. The application can submit a SQL Data Manipulation Language (DML) statement that is forwarded to the SQL Server system for execution.

Alternatively, the application can submit a SQL query that returns a row set. The resulting row set is transmitted to the Windows Mobile device where it is stored in a table. All changes made by the application will be tracked, and at the request of the application, the updated rows will be sent back to the server where they are applied to the SQL Server database.

RDA uses the authentication, authorization, and encryption services of Microsoft Internet Information Server (IIS). It supports anonymous and basic authentication as well as Secure Sockets Layer (SSL) encryption.

Remote data access (RDA) uses three components of Microsoft SQL Server 2005 Mobile Edition (SQL Server Mobile): the SQL Server Mobile Database Engine, the SQL Server Mobile Client Agent, and the SQL Server Mobile Server Agent.

Data Synchronization between Windows PC and Windows Mobile

Though there are multiple ways to make a desktop PC communicate with your mobile device, ActiveSync could be the ideal choice. Unless there is a specific need which demands you to directly read/write from/to a serial port/USB/Bluetooth of a mobile device and a desktop, you could very well use Microsoft’s ActiveSync technology.

Microsoft ActiveSync provides support for synchronizing data between a Windows-based desktop computer and Microsoft Windows CE .NET–based portable devices. Using time stamps and user preferences, the synchronization process tracks data changes on both computers, then transfers the appropriate data so that each machine has the most-recent versions.

If you have some custom application data on your mobile that your would like to sync with your desktop and vice-versa, you could very well go in for the Active Sync mechanism. And the data transfer or syncing or any custom activity that you would like to do on either one or both the ends (device/PC) can take place through Bluetooth, IR, USB or serial cable. The transport mechanism (be it Bluetooth, USM or infra-red) is abstracted from the developer and ActiveSync takes care of that. A user can choose the mode of transport using the ActiveSync client software that comes along with Windows Mobile.

Therefore, apart from the automatic sync capabilities for mail, contacts and appointments that ActiveSync provides, developers could write their own custom-implementation for data synchronization.

ActiveSync is built on a client/server architecture that consists of a service manager (the server) and a service provider (the client):

• The service manager is a synchronization engine built into ActiveSync; it resides on both the desktop computer and the Windows CE–based device. It performs those tasks common to all synchronization — establishing a connection, detecting data changes, resolving conflicts, mapping and transferring data objects. ActiveSync and related software components are shipped with Windows CE platforms and also downloadable from the link provied below.

• The service provider determines which data is tracked for changes by the service manager. It consists of two developer-written modules — the desktop provider on the desktop and the device provider on the device — that perform the synchronization tasks specific to your data. Microsoft provides service managers for several standard Windows applications.

There are two ways desktop applications can be notified that connection has been made with a Windows CE–based device:

• In registry-based notification, connection and disconnection are predefined events, each with its own registry key. Each key can be assigned a command line to be executed when the corresponding event occurs.

• In COM-based notification, two interfaces— IDccMan (provided by Rapi.dll) and IDccManSink (implemented by the application seeking notification) — handle connection/disconnection and related actions.

The fundamental difference between registry- and COM-based notifications is that registry-based notification simply causes a program to run. COM-based notification provides programmatic connection with those applications that want to be notified. This makes possible control of the connection manager, registering and deregistering for connection notification, or any kind of operation best-handled from within the application that creates the data to be synchronized.

But the scenario is totally different for Symbian users. Symbian has lagged behind in creating such powerful push-pull solutions for their users. If you are a symbian user and if you are looking for ActiveSync related technology for Symbian Phones check out EMOZE and RoadSync. Emoze is providing free push-email services for both Windows and Symbian phones.

Reference and reading links

Active Sync * MSDN - ActiveSync * ActiveSync FAQs & Version details * ActiveSync How To - Tutorial

Cross-device application development

Using .NET CF you could only create mobile applications targeting the Windows Mobile platform. And Microsoft would not be taking much of an initiative to change that scenario, just because they are Microsoft and they have a very dominating marketing strategy. I was just wondering if that would be possible using some tool. The search result lead to an interesting product from AppForge called "CrossFire". Here are my thoughts based on the review I did and some contnent on the net.

Crossfire lets you work in the Visual Studio .NET environment using all the familiar visual programming tools and use C# or VB.NET as the programming language to target Symbian, Windows Mobile, Palm, RIM and a few other platforms.

Here is how the whole thing works...

1. Install it - Load Crossfire software on a PC. It gets installed as a plug-in for Visual Studio .NET. The next time you launch Visual Studio .NET, a new "AppForge" menu appears in the main menu bar.

2. Write it - Use the C# or VB.NET language from within Visual Studio .NET to create the application. First, use the Crossfire project template to open a new project and display the AppForge control palette. Next, use the controls to build the user interface. Finally, write code to make the application functional.

3. Test it - To test, simply choose the standard Run menu option in Visual Studio .NET. The application translates and runs in Windows, so you can accurately test and evaluate it without leaving the Visual Studio .NET IDE.

4. Upload it - After completing the application, choose Deploy to Device in the AppForge menu and transfer the application to a handheld device with Crossfire Client installed.

5. Run it - The project runs the same whether in Blackberry®, Palm OS®, Pocket PC, or Symbian OS.

What happens internally?

At a basic level, Crossfire operates by transforming an application written in Visual Basic .NET or C# into a compact form that can be executed by a virtual machine on a particular target device. This virtual machine, highly optimized for each supported mobile platform, provides a gateway to a number of system services exposed through the AppForge namespace. Collectively, these services with the virtual machine itself form a deployable unit known as Crossfire Client. A copy of Crossfire Client must be present on an individual device before any application built with Crossfire (or its predecessor, MobileVB) can run.

You could access the very many Crossfire thin clients from their web site. After the client is installed on the device, you can build your code for any device and it will just work. The net result is that you use the same code and the same tools (with occasional adjustments to make use of the unique abilities of individual devices) to build cross-device applications, and deploy them to as many devices as necessary. The client software for the new devices is constantly being produced by Crossfire and available for download.

It supports everything from user interface to other advanced capabilities. You get support for Bluetooth, TCP/IP, SQL Server CE, Pocket Access, SymbianDB, an object model that supports contacts and calendars on various platforms, synchronization, Unicode, bar code scanners, GPS, basic telephony, and cell-ID, among other features. Crossfire works by taking the IL and transforming it into AppForge's own byte code, which can than be executed by "Booster" packages (downloadable or included with your setup) on supported platforms.

The final executable?

Once the translation into IL is complete from within the Visual Studio environment, a second translation pass begins. The AppForge .NET Translator reads and processes the generated IL and transforms it into a particular byte-code format that is able to be processed by the AppForge Crossfire Client virtual machine. Native implementations of this VM are available for all supported platforms, except BlackBerry. For BlackBerry devices, the Java™ virtual machine supplied with each device provides the native execution engine. Ultimately, these byte codes are packaged into a set of self-installing applications specific to each supported platform.

Conclusion

If an enterprise wishes to build mobile applications using Microsoft technologies and at the same time target multiple platforms, then Appforge's Crossfire is a product to look into. But a developer must understand that it is not a .NET CLR which would execute his mobile application. It would rather be a custom made Appforge client runtime (on the phone) which would execute it.

Everything looks positive about the product. But I guess it is quite a trick to have you pay $30 for getting the client software installed on the mobile devices. A developer seat would cost you $1200. The web site does not talk too clearly on the terms of purchase. In case you are looking at thousands of deployments, then you should look at their enterprise edition which would make you pay less for the client software as the number of copies keeps increasing starting from 18$ to 4$.

I guess AppForge would be the a nice bet for companies who have enough .NET talent. They need not re-invent the wheel by learning other technologies like Jave Micro Edition (J2ME) or Symbian C++ to target multiple platforms. It would definitely make them reach the market faster and quickly gather a rich client-tele whose demands might be for different devices on different platforms. And also with the rich Control Set exposed by crossfire, .NET programmers can tap into advanced features in quick time.

The major worrying factors would be the costing factor; especially for small players. I also guess the when it comes to deployment it wouldn't be as seamless as J2ME or .NET CF. And CorssFire's online community might not be as huge and as proficient as Java or .NET CF for that matter.

Features * Developers

Web Services ... an extended arm for mobile apps

Mobile hand held devices have a minimal capabilities based on the hardware and underlying OS. Even if you have the best mobile device in the world today, it cannot no where be compared to the powers of the desktop just for the simple fact that it is void of such powerful hardware, software and memory resources.

Therefore, the need to connect to powerful machines which has some exposed functionality that could be invoked by a client. For example an application on the mobile may connect to a web service to get live quotes via an exposed Web Service. This is just a typical example even though the scope of web services is quite mighty.

As defined by the W3C, Web Services has been here for a decent time now. Let us understand the basics and learn some important aspects of the same though we would be targeting to design web services for mobile devices.

So, what is a web service?

A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts, and supports direct interactions with other software applications using XML-based messages via Internet-based protocols.

W3C definition of a web service requires an XML-based description mechanism of some kind (such as WSDL) that can be used to describe the service's form and function. The parent for this industry-wide initiative around Web service technologies is a service-oriented architecture. As such, a non-XML based description mechanism (like IDL) would make an SOA implementation more complex and less open.

Web Services and Others...

Most of the web sites that talk about Web Services have a misinterpretation that Web Services require SOAP and SOAP works ONLY over HTTP. That is not true. Let us differentiate Web Services and other similar forms of technologies.

• Web services are software components that are developed using specific technologies from three primary technology categories:
• An XML-based description format (for example, WSDL)
• An application messaging protocol (for example, SOAP)
• A collection or transport protocol (for example, HTTP)

In each of these categories, there are proprietary (vendor- or platform-specific) technologies as well as open (vendor- or platform-independent) technologies available.

• Service-oriented applications include applications that MAY make use of Web service technologies such as SOAP but MAY NOT include a WSDL or other XML-based description. Such applications are considered Web-service-like but are not technically Web services.

Domain of Web service protocols

• Enterprise Web services are Web services that do provide a WSDL description but MAY make use of proprietary application messaging or transport protocols. An example of such a service would be one that sends SOAP messages over IBM MQSeries using JMS.
• Internet Web services are enterprise Web services that MUST only use open application messaging or transport protocols. An example of such a service would be one that sends OTA XML messages over HTTP.
• XML Web services represent the very small subset of Internet Web services that MUST use the W3C's adopted XML-based messaging protocol over a narrow range of transport protocols. Specifically, XML Web services will only send SOAP messages, and only send them over HTTP, SMTP, or raw TCP/IP connections.

Web Service Operation Modes

• RPC/encoded. Its strengths are its straightforward nature and that the receiver has an easy time dispatching this message to the implementation of the operation. Its weakness is that its type encoding info is usually just overhead, which degrades throughput performance.
• RPC/literal. Its strengths are the same as the encoded version and it is compliant with the WS-I Organization specifications.
• Document/literal. Its strengths are that there is no type encoding info, and any XML validator can validate the messages. Its weakness is that the operation name in the SOAP message is lost, so dispatching can range from difficult to impossible.

It is important that we do not have a preference for either synchronous or asynchronous implementations and for either RPC or document exchange style. Decisions should be based on how the business objectives may be realized.

Web services have always been designed to be applicable to at least two fundamental programming models: remote procedure calls (RPC) and document exchange.

RPC implies a client/server model in which the client requests that a specific activity be performed by the server and the results of that activity be immediately returned to the client. Communication in the RPC model is most often synchronous, and requested operations generally represent fine-grained, individual work items

Document exchanges are typically asynchronous and involve moving business documents (a purchase order, for example) between peer partners.

Unfortunately, the distinction between document- and RPC-style Web services is becoming extremely blurred through poor usage and corruption of the terminology.

What many Web services implementations currently call document-style Web services are actually RPC-style Web services that use one particular mechanism for defining and validating the content of the Web service messages exchanged. Quite funny? Try implementing these concepts. J

References Best practices for Web services * Designing mobile web services

Other links Top 5 mistakes while designing web services

Symbian - An Overview

Symbian is a consistent user interface having a comprehensive set of PIM (Personal Information Manager) and optional third party applications. It is a pre-emptive multitasking, multithreading, memory protection, event-based Operating System for mobile devices. It's special features include conserving memory, reliability, CPU. It also has the capability to being switched off when applications are not dealing with events.

From a developer’s perspective Symbian is an operating system for handheld devices with limited resources for UI framework, C++ based APIs and tools. J2ME is also one of the widely used technologies to target the Symbian platform.

General - Hardware Resources

CPU: ARM, 32-bit, 36-220 MHz
ROM: OS, middleware, applications, Z: drive
RAM: working memory, “disk” space, C: drive
I/O: keypad, pen input, CF card slot, CCD camera
Communication: GSM/GPRS/UMTS, infrared, Bluetooth Power source: rechargable battery 2000-3000 mWh (600-900 mAh, 3.5 V)
Display: 176x208 pixels, 65536 colors for smartphones

Memory Organization and Disk Drives

• RAM - runtime memory (stack, heap)
• C: Flash-RAM - application files, user files
• D, E, ... compact flash cards, memory sticks - application files, user files
• Z: ROM - operating system files

Classifications and OS flavors

Series 60

• OS: Symbian OS 7.0s
• CPU: ARM-9, 104 Mhz
• Memory * heap size: 3 MB * storage: 6 MB + MMC
• Display * 65536 colors * 176 x 208 pixels
• Interaction * numeric keypad * 2 labeled soft keys * 5-way direction key
  Infrared, Bluetooth Camera: 640 x 480 pixels
• Java: CLDC 1.0, MIDP 2.0 * Wireless Messaging API (JSR-120) * Mobile Media API (JSR-135) * Bluetooth API (JSR-82 No OBEX)
• Example: Nokia 6600

Series 80

• OS: Symbian OS 7.0s
• CPU: ARM-based, ~150 MHz
• Memory * heap size: 20 MB * storage: 80 MB + MMC
• Display * 65536 colors * 128 x 128 pixels (outside) * 640 x 200 pixels (inside)
• Interaction * numeric and qwerty keypads * 3 labeled soft keys * 9-way direction key
  Infrared, Bluetooth
• Java CLDC 1.1, MIDP 2.0 * Wireless Messaging API (JSR-120) * Mobile Media API (JSR-135) * Bluetooth API (JSR-82 No OBEX) * FileConnection and PIM API (JSR-75)
• Java CDC 1.0 (JSR-36) * Personal Profile (JSR-62) * Foundation Profile (JSR-46)
• Example: Nokia 9300

UIQ Series

• OS: Symbian OS 7.0 CPU: ARM-9, 156 MHz
• Memory * heap size: 32 MB * storage: 64 MB + Memory Stick
• Display (touch sensitive) * 262000 colors * 208 x 320 pixels
• Interaction * stylus on touchscreen * numeric and qwerty keypad * 5-way direction key * Infrared, Bluetooth • Camera: 640 x 480 pixels
• Java * CLDC 1.1 * MIDP 2.0
• Example: Sony Ericsson P910

Software Components and their purpose

• Kernel - Manages and controls access to hardware resources, hardware-supported privileges, kernel mode
• Application - Program with a user interface, Runs in user mode in its own process
• Server - Program without a user interface; manages resources, provides interface to clients
• Engine - Application part that manipulates data, often separate DLL

Processes, Threads, and Context Switching

• Process: fundamental unit of protection * Own address space * virtual addresses –MMU * physical addresses
• Thread: fundamental unit of execution * one or more per process * preemptively scheduled by the kernel
• Context switching: changing threads * expensive between two threads in different processes * typically just one thread per process * active objects

Kernel and User Library

• Kernel runs in privileged mode
• Kernel server: highest-priority thread in system
• User library (euser.lib): basic library and kernel access
  * entirely user-side (e.g. descriptors, arrays)
  * cross into kernel executive (e.g. time checking)
  * request services of the kernel server

Event Handling and Active Objects

• Symbian optimized for efficient event handling
• Active objects and active schedulers
  * non-preemptive event handling within a single thread
  * well-suited for GUI systems
  * active objects call asynchronous methods or register for events
  * active scheduler calls RunL method of active object

Client-Server Framework

• Most important servers
  * file server: operations on files
  * window server: user input, screen drawing
  * communications, databases, schedule, contacts, etc.
• Client-server interface
  * server proxy in client’s address space (e.g. RFile, RWindow)
  * kernel-supported message passing
  * inter-thread read / write: server can access client’s address space

More Reading:

• www.symbian.com/developer/techlib/papers/SymbOS_def/symbian_os_sysdef.pdf

References:

• Mobile Application For Mobile Devices (Symbian) – By Michael Rohs
• http://www.symbian.com/developer/tech_papers/index.html

Basic understanding of Windows Mobile OS

We have seen the emerging trends in hand held devices right from palm held PC, hand held PC to Pocket PC and Windows Mobile. The objective of this white paper would be to make the reader comfortable with the various terminologies used in the mobile world and will specifically be targeting at mobile device operating systems from Microsoft.

What is a Windows Mobile Powered device?

A Windows Mobile powered device is a handheld device powered by the Windows Mobile platform. It allows one to retrieve e-mail, keep track of one’s schedule and contacts, browse the Internet, send and receive text messages, read and compose Microsoft Word Mobile files, make Microsoft Excel Mobile charts, and view Microsoft PowerPoint presentations.

Windows Mobile is a rich platform that allows one to download third-party software for customization. Businesses use Windows Mobile powered devices to help their employees keep in touch while out of the office.

The Windows Mobile platform is available on a variety of devices from a variety of wireless operators.

Pocket PC vs. Smart Phone

Pocket PCs come with mobile versions of Office applications in addition to Microsoft Outlook Mobile. Though there are different Pocket PCs, many come with Wi-Fi to enable one to connect to the Internet using a wireless hotspot other than the lower end GPRS connectivity.

A smart phone has phone capabilities and comes with a smaller set of applications. Though one can add third-party software titles to smart phones, the smaller keypad and screen are designed to give quick one-handed access to important data. A smart phone is a good choice for business users who need to check e-mail, keep track of their calendars, and take voice notes, but who do not need the added functionality of Word Mobile, Excel Mobile, and PowerPoint Mobile.

Windows Compact Edition (Win CE) and Platform Builder

The Windows Compact Edition is a real-time, pre-emptive, multi-tasking operating system built from the ground up to become an OS built with multiple components. It is not a finished product that is shipped by Microsoft. It is basically composed of Platform Builder and a very large collection of software bits which the OEMs use to port it on their devices.

This collection is the superset with all available bits and pieces of software like UI, browsers that come in the form of DLLs and LIBs. And an OEM need not have everything shipped into his device. He can pick and choose what needs to get into the device.

Platform Builder is the integrated development environment for building, debugging, and deploying a customized embedded OS based on Windows CE. It is used to select the components that one wants in his version of Windows CE OS to contain. He can get to choose basic things like a UI, file system, network components and browser.

And based on the chosen components the OS memory footprint could vary from 250kb to 24MB OS. Platform Builder also doubles as a workbench for creating one’s own C++ projects that need the OS aimed at building device driver components and other helper modules. And finally the OS is built. When the OS is built, Platform Builder then morphs into an OS debugging environment allowing the developer to deploy the OS image to a remote embedded computer or to emulation environment and then step into the OS and debug right down to the kernel and see what is going on.

But this methodology has its own drawbacks. A developer cannot write software hoping that the targeted device’s OS will have the required API needed by his application. Therefore, the embedded solution might not work similarly on all devices.The solution was to have a baseline for the minimum set of features and functions that one can trust a device to posses. Microsoft Windows Mobile does that. But for that one needs to be aware of the difference between a Win CE.NET and the other Win CE versions.

Windows Compact Edition Flavors

Here is a brief listing of the Win CE versions and their supported device versions and notice that the naming/branding of the devices and operating systems kept changing from time to time.

Windows CE 2.0
- Serves as the underlying OS for Palm Sized PC, Handheld PC

Windows CE 3.0
- Serves as the underlying OS for PPC, Handheld PC 2000, PPC 2002, Smart phone 2002

Windows CE 4.2
- Serves as the underlying OS for:

Windows Mobile 2003 for PPC 2003
Windows Mobile 2003 for Pocket PC 2003 Phone Edition
Windows Mobile 2003 for Smart phone 2003
Windows Mobile 2003 SE for PPC 2003 Second Edition
Windows Mobile 2003 SE PPC 2003 Phone Second Edition
Windows Mobile 2003 SE for Smart phone 2003 Second Edition

The launch of Windows Mobile software extended the Windows brand to the Pocket PC and Smart phone mobile device categories. It also helped customers more readily understand the consistent user experience they can expect from the software inside Pocket PCs and Smart phones.

By standardizing core hardware requirements and providing a consistent set of programming APIs, Windows Mobile 2003 provided a consistent application development environment across devices.

Windows CE 5.0
- Serves as the underlying OS for Windows Mobile 5.0.

Microsoft announced Windows Mobile™ 5.0 (originally code named “Magneto”), was released on May 2005. It is powered by Windows CE 5.0 and uses the .NET Compact Framework - an environment for programs based on .NET to be used.Windows Mobile 2003 software for the Pocket PC builds on Windows CE by adding new functionality, user interface, and applications to create an optimized mobile computing platform for handheld devices.

Specifically, Windows Mobile 5.0 is based on Windows CE 5.0, Windows Mobile 2003 is based on Windows CE .NET 4.2 while Windows for Pocket PC 2002 utilizes Windows CE 3.0.

The developer perspective

Even though the standardization has taken place, many developers feel that it is still not in practice as OEMs freely over step the guidelines in place. Therefore, a developer's code that was supposed to be running on the standard platform exposed by Windows Mobile would not run.
Marcus Parryman in his article on MSDN blogs, feels that Windows Mobile as an OS has to tread a fine line between providing an unmovable target (in terms of its SDK) for developers to have confidence that their code base will work on any device branded with the 'Windows Mobile' logo and providing sufficient flexibility for OEM's (the guys that make and sell the hardware) and Operators to differentiate their handset or device in a competitive market.

”An OEM is provided with the basic bits to build the OS. He is also given the compatibility documentation that describes exactly what features must be present. It also defines the 'look and feel' and indicating areas the OEM can add changes to the OS. Microsoft also uses a compatibility lab to ensure consistency across devices.All others tools and SDKs might fall under the third party software category, which the OEM might or might not load onto the ROM. It is totally up to the OEM to decide on the additional components. So a developer cannot be assured that such components will be available with all the targeted devices.

References:
Microsoft and Marcus ParryMan's blog at MSDN Blogs

http://www.microsoft.com/windowsmobile

http://blogs.msdn.com/marcpe/archive/2005/04/22/410778.aspx

http://www.microsoft.com/downloads/details.aspx?FamilyID=111fe6d5-b0e1-4887-8070-be828e50faa9&DisplayLang=en

http://www.pocketpcfaq.com/faqs/comparison/index.htm

The Wireless Programming Space

I should say I have been lucky to keep bouncing back to one of my areas of interests on the professional space – embedded wireless programming. After a small research that I did, the findings were that the Symbian and Windows mobile were the two predominantly targeted platforms on the mobile devices and both of them were rapidly growing.

* Though both the platforms support a variety of programming languages, in recent times J2ME (Sun Java 2 Micro Edition) and .NETCF (Microsoft Compact Framework) remain to be the mostly sought after languages from the developer perspective.

* Emerging alternatives - which support the developer community to target multi-platforms.

And to my surprise it was tough to find a good place on the web which talked about both – the platform basics and the embedded mobile programming aspects. I mean, I had to go to different places to learn different concepts. My up coming posts would be covering the basics that any mobile application developer would be required to understand.

Another blog...

After a personal web log followed by a cooking blog (which was started mainly to kill time and boredom), I thought this is the right time to have a tech blog as I am sure that I am going to spend most of my time on technical stuff. The birth of this blog is just not because that my work demands it, but more as a result of an interest in pursuing the same idea for quite some time now. I am sure the learning and experiences on new technologies is going to bloat and therefore the birth of Kamz Tech Talk.

Even though I do not want to primarily target a particular domain, initially the topics would revolve around the wireless world, Windows Mobile, .NET Compact Framework, Symbian, J2ME, .NET Web Services and the likes. Leaving the rest to the future.

I hope that this blog would help me keep account of all the learning and would also aid the new comers to the technologies discussed, in whatever way possible. It would also enable tech discussions from developers around the world. Its time to roll!