Overview

J2ME and .Net CF are platforms for managed smart mobile clients. They are critical new technologies for advanced mobile commerce. Compared with micro-browser technologies such as WAP, smart clients

·     support rich user interfaces,

·     leverage device extensions (e.g., GPS and bar-code scanners)

·     support more flexible integration and security schemes

·     reduce network traffic and improve transactional stability through on-device data storage.

·     Java- or .Net-managed environments greatly improve developer productivity, application reliability, and mobile code security.

Overview of the .Net Compact Framework

Designed for mobile computing, .Net CF is a lightweight version of Microsoft's .Net Framework. The .Net CF Common Language Runtime (CLR) runs standard .Net byte code applications. .Net CF contains a subset of standard .Net API libraries necessary for mobile application development. It runs only on Windows CE/Pocket PC-powered high-end PDAs.

Code written on the .NET Framework platform is called managed code. The term "managed code" refers to the fact that the Common Language Runtime (CLR) provides several assurances for such code:

·     Managed code cannot have bad pointers.

·     Managed code cannot create memory leaks.

·     Managed code supports strong type-safety.

Furthermore, in the .Net compact framework

·     28 of the 35 desktop controls are supported in the .NET Compact Framework. These controls are enhanced for the size and performance requirements in the Compact Framework.

·     Not all .NET properties, methods, and events are supported in the Compact Framework controls.

·     Supports the same Win32 API Access mechanism as the .NET Framework but has a simplified data marshalling layer.

·     OLE DB Wrapper – Not supported in .NET Compact Framework.

·     Datagrids – Not built in to the editing support as in the .NET Framework. The .NET Compact Framework can only bind Datagrids to a single table object. The .NET Compact Framework only displays rows from a single table, and these are not able to be expanded as in the .NET Framework.

·     Infrared Data Association classes - .NET Compact Framework provides for making infrared connections and Web listening classes for HTTP services to devices. These are not available on .NET Framework.

·     Infrared send/receive – The .NET Compact Framework includes new APIs that allow applications to send and receive information over the IR port. This feature is not present on the .NET Framework.

·     Serialization - Due to performance considerations, .NET Compact Framework does not support binary serialization using BinaryFormatter, or SOAP serialization using SoapFormatter. There is, however, support for serialization to transmit object data using SOAP in XML Web Services.

·     Web services - Although .NET Compact Framework applications can consume Web services, they can't provide them due to the lack of a Web server.

·     XML support - Scaled-down XML support is available. .NET Compact Framework applications will have full support for reading and writing XML using the reader and writer classes, but they won't have support for XSLT or XPATH as these are resource consumptive.

·     Threads - .NET Compact Framework does not support priorities as in the .NET Framework.

·     Web Services – Only client implementation is supported in the .NET Compact Framework.

·     Win32 Calls - .NET Compact Framework does not support calls from Win32; you can make calls from Compact Framework into Win32. Communication between Win32 and Compact Framework is done by MessageWindows class.

Overview of J2ME

In the Java camp, the situation is more complex. J2ME contains standardized configurations and profiles designed to provide the best compromise between portability and performance for a range of mobile devices. Configurations support the Java core APIs. Profiles are built on top of configurations to support device-specific features such as networking and UIs. Each valid combination of configuration and profile targets a specific type of device:

·     Profiles on top of the Connected Device Configuration (CDC) target high-end networked devices. Those devices have similar hardware capabilities as .Net CF devices. The CDC includes a standard Java 2 Virtual Machine so it can run standard Java byte code and utilize Java 2 Platform, Standard Edition (J2SE) libraries if desired. The CDC Personal Profile has roughly the same functionality as the older PersonalJava environment.

·     Profiles on top of the Connected Limited Device Configuration (CLDC) target low-end PDAs and small cell phones. The CLDC uses a small footprint VM that is not compatible with J2SE or the CDC.

Limitations of CLDC include:

·     No floating point support.  Since many of the processors used in the target platforms for CLDC do not have floating point hardware, the virtual machine is not required to support floating point operations. In terms of the virtual machine, this means that certain byte code operations are not implemented.This leads to the following coding restrictions:

o      Variables of type float and double and arrays of these types cannot be declared or used.

o      Constants of type float and double (i.e., 1.0, 2.0F) cannot be used.

o      Method arguments may not be of type float or double.

o      Methods may not return double or float values.

o      Objects of type Float and Double cannot be created (and, in fact, these classes do not exist in CLDC)

Note that Sun does not supply a different version of its Java compiler for use when developing CLDC applications, so it is possible, using a J2SE compiler, to create Java class files that use floating point types and, therefore, violate these rules. However, these class files will be rejected when they are loaded into the CLDC virtual machine during class file verification.

Aside from the floating point restrictions, there are a few other Java language features that are not available to CLDC applications:

·     Reflection.  The java.lang.reflect package and all of the features of java.lang.Class that are connected with reflection are not available. This restriction is applied partly to save memory, but it also saves having to determine whether application code has the privilege to access these features.

·     Weak references.  Weak references and the java.lang.ref package are not provided because of the memory required to implement them.

·     Object finalization.  Object finalization causes great complexity in the VM for relatively little benefit. Therefore, finalization is not implemented, and the CLDC java.lang.Object class does not have a finalize( ) method.

·     Threading features.  CLDC provides threads, but it does not allow the creation of a daemon thread (a thread that is automatically terminated when all non-daemon threads in the VM terminate) or thread groups.

·     Errors and exceptions.  J2SE has a large number of classes that represent error and exception conditions.  Since Java applications are not, in general, expected to recover from errors (meaning thrown exceptions derived from the class java.lang.Error), most of the classes

