Remote Control by Phone (RCP)

This article discusses how RCP is designed and built, the challenges we faced, and future plans for further improvement of RCP.

After spending some time searching for a suitable idea for a senior graduate Computer Science project, the idea of remotely controlling a computer was raised. The idea was inspired by the remote controlling devices that some professors at our university purchased to make teaching easier and more interactive, but the problem was that those devices cost money, professors had to carry them from class to class in addition to their other gadgets, and the functionalities those controlling devices have are quite limited.

It's obvious that nowadays everyone carries a phone or PDA, so our visionary idea was: 'why not use our phones or PDA, which we always carry, in controlling our computers instead of buying an extra device'.

The system we proposed gained acceptance and encouragement from the supervisor as well as other professors at our university. So the next step was research. We did some reading and downloaded some APIs, and had to make many decisions regarding which APIs to use and what programming languages are most suitable for such a system, etc.

Before going to real implementation, we did a feasibility study. After making sure that the system can be implemented, we moved on to creating a design for the system. We selected the server-client architecture because naturally our system is comprised of two components, which are the computer (server), and the phone or PDA (client).

We selected Java 2SE for programming the server side, and Java 2ME for programming the client side, and the connectivity medium we selected was Bluetooth because of its amazing properties. These properties include speed, reliability, and the ability to pass through barriers.

The server side is divided into many layers stacked on top of each other, each layer receives data from the one beneath it, processes the that data, and delivers the result to the layer on top of it. This design adheres to the component based design which provides a high level of coherence and cohesion. These two measures are highly preferred in the contemporary software engineering trends.

Figure 1 below shows the design of the server side:



Figure 1

The bottom layer displayed in Figure 1 is the Bluetooth hardware; on top of it is Microsoft's XP2 Bluetooth Enumerator and Radio, which fetches the data received from the hardware layer, USB Bluetooth Dongle, and delivers this data to BlueCove's Bluetooth stack after passing through the Java Native Interface (JNI) tool; this JNI tool acts as a translator between Microsoft's XP2 Bluetooth Enumerator and Radio and BlueCove's Bluetooth stack.

A Bluetooth stack is a device driver that relies on the operating system's access to Bluetooth hardware. Programmers use Bluetooth stacks to gain control of Bluetooth hardware. Some of these Bluetooth stacks are free and others are commercial. We selected BlueCove's Bluetooth stack because of its platform independence and being open source. Another Bluetooth Stack is Harold Bluetooth stack.

On top of BlueCove's Bluetooth stack is Sun's Microsystems Bluetooth API, this API is standardized as the JSR-82; this API gives programmers the ability to perform Bluetooth operations which are discovery, device management and connectivity.

The top layer is a set of classes, each of which performs a certain task. When data, which represents commands sent by the remote control, reaches this layer, it gets investigated to determine what type of command it represents. It might be a command for the mouse, the keyboard, etc.

The remote control's operating system, which is in many cases Symbian for phones or Windows CE for PDAs, has built in Bluetooth libraries that are available to programmers. The client side uses these libraries to perform Bluetooth operations.

Before the client side starts sending control-commands to the server side for execution, the client side has to search for surrounding Bluetooth devices and connect to the intended computer after checking its identity and the services it offers, the identity of the computer is determined by Universal Unique Identifiers (UUIDs) and Services that the computer offers are verified using Service Record Databases (SRDBs). Next a Bluetooth channel is created, this channel is tolerant to intervention attempts.

Figure 2 below shows the design of the client side:



Figure 2

After talking about technical issues, the thing that is of most importance is what services RCP has for its users. RCP is targeted for any user who wishes to control her/his computer remotely for some purpose. RCP has many features available to the user with the intent of making remote controlling of a computer an easy, efficient and fun experience.

Services that RCP has include:

• Mouse Mode:
The mouse mode enables the user to perform basic mouse motion, right and left clicks control; moreover, RCP's mouse mode has the pageup and pagedown keys to make navigating through the desktop or any document easier.

• Keyboard Mode:
The keyboard mode types capital and small letters, it can also type numbers, in addition to that, the keyboard mode has 29 symbols.

The keyboard mode also has the F5, Esc, and Caps Lock keys; the presence of these keys is very useful especially for applications like Microsoft Power Point.

• Shortcuts Mode:
This mode assigns keys on the phone's keypad to applications available on the server side, so as to make the process of running applications easier by only on click of a button. Users can assign up to 10 different applications to the phones key pad.

• Help and Language:
RCP is shipped with a rich help facility just to make sure that users will get to use it in a very small time.

RCP initially supports Arabic and English to increase the number of its users. The user selects the language of choice only once, and RCP will remember what language has been chosen in the next session, this increases usability and efficiency by not having the user select the language every time he starts RCP.

We have also paid close attention to the graphical user interface of RCP. The server side uses Window's Look and Feel, whereas the client side uses POLISH in implementing its interface. Polish is an API that can be used in building attractive and pleasing interfaces for applications that run on phones and PDAs.

Figures 3 and 4 below show snapshots from the server side and client side screens:



Figure 3



Figure 4

In building the RCP system, we faced many technical and theoretical complications, such as hardware problems in figuring out that some Bluetooth hardware are programmable and others are not. Another problem we experienced was the lack of resources. Nevertheless, working on RCP was an amazing experience; we loved it and learned a lot from it.

We plan to add more features and further improve RCP. We intend to add a remote computer login. This service will enable a user to access his computer no matter how far apart the user and the computer are when using the Internet.