As seems to be the case with many innovative start-ups the team that founded apps for phones has been working together for a number of years. The founders originally worked for Bristol, UK, based ASL (Advance Systems Limited), who created the first synchronization product for PDAs. ASL was bought by Extended Systems in 1999 and its technology incorporated into what is now the OneBridge mobile groupware product. Following the purchase the apps for phones team became disillusioned working for overseas owner who, in the words of apps for phones VP Business Development and Co Founder Bill Colwill, "didn't quite get it".

After a period of contemplation, during 2002, the team started to look at the development of Java applications on mobile phones. "We started playing with the available development tools," says Bill. "We soon found that these tools were absolute rubbish. It was almost impossible to get anything to work. You were installing multiple SDKs and multiple emulators for multiple versions of Java, all of which were incompatible with each other. So we thought there has got to be an easier way of doing this, particularly if it is going to hit mainstream." As a result apps for phones started to create its own IDE, with the plan of providing everything a developer would needed in one tool. "As we got into the project we realized that it probably was not a good idea for a five person company to be taking on the likes of Borland," says Bill "It was just too big a task. We also realized that it was not going to solve the problems we saw with mobile Java development."

The big issue, in Bill's opinion, is the way Sun licensed Java; giving the handset manufacturers freedom in the way they implemented the JVM's. "It might have helped create the momentum to get Java in so many phones, but as a result each manufacturer thinks that they have the best way of doing it, resulting in a plethora of different implementations. This means that if you create an application and get it looking right on one phone, which is quite a lot of work, trying to port it to the next device is still a lot of work," says Bill. "Every text box works in a different way, every font is different, every screen size is different, there are different API's in different devices, it's all a huge muddle."

While solving this problem was one of apps for phones goals they identified another. "To program for a Java phone you need to learn Java," says Bill. "This is not a trivial task for many people. If you come from the C++ or mainstream Java worlds you can cross to J2ME pretty easily; but for the majority of developers, who are using Visual Basic, Access, Perl or any other scripting languages, it is a major leap. We don't think they are going to want to or should need to make that leap."

As a result apps for phones redirected their efforts with two new design goals. To create a product that provides consistency across all the different Java phones, so that porting was reduced to allowing for different screen sizes and fonts. Next was to allow developers with Basic skills to add business logic quickly and simply to create fully featured applications.

The first goal was achieved with version 1 of apps for phones. The IDE allows developers to create database based applications with simple drag and drop technology. It also separates the UI and the business logic, which means only the UI needed tweaking for individual phone. To make "porting" easier the tools is also supplied with skins that allow the developer to see exactly what they will get on different phones, without having to download a individual emulators.

Version 2 achieves the second goal, with the addition of a simple basic scripting language that allows unique business logic to be added to an application. "Now even a humble sales type, like myself, can create cool applications on mobile phones," says Bill.

Interestingly the first version of the tool created a lot of interest from the mainstream Java community and apps for phones got many requests to add Java based development. "This did cause us something of a dilemma," says Bill. "But Java language coding would have required us to link it to a third party emulator. We wanted to stay in our own self contained world. Stepping outside it would have exposed us to the range of different APIs in the many mobile Java implementations."

There is one limitation with the approach that apps for phones has taken. "We choose which API's we support and which we don't support," says Bill. "In doing so we largely limited ourselves to functionality which is common across a range of phones. Underneath the tool sorts out which specific APIs to use." This means apps for phones does not implement the latest features of mobile Java, such as camera or video APIs.

Developers using the tool still have to be specific about the phones they want to target. "If a developer wants to target Series 60 2nd Edition they select that phone group and the tool takes care of the underlying APIs used, as the developer draws the application," explains Bill. "If they then switch to building for a Motorola or Nokia Series 40 device the tools adjusts the APIs called. When development is complete apps for phones creates the JARs and JADs for each group of devices."

Java implementation are becoming more functional. This unfortunately means that, as apps for phones adds new features, it will not be possible to completely eliminate all compatibility issues. SMS is the most recent example of an extended feature supported by apps for phones, which is not available on all the phone that can be targeted with the tool. "SMS requires JSR120, but that is only available on some phones," say Bill. "So if a developer tries to create an SMS enabled application for a group of phones which doesn't support SMS apps for phones will warn them. Even so some phones within specific groups don't support JSR120, but you won't find out there is a problem until you install the applications and the device say 'I am sorry I don't understand what I am being asked to do'."

This is an issue that will become an increasing challenge for apps for phones in the future. "There are going to be some issues as we add more functionality to the tools," says Bill. "We are still working out how to best handle this, at least at present the differences are not too great."

So what can you develop with apps for phones? "Our core goal is to mobilize people with information applications," says Bill. "This includes pure business to business applications, providing mobile workers with the same access that executives have had on their PDA's. But we also see opportunities in the consumer space; to deliver application that can act as the front end for businesses and services. A lot of those applications are straightforward in terms of functionality but can be very useful commercially."

Given the companies heritage in synchronization products it is perhaps understandable that backend database integration is a big part of apps for phones. However, rather than using synchronization apps for phones employs web services technology. "Any business that has its data available in any form of web service can load the web service definition file into apps for phones; to create the linking, database tables and controls that make data available," says Bill. "We take care of it automatically, there is no need to cut any code. This approach also means that complicated data manipulations can be done on the server where there is significant processing power."

apps for phones also includes its own "very light, very efficient database" to store data on a device. "Even with web services we want to minimize the amount of data applications are moving," says Bill. "So local data storage is important."

While the memory in Java phone is increasing, it is still limited. One of the disadvantages with tools which offer a uniform implementation over a wide range of devices is usually that they add a considerable overhead in terms of size. Is this the case with apps for phones? "It very much depends on what you are doing and how much functionality is built into the application," says Bill. "But typically we believe an apps for phones application is about 20k bigger than a similar application develop purely in Java. Importantly everything is delivered in the on JAR, so there are no separate components to install."

Ultimately apps for phones biggest challenge is getting the message about its tools out. "There are millions of people out there who look and think 'Oh it is Java, I don't know Java, I can't do anything'," says Bill. "Educating them that they can get into this market space today, with their existing skill set and no big learning curve is the ultimate challenge for a small company like ours."

apps for phones is available as a 30 day free trial. Full licenses cost US $549, with 5 and 10 user licenses available for $2250 and $3600 respectively. Licenses include free upgrades for 1 year. For more information see: www.appsforphones.com.