.NET As A Platform For Wireless Applications
Juha Järvensivu and Tommi Mikkonen
Institute of Software Systems, Tampere University Of Technology, Korkeakoulunkatu 1,
33720 Tampere, Finland
Abstract: Wireless applications implemented in mobile gadgets are a new
trend in software development. One platform on top of which such applications
can be implemented is Windows, where two different flavours of design envi-
ronments are available. .NET Framework (.NET) is aimed at full-fledged com-
puting environments, and it is used in e.g. laptops. In contrast, .NET Compact
Framework (.NETCF) is for smartphones and PDAs that consist of more re-
stricted hardware. From the development perspective .NET and .NETCF are
closely related as they rely on the same application model. Moreover, .NETCF
is a subset of .NET environment, with features that are not relevant in smart-
phones or PDAs removed. Therefore, it seems tempting to run the same appli-
cations in all wireless Windows environments, disregarding the type of the de-
vice. In this paper, we analyze the possibilities achieving this goal in practise.
1 Introduction
Wireless applications are gaining more and more interest due to the increasing num-
ber of devices. One family of such devices is based on Windows, where two slightly
different platforms are available: .NET Framework (.NET for short) and its simplified
version .NET Compact Framework (.NETCF). Of these platforms, .NET is aiming at
devices that run on e.g. laptops. In contrast, .NETCF is targeted for smartphones and
PDAs that run on more restricted hardware.
Despite being targeted to different types of devices, .NET and .NETCF are closely
related,
however. In particular, they share the same basic infrastructure and applica-
tion model. Moreover, .NETCF is a subset of .NET, with only features that are not
suited for a restricted environment removed. Therefore, it is tempting and in fact
seemingly straightforward to develop applications that run unaltered in all wireless
Windows environments.
This paper studies the possibility to design and implement such wireless applica-
tio
ns. The study is structured as follows. Section 2 discusses the main commonalities
and differences of .NET and .NETCF. Section 3 introduces some principal problems
in designing wireless applications for .NET and .NETCF environment. Section 4
introduces a simple framework that allows common application development for all
wireless Windows clients. Then, Section 5 introduces a sample application that has
been implemented using the framework. Section 6 presents an evaluation of experi-
ences gained when designing the application. Finally, Section 7 concludes the paper.
Järvensivu J. and Mikkonen T. (2005).
.NET As A Platform For Wireless Applications.
In Proceedings of the 4th International Workshop on Wireless Information Systems, pages 104-113
DOI: 10.5220/0002557801040113
Copyright
c
SciTePress
2 Overview of .NET and .NETCF
In this section, we give an overview of .NET and its smartphone and PDA capable
version, .NETCF. The focus of the presentation is on the properties that are important
for wireless setting.
2.1 Platform Principles
Perhaps the most important technical aspect of .NET platform is the definition of an
intermediate representation for executables. This representation is called MSIL (Mi-
crosoft Intermediate Language). All composed .NET programs are first compiled to
MSIL, and only immediately before execution, they are compiled to executables
using Just-In-Time (JIT) compilation techniques. For a developer, this decision
means that several programming languages can be used, assuming that a compiler is
provided for generating MSIL from the used language. Furthermore, porting of the
whole .NET system is eased, as it is enough to produce MSIL-to-platform compiler
per hardware platform, not one for every supported language.
The use of MSIL and JIT requires support at run-time. This support has been im-
plemented in software component called CLR (Common Language Runtime), which
forms the runtime environment of .NET. The use of JIT compilation is optimized so
that code is compiled the first time it is needed. After the compilation, it is stored in
the memory in the compiled form as long as the program is active. As a consequence,
the first call of a method is slower than subsequent calls. In addition to JIT compila-
tion, CLR also handles memory management. It provides facilities similar to those of
Java to prevent memory garbaging.
2.2 Web Services in .NET
One of the main elements of .NET is eased development of applications that use Web
Services. By definition, Web Services provide means for accessing services offered
by the Internet. In the sense of implementation, Web Services use the following tech-
niques.
Web Services are accessed using SOAP protocol (Simple Object Access Protocol).
A SOAP message is a text based XML document (External Markup Language) for
exchanging messages between two pieces of software that may run in different com-
puters. A SOAP does not define any protocol for transferring messages over internet
but HTTP protocol (Hyper Text Transfer Protocol) is commonly used. SOAP mes-
sage is a simple one-way message where the sender does not receive a response. The
receiver could, however, send a response back to the sender. Then both pieces of
software have to work as sender and receiver.
In the technical sense a SOAP message is an XML document, which contains a
header element and a body element. The header element contains application specific
information about SOAP message and the body element contains the actual SOAP
message.
105
WSDL (Web Service Definition Language) is an XML document that defines Web
Service’s interface offered to the client. WSDL contain all the information required
for writing a client for a particular Web Service. It is specifies the location of the
service and the operations the service exposes.
2.3 .NET Libraries
Libraries of .NET can be divided to four categories. The first category includes all
basic classes needed in every application. This category is called BFC (Basic Frame-
work Classes). Such classes include Object, String, Thread, and Type. Object class is
the root class of the class hierarchy of .NET. It provides some low-level services to
derived classes. Similarly, Type is the abstract root class of the reflection functionality
and is the primary way to access metadata. Type is used to get information about the
type declaration, such as constructors, methods, and events of classes.
The second category is called ADO.NET. ADO.NET is a set of classes that expose
data access services. ADO.NET is an essential part of .NET providing access to rela-
tional data, XML documents and application data.
The third category is discussed about ASP.NET. ASP.NET allows the design of web
applications and provides support for Web Services described above.
The fourth category is called Windows.Forms that contains classes for implementing
graphical user interfaces.
2.4 .NET Compact Framework
.NET has been squeezed to smaller size under the name .NET Compact Framework
(.NETCF). This has required the removal of several libraries and other facilities that
are not essential in smartphones or PDAs.
Based on the target devices and their requirements, ASP.NET has not been in-
cluded in .NETCF, as it has not been considered adequate for restricted devices.
However, other categories of libraries are included, at least to some extent. While the
libraries are in principle included in the platform, there are some challenges to be
tacked that need explicit attention in practice.
3 Principal Problems
In the following, we discuss some principal problems that prevent the use of same
software in wireless devices disregarding whether they rely on .NET and .NETCF in
their implementation.
3.1 Graphical User Interface
Perhaps the most obvious challenge regarding the compatibility of a wireless applica-
tion results from user interface. Some devices contain a full qwerty-keyboard, some
106
others are to be used with a pen, and some are to be used with one hand only. As a
result, graphical components and especially their convenient layout vary, together
with the pattern of user interactions needed for using the device. In the case of .NET
and .NETCF, the following differences have been identified.
In both .NET and .NETCF environments, the user interface layout is typically de-
signed with the Dialog editor integrated in Visual Studio. Unfortunately resource file
format of .NET and .NETCF are incompatible. The difference lies in allowed serial-
ized types. When a type is a serializable, it means that its state can be saved and re-
stored. .NETCF only allows a fixed number of types to be binary serialized, whereas
.NET is fully extensible.
Regarding the actual application design, the main difference in GUI programming
is that .NETCF does not support all user interface components provided in full .NET.
It is also important to note that if the same class exist in both .NET and .NETCF, this
does not mean that .NETCF version includes all the methods, properties and events
from the full version. Sometimes a class is not implemented at all, and sometimes it is
only partially implemented. When composing a program, the designer that is familiar
with .NET but not with .NETCF is bound to hit such classes frequently. As an exam-
ple, Table 1 lists public methods of ListView class in .NET .NETCF.
Table 1. ListView public methods not supported by .NETCF
ListView .NET .NETCF
ArrangeIcons YES NO
BeginUpdate YES YES
Clear YES YES
EndUpdate YES YES
EnsureVisible YES YES
GetItemAt YES NO
GetItemRect YES NO
Sort YES NO
ToString YES YES
To add complexity to the design of a user interface, smartphone does not support
all components provided in .NETCF. One such component is Button. If an instance of
class Button is used in the code executed in a smartphone, it will compile success-
fully. However, as soon as CLR tries to enter the illegal code, a NotSupportedExcep-
tion will be thrown. Other similar classes supported on .NETCF but not on smart-
phone are e.g. ListBox, TabControl, Toolbar, Statusbar, and ContextMenu.
Further restrictions result from the fact that Smartphone UI is optimized for ease
one-hand operations. Therefore it does not support a touch screen or any similar
mouse activity. The maximum number of top-level menu items is two and only sec-
ond top-level menu item can contain submenus. While .NETCF as such does not
enforce these restrictions, exception NotSupportedException will be thrown at run-
time if code does not follow them in practice.
107
3.2 Data Communications
In addition to the graphical user interface, different types of devices have different
data communication capabilities. For instance, a modern GSM phone enables the use
of GPRS data communication, whose data rate is 10-20kb/s. In contrast, a PDA may
have a built-in wireless LAN card, whose capacity is e.g. 11Mb/s. Furthermore, pos-
sibilities of applying data communications offered by the platforms may also vary.
In our experiment, we have identified the following aspects regarding communica-
tions. Firstly, lower data rates slow execution. Secondly, serialization, i.e., the possi-
bility to transfer complete objects to data and then back, is not offered in .NETCF.
This is surprising, as this facility is needed for the use of Web Services, which are
supported also by .NETCF. However, assuming that we rely on higher-level services
and operations on the web, these problems can be circumvented.
We found no problems when using the same source code to access Web Services
in different kinds of environments. Clients access Web Services in the same way, and
automatically generated proxy-classes are identical.
4 Unifying Framework
In order to enable the use of the same source code in all wireless environments, we
have implemented the following wrapper components. In addition, there are some
issues that differ from normal Windows practices, which will also be addressed.
4.1 Graphical User Interface Design
The core problems of the graphical user interface design is how components are
arranged to the dialogs, and how top-level menus and button components are handled
on smartphone. It is also important to follow user interface programming guidelines
and styleguides to ensure the high level of usability.
Unlike laptop version, user interface components can be automatically arranged in
smartphone and PDA versions in a straightforward fashion. To accomplish this, a
new class, WrapperForm, has to be created. WrapperForm is derivered from class
Form defined in System namespace. As a result, user interface design has to be car-
ried out only on laptop version, and after that, the wrapper layer handles layout auto-
matically for smartphone and PDA versions.
Similarly, when creating a Button inside the wrapper layer, it is possible to replace
buttons with menu items on smartphone version. To maintain compatibility with other
platforms, the buttons have to be placed at the bottom of dialogs on other platforms
too. This differs from normal windows behaviour at code level only in the way how
Button component is created.
Restrictions of top-level menus of the smartphone can also be handled with a
wrapper layer. This problem can be solved so that in case of smartphone an extra
menu item, Menu, is created and all top-level menus are added to its submenu. This
108
only alters the way top-level menus are created. In particular, it is still possible to
freely create any kind of menu structures.
The solution for these problems is to introduce a wrapper layer that handles the diffe-
rences of the platforms. The resulting design is illustrated in
Fig. 1.
Fig. 1. Unifying wrapper layer
4.2 Internal Functions
In the design of internal functions of an application, it became evident that the omis-
sion of methods and parameters for decreasing memory footprint also leads to compa-
tibility problems. Many of the problems were identified when composing the actual
code. As a fix that can be created when implementing a framework, we could imple-
ment a wrapper layer similar to that of the graphical user interface. However, such
intensive wrapping seems superfluous and is dangerous for memory usage point of
view. Therefore, we chose not to implement such a facility.
As all-purpose wrapping was not implemented, we had to search for other means
of portability. As .NET environment favors the use of Web Services, we considered
that this technology should be used as the means of portability. Thus, the structure of
applications resembles that of Model-View-Controller pattern, where the model is not
at the same computing unit as the rest of the system but distributed to a web service in
the fixed network.
109
5 Sample Application
As a proof of concept, we have implemented a simple wireless chat application called
NetChat that runs unaltered on laptops, PDAs and smartphones (
Fig. 2). NetChat is a
chat-program where users can create conversations and send text messages to each
other similar to Microsoft MSN Messenger. The architecture of the application is
illustrated in
Fig. 3. The purpose is to implement one source code that can be used in
different types of client devices. As already discussed, web services play an important
part of the solution.
NetChat application consists of a Web service that forms the server-side and appli-
cations that run on mobile clients. The applications communicate with each other
using XML Web service. Essential parts of the client-side application are graphical
user interface code and XML Web service proxy-class automatically generated by
wizard. In addition to the Web service, a basic file handling is needed to read and
write some settings to the local text file.
Fig. 2. NetChatGUIs
110
Fig. 3. Architecture of NetChat
5.1 Wireless Client
Using Web services is straightforward. The same proxy code can be used in different
types of client devices without any changes. Only the required dynamically linked
libaries have to be included in the project. It does not matter whether synchoronous or
asynchronous methods are used. However, due to different data communication capa-
bilities, some methods have to be implemented as asyncronous methods to avoid
freezing of the UI on smartphone and PDA devices.
Many kinds of UI components are needed to implement the UI of NetChat applica-
tion. The most important components are ListBox and TextBox components. The
layout of the components is not any problem thanks to automatic layout functionality
implemented on wrapper layer described in section 4. Also the use of simple compo-
nents, like TextBox, is similar, even if they look very different on different types of
devices.
In contrast, the circumvention of ListBox component is much more complex.
Firstly, ListBox component is not implemented on smartphones in the first place, and
therefore a ListView component has to be used. Selecting a single item caused pro-
blems, because multiselect property is not supported by .NETCF, but is by default set
to true on .NET version. The application cannot change the value of multiselect pro-
perty on .NET, because it is not implemented on .NETCF. Multiselect property has
been removed from .NETCF because it is not needed on smartphones or PDAs. To
solve this problem the number of selected items has to be counted and do the action
only if exactly one item is selected.
The second problem was the background colour of a ListView item. In .NET ver-
sion, it is possible to change the colour of individual ListView items. With the aid of
this functionality, it would be easy to inform user about new messages. Unfortunately
only changing the colour of complete components is supported on .NETCF.
However, both versions support the use of icons to identify the type of listview
item. A purple icon was used to inform that a new message has arrived to the conver-
sation. The same size of icons can be used on .NET and .NETCF versions. The next
thing to do is to determine the path of application directory so that icons can be loa-
ded. Default path cannot be used because it is pointing to different locations. In .NET
111
version, it is pointing to the same directory where the program is started. In .NETCF
version, it is pointing to the root directory of file system. Fortunately, it is very simple
to get path to the executed program file and put icons to that directory.
5.2 Fixed Network Server
The main purpose of the fixed server is to store the data of NetChat application and to
dispatch messages between users. Data can be stored as session objects or application
objects. An application object provides a mechanism for storing data that is accessible
to all clients, whereas a session object cannot share data between clients. Therefore
the data of NetChat application have to be stored as an application objects.
Due to the implementation of Web services technology, it is not possible to send
notifications from the server to a client when a new message has arrived. One possi-
ble solution is that clients poll the server and ask in a loop until new messages arrive.
This is a very ineffective implementation and should be avoided if possible. The
primary problem is how to inform the client when new message is arrived. The ans-
wer is the use of asynchronous web service calls. In the client side application,
asynchronous web service method is implemented with threads and callback func-
tions. It is a powerful way to create responsive user interfaces and function calls do
not have to respond immediately. The user can ask a new message with a function
that does not return until new message has arrived.
Because the fixed server is used over the Internet, it is not certain that the user
always logs herself out when closing the NetChat application. Therefore, a mecha-
nism to recognize invalid users is needed. In a NetChat application, the user has to
make at least one function call to Web service every minute to keep connection alive.
If the frequency of calls is less than one call in every minute, the server will destroy
the user information. As the result, the user has to login again.
6 Evaluation
There are several reasons for problems to run same code in both .NET and .NETCF
environments. The most obvious reason is the different patterns of usage. Smart-
phones are designed to be used with one hand only and they do not support touch
screen or any other similar mouse activity. On the other, hand PDAs support touch
screens but do not contain proper keyboard whereas laptops contain full qwerty key-
board and versatile pointing devices. A further major challenge is created by the dif-
ferences in screen resolution.
From the technical point of view, these differences are not very serious, because
the same messages are sent in spite of how components are used. Nevertheless these
differences have to be taken care of in the design of a user interface. Because of the
lack of pointing device, smartphone also does not support drag-drop functionality or
Button component. Also the number of top level menus is restricted into two.
The second significant problem is that .NETCF does not support all user interface
components provided in full .NET. Even if the same class exist in both .NET and
112
.NETCF, it does not mean that .NETCF version will have all the methods, properties
and events from the full version. Methods and classes has removed for decreasing the
memory usage. These differences are typically noticed only when implementing the
application and thus can cause harmful problems. Fact is that many classes and prop-
erties have been removed if they are not needed in mobile device without thinking an
influence at the compatibility. This kind of incompatibility is not only the problem of
GUI libraries but can be found in other libraries as well. A pleasant exception is Web
service. In general ADO.NET, including web service and database support, is well
supported by .NETCF, apart from the object serialization.
7 Conclusion
This paper evaluates the option to use the same applications in both .NET and .NET
Compact Framework environments. The main conclusion is that in the present shape,
these platforms do not lend themselves easily for the design of common applications.
There are several reasons for problems. The most important ones are:
different patterns of usage
different facilities for designing user interfaces (e.g. some components miss-
ing or unusable, incompatible resource file format)
incompatible interfaces, resulting from the removal of some methods and
their parameters in many .NETCF classes.
While the last item can be fixed in future releases of platforms, the other two issues
are fundamentally associated with the different purposes of wireless devices.
Even if it is technically possible to circumvent all these issues as described in this
paper, the resulting applications are not necessarily well-suited for end users, and
therefore should be depreciated. However, for e.g. experiments on using a certain
technology in a new environment or context, the commonalities offer a practical way
to compose rapid implementations.
Based on our experiences described above, the most tempting wireless application
development approach for us is to implement an application and device specific
graphical user interface for all different types of devices if necessary, but rely on the
use of web services for main functions of the application whenever possible. This
approach is supported by both .NET and .NETCF development tools, which enable
an easy access to web services from source code.
References
1. Ballinger, K., .NET Web Services: Architecture and Implementation with .NET, Addison-
Wesley, 2003.
2. Järvensivu, J., .NET as a mobile application platform. Master of Science Thesis, Department
of Information Technology, Tampere University of Technology, 2005. In Finnish.
3. Troelsen, A., C# and .NET Platform, Apress, 2003.
4. Wigley, A, Wheelwright, S, Burbidge, R, MacLeod, R and Sutton M, .NET Compact
Framework, Microsoft Press, 2003.
113