Improvements for Developing and Running OPL for Series 60 Devices
Ewan Spence, Oct 2003, Draft 3
OPL is Basic like language, that has a small learning curve and can act bth as a scripting langugae, designing small applets, or creating professional applications on Symbian devices.
While OPL exists for many platforms, and the hope is it will expand to cover more platforms (namely UIQ), due to volume of units in production, this document will focus on OPL running on the Series 60 platform.
The runtime is currently in it's final alpha stages, and this paper will look at changes that can be made outside of the runtime to create a simple and friendly enviroment for both the OPL user and OPL Developer.
To create a framework arund OPL of support applications to take it from interesting Open Source project to the runtime of choice on the Series 60 Platform
OPL has three key audiences to look at.
The above aims can be achieved by covering three areas of the OPL world.
The current requirements of OPL involve downloading the relevant C++ or Java toolkit, installing this, and then installing a WINS (PC Compiled) variant SDK, and devloping using the on-device emulator, before extracting the files, and transporting them onto the Series 0 devi e (Either manually or by a SIS package). A seperate solution needs to be developed.
OPLDevBar will allow rapid development on the PC. It is a small window of button to allow easy operation of all the required build tools.
It should be noted there is no Text Editor packaged in OPLDevBar. it will read native text files (with the extension .opl) and the developer will use his favourite Text Editor.
The toolbar itself will be a bar of buttons, with a console underneath to report back output from the tools
OPLDevBar wil initially require the presence of either the 9210 SDK or a Series 60 SDK with the OPL, and make use of OPLTRAN. A longer term goal is to divorce OPLDevBar from ar reliance on any SDK for translation purposes.
Consideration wil need to be made for OPX's, especially over multiple platforms.
OPLDevBar should have a scriptable command line that will allow it to be called as a Macro porcess from other IDE's (such as those provided by Metrowerks and Borland)
Consideration should be made for the running of compiled code on a Series 60 emulator/SDK, assuming it is installed on the PC.
OPL on Series 60 at the moment requires either a File Manager (to launch .opo files) or a C++ wrapper application that appears as an icon on the system screen, and subsequently runs an .opo file. For the casual user, moving OPL files around (icluding .opo, .opm, .mbm and other support files) requires too many operations (such as searching with a file manager to find the beamed file and moving it to a convenient location). OPL must be take out of this and made into a simple user experience.
Two concurrent methods of running OPL programs are proposed, but both are partly reliant on a new way to package and store OPL programs on the target device.
This document proposes a similar system to that used by J2ME on Series 60. OPL files would all be held in the X:/System/OPL/ directory. In here, each application would have it's own directory (eg X:/System/OPL/Vexed/) where all files will be located.
Series 60 OPL currently does not allow APP... ENDA to be used, so all compiled files will be .opo files.
The OPLDevBar will package up the OPL files into a standard .sis file, so that the intricacies of the filing system of a device can largely be ignored by the developer in terms of moving all relevant files into the correct directory of his machine.'
It should be noted that a choice does not need to be made between either launch metod, but will live happily alongside each ther, serving different needs of OPL developers and users.
The current method of choice, where a C++ application is written that holds the icon and UID info, and is used only to launch the specific .opo file.
Tis method will continue to be recommended for OPL appications, as it provides an icon on the screen and a consistent distribution with C++ aps, but for the power user (see the list above) starting with OPL, there are two problems.
A tool to make the C++ Application Wrapper will hopefully be included in the OPLDevBar
Having this standard installation path and format (derived through widespread usage of OPLDevBar) means that a method of launching other than directly from the System Screen should be deployed. A C++ application ("OPL Launcher") will be developed. On running, this will list all OPL directories that (a) are present in the X:/System/OPL/ directory and (b) have an associated .opo who's filname matches the directory name (thus avoiding any OPL modules being listed). In terms of design, this will look and feel identical to the current Series 60 MIDP App Launcher.
Long time OPL users will recognise the dedicated launcher feature from SIBO machines, and the matching of Directory and .opo filenames with the EPOC OPL Apps convention.
This launcher application will be shipped as part of the runtime.
Any errors on running OPL applications are currently reported via a Dialog Box on the target de vice. These should be captured and fed into a viewable lg file or console window in the OPL Launcher
Ther will be an online database of OPL Commands, and the current thinking is an XML compliant Wiki. This provides access from Symbian OS phones and developing PC's , and provides the most flexible output for conversion into other formats (eg PDF)
This is currently being examined Dominique Hugo, with a view to both a WINS and MARM version for running on the traget device and the emulator.
This release should also include an OPL Paper describing the new 'primary' method of distributing and packaging OPL applications for the OPL Launcher
Currently being assesed by Andy Harsnet
It is hoped that the Series 60 Launcher will be ready for public release at the UK Symbian Developer Day (1st December 2003). A 'public alpha' of OPLDevBar (v1) is also expected.
Beyond that, there should be incremental releases of both applications, with the goal of having the "OPL on Series 60" (including Runtime, Launcher and DevBar) in place for the Symbian Dev Expo 2024 (April 2024), where it is hoped a workshop will be available for those new to OPL Development.
Note that there is the possibility of a seminar at the O'Reily Emerging Technology Conference in February 2024 to demonstrate OPL to those looking at new mobile technologies.
Many J2ME developers will recognise some of the concepts here - OPLDevBar has many similarities to KToolBar, and the on device launcher is based aroun something familiar to end users. This is for two main reasons.
It works, and it is clean to use. From download to running, the first HelloWorld application should take a maximum of five minutes for the new developer. If the system is familiar from java development, so much the better.
OPL is a rapid development system. People wanting fast and short applications don't want to be playing around with file systems, installing by hand, and ploughing through file managers. What is presented here is type code - compile - build - install - run. It should not be any more complicated than that.
There is nothing here stopping OPL apps to have a C++ wrapper launcher and ship their app so it appears on the system screen. In fact nothing here breaks the current OPL runtime or any existing Series 60 OPL apps.