Mobile Applications and Web Services

symbian.gifI am not a great fan of consuming web services from mobile JAVA or Symbian applications. They just seem to complicate mobile development unnecessarily. Also, applications tend to get bloated with service related code making them significantly larger (to download, use more memory etc) while the service calls themselves result in extraneous data being passed back and forward.

Take S60 for example. In a recent project I had to use some web services that were all that were provided by the server. I started off using a port of gSOAP (incidentally Sony Ericsson Developer World have a great tutorial) as this gave me full visibility of the service source code and allowed me to support S60 2nd and 3rd. However, I found that the Symbian port excluded some things, for example, support for datetime that were declared in the web service description language (WSDL). I tinkered with the gSOAP library a bit but gave up when I realised that adding support for the missing features was probably going to be non-trivial.

I moved on to the Nokia supplied WSDL to C++ Wizard that unfortunately only works for S60 3rd (not 2nd). It also requires that you include and install a XmlDataBinding.sis within your own sis – that is a needless distraction for the end user when they are prompted to also install this. Once you have worked out how to use the generated code (it isn’t that well documented) it all works very well but the whole concept really is using a sledgehammer to crack a nut.

Instead of web services, for designs where you have control of what the server provides, I favour simpler http GET/POST requests that don’t used SOAP and just return structured information such as delimited lists of things, encoded images or, if you must, XML. (ie REST style calls). All this is much simpler to achieve and more efficient.

Location without GPS or Operator LBS

skyhook.gifThe problems of mobile phone GPS (slow/battery hungry) and operator LBS (often closed to developers) have caused people to think about obtaining location in other ways. Skyhook have created a Wi-Fi access point database and associated windows/Linux/Symbian SDK to allow developers to obtain location to within 20m.

The clever bit is that after the database has been initially created (presumably by someone from Skyhook driving around), the system and hence database self-adapts to changes by comparing new/changed access points to those with known positions.

Skyhook have a new SDK and a contest to provoke developers. You can win an iPhone or N95 – it’s ironic that they picked a GPS phone as a prize!

J2MEdit

j2meedit.gifAt the beginning of this month, I commented on how some successful Java ME applications tend to be based on processing performed at the server. SteelByte Media, LLC have just released a new code editor to allow editing, syntax highlighting and even compilation of JAVA and C/C++ from within a Java ME application. It does this by submitting code to a server where it can be saved, emailed or compiled.

As it is server based you don’t pay for the application and instead pay a low subscription for the services provided by the server. It’s an interesting business model because there’s no need for a demo version, people are encouraged to download the application because it is free and copying/piracy isn’t an issue. This server based application is also technically interesting because it allows things to be done that usually can’t be done under JAVA ME.

Porting Code to Symbian

symbian.gifThis week, several things have made me think back to previous projects I have worked on where I have had to port code to Symbian. One thing stands out – if at all possible avoid porting code that’s still unstable and changing significantly. Otherwise, depending how you do it, you will may up doing the porting exercise lots of times. Also, debugging unstable code on the phone as opposed to the donor platform will always take significantly longer.

If code is changing or is likely to change at all in the future, ensure you modify the donor code rather than creating a Symbian branch. You can do this by, for example, adding  #ifdef _SYMBIAN_ for the Symbian specific code. This will prevent you having to do the same porting lots of times. Also, this may even get the donor code writer into thinking what to do to make the code less platform specific!

Finally, here’s a tip I got from the Nokia S60 WebKit. When porting C++ code to Symbian, it can be difficult to detect and report out of memory conditions (in a Symbian way) during donor code object construction without putting lots of Symbian code in the donor code. The solution is to overload new and delete. In the WebKit this can be seen as the OOM_NEW_DELETE macro used throughout the code and declared in oom.h   This uses an ObjectBase to allocate memory which, in turn, uses a MemoryManager that takes care of out of memory issues. MemoryManager does a lot more including logging and Javascript garbage collection and instead it’s possible to just do the allocation and error checking in something like ObjectBase.inl.

Using the Idle Screen

visionmobile.gif

There’s an free informative report at Vision Mobile that discusses use of the idle screen…

The main problem with this is that…

"Idle screen replacement requires integration of the AIS software with tens of relatively inaccessible APIs (application programming interfaces) which are only available to third parties subject to manufacturer approval. This implies that the AIS technology is mostly accessible to companies with strong relationships with handset and operating system vendors."

Some thoughts…

  • Replacing the idle screen under Symbian is only possible if you are a Symbian Partner.
  • The JAVA ME MIDP 2.0 specification doesn’t provide support to allow Java applications to use the idle screen. However, a few devices provide this extra non-standard functionality.
  • Using the idle screen creates some other considerations related to performance. Phone and battery performance can be affected when (especially network) active applications use the idle screen.
  • Active idle screens are likely to become more important as phones supporting widgets and MIDP 3.0 start to appear. (S60 will eventually allow links to widgets rather than embedding widgets themselves)

EDGELIB

edgelib.gifWhile doing some surfing related to mobile gaming, I came across a useful library that I didn’t even know existed.

EDGELIB allows you to…

"Compile and create multi-platform games smoothly through the generic interface for Windows Mobile Pocket PC, Windows Mobile Smartphone, Symbian Series 60, Series 80, Series 90, Symbian UIQ, Gamepark Holdings GP2X and Windows desktop.

EDGELIB offers an device independent API for high-performance 2D graphics, hardware accelerated 3D graphics using OpenGL ES, software 3D rendering, file access, input, network connectivity and much, much more!"

I had a thought that the library might even be used to easily create non-game applications. It’s a true native library (no runtime) which means you might even mix functionality with native controls (standard list and edit boxes etc) – although you would obviously lose the cross platform advantages if you did this.

It supports the latest UIQ/S60 Symbian 9.x devices and the pricing even seems affordable.

June MoMo London

momlondon.pngLast night’s MoMo London covered graphics, multimedia and games. Here are some new insights I took away from the meeting…

  • Native gaming (as opposed to JAVA) may become a more viable platform as the installed based of devices increases over the next few years
  • Today’s low end and high end native programmable phones compare favourably (in performance) to the Nintendo DS and Sony PSP respectively
  • Open standards such as Open GL (ES 2.0) will help abstract away the functional fragmentation when coding native across devices
  • NVIDIA and Symbian are currently building in capabilities to use such standards and GPUs (low power auxiliary graphics processors) in tomorrow’s phones
  • High end gaming capabilities provided by GPUs may have knock on effects on the phone user experience and allow for visually rich user interfaces

Playing devils advocate for a moment, do people want or need to play such graphically complex games on their phone? In the past I worked with a extremely successful mobile developer who created both mesmerising arcade games and simpler casual games. At the end of the day, casual games proved to be more popular. Similarly, does a graphically rich phone UI necessarily mean the phone is easier to use? Not according to Microsoft who, due to to extensive user trials, actively removed eye candy in it’s mobile offerings.

There was also a presentation by Motorola on the new RAZR Z8 which I have had some thoughts on that I will save for a future post.

Symbian Data Sharing

symbian.gifThere’s a great new free booklet entitled "Data Sharing Tips" that describes common methods of sharing data within Symbian 9.x.

Strangely, it doesn’t mention Client-Server, the most used Symbian OS data sharing mechanism.

Also, many of these mechanisms may be over the top for simple applications. The simplest way of sharing data is via files! These have the advantage that data can also be read by a human. One tip for beginners: Don’t save to the (default) private directory otherwise other applications won’t be able to see the data. Instead write to non-protected directories.

Update from David Mery… Check out the UIQ FAQ "Where should I store my files and why some of my files disappear?"