Development Options

EPOC provides the developer with three options. Each option is supported by a SDK that is available free from the Symbian Web site; however, development in C++ and Java require additional ADEs to allow development to be undertaken. The SDKs allow code to be developed and run under a PC based emulator before being packaged in a SIS file for distribution and deployment. (It is worth noting that there is no need to own an EPOC devise to develop using the Symbian SDKs).

OPL

OPL, or the Organiser Programming Language, had it origins back on Psion's original Organiser. It is essentially a BASIC style language. The principal advantage of OPL is that, in addition to development using the SDK, it can be written directly on the EPOC device (although some more recent devices, such as the Revo, do not include this capability). Also, code written and compiled on the emulator can be copied to and run immediately on EPOC hardware.

The disadvantage of OPL is that it does not provide direct access to all of EPOC's services; however, these are becoming available via OPX's (C++ DLLs) which provide access to the base classes.

In addition, a number of OPM's are available. OPM's are OPL routines that implement commonly used functionality (for example: button manipulation and scrolling) which can be shared between applications.

A range of OPX's and OPM's are available from Symbian and 3rd party developers. Those from Symbian are available free of change as are most of those provided by third parties.

Despite OPL's limitations, it is still a powerful language as witnessed by the vast range of games, graphics packages, databases, and other application software developed as freeware, shareware and commercial packages.

3rd Party Extensions to OPL

OPL has also been extended by two third parties. Neuon supplies nOPLPlus which includes a project-based editor and translator which adds a number of additional features such as #pragmas, macros, 'C' style operators, re-use of code libraries, multi dimensioned arrays and STRUCTS to OPL. As nOPLPlus includes a translator, it allows OPL the ability to be provided on those devices not shipped with native OPL.

The second extension is OOPL; this adds object-orientated constructs to OPL. This works by pre-processing OOPL code into standard OPL (using a Perl script). Development can be undertaken on both a PC or EPOC machine (as a port of Perl to EPOC is available). While the OO extensions are somewhat limited at this stage, this could be an interesting development for OPL.

Java

EPOC supports Java 1.1.4 development of applets and applications. As with OPL, however, development of native methods will require the use of C++.

The development process involves writing the code in any Java ADE, testing locally, then transferring it to either the emulator or an EPOC device for final testing. As with OPL, Java class files that are run under the ADE (or emulator) do not require recompilation to run on an EPOC device (as would be expected).

It is worth noting that Swing is supported but AWT is recommended because of Swing's heavy memory and CPU demands.

C++

C++ is the power development environment for EPOC. Like Java development, C++ development takes place on a PC. However, unlike OPL and Java, it provides full access to all of EPOC's underlying services. To develop C++, in addition to the SDK, any class of Microsoft Visual C++ version 5 or 6 is required.

The development for C++ is slightly more involved than OPL or Java. This is because the code run under the emulator is for x86 binaries and not the target ARM binaries. Therefore, code is written under VC then compiled and run in the emulator. Once tested and debugged, the code is then recompiled using the GNU C++ compiler for the EPOC device.

C++ for EPOC presents some challenges when compared to standard VC++. There are two reasons for this. First, EPOC makes use of VC features prevalent in 1994/95 and therefore does not take advantage of more recent VC improvements. Secondly, and probably more importantly, in the development of EPOC the designers did a number of unique things to optimise code for the reduced memory and processor capacity on portable devices. For example, the first 4 bytes of a length word is used to indicate the descriptor class, meaning that the descriptors data is limited to 250 million characters not the full 4 billion normally available. The feature that seems to cause the most problems is the inability to use writable statics in DLLs, which has significant implications for porting. This was done because writable static could consume all the memory on a handheld device before they get around to doing any real work.

Connectivity

In addition to the environments mentioned previously for the development of EPOC applications, there is also an SDK for EPOC Connect (which forms the basis for PsiWin). EPOC Connect allows for development in any language which implements COM. Object models for all the EPOC file formats are exposed and therefore allows the development of conversion and synchronisation utilities.

Books

References

About The Author