MOBILE APPLICATION DEVELOPMENT - One source code fits all?
Eric Lemarechal looks at how the barriers to mobile application development can be broken down
It's becoming increasingly obvious that it's possible to reach both employees and customers through a feature-rich communications device that they carry around all day. That device is the mobile phone. There are major obstacles to the development of mobile apps since the market is seen as being totally fragmented. The facilities a handset can offer vary enormously not just between mobile phones made by different manufacturers but within each manufacturer's own model range.
In the USA, for example, there's a degree of uniformity provided by the fact that Qualcomm's Brew has established itself as the premier development environment. In Europe, however, there's only one common factor - Java. Virtually all handsets – from the very basic, prepay entry level phones right up to the very latest smartphones – are capable of running the mobile version of Java, J2ME. Hence the ability to build mobile-aware applications using Java has enormous potential.
Wouldn't it be great if you could write just the one piece of code and run it on exactly the sort of mobile phones that everybody already possesses? That's exactly what vendors of conversion engines aim to provide. These packages enable fast and efficient porting of Java apps to hundreds of different mobile phones.
The objective with any conversion engine is to take the pain out of ensuring that an application will run on an ordinary handset in exactly the way its author expects. The conversion process doesn't just cover obvious features like keypad mapping; it also covers sound, graphics and connectivity – such as Http, Bluetooth, SMS and NFC (Near Field Communication).
The first sector to pick up on the advantages of conversion engines was the mobile games industry, while those in mobile marketing have quickly appreciated the potential offered by application conversion. However, many believe that this technology is just as relevant to ordinary, everyday business enterprises as it is to companies with an existing mobile focus. It's particularly suitable for rolling out CRM style applications, for example. By harnessing the power of the mobile phone, corporations can reach out directly to their customers with their applications, not solely to their own workforces.
Those companies connected with transportation are amongst the obvious potential customers, for instance. A good example of a transport-orientated application is one that utilises a mobile phone's NFC capability. Such an application could enable handset owners to purchase a train or bus ticket simply by touching the phones against a ticket barrier. More impressively, the conversion process could be employed by a car rental firm to create an application that enables customers to open the hire car's doors via the mobile phone. That very same app would then load a planned route into the phone's built-in mapping and navigation software module.
Mobile apps don't have to look dull and boring, either. Using conversion engines, it is possible to create the kind of 'feature rich' applications that companies are accustomed to building on the web. One capability, which has, until now, been missing from mobile applications, is the ability to mimic Adobe's Flash environment. One problem is that there are not many handsets with sufficient processing power and available memory to run Adobe's FlashLite offering – which is produced specifically for mobile phones. One solution is a facility called Flashlike Forms. Forms enable designers to utilise pull-down menus, text fields, radar buttons which can all be mixed with animated graphics for example. Once the user makes a particular selection via the keypad, the menus are then correctly populated with text. The chief benefit with Flashlike Forms is that it can run on very basic mobile phones – not merely on powerful smartphones.
The most popular way of distributing mobile apps is via an OTA (Over-The-Air) download. The drawback is that such apps are restricted to a maximum of around 1 MB. An alternative method of rolling out a feature-rich application to low level handsets is therefore to take advantage of a product from SIM card specialist manufacturer, Gemalto. This company produces the Multimedia SIM card, which can offer up to 1 Gigabyte of storage. The advantage here is that high resolution images, for example, can be stored on the SIM card along with the Java code that enables the handset to read the data. The Multimedia SIM card could then be swapped from phone to phone and still function regardless of the type of handset into which it has been inserted. Loading applications and data onto a SIM card also opens up the possibility of distributing applications via a broader range of outlets. Instead of requiring customers to download an application themselves over the Internet, apps could be loaded onto the SIM via existing mobile phone sales outlets.
To date, many IT departments are wary of venturing outside a very tightly controlled software development environment, which is heavily dominated by Microsoft. The reality is, however, that there are very few opportunities to create a 'consistent Windows-based experience' in the mobile world. It's been estimated that less than one per cent of existing handsets run Windows - let alone support the very latest version, Windows Mobile 6.0. By contrast, taking the Java approach enables an IT department to roll out an application to the kind of phones which employees and customers already own. Given that conversion engines offer support for hundreds of phones, there isn't even any real necessity to carry out an audit to discover what make and model of phones users already possess.
Companies have already learnt from the WAP experience and appreciate that mobile applications have to work perfectly when they're rolled out. Otherwise, if they don't, you probably won't get a second chance. The typical customer for a conversion engine won't select the entire base of supported phones but will pick a subset of, say, around 220 handsets. Out of those, normally it's only necessary to thoroughly test some 60 to 70 handsets to ensure the application works exactly as intended. Plus there's flexibility. It's also quite common for users to customise parts of the conversion process – by selecting a specific level of graphics resolution to run on a particular mobile phone, for example.
While those involved in producing mobile phone games formed the first wave of conversion engine users, those involved in supplying financial services will almost certainly form the next wave of mobile apps adopters. As an example, mobile phone apps will provide a highly convenient way for banks to inform their customers that they have sufficient credit to make a purchase when they're standing at the point of sale. Previously consumers had to return home to their PCs to discover if they had sufficient credit or were forced to accept the finance package being offered by the sales outlet itself.
As a final point, more and more mobile handsets are now capable of accessing the conventional web – not just WAP sites. Mobile apps can tap into this capability, too. A Java app can be designed to send a request to a web server to download an image or text. This effectively means that mobile phones can tap into the many web-based applications which corporates have already spent time and energy building.
For those businesses whose IT departments are already over-stretched, there's also good news. Conversion engine vendors are rapidly building relationships with established systems integrators who can readily take on the necessary development work rather than requiring the work to be done in-house.
Eric Lemarechal is co-founder, Mobile Distillery
Printed from http://www.eurocomms.com/features/111804/MOBILE_APPLICATION_DEVELOPMENT_-_One_source_code_fits_all%3F.html



.gif)


Comment on this article
Skip to comments
We encourage users to analyse, comment on and even challenge European Communications's articles, including the one above - 'MOBILE APPLICATION DEVELOPMENT - One source code fits all?'
User reviews and comments that include profanity or personal attacks or other inappropriate comments or material will be removed from the site.
Additionally, entries that are unsigned or contain "signatures" by someone other than the actual author will be removed. We will take steps to block users who violate any of our posting standards, terms of use or privacy policies or any other policies governing this site.