More on Mobile Applications and Web Services

sap.jpgFollowing on from my previous post on Mobile Applications and Web Services, I thought I’d post some more tips that might be useful to Symbian, Java ME and Windows Mobile developers.

What if you can’t get the gSOAP libraries working against your web services nor use the S60 Nokia WSDL wizard and associated large XmlDataBinding.sis? For example, it’s my experience is that datetimes tend to be especially troublesome for auto generated web service code tools.

You might like to try hand crafting the web service queries and parse the results. It’s not as hard as it seems and you can use this technique from Symbian c++, Java ME or Windows Mobile. In fact, it’s an ideal method if you want common code across these platforms.

What you need is a web site such as the SAP web services navigator. Type in the URL of the WSDL and it will allow you to query the web service from the web browser. More importantly, it provides the XML for the request and the resultant XML response. Copy the request into your code as a http request and programmatically change the service parameters (search replace strings) to be those provided by your application. Similarly, you can look at the response to determine how to write code to extract resultant data from the returned XML in the http response. You don’t even need an XML parser – just extract strings between XML tags.

Incidentally, if you use the SAP web services navigator you can also strip out the session stuff in the XML request as it usually isn’t required by the server.

The resultant code is as lean as you can get (if you have to use web services) as it doesn’t rely on any extra classes to convert XML to objects.

Finally, if you have (repeating) web site content that you wish to convert to more structured content for downloading to a mobile application then you might like to try Dapper. You can also purchase a SLA should you wish to use Dapper for commercial purposes.

Speeding Up Builds

quadcore.jpgI seem spend a disproportionate amount of time waiting for builds – especially when I tend to be only updating one source file at a time. In my case it’s currently Carbide.c++ / S60 SDK builds but what I am about to say is probably equally as applicable to JAVA ME or other build environments.

I started thinking if it’s possible to speed up builds. Should I buy a new machine with dual (or even quad) processor? Should I get more memory (I only have 1Gb). Should I put the SDK or tools into ramdisk? Here’s what I found.

I began by looking at hardware based solutions such as HyperDrive4 hard drive and the PCI based GigaByte i-RAM. I came away with the conclusion that while they were obviously faster than normal hard drive, they are actually limited to a great extent by the SATA disk interface.

Next, my thoughts moved onto a software RAM disk and I found SuperSpeed RAMDisk. I learnt that it’s limited by Window’s (32 bit) max addressable memory of about 3.5Gb. However, that would have left me a reasonable 2Gb for SDK and Carbide and 1.5Gb for running the OS and apps.

Then I remembered that it’s often faster to compile/link (and also start the S60 emulator) once you have already done it once. At this point I looked at Windows File Cache performance and tuning  and the possibility of using CacheSet to optimise the cache size.

I did some tests while monitoring the Windows Performance cache copy read hits. This is the % of requests for files that result in a hit in the cache and hence no disk access. I compiled and linked a large project and afterwards started the emulator. After I had done this once, no matter how many times I re-built or started the emulator, I always got a very reasonable 95 to 99% caching of files.

Remember, I only have 1Gb of memory. So I started a few heavy apps such as Adobe Photoshop and repeated the test. I still got a high level of caching. I even tried loading eclipse with the Android SDK at the same time as Carbide and I continued to get a high level of caching.

So what did I conclude? First of all, Windows is very good at caching files. For Carbide.c++ and Symbian SDKs, 1Gb is more than enough memory to obtain the benefits of Windows File Caching even when you have other applications open. The hardware and software based RAM disks would have helped my ‘first time’ access to files but probably wouldn’t have helped much after that.

Next I looked at CPU (perhaps I should have looked at it first!) and noted that, while building, I am spending a considerable proportion of time near 100% cpu. While my machine isn’t state of the art, the latest machines would only provide low fractional increases in speed. So what about dual and quad core? These work by getting cores to simultaneously process different threads. Unfortunately, Carbide and the Symbian ABLD build mechanisms are synchronous (eg one thing compiled after the previous has completed) so I suspect there wouldn’t be many gains there. A dual core might help keep Carbide UI responsive (it’s in another thread) but that’s not what I need.

So, Carbide team, how about allowing support for multiple threaded builds? Also, I wonder if it would be possible to just do a link based on previously calculated dependencies? It’s often the case that I am changing just one file and I can manually just quickly compile that file (Ctrl Alt C). A build can take forever but the actual link is relatively painless – it’s the dependency checking that seems to kill the speed. I often know I can get away with just a new link without building anything else. I know I could link from the command line but I can’t be bothered with creating and more importantly maintaining the complex command line required. Surely, the Carbide.c++ IDE could do this for me?

Small Memory Software

softwareengineeringradio.gifThere’s a new interesting podcast on Small Memory Software at Software Engineering Radio…

