There are several reasons why we feel that the Android platform is going to win over the competition – and as long as Google don’t mess it up, it will clean house.

Now, before anyone starts thinking that this is a fanboy gush post with a heavy bias or that this is a bash against Windows or Apple, be aware that we’ve been evaluating many different devices, including the iPhone and iPad as well as the Android offerings. They are all great products – but we’ve found that there are a few things which hold them back.

Note that We already develop for windows and can see no future in it in its current state. (It’s WinMo 6.5 for a while folks – from the horses mouth)

Against the iPad and the iPhone.

No 1. The App Store.

Everything has to go through the app store. In most cases, this is fine. It keeps the platform safe and free from malicious applications because everything is vetted. For a personal application developer, there are good and bad aspects to this. We could spend many hours arguing the finer points of having a single entity being the market and the police and the potential for corruption which comes with this absolute power… but we won’t

We could also spend many hours arguing about how the openness of the Google Market place could result in a glut of poor quality or malicious apps trying to take your stuff…  we’re not going to do that either.

For a business application user, there are important issues which neither the Apple App Store or the Google Market address and that is the commercial advantage that can be gained by using bespoke or niche tools.

By placing an application in the App store or the Market place, anyone can download it. It sits in amongst the chaff of the countless other apps and has to be searched for – opening up the chance that the user will install the wrong app or an imposter. This is not what you want.

The solution is to allow a user to download the application from an additional source – say, a vendor’s web-site.

This is only possible with Android or Windows as Apple wants to (and does) control the whole process. Like I said, great for the private user but bad for the business application user.

No 2. Device Range and suitibility

Unfortunately, as beautiful as Apple’s devices are, they are really only intended for the personal user. They are the cool gadget, the executive toy. They offer plenty of features, but they wouldn’t last 5 minutes on a shop floor, in a mail room or a warehouse. They’re just not robust enough. If you could guarantee that the person issued with the iPhone or iPad was going to treat it with kid gloves then maybe it would be viable. But everyone knows that Murphy’s law dictates that this won’t happen and the device Will become damaged. Apple devices are expensive so the business owner really needs to weigh up the pros and cons of using such a device in such a dangerous environment.

Android devices are not subject to the Apple blueprint. Sure, the Android Cell phones and Tablets are generally as vulnerable to dropping and scratching as their Apple counterparts – but there is a big difference between the 2 platforms. Openness; and it’s this Openness that makes Android such a powerful potential business tool. Rugged Android devices are already in the market place with capabilities far beyond what Apple can offer.

Devices like the Bluebird Pidion and the Casio G’zOne Commando are just the vanguard which will be followed by many more ruggedized devices as the business world catches on.

No 3. Developer Support

Unfortunately, Apple chose to leverage their Objective-C language – a great language to be sure but as it’s only used within the Apple family of products, it has limited appeal. Apple also actively excluded any other means of development. This effectively killed any chance of third parties developing platforms to cross the platform divide. So there are no Adobe Air applications running on Apple devices, No Flash and no Java means that developers are back in the bad old days. Writing for multiple platforms using different languages with no possibility of shared code libraries. On top of this, to write in Objective-C, you need X-Code – Apple’s own IDE.

Business Application developers are generally not going to waste time learning a new IDE and a new flavor of C just to write software which will be usable by a small section of their customer base.

The same point could be argued against Android in a way. The vast majority of business developers use C# on the .net framework. For mobile devices, this means the Compact Framework and Windows Mobile 6.x (or 7 for phone app developers). These developers have an investment in time and tools on the .net framework. Windows Mobile 7 is not going to be released for rugged business devices however – so it’s 6.5 or nothing at the moment for .net.

However, Windows Mobile is old. It’s not pretty to look at and has been left behind in terms of providing a rich user experience.

If Apple has done anything in this last few years, it’s that it’s kick-started a revolution for the better in application user interface design. Something that Google really took to heart with Android. Both iOS and Android offer silky smooth experiences which leave their poor cousin looking old and haggard in comparison. Because of this, users have now come to expect their apps to look crisp, nice and feel responsive.

The change is as significant as that from DOS to Windows.

There’s also the matter of the tools. To develop for Windows, you need to purchase a flavor of Visual Studio – you can get away with using Sharp Develop sure, but in our experience, it leaves a lot to be desired for mobile app development. To develop for iOS, there’s the aforementioned X-Code requirement – Which is free but needs a Mac to run.

Android Applications can be developed using Eclipse or Netbeans. The SDK is free and available to anyone. It has a rich set of tools including a device emulator. Java is very similar to C# in many ways and the internet is filled to the brim with Java coding examples.

Finally

The mobile development world is crying out for decent cross platform tools. It seem inconceivable to me that after all these years, we’re still sitting in different camps. We should instead be leveraging these new great tools and shaping the business world by offering tools that employees actually want to use. But that’s not the fault of the application developers. You can blame political wrangling at various companies for that.

So to write applications for every device, we would have three code-bases… that’s not going to happen now is it?

