{"id":1525,"date":"2013-08-30T19:12:26","date_gmt":"2013-08-30T07:12:26","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=1525"},"modified":"2013-08-30T19:12:26","modified_gmt":"2013-08-30T07:12:26","slug":"rad-studio-in-auckland-android-in-a-vm-touchy-feely","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/1525\/","title":{"rendered":"RAD Studio in Auckland \/ Android in a VM \/ Touchy Feely"},"content":{"rendered":"[Estimated Reading Time: <\/span> 7<\/span> minutes]<\/span><\/span>

Well, not really RAD Studio as such, more like Mobile Studio (whether as part of RAD Studio Ent+ or the Mobile Add-On) since everything shown was oriented around the Android support and emphasising the fact that an application written for iOS can simply be recompiled and will run on Android. Or Windows or OS X, as before of course. About which nothing was said (or, to be fair, asked either).<\/p>\n

<\/p>\n

As such, there’s really not much to be said that hasn’t already been said in other World Tour Reports and that had not already been anticipated.<\/p>\n

The Android support works as expected and, as expected, from my perspective, it is an extremely pessimistic expectation that it works toward. Namely, there seems to be no appetite for attracting new users to Delphi.<\/p>\n

Some mention was made of “talking to universities” but frankly with the approach they have taken I do not think they will get anywhere with this. Universities are increasingly concerned with commercial relevance and FireMonkey simply isn’t going to score highly in that department.<\/p>\n

The emphasis seems to be “use what you know to do this new stuff<\/em>” and not as much “we believe we have a compelling story to tell to all mobile developers<\/em>“. Some numbers suggesting the advantage in reduced team sizes and development costs of using Delphi were thrown up on the slides at one point but at this stage any such numbers are entirely theoretical, given that there aren’t any established ISV’s using Delphi to support a range of mobile platforms with which to compare, like for like, with the established successful multi-platform development sites.<\/p>\n

The problem I see them having in taking their story beyond the borders of the existing Delphi user base is that once you scratch beneath the “one codebase” headline, the shortcomings and compromises are quickly exposed. <\/p>\n

Now, whether those matter<\/em> is a subjective question.<\/p>\n

My guess is that it will matter more to mobile developers, as distinct from Delphi developers looking to do a bit of mobile.<\/p>\n

Going Native<\/h3>\n

The word “native” was predictably ever present, sometimes attached to the word “code” and sometimes to the word “style”. But I am still not convinced. I think “native” is like what they say about “sex”. Anyone talking about it all the time usually isn’t doing it. \ud83d\ude42<\/p>\n

It can be argued both ways, but for my money Embarcadero’s interpretation of “native” doesn’t work for me. Yes it’s unmanaged code, which is what we tended to mean when we were comparing .NET vs Win32 on Windows for example. The problem being that “unmanaged” also happened to coincide with “native” on that platform. .NET was a runtime that sat – for the most part – on top of the OS. With the mobile platforms there really isn’t as much – if any – distinction between the managed runtimes and the platforms they support. They are, in a very real sense, the platform.<\/p>\n

On Android in particular, Java is the native environment<\/em> even though it involves a managed runtime (Dalvik). There is something that illustrates the distinction quite well I think. Consider this screenshot:<\/p>\n

\"Androidx86\"<\/a><\/p>\n

This shows a debug session of a simple Android application (the Oxygene Android Application<\/em> template in fact) and the Android VM (a Parallels Desktop<\/em> instance) that the application is running in.<\/p>\n

In the Visual Studio tool bar you will see “CrossBox: Local: 192.168.1.16:5555<\/strong>“. This indicates that the debugger is attached to the Android device (the VM) at that address. Essentially CrossBox is to Oxygene as PA Server is to Delphi.<\/p>\n

If I had a physical device connected then the device ID would be shown rather than an IP address. An IP address is involved here because I am debugging in a virtual machine. Not the Android emulator<\/em>, but another Parallels VM instance, running an installation of Android-X86. That’s Android running on an Intel X86 processor (albeit virtualised in this particular case).<\/p>\n

Obviously I cannot attach a USB cable between two VM’s, but fortunately the Android debugger is prepared for this. I simply need the IP address of the Android VM (obtainable from the Tablet Status info) and then run:<\/p>\n

\r\nadb connect <ip address><\/em><\/strong>\r\n<\/pre>\n
In a Windows command prompt.  At which point my Android VM is detected and presented as a debug target by Crossbox.  The Android machine that my application then runs on is a virtualised Intel x86 machine running my Android application.<\/p>\n
As far as I know, you cannot do this with a compiler that emits a Java stub that then bootstraps into native ARM code.  The Java stub will run but then fall flat on it’s face when it tries to run ARM instructions on an X86 processor.<\/p>\n
But I do not have XE5 – not even in beta – to actually try this.<\/p>\n
The Java, the Whole Java and Nothing But the Java<\/h3>\n
For those who for some reason still aren’t aware, you will also notice that the source code of this Android application is very much Pascal<\/strong>.  Not Java<\/em>.  The “for Java<\/em>” part of Oxygene Cooper refers to the fact that the compiler emits Java byte code out of its rear end, instead of X86 instructions and has nothing to do with the language.<\/p>\n
It also extends to the fact that the compiler is able to make use of other Java libraries directly.  No need for wrappers or other shenanigans to “get at” the underlying platform.<\/p>\n
Furthermore, there is no supplementary framework required to make this application run<\/strong>.   No mono.NET<\/strong> (as some people seem to think is required by Oxygene) or any other framework beyond that provided by the platform itself.<\/p>\n
It is an Android application pure and simple.<\/p>\n
Very simple in fact.<\/p>\n
“How simple ?” you ask …<\/p>\n
\"HelloAndroidSize\"<\/a><\/p>\n
48KB simple.  That’s<\/strong> how simple.<\/p>\n
We did not get shown how big a “Hello World” Android application is in Delphi, but with the need to drag along the FireMonkey platform, I doubt anyone would take a bet that it won’t be an order (or orders) of magnitude larger than 48KB.<\/p>\n
Touchy Feely Lookey Likey<\/h3>\n
One of the “5 mistakes to avoid” suggested for mobile developers was forgetting the user experience.  That is, if your app does not look and feel like an app that the user is used to, they likely will not want to use it.<\/p>\n
Your apps must look at home on their devices.<\/p>\n
And FireMonkey helps you do this right?  With all it’s pixel-perfect bitmap styles and what have you.  No?<\/p>\n
Well yes.  And no.  Consider the humble Tab Bar.<\/p>\n
A Tab Bar in a FireMonkey application will certainly change it’s appearance to suit either Android or iOS as appropriate, thanks to the different styles that can be applied.  But it won’t change it’s position.<\/p>\n
On iOS, the convention – and the user expectation – is that a Tab Bar is positioned at the bottom of the screen.  On Android, not only does the Tab Bar look different but it is positioned at the top<\/strong> of the screen.<\/p>\n
This is in fact the subject of a question on stack overflow<\/a>, posted by someone seemingly intent on breaking the rule of User Expectations (which also illustrates the difference between iOS and Android tab bars for those not familiar.<\/p>\n
With FireMonkey, if you want your application to reconfigure itself for the different platforms then you will have to either:<\/p>\n