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).
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.
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.
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.
The emphasis seems to be “use what you know to do this new stuff” and not as much “we believe we have a compelling story to tell to all mobile developers“. 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.
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.
Now, whether those matter is a subjective question.
My guess is that it will matter more to mobile developers, as distinct from Delphi developers looking to do a bit of mobile.
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. 🙂
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.
On Android in particular, Java is the native environment even though it involves a managed runtime (Dalvik). There is something that illustrates the distinction quite well I think. Consider this screenshot:
This shows a debug session of a simple Android application (the Oxygene Android Application template in fact) and the Android VM (a Parallels Desktop instance) that the application is running in.
In the Visual Studio tool bar you will see “CrossBox: Local: 192.168.1.16:5555“. 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.
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, 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).
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:
adb connect <ip address>
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.
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.
But I do not have XE5 – not even in beta – to actually try this.
The Java, the Whole Java and Nothing But the Java
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. Not Java. The “for Java” 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.
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.
Furthermore, there is no supplementary framework required to make this application run. No mono.NET (as some people seem to think is required by Oxygene) or any other framework beyond that provided by the platform itself.
It is an Android application pure and simple.
Very simple in fact.
“How simple ?” you ask …
48KB simple. That’s how simple.
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.
Touchy Feely Lookey Likey
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.
Your apps must look at home on their devices.
And FireMonkey helps you do this right? With all it’s pixel-perfect bitmap styles and what have you. No?
Well yes. And no. Consider the humble Tab Bar.
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.
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 of the screen.
This is in fact the subject of a question on stack overflow, 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.
With FireMonkey, if you want your application to reconfigure itself for the different platforms then you will have to either:
- Write code to manipulate your UI (or construct it) to reflect differences in the platforms at runtime
- Maintain different forms for each different platform
The same applies not just for different platforms but for different devices on the same platform. An application UI designed for an Android or iOS tablet will rarely simply scale down to a phone, or sometimes not even to a smaller tablet/phablet.
Each difference in layout, whether to reflect device or platform, will mean code to modify the layout or different forms. Unlike the form design infrastructure provided by the iOS and Android platforms, where the form layout is free of code and (largely) decoupled from your application behaviours, a form in Delphi and FireMonkey is full of code, even if only simple code to invoke more complex behaviours in business objects.
You may indeed have only “one codebase” from which to generate all your different versions of your application for different platforms and devices, but I suspect that (if you are to get a worthwhile result) you will end up writing a lot of code simply to manage the user interface and not at all related to the business of your app.
If, that is, you wish to do mobile properly.
It should be mentioned at this point that we were told that a brand new form designer is in the works for Delphi that will apparently address at least some of these issues, though how was not explained and neither was when mentioned (but the impression I got was that it is not something you can expect in XE5).
Finally on this note, it was mentioned that iOS 7 support will be offered “very quickly” by Embarcadero, once it is finalised by Apple. In current beta’s the look and feel is seemingly still being refined and each time there is an update there is a graphic designer in Embarcadero whose job it is to tweak the iOS styles for FireMonkey to reflect those changes.
Let’s think about that for a minute:
iOS 7 “support” is dependent upon… a graphic designer.
Meanwhile, if you are using Delphi for iOS you will already have an Apple iOS Developer subscription.
You will already be receiving – or able to obtain – iOS 7 beta SDKs.
Of course, you still need that Apple subscription even if you are using Xcode or even Oxygene but in both of those cases you can get cracking with creating iOS 7 applications, complete with the actual iOS 7 look and feel, as soon as you get the SDK’s from Apple (we’re up to beta 6 of iOS 7 already).
The Final Stage: Acceptance
It seems now unavoidably the case that Embarcadero are not concerned with securing the future of Delphi by attracting new users, or if they are then they have a very strange way of going about it which is doomed to fail. Which throws the longer term future of Delphi into serious doubt imho, irrespective of the technical merits – or otherwise – or quality of the delivery.
We used to joke that Delphi was the new COBOL.
Sadly, we don’t joke about it any more.