So when you strip out all of the vanity,  hype, the marketing and boil things down to the actual facts – the points that really matter, there is a platform which ticks more boxes than the others.

It’s not iOS and it’s not Windows.

Well, mostly anyway.

The wonderful world of Java applets is a funny old world. One of pitfalls and woe on one side and unparalleled power on the other.

Java has been around for a while and has a very substantial support base, which comes in handy when trying to get around some of the more annoying problems associated with Java development, well Applet development anyway. It runs on pretty much anything, part of it’s charm is that you don’t need to run on a Microsoft platform unlike .net

One of the best things is that as a language, it’s free and there are many free IDEs out there to help you to develop. One of the best I’ve seen so far is NetBeans v6.5 – An IDE originally written by Sun Micro systems, made open source whilst being heavily sponsored by Sun. It’s completely free, Cross platform and downloadable from the their site www.netbeans.org
Without wanting to spend too much time singing the praises of NetBeans, I have to mention that it’s PHP editing tools are pretty fine too and when coupled with the correct version of xdebug for your PHP runtime, make for a very powerful PHP development platform indeed.

We found a couple of minor issues which were noteworthy when developing Java Applets.

One of them being that the HTML standard has kind-of left Applets behind, deprecating the Applet tag for the more generic Object tag. Not a big problem, but slightly annoying and important if your web site is to be XHTML compliant.

We had a simple task to solve for our client:

Print PDF documents on a cross browser web page, without user intervention.

The task in itself doesn’t sound too bad. PDFs are a well known standard for documents and there are numerous browser plug-ins we can use. The tricky part is the “Without user intervention” bit.

That suddenly throws all of the spanners into the machine, leaving a poor engineer with the task of putting it all back together again.. only this time making it spanner proof.
Browsers are very protective of the printer. You can’t access it directly. Sure, you can print a web page, but you can’t bypass the all-seeing eye of the Printer Dialog.

Because of this, numerous ActiveX components have been developed and are sold to get around this issue for web applications. The thing is, ActiveX is a Microsoft Only technology, for Windows and Internet Explorer. That goes against the Cross Platform, Cross Browser requirement.

Java to the Rescue… mostly

So we had to set about printing from the browser. Thankfully, Java does have the capability to talk to the printer directly. The only downside being that it keeps asking for permission to do so, rather like an over-polite child constantly asking to use the bathroom.. The temptation to lose all patience and say “Yes, for the 1000th time, just use the bathroom if you need it OK?” – which would be bad.

There is a way to instruct the Java runtime that it’s OK for it to use the bathroom.. I mean, Printer. You can modify the java.policy file in your runtime directory/lib/security folder to grant permissions to use the printer. A cheap and nasty solution in more than one way.

First of all, it meant having to modify the file on the machines of each user using the web application to grant access to the printer and secondly (and possibly more importantly) Every time you upgrade your Java runtime, it keeps a copy of the old one and installs the new one in a fresh directory.
This means that you have to re-apply your cheap hack to the new runtime, whenever your users upgrade their Java.. Support Nightmare!

Thankfully, there was a solution.
First of all.. Sign the Applet. You can self sign your applets but we chose to buy a certificate and sign it that way. It looks much better with a certificate from a trusted Certificate Authority, and they’re not expensive.

A signed applet is a trusted applet (assuming the user says ‘Yes’, they trust your applet) and has access to things like Printing and Files etc. Things a normal applet just doesn’t have (without above hack).

But we were still running into problems. The over-polite child.. I mean, Java.. was still asking to use the printer, each and every time we initialized the applet and tried to print. Even though we’d checked the little box which was supposed to remember our selection. I’m not sure if this is a bug in the runtime or not, but that’s another thing entirely.

Odd permissions issue – The day Logic took the day off
It turns out that the reason it kept asking, even with a signed applet was that the code being called to talk to the printer was being accessed from Javascript on the web page, and was therefore un-trusted. I’m unsure of the logic here, what was going through the minds of the Java Runtime developers.. a trusted applet should be a trusted applet irrespective of what is calling it, but it is what it is.

The way around that was to make sure that the Javascript was not directly accessing the printing method.

This was done using a separate thread, sitting waiting for a variable to be set.
The public method accessed by the Javascript then only set a variable along with the printing details.
The printing thread then picks this information up and prints the document. No problems.

Are we nearly there yet?
Another issue was telling when the applet was loaded so that we could call it’s methods from the site. This turned out to be more problematic than we originally thought. The isActive method didn’t always work and we had to resort to getting the Applet to call a Javascript method on the page (if it existed) to inform the page that it was ready.

..and Finally

Now, figuring that all out took more time than writing the entire applet and if this was a few years ago, If google didn’t have access to forum threads where other people had solved these same problems, it would have taken a lot longer. In some ways, I can see why the .net framework has overtaken Java as the development platform of choice for business. It’s certainly easier to get up and running faster with .net but .net can’t do everything and Java shouldn’t be dismissed as old hat.

It’s very powerful, fast, cross-platform, cross-browser and free. These factors alone make it a language worth using.