·     J2ME in a Nutshell.  representing them are not included in the CLDC platform. When such an error occurs, the device is responsible for taking appropriate action instead of reporting it to application code.

·     Java Native Interface.  CLDC does not provide the J2SE JNI feature, which allows native code to be called from Java classes. JNI is omitted partly because it is memory-intensive to implement and partly in order to protect CLDC devices against security problems caused by malicious application code.

Multiple platforms

.Net CF supports only one OS platform—Windows. One could argue that .Net CF is cross platform to some degree because of the CLR. Windows CE and Pocket PC operating systems run on more than 200 different devices. .Net CF applications are directly portable across those devices only.

For many mobile developers, having their applications run on multiple platforms with minimum effort proves absolutely essential. This is where Java really shines. Many of the mobile platforms now have built-in Java support. Such platforms include:

·     On cell phone devices: Motorola iDEN, Nokia Symbian OS, and Qualcomm Brew, Nokia Series 40.

·     On low-end PDAs: Palm OS.

·     On embedded or telematics devicesL QNX Software Systems and Wind River's VxWorks. 

·     On high-end PDAs: Symbian OS and different Linux flavours

Third-party J2ME runtimes from Insignia and IBM are available for all mobile platforms, including all Windows flavors. The Java approach allows developers to be productive across many mobile platforms.

However, Write Once, Run Anywhere is easier said than done. Given the variety of mobile devices, the lowest common denominator approach does not work. Quite a few standard J2ME extensions and optional packages support various features unavailable on every device (e.g., SMS (Short Message Service) and multimedia playback), which could confuse new developers. Device vendors also tend to add value to their solutions by providing proprietary J2ME extension packages. Even for well-defined standard J2ME platforms, such as MIDP (Mobile Information Device Profile), different vendors have slightly different implementations. Thus, for J2ME to keep its cross-platform promise, we must put more effort into the standardization process.

Multiple languages

A much-touted benefit of .Net is its ability to support multiple programming languages. That ensures that .Net CF can reach a variety of developers and reuse existing libraries. However, due to the object-oriented nature of the .Net CLR, developers must be familiar with object-oriented programming concepts before they can write effective .Net code. The .Net CF development tool, VS.Net, currently supports only two major .Net languages: C# and VB.Net.

Web services

XML Web services are the key to future enterprise integration. SOAP (Simple Object Access Protocol) is becoming the ubiquitous protocol for accessing componentized enterprise back ends. Being an early adopter and promoter of SOAP Web services, Microsoft has a head start on Web services integration with mobile devices. With the support from VS.Net, consuming Web services in .Net CF applications is easy. In many cases, developers do not need to write any code and can just treat the remote service as a local object.

On J2ME, SOAP client support is currently not standardized. We must rely on third-party J2ME SOAP libraries, such as the open source kSOAP, to build mobile SOAP clients. Popular J2ME IDEs such as Sun ONE Studio, CodeWarrior Wireless Studio, and WebSphere Studio Device Developer have recently added SOAP client stub generators for kSOAP. Oracle supports J2ME Web services clients through its upcoming 9i wireless application server. The server communicates with J2ME clients using a proprietary RPC (remote procedure call) protocol and relays SOAP messages. In the future, the J2ME Web Services Specification (JSR 172, available in third quarter 2003) will likely standardize J2ME Web services client APIs.

Development

One of the most compelling reasons for choosing .Net CF or J2ME is to leverage existing developer skills. The list below summarizes available mobile application platforms and developer groups most likely to adopt them:

.Net CF development tools

Microsoft's flagship IDE Visual Studio .Net is an excellent product that provides similar design interfaces for desktop and mobile applications. For example, to migrate a desktop UI design to .Net CF, you merely copy and paste visual components to a new designer window. VS.Net also features strong support for Web services integration and relational database access. Most auto-generated code snippets are easy to read and modify by hand.

VS.Net is tightly integrated with Visio Enterprise Network Tools edition, which can generate C# or VB.Net code from your UML (Unified Modeling Language) diagrams. VS.Net supports debugging on both high-fidelity emulators and real devices. However, VS.Net is not cheap. As of today, no free command-line tool exists for .Net CF development. Nor does any third-party IDE product support .Net CF. More tools will be available in the future when .Net CF matures.

J2ME development tools

On the J2ME front, command-line tools and vendor-specific toolkits are readily available. Sun's J2ME Wireless ToolKit is a widely used MIDP development tool. Antenna is an open source project that extends Java's de facto Ant build tool to J2ME. But of course, for most developers, IDEs are still essential. All major Java IDEs now have J2ME modules or plug-ins:

·     Sun ONE Studio Community Edition with wireless modules is free and has excellent support for enterprise features.

·     JBuilder with MobileSet has a great visual UI designer and good UML design support.

·     CodeWarrior Wireless Studio is bundled with many useful third-party tools. It supports development on both CLDC and CDC/PersonalJava.

·     IBM WebSphere Studio Device Developer is based on the popular Eclipse IDE platform. It supports both on-device and emulator debugging. If you choose one of IBM's smart mobile middleware solutions, WebSphere Studio Device Developer is naturally the best tool.

·     Oracle9i JDeveloper IDE helps integration between Oracle mobile servers and J2ME clients.

·     Data Representation's Simplicity IDE has visual designers not only for UI components, but also for end-to-end communication logic components, such as an XML-based transaction engine. Simplicity supports integration with legacy (mainframe) information servers through a visual screen reader.

Features

Borrowed from http://www.enterprisej2me.com/pages/yuan/articles/jw-0221-wireless.html