Fair Comparisons

[Estimated Reading Time: 5 minutes]

There is an old saying about comparing “apples and apples” or more accurately in this case, “Androids and Androids”. A commenter has already pointed out that an Embarcadero blog post referencing the “effort” described by my series of posts demonstrating how to build a camera app for Android using Oxygene was not a fair comparison.

Despite having specifically drawn attention to the amount of code involved, the author of the post is now claiming that the focus of his post was not actually the focus of his post.

In that post, to demonstrate what was not his point and not intending to show how little code was needed to achieve what he implied was the same thing using the FireMonkey runtime, he pointed to one of the tutorials included with XE5.

Unfortunately in his rush to sell the benefits of FireMonkey, he missed a key difference and neglected to mention a key fact.

Vive La Difference

The difference he missed was that so far in my series I have not actually reached the point where we take a picture with the camera.

“AHA!” goes up the cry. “Then it’s even worse with Oxygene! You have done all that work and haven’t even got as far as taking the picture! This shows the superior productivity of FireMonkey, confirming David’s point, surely ?”

Not so fast. There are a few things missing in that tutorial he cites.

One thing it does not demonstrate and what David did not mention, is how to configure a FireMonkey application to indicate dependency on the presence of a camera. Or how to state the permissions required by such an application (access to the camera and the ability to write to device storage – if you wish to save the image).

Those are the things covered in Part 1 of my tutorial. It is important not to confuse the amount of detail in the coverage with the amount of effort involved.

The building of the UI was similarly almost incidental and no more arduous to craft in XML in my view than dropping a bunch of components and then navigating your way through a bunch of properties and dialogs to set them up. Code Completion won’t help you find the right property to set. It will help you write the correct XML.

I strongly suspect that creating the XML was actually quicker, and I say that as someone who believes that XML is proof that there is a God since the Devil – and thus XML – would not otherwise exist! 😉

Admittedly, a text editor is not as pretty as a cosmetically skinned form designer. But I thought the point here was productivity, not a beauty contest.

Fit and Finish

And of course, the tutorial completely ignores the question of ensuring your UI “fits” the expectations of the users on different platforms (or indeed on different sized devices on the same platform). It assumesyou will simply use the identical UI on all platforms.

The native platform tools provide explicit support for this which FireMonkey cannot take advantage of and (as yet at least) provides no equivalent. You will need separate forms for different layouts with at least some duplication of code. But hey, it’s still “one codebase”, nobody said it would be a maintainable codebase. 😉

I guess we are just ignoring such niceties as making sure our apps look and feel right for each platform, even though it’s one of the “Top 5 Mistakes” to avoid, at least, according to a presentation I saw recently. 😉

Of course, multi-platform issues are not addressed in my series of articles because I’m not writing a multi-platform application and not claiming to do so. But if you are going to claim that an approach solves this problem in addition to others then this really needs to be substantiated if not demonstrated.

The Missing View

So moving on from UI issues, Part 2 of the series was about code, but it didn’t represent any “work” at all. It was a discussion piece, exploring one of the advanced language features in Oxygene that makes working so directly and closely with the Java Android SDK such a delight in comparison to using Java.

Part 3 did involve a bit of work, though really not very much. In terms of code, establishing the live viewfinder functionality was trivial. The bulk of the effort went into ensuring that the viewfinder image was oriented correctly with respect to the physical device orientation and even that was primarily some trivial math. This seems to be an issue which caused some confusion for Tim DelChiaro when capturing images during his own demonstration of building a camera app using XE2. Or perhaps that was just a bug in FireMonkey at the time ? Either way, perhaps he would have realised what was going on if he had been working more directly with the platform API’s, rather than at arms length using the FireMonkey waldo ?

But of more relevance – and significance – is that the tutorial David I references does not include any form of live viewfinder support at all. There is a button for taking a picture but as far as I can tell, you do not see what you are getting until you press that button.

Fair’s fair. Let’s see what’s involved in achieving a live camera preview – correctly oriented – in FireMonkey before we start knocking the alternative as “less productive”, shall we ?

Maybe it is easier and more straightforward, but I don’t think we can just take it as a given.

Of course that wasn’t the author’s only point. There was another point dropped in as a final sentence of a paragraph dominated by the amount of code involved. This final sentence apparently was the main point.

That this same app would work, as is, unaltered, with just a simple recompilation required, on both iOS and Android.

Which may even be true. As long as you are just doing a demo, ignoring getting your platform specific settings right and aren’t concerned with ensuring a platform-correct look and feel.

But apart from that extra work to take into account there is no extra work to take into account. 😉

Develop Applications Quickly! Working Ones? Oh

A comment has subsequently appeared on David I’s own post from what appears to be a quite frustrated developer that seems to have been involved in the beta program. The commenter complains that a known issue that prevents access to the camera on some Android devices still does not appear to have been resolved.

I hope this commenter does not get into trouble for what looks like a violation of the beta NDA. It wouldn’t really be fair now that the state of FireMonkey is out from behind the cover of the beta.

Is this one of the known issues that some people have suggested were ignored in the rush to get a product released ? It’s certainly just one of a number of quite painful bugs that still plague the FireMonkey runtime framework.

I don’t have time to compile links and list them all, but this search of Google+ throws up some of them.

One particularly nasty one does deserve special mention I think: a catastrophic texture memory leak.

In case anyone gets the wrong idea, this is not to say that Oxygene is a pristine example of bug free software nirvana. I already posted about my experiences in that regard.

How long will people have to wait for their first FireMonkey hot-fix I wonder ? Never mind hot-fixes or updates, in some cases people have been waiting for some of those bugs to be fixed for not just one version but two or more.

In any event, I do not quite think it fair to mock a solution based on an alternative technology which works with a less capable one which – even as simple as it is – does not appear to work consistently or reliably on even the subset of devices that are supported.

It seems to me that it doesn’t much matter how quickly you can write an app if you can’t be sure it’s going to even work.