The following are questions that were asked of Jonathan Allin in November regarding Java, Symbian, and the wireless market. Jonathan is Symbian's Java Technology Manager responsible for Symbian's Java strategy. He is one of a number of people whose role is to ensure that Symbian provides a first class Java platform for wireless information devices. Jonathan is also the lead author of Wireless Java for Symbian Devices published by Wiley (Europe).
- What is Symbian's significance in the wireless market?
- What is the role of wireless Java?
- Why should a developer choose Java instead of other development environments?
- In what areas do you think wireless Java on Symbian OS will be applied?
- What services are being developed?
- What are your plans for Java on Symbian OS?
- Why should developers target Symbian OS, rather than any other phone running a Java VM?
- How can a developer or service provider get started?
- What are the pitfalls, and how to avoid them?
Symbian plays a central role within the wireless market: Symbian's licensees represented over 80% of mobile phone sales in 2002. The importance of this role was underlined by Jorma Ollila, Chairman & CEO of Nokia, when he stated in May 2001, that "..by 2004, 50% of Nokia's 3G phones will be Symbian OS based"
The wireless market is changing, driven by customers who want access to services and applications that will add value to their leisure and work, and by operators who need a return on their huge investments in 3G licences and infrastructure. They will have invested something like €300bn in Europe.
So we see fantastic opportunities. Opportunities for new services and applications, such as multi-user games, location based services for route planning or localised advertising, and soon wireless commerce. However this is a new world. Both handset manufactures and operators are moving from closed systems to open systems, giving users the ability to download applications and services. This change isn't going to be painless, however Symbian is in a unique position to minimise the cost of change. Symbian OS is an advanced, open platform and Symbian is committed to supporting, implementing, and guiding the major wireless standards. But perhaps most importantly of all, Symbian understands the wireless market and the way it is changing. This includes the necessary security infrastructure, application and service provisioning and their business models, and rapid service development.
So how do we deliver these new services? In order to achieve a return on their investment, operators and service developers need to create and deploy services and applications rapidly and reliably, and they must target a wide range of devices. Furthermore users and operators must be confident that services and applications are secure.
Symbian mobile phones are "intelligent clients", so they don't have a thin client's dependency on a network connection. Instead, by making good use of local resources such as databases, messaging, and telephony, together with good processing power, Symbian devices can deliver functionality both off-line and on-line. For instance a route planning application will generally work from locally stored routes and data, and only go on line when it needs to update a route.
Our goal is to provide a Java environment that will enable operators and services provides to create revenue through rich, exciting, value added services. We are achieving this by exposing the advantages and strengths of Symbian OS to Java developers, through APIs, that, by and large, are standard. Many of the newer wireless Java APIs, such as multimedia, messaging, Bluetooth, and PIM, are interfaces onto native functionality, which means that a Java implementation is only as good as the underlying platform.
However Java on Symbian devices is compelling even for operators and application developers writing to the common MIDP APIs. Larger screens, fast performance, and the way Java applications are integrated with native Symbian applications, results in a better user experience.
It's about choosing the right tool for the job. We've talked about the benefits of Java, and for these reasons Java has an important role in creating third party applications and services. C++ is more appropriate where Java may not provide the required functionality or performance: we'll certainly be using C++ for application engines, device drivers, and other core components for quite some time to come.
The really exciting Java applications and services, including games, will be those that bring together a wide range of resources and bring people together. So a sales application might use a product catalogue, route planning, a time table, and location services. Or Java can add value to even a simple game like "Snake" by allowing me to play against my children when I'm overseas with a few minutes between meetings.
Services like these also make use of network resources and bandwidth, which of course helps the operators' business models.
It's early days for rolled out services, but we're seeing pilots and experimental services being created. For instance "Wireless Java for Symbian Devices" describes the Handheld Travel Assistant, developed by Telenor R&D. This uses Java and existing Internet services to provide users with location related information, including local maps, location of friends, transport routes, and information about local shops and restaurants. A GPS system was used for position information, but transmitter signal strength can also be used to locate the user.
There's also the Simple Conference example from Digia. This allows users of different mobile phones to work on a shared whiteboard. Both drawings and textual information can be shared, with the whiteboard model being held on a server.
In addition Cell-Telecom ( www.cell-telecom.com) have deployed a number of Java applications, which includes sales support and industrial QA.
The PersonalJava and JavaPhone APIs on Symbian OS provides perhaps the richest Java environment for mobile phones. As an example we might use this capability to create an application for coordinating a meeting: it would use calendar APIs, contacts APIs, and messaging APIs to negotiate a suitable time and venue amongst the delegates.
However we recognise that for many devices PersonalJava's footprint is too big, so in addition we provide MIDP compatibility for all our phones, large and small. Symbian OS thus delivers both rich high-level PersonalJava and universally compatible MIDP Java implementations.
Of course what we want is both: a rich Java environment that is also small enough for the smaller phones and hence mass market. So we're moving to a single Java technology, based on MIDP 2.0 and CLDC. It will use Sun's powerful CLDC HI VM and additional, highly functional APIs. This gives us the important benefits of a CDC based solution, but in a smaller footprint and a more appropriate programming model. It will allow developers to create and run larger, more interesting, games and services.
In addition to MIDP 2.0 our next major release will include Java APIs for Bluetooth and messaging, with multimedia, location, PIM, and others following soon after. These APIs all conform to the relevant Java specification.
This is a good question. We talked earlier about the business benefits, however there are also important technical reasons to do with:
- Functionality and platform integration
- Performance, both in terms of speed and memory footprint
Robustness: Symbian OS is designed to operate 24 hours a day, 7 days a week. User data loss on Symbian licensee devices is very rare, and system resets are almost never required. Java builds on this robustness
Functionality: Symbian's Java implementation is the richest Java environment for mobile phones, giving Java developers access to application engines, communications, messaging, Bluetooth, multimedia, etc.
Java is also well integrated: the user installs and starts a Java application as they would a native application, and the use of native windows controls means that a Java application looks like a native application
Java on Symbian OS is probably best of breed in terms of matching high performance with a tight RAM and ROM footprint:
- Symbian's Java implementation takes advantages of Symbian OSs mean and lean philosophy. Symbian, in both its Java implementation and its core operating system, has followed a philosophy of making optimal use of constrained memory resources. As an example Java classes can be run from ROM
- The Java implementation is highly optimised at all points in the chain. This includes graphics, libraries, and of course the VM. Our next release will be based on Sun's CLDC HI Java VM
Well, of course the first tip has to be buy a copy of the book "Wireless Java for Symbian Devices"! This covers the business and technical issues to do with creating, deploying and gaining financial return from developing wireless applications and services. There's also a support web site to guide readers in finding all the other resources they need to get started ( http://www.symbian.com/books/wjsd/support/wjsd-support.html).
Also look at Symbian's developer web site ( http://www.symbian.com) and those of our licensees. From there you can download a free Java SDK: the Symbian OS SDKs are targeted for Microsoft Windows and provide good emulators both for Java and C++. You can also download example applications and papers that cover getting started, native interface programming, and general programming hints and tips; and you can get help from the knowledge base and discussion forums.
Having written your application and tested it under the emulator, you'll want to test it on a Symbian OS mobile phone. Currently available phones include the Nokia 9200 series, the Nokia 7650, and the Ericsson P800, and we're looking forward to other exciting mobile phones from other Symbian licensees as well.
I think the biggest mistake a developer can make is assuming that Java on a mobile phone is just like Java on the desktop. Even though we provide the same or similar APIs, there are many constraints, and of course opportunities, that must be taken into account.
Constraints include a slower processor, less memory, smaller screen, and more limited input, which could be keyboard, pointer, or keypad. So a developer has to learn how to get "a quart from a pint pot". This can be done, and it's fair to say that in general a well written Java application on a mobile phone will be more effective than a poorly written one on a desktop machine. In "Wireless Java for Symbian Devices" I devote a whole chapter to detailing optimisation techniques to create more efficient Java applications for mobile phones.
Both existing Java developers and new developers will need to adapt to the wide range of user interface characteristics (for example screen size and keyboard or pen input) of data-enabled mobile phones. To create applications which are easily modified for different phones, it's best to write your applications as an engine and a user interface module. This means only the UI module needs to be modified for different phones.
But of course there are the opportunities that come with mobile phones: mobile phones have two important characteristics, mobility and timeliness. In other words the ability to use an application, or play a game, where and when it's convenient to you, and those you are working or playing with. A good Java application will take advantage of these features.
# # #