"In this Episode we’re discussing patterns for small memory software with the authors of the like-named book by Charles Weir and James Noble. We look at various aspects of the small memory problem: How can you manage memory use across a whole system? What can you do when you have run out of primary storage? How can you fit a quart of data into a pint pot of memory? How can you reduce the memory needed for your data? How do you allocate memory to store your data structures?"

If you are interested in the book itself then you can view it free online at together with two unpublished chapters and the example source code.

By the way, while you are on the Software Engineering Radio site, you might also like to take a look at Episode 61: Internals of GCC.

Simple Directmedia Layer (SDL)

sdl.gifI recently commented on how Symbian libraries are starting to appear. SDL is a new Symbian multimedia library that provides low level access to audio, keyboard, 3D hardware via OpenGL and a 2D frame buffer.

SDL is particularly useful for cross platform development…

"SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. "

 SDL is great for writing platform independent games. In fact, Doom for S60 uses this library.

Carbide.c++ FAQ

carbide.gifNokia has a new useful Carbide.c++ FAQ on Nokia Forum.

The FAQ mentions that there’s special upgrade pricing (approximately half price) if you are moving from CodeWarrior.
Tip: What it doesn’t say is that this is only for recent CodeWarrior purchases – so if you have recently purchased (in the last 18 months) then get your upgrade while you still can.

Flash Lite Contest

adobe.gifThere are so many developer competitions on at the moment. As well as the high profile Android Challenge there’s also UIQ’s Open, BT’s Wi-Fi Challenge and Nokia’s Mobile Rules.

One you may not of heard of is the Adobe/Playyoo contest geared towards Flash Lite game developers.

Android First Thoughts

android.gifIn my previous post on the Google Handset Alliance I commented that Google have a large amount of work to do and that they have to catch up with Symbian and Microsoft in terms of OS capability, tools and documentation.

Now that the early look SDK has shipped I must say that I under-estimated how much Google has already done. (or was it mainly done by Android before Google acquired it?). Also, with the $10 million developer challenge and the active community (already forming teams for projects and Wikis) I now think what isn’t there, will soon be created.

Google has been very shrewd with the $10 million developer challenge. Although it seems a lot of money, it would only fund say 100 Google developers for a year. With the Challenge, it has many more developers developing for the platform.

When I think back to the early Microsoft Windows CE (Pegasus) and first Symbian SDKs, the Android SDK seems so easy to set up and use. No strange things to do to, for example, easy access the Internet via the underlying emulator host OS, few pre-install requirements, no post install fixes, few workarounds needed and no strange idioms.

It’s interesting that Google has chosen to create it’s own flavour of Java. I didn’t expect this because the existing Google Java apps are written in Java ME – why re-write them? As I mentioned previously, it turns out Android could also run a conventional Java ME VM so this may be less of an issue. It’s still not clear how Google’s VM will perform in multimedia (mobile TV?), games and real time applications.

I suspect all this about Java is a side issue anyway. Some people have already commented on the Android developers group that it’s possible to run compiled C/C++ on android. (although Google say you can’t). If the system really is open (or will be) then if you have a question ‘can it do xyz?’ then the answer will be ‘yes, do it yourself’.

The SDK documentation looks rushed in places (spelling mistakes, badly formatted pages and deprecated functions already) and there are holes in the functionality (no WiFi, localisation for example). However, the first look SDK is real ARM binaries actually running Linux and not just some limited emulated WINS UI thing that I expected. It should be enough to get Symbian and Microsoft thinking hard.

I would expect to see two classes of Android phone…

1. Open phones used by developers, early adopters and techie types. These might be produced by HTC or may even be existing ARM phones with new firmware. The functionality would only extend to that provided by the open source community.

2. Handset OEM phones with extra (licensed) commercial components and locked down to a greater extent.

I wouldn’t get too excited though. Most people I have spoken to think Android will just be another platform no more or less successful than Symbian or Windows Mobile.

Why would the mass market want to buy an Android phone? Why would a network operator sell an Android mobile phone over another? The phone may be 10% cheaper (estimate according to Google at Future of Mobile Conference) but I don’t see this as significant. The answer may lie in the Google engineering driven approach to everything. In one Google video I saw, the $10 million Developer Challenge is particularly looking for things that haven’t been done before. Maybe Google hopes new applications will cause people to want Android phones and, in turn, network operators to stock these phones.

Mobile Development Job Market

It’s strange when you get a week when you get a topic that keeps appearing again and again. This week it was the UK mobile job market. I have had one of my clients trying to find a Symbian developer, a colleague in the industry comparing industry rates, someone I used to work with looking for a Symbian developer and several agencies looking for people.

The overall impression I get is that there is a shortage of people. As an example, if you look at the Symbian careers web site there are more vacancies than I have time to count. I have heard from more than one source that the shortage isn’t just in mobile. The banks are heavily recruiting at the moment with very attractive rates and are even causing shortages in more common skills such as c++, .NET and Unix.

This doesn’t make much sense to me given that so much work is now performed offshore. I have even been told that some companies are now going offshore, not to save costs, but to find people with skills.